Add cni-plugins init container to calico-node DaemonSet#4819
Open
caseydavenport wants to merge 5 commits into
Open
Add cni-plugins init container to calico-node DaemonSet#4819caseydavenport wants to merge 5 commits into
caseydavenport wants to merge 5 commits into
Conversation
Calico no longer ships the upstream CNI plugin binaries baked into the combined image. Pair the new calico/cni-plugins image (from projectcalico/calico) with an init container ahead of install-cni that copies the binaries into a shared emptyDir mounted at /opt/cni/bin on install-cni. The install code's existing /opt/cni/bin walk picks them up unchanged. - pkg/components: add ComponentCalicoCNIPlugins and ComponentTigeraCNIPlugins, wire them through the version templates and config files. - pkg/render/node.go: resolve the cni-plugins image based on variant, add the cni-plugins-stage emptyDir volume, render the cni-plugins init container ordered before install-cni, and mount the staging volume at /opt/cni/bin on install-cni. - pkg/render/node_test.go: cover the new init container, mount, ordering, and OSS / Enterprise image selection.
Adds Installation.Spec.CNI.InstallMode with values All (default) and CalicoOnly. CalicoOnly skips the cni-plugins init container, the shared emptyDir, and the install-cni /opt/cni/bin mount, leaving only Calico's own binaries to be installed. For environments where the host already provides the upstream plugins (kind, certain managed node images), avoiding the extra image pull + init step is the right call. Also adds cni-plugins to the CalicoNodeDaemonSetInitContainer name enum so users can set resource overrides on the new container.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pair with the new `calico/cni-plugins` image from projectcalico/calico (calico#12794). After the mono-image consolidation, `calico/calico` no longer ships the upstream CNI plugin binaries baked into `/opt/cni/bin`. On platforms that don't pre-populate the host CNI bin dir, `install-cni` finds nothing to copy and pods depending on `host-local`, `portmap`, `loopback`, `tuning`, or `flannel` break.
This change adds a `cni-plugins` init container ahead of `install-cni` that runs the new image. Both share a `cni-plugins-stage` emptyDir; the cni-plugins entrypoint copies the binaries into it, and install-cni mounts the same emptyDir at `/opt/cni/bin` so its existing walk picks them up unchanged. No change to install-cni's behavior.
Description
Depends on the calico PR landing and producing a dev tag of `calico/cni-plugins` (and `tigera/cni-plugins` for enterprise). Until then, image pulls for the init container will fail.
```release-note
NONE
```