Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support using custom CNI #5217

Closed
jiayiwang7 opened this issue Mar 9, 2023 · 4 comments · Fixed by #5262
Closed

Support using custom CNI #5217

jiayiwang7 opened this issue Mar 9, 2023 · 4 comments · Fixed by #5262
Assignees
Milestone

Comments

@jiayiwang7
Copy link
Member

jiayiwang7 commented Mar 9, 2023

Sometimes user needs to use its own preferred CNI solution instead of EKS-A Cilium. It would be ideal if EKS-A can provide the possibility to swap out the default CNI with custom one, and EKS-A shall not revert the CNI changes made by the user during CLI upgrade / controller reconciliation.

In terms of solution, there are 2 routes we can go:

  1. add a CustomCNI field in ClusterNetwork where we apply the CNI manifests user input during create/upgrade workflow.
  2. add a UserManaged field in ClusterNetwork indicating user is managing its own CNI. During cluster creation, we still install the default EKS-A Cilium CNI to guarantee the successful provision of the cluster. After the cluster is running, user can update the ClusterNetwork with UserManaged true, manually delete the default EKS-A Cilium CNI and install custom CNI. Whenever the UserManaged flag is presented, the EKS-A CLI upgrade and EKS-A controller will skip updating/applying Cilium components.

We shall go with option 2 first, as option 1 is hard to validate and test given all the open options that exposes to the user. Also different CNI needs to be installed in various way, some of which cannot be set up properly with single manifest apply. The workflow to support it can be less trivial.

@Cajga
Copy link
Contributor

Cajga commented Apr 11, 2023

Hi @jiayiwang7, @chrisdoherty4,

Thanks a lot for working on this feature. We were really happy when we saw this listed in the release notes.

We just want to cross check: did all the necessary commits made it to the v.0.15.0 release?

If we check the list the commits since the last release (v.0.15.1) there seems to be still some commits related to this change:

Also note: these PR-s have still the milestone set to v0.15.0...

@chrisdoherty4
Copy link
Contributor

Hi @Cajga. I've been out the last few weeks so hadn't seen your message. I'll get back to you soon.

@chrisdoherty4
Copy link
Contributor

@Cajga, the commits were squashed into a single commit as seen in https://github.com/aws/eks-anywhere/pull/5366/commits, or cherry-picked so you won't see the commits from main.

We'll reflect on our process to make identifying commits in release branches easier in the future.

@Cajga
Copy link
Contributor

Cajga commented Apr 27, 2023

Hi @chrisdoherty4 ,

Thanks for confirming it.

I was trying to figure it out myself but was not 100% sure what was happening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants