Clarification on Configuring Karpenter with Security Groups for Pods to Reflect the Real MaxPods Count #2607
Unanswered
3issa13480
asked this question in
Q&A
Replies: 0 comments
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.
-
Hi,
According to the Karpenter documentation, when using Security Groups for Pods, it is recommended to reserve one ENI for the trunk interface by setting RESERVED_ENIS=1. This is meant to avoid discrepancies between the calculated maxPods and the node’s actual pod capacity.
However, when we reserve one ENI, the resulting maxPods calculation no longer seems to reflect the real number of pods that can be scheduled. This is because pods attached to branch ENIs (created by the VPC Resource Controller when Security Groups for Pods are enabled) are not considered in the standard maxPods formula, which only accounts for primary and secondary IPs on traditional ENIs.
In practice, this causes Karpenter to underestimate the node’s true pod capacity — especially for instance types where a single trunk ENI can support multiple branch ENIs and, therefore, a larger number of pods.
Could you please clarify:
How Karpenter should be configured (or patched) so that the maxPods calculation accurately reflects the additional pod capacity provided by branch interfaces?
This clarification would help ensure consistent pod scheduling and prevent nodes from being underutilized.
Thank you for your assistance,
Beta Was this translation helpful? Give feedback.
All reactions