Cilium CNI instead of Calico?

[pszelestey]

Hi Guys,

Have you considered trying Cilium CNI with eBPF instead of Calico? Are you using Calico with eBPF enabled? If yes, what advantages do you experience with eBPF function?

We have been using Calico in our on-prem K8s workload clusters for IT applications (based on VMware vSphere) for almost 4 years at Magyar Telekom and we have good experiences with Calico, because it provides great network capabilities over BGP so that we can use our internal/harmonized IP CIDRs.

However, as we are getting closer to cloud-native container based mobile core network services we looked around which functions/tools can give us more observatibility for tracing/troubleshooting mobile voice/network issues. That's how we got out at eBPF (and as long as I know Cilium CNI was the first which offered eBFP).

I would be really grateful if you could share some experiences about observability features and tracing capabilities which you use in Das Schiff clusters.

Thank you in advance!
Best regards,
Peter

[Cellebyte]

On-Prem_Bare-Metal_Kubernetes_Network_Stack_Telco_Ready.pdf
Good morning Peter,

we are also currently looking into Cilium as it will solve and hopefully streamline the cni stack we have.
Our current Bare Metal stack is mainly on coil for cni and calico as Networkpolicy engine as we needed a more pluggable solution to host NT Workloads.

We will try to run it soon as a Multus/Calico/Coil replacement in native routing mode.

We currently do not leverage and probably will not leverage routing functionality from the cnis. As we integrated it directly into our Fabric and added a local routing engine to every node.

Best Regards
Marcel

PS: I added our presentation from KubeCon.

[pszelestey]

Hi Marcel,

Thank you for the quick answer and the presentation! I will check it and watch the recorded video. We also attended KubeCon this year. Unfortunately we had to leave before your presentation, so we was not able to watch it in person.

Best regards,
Peter

[koolipaasha]

On-Prem_Bare-Metal_Kubernetes_Network_Stack_Telco_Ready.pdf Good morning Peter,

we are also currently looking into Cilium as it will solve and hopefully streamline the cni stack we have. Our current Bare Metal stack is mainly on coil for cni and calico as Networkpolicy engine as we needed a more pluggable solution to host NT Workloads.

We will try to run it soon as a Multus/Calico/Coil replacement in native routing mode.

We currently do not leverage and probably will not leverage routing functionality from the cnis. As we integrated it directly into our Fabric and added a local routing engine to every node.

Best Regards Marcel

PS: I added our presentation from KubeCon.

@Cellebyte sorry to hijack this thread,we follow your work,especially on the networking side .It would be interesting to understand your thought behind replacing Multus,as its used by almost all NT workloads. I couldnt find a reference even in Anuket/CNTT about a simillar work .Or were you referring to using pods in host-net mode

[Cellebyte]

we are currently not replacing Multus, but we requested the possibility to use cilium’s IPAM for secondary interfaces.
If that works we can remove at least whereabouts from the stack and also use macvlan and ipvlan with it.
As of current discussions there is work requested to support NetworkAttachmentDefinitions by Cilium or have a migration path for it to a Cilium CRD. Multiple IPs on containers is theoretically possible. The KEP-563 mentions the capability to extend the ipAddrs field later.
It will not replace SRIOV unfortunately.