[EKS] [request]: Support Cilium as CNI for hosted EKS
- 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
Currently, Cilium requires chaining or removing the aws-node daemonset and restarting all pods that were created with old CNI.
EKS Anywhere now uses Cilium as the CNI by default.
It would be great if new clusters could be provisioned with an optional configuration option to use Cilium, or if Cilium were provided as a managed add-on with a documented/automated migration process.
Contributor guide
Research direction
Start by reviewing how hosted EKS clusters provision the aws-node daemonset and how CNI choices are configured. Compare the requested alternatives: an optional Cilium configuration versus a managed add-on with documented or automated migration. Done would mean a defined implementation path that supports new clusters and addresses existing pods and CNI migration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes
- Domain
- cloud, infrastructure, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100