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
CNI: improve plugin chaining #24956
CNI: improve plugin chaining #24956
Conversation
fyi @sofat1989, do you want to see if this covers your use case? |
70f051a
to
59276bf
Compare
as far as I can tell, the test failure isn't caused by this PR: the pod's CNI plugin execution returned without any issues, meaning that nothing this PR touched failed. Unfortunately there's not enough information to debug; #24982 will improve that situation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CLI related changed LGTM. I'll read through to see if I have any other comments, and leave reviews of other portions to the related codeowners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vendor changes lgtm
59276bf
to
edd77e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Helm changes LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nits for typos and clarity, otherwise LGTM 👍
Approved preemptively with the understanding that changes must happen prior to merge.
edd77e9
to
dad6331
Compare
/test Job 'Cilium-PR-K8s-1.27-kernel-net-next' failed: Click to show.Test Name
Failure Output
Jenkins URL: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.27-kernel-net-next/108/ If it is a flake and a GitHub issue doesn't already exist to track it, comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a couple of nits.
Just some capitalized errors that were annoying the linter. Signed-off-by: Casey Callendrello <cdc@isovalent.com>
We determined exactly how to chain by reading the CNI network name. This is fragile, and means that end-users can't easily configure chaining for their own networks. This keeps the existing logic but adds an explicit chaining-mode field in the CNI configuration. Additionally: remove the "portmap" plugin, since all it did was signify that the network "portmap" was the same as "cilium". There are cleaner ways to handle that. Signed-off-by: Casey Callendrello <cdc@isovalent.com>
Signed-off-by: Casey Callendrello <cdc@isovalent.com>
People would like to automatically inject Cilium in to CNI configuration files. Add an option to the daemon that watches for networks of a given name and injects Cilium into it. We already supported this in a limited sense with aws-cni, but let's generalize it to support arbitrary CNI networks. Signed-off-by: Casey Callendrello <cdc@isovalent.com>
Add the option to set a CNI chaining target explicitly. Also, clean up some of the defaulting around cni chaining mode. Signed-off-by: Casey Callendrello <cdc@isovalent.com>
There was a logic error when handling an unset chaining mode. Signed-off-by: Casey Callendrello <cdc@isovalent.com>
dad6331
to
0f75ecd
Compare
/test |
The Cilium agent already supports a mode where it waits for a certain CNI network to exist, then injects itself as a chained plugin, and writes a new file. However, this was only only supported for AWS. Instead, let's make this functionality generic.
This PR makes these changes:
The end result is a cleaner setup for end-users who would like to chain Cilium.
Fixes: #22286
Inspired-by: #22358