/triage accept

@tico88612: The label(s) triage/accept cannot be applied, because the repository doesn't have them.

/triage accepted

/assign

I'm thinking of changing the installation method to a Cilium CLI installation. Otherwise, maintenance now involves manual modification of Jinja templates, and every update is painful.

@VannTen, do you have a better idea?

I'm not sure what a cilium cli install means exactly TBH.

Installing Cilium can be done through the Cilium CLI (e.g. cilium install, cilium install --version 1.17.2 -f my-setting.yaml), which eliminates the need to maintain the jinja template in the Cilium folder.

I'm all for it, if we can do it without breaking compatibility.

For reference, I've upgraded Cilium via Kubespray on multiple existing clusters, moving up to K8s v1.32.3 & Cilium v1.17.2 without changing any of the Jinja templates, just by updating the values for the versions as stated above. All working just fine.

EDIT: However, the upgrade had to be done in 2 phases: v1.15.9 -> v1.16.6 -> v1.17.0 (later patched to v1.17.2)

I agree with changing the Cilium installation method in Kubespray. The primary concern is that Cilium deployed by Kubespray can behave differently from installations using Cilium's official CLI or Helm charts.

For instance, the config init container, introduced in Cilium v1.13, is missing in Kubespray deployments even when specifying the latest Cilium version. In fact, I recently encountered unexpected issues caused by this absence, which do not occur in standard Cilium environments.

To ensure consistency and reduce potential problems, it would be beneficial to align Kubespray's Cilium deployment with the official installation methods, rather than maintaining separate Jinja templates.

To ensure consistency and reduce potential problems, it would be beneficial to align Kubespray's Cilium deployment with the official installation methods, rather than maintaining separate Jinja templates.

Yes, 100% agreed. I was only suggesting it can be upgraded without heavy changes to release in v2.27.1.

As a long-term vision, moving to use the Cilium CLI is the way to go.

Yes, 100% agreed. I was only suggesting it can be upgraded without heavy changes to release in #12065.

I agree with your thinking. If updating Cilium version in Kubespray doesn't require major changes, it makes sense to address that first, with the installation method improvements coming at a later stage.

I've been thinking the Cilium installation method in Kubespray could use some improvements, so I just wanted to add my support when I saw this issue :)

@RaulButuc @Kaniikura I have refactored this #12101. Could you help me review it?
If you can help with the review, this refactor is expected to be added on 2.28.

@tico88612 lgtm, just a nitpick on the version (latest patch).

Hi all,

I had to modify the kubespray\roles\network_plugin\cilium role to install cilium v1.17.2 using helm (not cilium cli).
The existing manifests were outdated/had cilium bugs, not allowing version upgrade.
It's very rough and does not have verification baked into the playbooks.

I have a few questions:

• are we expecting this new cilium installation in v2.28.0? I already see a PR
• I also read somewhere, are we upgrading the cilium version up to only v1.16.x? (I would assume, if version is being upgraded, it would be to latest version i.e. v1.17.2 as kubespray already supports kubernetes 1.32 )
• also, are there any merits to using cilium cli instead of cilium helm for installation?
  I find helm more easy to understand and control, I may be missing something (just want to make sure)

Thanks

The existing manifests were outdated/had cilium bugs, not allowing version upgrade.
It's very rough and does not have verification baked into the playbooks.

That's why we need to change. We shouldn't be manually maintaining Cilium's manifests.

are we expecting this new cilium installation in v2.28.0? I already see a PR

If someone helps with the review, yes, it will appear in v2.28.0.

I also read somewhere, are we upgrading the cilium version up to only v1.16.x? (I would assume, if version is being upgraded, it would be to latest version i.e. v1.17.2 as kubespray already supports kubernetes 1.32 )

You can set cilium_version to 1.16.x, but I don't have testing on that version; however, I don't think there are too many changes with 1.17.x.

also, are there any merits to using cilium cli instead of cilium helm for installation?
I find helm more easy to understand and control, I may be missing something (just want to make sure)

Cilium CLI is based on Cilium Helm (if you have read Cilium docs, it changed on 1.15)
It can automatically detect some (minor) missing values. Helm needs to be adjusted from scratch.