[EKS] [request]: Pack IPs more efficiently when using Prefix Delegation
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
I would like an option that allows repacking of pods into more efficient CIDR ranges when using prefix delegation on AWS CNI.
**Which service(s) is this request for?**
EKS
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
I see this scenario often:
I run AWS CNI with prefix delegation:
- IP range with 16 IPs assigned to the node
- The 17th pod is scheduled, so an additional range is assigned (ignoring warm prefix, the logic works with and without)
- Some of the original pods are descheduled
- The node is left with say, 10 pods and two CIDRs assigned to it, using up 32 IPs
I’d like the AWS CNI to be able to deschedule pods that are inefficiently packing. In it's current form we are having to assign a lot of overhead of IP space to deal with heavy churn.
**Are you currently working around this issue?**
As above, we just assign extra IP space, and use bigger nodes so there is less likely of the above happening.
**Additional context**
This is on IPv4. Another possible solution to this would be to be able to change the CIDR range assigned to nodes.
Contributor guide
Research direction
Start by reviewing the AWS CNI prefix delegation behavior described in the issue, including the 16-IP and two-CIDR churn scenario. Define how more efficient pod packing or changing the CIDR assigned to a node would work for IPv4 on EKS, and consider what observable behavior would confirm the request is complete; no files or tests are identified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes
- Domain
- cloud, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100