Replies: 1 comment
-
Jumped the gun a bit. Found out EKS managed node groups do the correct max-pods calculation based on CNI config during creation. https://aws.amazon.com/blogs/containers/amazon-vpc-cni-increases-pods-per-node-limits/ Our cluster that 'magically' calculated max-pods correctly had a managed node group, so all was well. For our self-managed node groups, it appears we still need to leverage the bootstrap container method to dynamically calculate max-pods. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello - We've been trying to solve an issue with the max-pods value on bottlerocket nodes not taking into account the use of CNI custom networking (which reduces the available ENIs by 1). The solution we've leveraged is calculating max-pods in a bootstrap container.
We just noticed that an EKS cluster (K8s 1.27 and ami-0b312c9ed12d199b0) that is using CNI custom networking appears to be calculating the correct max pods by default (without the bootstrap container).
Has there been a change that allows for bottlerocket to know that CNI customer networking is in use and to calculate max-pods appropriately?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions