capi: install CNI plugins from upstream tarballs by default by MaxRink · Pull Request #2098 · kubernetes-sigs/image-builder

MaxRink · 2026-07-05T21:11:34Z

Change description

Switch the default CNI plugin install path from Kubernetes kubernetes-cni packages to upstream containernetworking/plugins release tarballs.

The package-based Kubernetes paths still install kubelet, kubeadm, and kubectl from distro packages, but CNI plugins now use the existing HTTP/tarball source by default. The CNI tarball tasks are split out from the Kubernetes binary URL tasks so they can be used with package-based Kubernetes installs. The legacy kubernetes_cni_source_type=pkg path still installs the kubernetes-cni package when explicitly selected.

Is this change including a new Provider or a new OS? (y/n) n
If yes, has the Provider/OS matrix been updated in the readme? (y/n) n/a
If adding a new provider, are you a representative of that provider? (y/n) n/a

Related issues

Fixes Ensure image-builder continues to work once kubernetes-cni is discontinued #1861

Notes

kubernetes_cni_semver is updated to v1.9.1, which matches the current containernetworking/plugins release and the Kubernetes release-1.36 CNI package metadata. The old v1.2.0 value was only the lower-bound dependency declared by kubelet, not the effective package version installed from recent pkgs.k8s.io minor repositories.

Effective kubernetes-cni package versions from the current minor repositories:

Kubernetes minor	DEB package	RPM package	kubelet constraint
v1.32	1.6.0-1.1	1.6.0	>= 1.2.0
v1.33	1.6.0-1.1	1.6.0	>= 1.2.0
v1.34	1.7.1-1.1	1.7.1	>= 1.2.0
v1.35	1.8.0-1.1	1.8.0	>= 1.2.0
v1.36	1.9.1-1.1	1.9.1	>= 1.2.0

Validation run locally:

ansible-lint --profile min images/capi/ansible/roles/kubernetes
python3 -m py_compile images/capi/hack/generate-goss-specs.py
python3 images/capi/hack/generate-goss-specs.py --provider amazon --os ubuntu --dry-run
JSON/YAML parsing for touched config, Ansible task files, and rendered Goss specs
Rendered Goss for kubernetes_cni_source_type=http and verified the generated checks assert executable CNI plugin binaries plus the active /opt/cni/bin/host-device version
Rendered Goss for kubernetes_cni_source_type=pkg and verified the generated checks assert the kubernetes-cni package, executable CNI plugin binaries, and package ownership of the installed plugin binaries
make -C images/capi validate-qemu-ubuntu-2404 PACKER_FLAGS=-syntax-only
make -C images/capi validate-qemu-ubuntu-2404 PACKER_FLAGS="-syntax-only --var 'kubernetes_cni_source_type=pkg'"
packer validate -syntax-only for qemu Ubuntu 24.04, qemu Flatcar, and Proxmox Ubuntu 24.04 templates with the common node var files
Verified containernetworking/plugins has v1.9.1 tarballs and checksums for linux-amd64 and linux-arm64
Checked current pkgs.k8s.io DEB/RPM metadata for v1.32 through v1.36 Kubernetes minor repositories

kubernetes-prow · 2026-07-05T21:11:36Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

kubernetes-prow · 2026-07-05T21:11:42Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign averagemarcus for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

drew-viles

Looks good. It's a heck of a jump on the CNI version but I am also using the latest on mine so I think it's something that's just fallen behind. Unless there is a reason it's currently locked to that of which I am unaware.

I'll prod @mboersma as a follow up to confirm my thinking.

/ok-to-test

MaxRink · 2026-07-06T18:11:03Z

@drew-viles As far as i can see 1.2.0 never was the effective version that ended up in an Image.

Ive updated the PR description above to indicate the actual versions that ended up on images

MaxRink · 2026-07-06T18:43:10Z

#2106 would be a port of how we handle this downstream

drew-viles

Minor notes

mboersma · 2026-07-17T15:16:33Z

Really nice work, the cni-url.yml/cni-pkg.yml split is clean and bumping kubernetes_cni_semver off the bogus v1.2.0 lower-bound is a good fix on its own.

One thing to work through before this lands, since it changes every provider's default image. The default is kubernetes_source_type=pkg, and kubelet hard-depends on kubernetes-cni (>= 1.2.0) (I checked v1.32 and v1.36 repo metadata). So on the default path we still pull the kubernetes-cni package via kubelet, then overlay it with the v1.9.1 tarball. Two side effects:

The package stays installed but its files no longer match on disk, so dpkg --verify / rpm -V kubernetes-cni will flag the plugin binaries.
CNI is now decoupled from the k8s minor: every image ships v1.9.1 (a 1.32 image gets 1.9.1, not the package's 1.6.0). Compatibility is fine, but it's a real behavior change worth calling out.

Ordering is safe, the tarball always wins. Should we document this explicitly, or scope the http-CNI default to the http-Kubernetes path where kubelet isn't a package?

linux-foundation-easycla · 2026-07-17T16:16:04Z

The committers listed above are authorized under a signed CLA.

✅ login: MaxRink / name: Maximilian Rink (145a13a, 3a824dd, 5cbd405, 732e462)

drew-viles · 2026-07-18T08:37:13Z

/retest

mboersma · 2026-07-19T23:40:38Z

/label tide/merge-method-squash

…lidate CNI source type Address review feedback on the CNI tarball default PR: - Move kubernetes-cni package installation (repo setup + package install) into cni-pkg.yml so it runs whenever kubernetes_cni_source_type == "pkg", independent of kubernetes_source_type. Previously the CNI package install tasks lived inside debian.yml/redhat.yml/azurelinux.yml/photon.yml, which are only imported when kubernetes_source_type == "pkg", so setting kubernetes_source_type=http with kubernetes_cni_source_type=pkg silently skipped CNI installation and failed validation. - Add an early assert task that kubernetes_cni_source_type is one of "http" or "pkg" before the CNI import tasks run, so an unsupported/typo'd value (e.g. "htpp") fails the build clearly instead of silently matching neither branch and skipping CNI installation and validation entirely.

The kubernetes-cni package install task moved into cni-pkg.yml when CNI package installation was decoupled from kubernetes_source_type. The existing kubernetes/tasks/photon.yml no-changed-when ignore entry covers the same tdnf install pattern but doesn't apply to the new file path, so pull-lint failed on the moved task.

…path Address review feedback from mboersma: on the default kubernetes_source_type=pkg path, kubelet's own package dependency still pulls in the distro kubernetes-cni package, which the http CNI tarball install (kubernetes_cni_source_type=http, the new default) then overlays. The tarball always wins on disk, so image behavior is unaffected, but dpkg --verify/rpm -V will flag the plugin binaries as modified since the package metadata no longer matches. Document this explicitly rather than changing default behavior.

The CNI package install task moves from debian.yml to cni-pkg.yml in this pull request. This commit gives it the apt lock retry loop from kubernetes-sigs#2130 and kubernetes-sigs#2136.

mboersma

Could we finish separating Kubernetes and CNI installation before merging? url.yml still installs the CNI tarball whenever Kubernetes uses HTTP, so http/http installs it twice and http/pkg overlays a package installation on top of tarball files. Please remove the CNI work from url.yml and install it only through cni-url.yml or cni-pkg.yml.

It would also be good to validate both source-type variables before installation starts, explicitly reject package CNI on Flatcar, make the HTTP Goss checks independent of the CNI source, and retain the existing download retries.

kubernetes-prow Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 5, 2026

kubernetes-prow Bot requested review from drew-viles and kkeshavamurthy July 5, 2026 21:11

kubernetes-prow Bot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jul 5, 2026

MaxRink marked this pull request as ready for review July 6, 2026 13:09

kubernetes-prow Bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 6, 2026

kubernetes-prow Bot requested a review from AndiDog July 6, 2026 13:09

drew-viles reviewed Jul 6, 2026

View reviewed changes

kubernetes-prow Bot added the ok-to-test Indicates a non-member PR verified by an org member that is safe to test. label Jul 6, 2026

MaxRink force-pushed the capi/use-cni-plugins-tarball branch 5 times, most recently from b00846d to b236b38 Compare July 8, 2026 00:08

drew-viles reviewed Jul 16, 2026

View reviewed changes

Comment thread images/capi/ansible/roles/kubernetes/tasks/main.yml

Comment thread images/capi/ansible/roles/kubernetes/tasks/main.yml

MaxRink force-pushed the capi/use-cni-plugins-tarball branch from b236b38 to f55871d Compare July 17, 2026 16:15

kubernetes-prow Bot added cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. and removed cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Jul 17, 2026

MaxRink force-pushed the capi/use-cni-plugins-tarball branch from 8901632 to 3a824dd Compare July 17, 2026 17:45

kubernetes-prow Bot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Jul 17, 2026

kubernetes-prow Bot added the tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. label Jul 19, 2026

MaxRink force-pushed the capi/use-cni-plugins-tarball branch 2 times, most recently from 892b274 to 223264d Compare August 14, 2026 17:40

MaxRink mentioned this pull request Aug 14, 2026

capi: retry upstream artifact downloads #2138

Merged

MaxRink force-pushed the capi/use-cni-plugins-tarball branch 2 times, most recently from e128aa5 to 1760bb7 Compare August 19, 2026 11:40

MaxRink added 7 commits August 28, 2026 03:13

Use upstream CNI plugin tarballs by default

8ccad94

capi: validate CNI plugin install source

5a6283f

capi: retry dpkg lock contention on CNI package install

1366060

The CNI package install task moves from debian.yml to cni-pkg.yml in this pull request. This commit gives it the apt lock retry loop from kubernetes-sigs#2130 and kubernetes-sigs#2136.

capi: fail Goss validation for invalid CNI source type

b4367db

MaxRink force-pushed the capi/use-cni-plugins-tarball branch from 092d40a to b4367db Compare August 28, 2026 01:15

mboersma requested changes Aug 31, 2026

View reviewed changes

Navigation Menu

Uh oh!

capi: install CNI plugins from upstream tarballs by default - #2098

capi: install CNI plugins from upstream tarballs by default#2098
MaxRink wants to merge 7 commits into
kubernetes-sigs:mainfrom
MaxRink:capi/use-cni-plugins-tarball

MaxRink commented Jul 5, 2026 •

edited

Loading

Uh oh!

kubernetes-prow Bot commented Jul 5, 2026

Uh oh!

kubernetes-prow Bot commented Jul 5, 2026

Uh oh!

drew-viles left a comment

Uh oh!

MaxRink commented Jul 6, 2026

Uh oh!

MaxRink commented Jul 6, 2026

Uh oh!

drew-viles left a comment •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

mboersma commented Jul 17, 2026

Uh oh!

linux-foundation-easycla Bot commented Jul 17, 2026 •

edited

Loading

Uh oh!

drew-viles commented Jul 18, 2026

Uh oh!

mboersma commented Jul 19, 2026

Uh oh!

mboersma left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

MaxRink commented Jul 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change description

Related issues

Notes

Uh oh!

kubernetes-prow Bot commented Jul 5, 2026

Uh oh!

kubernetes-prow Bot commented Jul 5, 2026

Uh oh!

drew-viles left a comment

Choose a reason for hiding this comment

Uh oh!

MaxRink commented Jul 6, 2026

Uh oh!

MaxRink commented Jul 6, 2026

Uh oh!

drew-viles left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

mboersma commented Jul 17, 2026

Uh oh!

linux-foundation-easycla Bot commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

drew-viles commented Jul 18, 2026

Uh oh!

mboersma commented Jul 19, 2026

Uh oh!

mboersma left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

MaxRink commented Jul 5, 2026 •

edited

Loading

drew-viles left a comment •

edited

Loading

linux-foundation-easycla Bot commented Jul 17, 2026 •

edited

Loading