Skip to content

The max pods bootstrap logic is incorrect especially when prefixes are used #782

@stevehipwell

Description

@stevehipwell

What happened:
When bootstrapping a new node, the memory reservation calculation uses the values in /etc/eks/eni-max-pods.txt without any option to customize this for the new prefix mode.

This behaviour has always been wrong as there is the USE_MAX_PODS variable to disable using the values in /etc/eks/eni-max-pods.txt as the node max pod limit but which has no effect on the memory reservation. With the prefix logic the current behaviour isn't even close enough to be safe; e.g. a m5.large instance couldn't have more than 29 pods without prefixes so a custom max limit would be lower, with prefixes the recommended max pods would be 110 so required reserves would need to be significantly higher and this logic would be well off.

What you expected to happen:
The memory reservation should respect the USE_MAX_PODS variable. A new variable should be added with a new lookup file to support prefix mode. I'd suggest MAX_PODS_MODE and defaulting to eni with prefix being an option. it would be even better if MAX_PODS could be added to support custom max pods with the correct resource requests.

How to reproduce it (as minimally and precisely as possible):
n/a

Anything else we need to know?:
I'd be happy to open a PR to fix this if it would actually be reviewed.

Environment:
n/a

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions