-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] availabilityZones setting not being respected for managedNodeGroups #8208
Comments
Hmm, looking at this a bit more, my zone-specific workload is actually being scheduled on a node in my managed group that did land in the correct zone, so maybe there's something else going on here... I'll continue debugging. But is it expected for the launch template AZs to not match those requested at managedNodeGroup creation time? The relevant event from
(specifically the bit about |
I came across this example recently and it sounds similar to your setup - can you try adding the zones similar to this example to see if that resolves your issue
|
@bryantbiggs Interesting, that looked insanely promising but unfortunately the problem still remains after creating a new nodegroup with that in place... 😢 HOWEVER, that got me started down a path which serendipitously led me to this SO answer for the error message I was having... It turns out that my problem was simply not having installed the I added the following to my cluster config: addons:
# eks-pod-identity-agent is required for
# `useDefaultPodIdentityAssociations` support, which is needed for
# aws-ebs-csi-driver
- name: eks-pod-identity-agent
# aws-ebs-csi-driver is needed in order to get the latest EKS-supported
# storage classes (like gp3 EBS).
- name: aws-ebs-csi-driver
useDefaultPodIdentityAssociations: true and now I'm cooking! It looks like gp2 might be supported out of the box with Kubernetes' in-tree storage drivers, but gp3 needs the I really appreciate you taking the time to look at this. |
What were you trying to accomplish?
Trying to create a managed node group which is restricted to a single availability zone within my cluster's region.
What happened?
The resulting launch template has an empty availability zone field (screenshot below), meaning instances can be launched into any AZ in the region. Since I have zone-specific EBS volumes for some of my pods, those pods are unable to be scheduled on nodes in the managed nodegroup that don't happen to land in the correct region, resulting in a bunch of cluster-autoscaler scale-ups while the scheduler tries over and over again to find a suitable node.
I need to be able to restrict the AZ for the nodegroup so that zone-specific workloads can be scheduled reliably.
How to reproduce it?
Create a new cluster with no nodegroups, like so:
cluster-config.yaml:
And create a nodegroup from a separate config file:
nodegroup-on-demand.yaml:
The launch template for the resulting nodegroup does not have the expected AZ restriction:
Logs
nodegroup create logs
Anything else we need to know?
Host OS: Arch Linux, using a downloaded (not self-built)
eksctl
, default AWS credentials profile.Versions
The text was updated successfully, but these errors were encountered: