We’re excited to announce that Mirantis Kubernetes Engine now integrates with Cilium, giving users a powerful new option when choosing a container network interface (CNI) plugin for their cloud native infrastructure.
As our customers have increased the number of applications and services deployed on Mirantis Kubernetes Engine (MKE) clusters, some have requested support for additional CNI implementations and configurations. After collaborating with Cilium creators Isovalent, we’re proud to provide integration with an industry-leading open source solution utilized by AWS, Google, GitLab, Bell, and many others. Today, Cilium is an Incubating project with the Cloud Native Computing Foundation (CNCF).
What is CNI?
What exactly is a container network interface, and why is it so important for Kubernetes users?
Kubernetes networking — and more specifically, container networking in a Kubernetes environment — is an evolving discipline in which there isn’t one universally correct solution. Instead, there are a range of approaches, any of which might be best-suited to a particular use case. For this reason, the Container Networking Interface project — an open source project under the auspices of the Cloud Native Computing Foundation—defines specifications for networking plugins.
That means plugin creators can build solutions that “just work” in a standardized way, and users can choose the CNI plugin that best fits their needs.
How Cilium Helps You Scale Faster
Cilium is a CNI plugin that brings a key technology to container networking: extended Berkeley Packet Filter (eBPF). Cilium uses eBPF to dynamically embed networking control logic at the level of the Linux kernel. With eBPF running at the kernel level, the Cilium agent runs on each cluster node like a pod. This brings Cilium’s functionality to bear from the bottom of the cluster stack all the way up—without making any changes to the configuration of individual containers or applications. Why does that matter? Cilium’s functionality is all about accelerating Kubernetes cluster operations at scale. It replaces kube-proxy for load balancing, providing faster convergence times when increasing the number of services in a cluster. In real terms, that means your services can pivot on a dime, responsively scaling to meet even dramatic and dynamic shifts in demand.
In addition to speed, Cilium provides holistic network security for the cluster, and enables multi-cluster routing, giving enterprises the responsiveness, cloud security, and flexibility they require.
Mirantis Kubernetes Engine is Cilium-ready
Our recent work with the folks at Isovalent ensured that Mirantis Kubernetes Engine could be deployed without kube-proxy enabled. This change can be applied either during configuration before the cluster is created or after the cluster is created. We also ensured that when this setting is switched on, we run the
kube-proxy –cleanup command to ensure that all iptables rules set up by kube-proxy are removed.
With this new ability, Mirantis Kubernetes Engine users can deploy Cilium in Kube Proxy Replacement mode. This enables the use of eBPF to handle the internal load balancing that kube-proxy normally provides—a configuration that gives our users the ability to leverage networking control from the kernel level. Moreover, since Cilium deploys on top of Kubernetes, it fits into our philosophy of empowering users to utilize the tools that fit their needs, from the container runtime to the CNI plugin and beyond.
If you’d like to explore the technical details of Cilium’s implementation more deeply, check out Cilium’s excellent primer. If you’re new to Mirantis Kubernetes Engine, you can learn more and try it out here.