autoscaler
autoscaler copied to clipboard
kubernetes
Scaling up EKS Managed Node Group using Windows nodes
Which component are you using?:
cluster-autoscaler
What version of the component are you using?: 1.29.0
What k8s version are you using (kubectl version)?:
1.29
What environment is this in?: AWS EKS
What did you expect to happen?:
When I schedule a pod with nodeSelector=kubernetes.io/os: windows on a Windows-based EKS Managed Node Group that's currently running at 0 nodes, I expect cluster autoscaler to scale up the node group from zero.
What happened instead?: Cluster autoscaler didn't scale up the node group from zero. Logs indicate that the nodegroup doesn't match the nodeselector.
My hunch: Cluster Autoscaler doesn't know that EKS Managed Node Group will inject the kubernetes.io/os=windows node label because it's not part of the DescribeNodeGroup response that's being used to feed the cache.
How to reproduce it (as minimally and precisely as possible):
- Create a Managed Node Group in EKS using a Windows AMI type (e.g.
WINDOWS_CORE_2022_x86_64) with a min count of0. - Make sure no nodes are running in that group yet.
- Schedule a pod with:
nodeSelector:
kubernetes.io/os: windows
- See cluster autoscaler not starting a new node
Anything else we need to know?:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
