Deploy Cilium using official helm chart

[prashantchitta]

What would you like to be added:
Cilium has its own official helm charts. Currently in kubespray we dont use those helm charts. Instead we copy those into this repo and manage it here.

Why is this needed:
Whenever we want to upgrade Cilium, we have to update kubespray codebase to pull in the changes from upsteam cilium helm charts. We noticed that when we upgraded Cilum to 1.12, cilium deployment inside kubespray is broken.
Look at the PRs to fix it #9856, #9735, #9876, #9880

So Instead of porting all the charts and templatizing it in kubespray, wondering if there was consideration to point kubespray to deploy cilium using upstream helm charts directly?

cc: @oomichi

[MrFreezeex]

Hi @prashantchitta the documentation is still in a PR but does the Custom CNI helps: https://github.com/kubernetes-sigs/kubespray/pull/9878/files ? It takes some arbitrary manifest to install a CNI so you could generate them via the cilium helm chart (like we do in the kubespray tests actually). There could be some opportunity to leverage the helm-apps role to extend custom CNI to use an arbitrary helm charts directly as well in the future.

I wanted to switch to a helm chart directly for a long time to deploy Cilium in Kubespray but as there is a lot of variable to configure Cilium in Kubespray it might be tricky to do this in a way that is non breaking (but maybe we should change the variables anyway?).

[oomichi]

This is a good point.
We had some discussions we should continue maintaining deployment manifests in Kubespray repo, or just remove those manifests and use official helm charts.
For example, #3181

TBH I don't have a strong opinion about this topic.
Actually I used to deploy some apps from helm chart instead of using Kubespray own ones even if the environment is deployed from Kubespray.
I am fine to accept pull requests from contributors to update Kubespray own manifests as an open source project.
But if some manifests get rotten in long time, I think we should remove them from Kubespray repo.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[titansmc]

Could we leverage on custom_cni to support a migration from calico to cilium @oomichi ? So let's say I manually deploy cilium and migrate it, and later on I add the cilium charts to custom_cni

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.