Get the Best of Both Worlds With the KKP 2.19 CNI Strategy

March 11, 2022

Introduction

Kubernetes is all about sharing machines between applications. Typically, sharing machines requires ensuring that two applications don’t try to use the same ports. Managing port allocation across multiple developers is difficult at scale, and exposes users to cluster-level issues they can’t control. Instead of dealing with dynamic port allocation (which introduces a lot of complexity to the system), Kubernetes uses a different, more practical approach: the Kubernetes Network Model.

Since the requirements for this vary depending on the application, Kubernetes abstracts the networking, so that vendors can tailor solutions to different needs and users can choose their preferred networking solution when building their clusters. This is where CNI plugins can help!

What Is a CNI, and Why Use It?

To define a standardized interface between container execution and the network layer, the Container Network Interface (CNI) defines the standard between container execution and the network layer. It’s a standard designed to make it easy to configure networking when containers are created or destroyed. The specification’s simplicity has led to its widespread adoption with a large number of supported plugins. Each plugin that conforms to the CNI specification aims to address different aspects of container networking; determining the right plugin, or combinations thereof, therefore, is crucial to meeting project requirements.

Which CNI Plugins Were Previously Supported by Kubermatic Kubernetes Platform (KKP)?

The Flannel plugin is one of the oldest and most mature CNI plugins for Kubernetes. It’s a great entry-level plugin that provides access to basic networking features. Best of all, it requires a limited amount of administration to set up and maintain. Flannel, however, lacks advanced features like the ability to configure network policies and firewalls, making it less appropriate for advanced networking applications.

Calico, on the other hand, has earned a reputation for being reliable, flexible and can support highly performing networks for Kubernetes clusters. With its advanced policy support, it also pairs well with other systems like Flannel.

With KKP, we aimed to simplify the process of choosing the right plugin without taking away the user’s control. That’s why we chose to go with Canal -> a combination of Flannel and Calico. Canal’s networking layer is the simple overlay provided by Flannel. Layering this on top enhances the base network and Calico’s powerful networking rule evaluation provides additional security & control. Canal is an excellent way for teams to experiment and gain experience before they are ready to test changing their existing networking.

And, What’s New With KKP 2.19?

While we wanted to continue making it as easy as possible for our users to select the right CNI plugin, we also wanted to provide them with greater flexibility. We achieved this in two ways:

1. KKP users can select between Canal and Cilium as the default CNI Plugin

Cilium is an eBPF (Extended Berkeley Packet Filter) based open-source software deploying, securing, and observing network connectivity between container workloads. Cilium’s ability to apply policies to multiple layers allows greater flexibility to manage traffic ingress and egress within your Kubernetes cluster. Cilium not only makes it simple/easy/painless to apply security policies in a highly dynamic environment by decoupling security from addressing, but can also provide stronger security isolation.

We tested the performance of both Canal and Cilium. Cilium performed up to 30% better than Canal when running in ordinary Kubernetes clusters on the same hardware.

Canal test performance results

Cilium test performance results

Cilium also has a built-in network observability tool called Hubble. Hubble enables deep visibility into the communication and behavior of services and the networking infrastructure in a completely transparent way.

Network Observability with Hubble

2. KKP users can also “bring your own” CNI plugin

KKP 2.19 supports the CNI type “none” in special cases where the built-in CNIs (Canal and Cilium) may not be sufficient. By selecting “none”, KKP ensures that no CNI is installed in the user cluster and CNI set up and management is entirely up to the user.

Network Configuration with Kubermatic Kubernetes Platform

In a Nutshell…

KKP users can now choose from the following options:

KKP V2.19 supports two CNI add-ons: Canal and Cilium, and also allows the user to bring their own CNI if desired.
Both Canal and Cilium can be made default add-ons at the same time. One of them will be installed into the user cluster based on the selection.
KKP V2.19 now supports CNI type “none” for special cases.

So KKP users can either choose one of the CNI plugins that Kubermatic supports or add and manage a CNI of their choice. This gives full control and flexibility to the users to install any other CNI they might need, regardless of whether it’s supported by KKP or not.