Es gibt verschiedene Gründe sich im Kubernetes-Umfeld Gedanken zur Netzwerkkonfiguration zu machen. Zum Beispiel steht ein neues Projekt an, man hat es endlich geschafft einen Schritt in Richtung Containeriserung zu machen oder es wurden neue Richtlinien eingeführt, die mit der aktuellen Netzwerkkonfiguration nicht umgesetzt werden können. In diesem Zusammenhang lohnt es sich einen Blick auf die Innovationen im Bereich Container Network Interface (CNI) zu werfen.

Doch welche gibt es, wie unterscheiden sich die Implementierungen und wie wählt man das richtige CNI aus? Ich stelle euch die verbreitetsten CNI-Plugins für Kubernetes vor und vergleiche diese am Ende in einer Tabelle, damit ihr euch besser orientieren könnt.

Was ist ein CNI-Plugin?

Das Container Network Interface Plugin ist eins der Herzstücke von Kubernetes und bestimmt, wie die Kommunikation im Cluster aussieht. Dazu gehören z. B. Konfigurationen, die festlegen, wie die Verschlüsselung der Kommunikation erfolgt und wer mit wem reden darf. Während große Cloudanbieter wie AWS und Azure jeweils eigene CNI-Plugins für ihre Plattform anbieten, existieren auch unabhängige CNI-Plugins aus der Open-Source Community, die weit verbreitet sind und plattformunabhängig eingesetzt werden können. Da sie alle die CNI-Spezifikation umsetzen, sind sie untereinander austauschbar und unterscheiden sich lediglich in ihren Funktionalitäten.

Wie wähle ich das richtige CNI-Plugin aus?

Welches CNI-Plugin man nun wählt, hängt natürlich von der spezifischen Situation und den damit einhergehenden Anforderungen ab. Normalerweise hat jede Kubernetes-Distribution ein CNI-Plugin als Default vorkonfiguriert. Sollten also keine besonderen Anforderungen an das Netzwerk des Clusters bestehen, ist die Entscheidung einfach: Es wird einfach das bereits vorkonfigurierte Plugin der Kubernetes Distribution genutzt. Dabei entstehen keine Aufwände und das Cluster kann direkt produktiv eingesetzt werden.

Oftmals ist dies aber nicht ganz so leicht. Denn sobald das vorkonfigurierte Plugin eine benötigte Funktionalität nicht unterstützt, benötigt man eine Alternative. Zu den Kriterien, die dabei beachtet werden müssen, zählen unter anderem:

• Die verwendete Kubernetes Distribution (Vanilla, Rancher oder Cloudanbieter spezifisch)
• Unterstützte Funktionalitäten des CNI-Plugins (z. B. Netzwerkrichtlinien oder Routingprotokolle)
• Technische Limitierungen wie eine maximale Anzahl an Pods pro Knoten und IP-Versions-Support
• Verfügbarkeit von professionellem Support
• Marktverbreitung und Community
  • Wie verbreitet ist das Plugin bzw. wie beliebt ist das Projekt auf Github?
  • Gibt es reguläre Updates?

Die bekanntesten Plugins im Vergleich

Um die Entscheidung für ein bestimmtes Plugin zu vereinfachen, werden die bekanntesten Plugins nun kurz vorgestellt und danach in einer übersichtlichen Tabelle Seite an Seite gegenübergestellt. Die Tabelle dient dabei dem schnelleren Überblick, während die Vorstellungen der einzelnen Plugins zusätzliche Informationen zu den Plugins beinhalten können, die nicht für das Format einer Tabelle geeignet sind.

Zu den betrachteten CNI-Plugins gehören

• Flannel
• Calico
• Cilium
• Weave
• AWS VPC CNI
• Azure CNI

Neben diesen existieren natürlich noch weitere Optionen. Ich habe mich auf die fokussiert, die uns häufig im Projektalltag begegnen.

Flannel

Flannel ist ein Open Source CNI-Plugin, das versucht, möglichst kompatibel und einfach zu sein. In vielen Fällen funktioniert es daher ohne eine zusätzliche Konfiguration. Obwohl es im Vergleich mit anderen CNIs keins der fortgeschrittenen Features umsetzt. Flannel wird häufig von simplen Kubernetes Distributionen (z. B. K3s) als Default CNI verwendet. Es bietet eine schnelle und einfache Netzwerkkonfiguration mittels VXLan Overlay Network, aber keine Unterstützung für Netzwerkrichtlinien. Alternativ kann Flannel für den Support von Netzwerkrichtlinien mit einer anderen Implementierung wie z. B. Calico, kombiniert werden. Diese Kombination verwendet auch Rancher selbst als „Canal“.

Leider wird Flannel bei den meisten Cloud-Anbietern nicht out-of-the-box unterstützt und muss daher selbst installiert werden.

Calico

Calico ist ein von Tigera entwickeltes Open-Source-Projekt und setzt vor allem auf Flexibilität und Performance. Es besteht aus zwei Komponenten, die zusammen oder auch getrennt genutzt werden können. Diese beiden Komponenten sind das CNI und die Suite für Netzwerkrichtlinien. Wie die Namen bereits verraten, unterstützt Calico somit Netzwerkrichtlinien und kann sogar allein für diese mit anderen CNIs wie Flannel kombiniert werden. In den Kubernetes Distributionen von Google (GKE) und Azure (AKS) werden von Calico sogar nur die Netzwerkrichtlinien out-of-the-box unterstützt, während die Kombination mit Flannel in Rancher bereits vorkonfiguriert ist.

Insgesamt bietet Calico umfassende Möglichkeiten, um Netzwerk und Routing des Clusters einzurichten. Dazu gehören unter anderem der eBPF Support oder das Routen mittels BGP. Dadurch wird es einfacher, Pakete zurückzuverfolgen und den Datenverkehr anhand von komplexen Regeln zu steuern. Für zusätzliche Sicherheitsvorkehrungen ist es außerdem möglich, einen Service Mesh zu integrieren. Neben Istio haben wir dabei auch mit Kuma gute Erfahrungen gesammelt.

Canal

Canal ist eine Kombination aus Calico und Flannel. Das ursprüngliche Ziel des Projekts war es, die Funktionalitäten beider in einem einfachen Deployment zu vereinfachen. Da jedoch beide Projekte mittlerweile auf ihre Kompatibilität achten, wurde die Entwicklung von Canal eingestellt. Canal wird dennoch weiterhin als Bezeichnung für die Kombination von Flannel mit Calico genutzt. In diesem Sinne wird es auch als Default CNI in Rancher eingesetzt.

Cilium

Cilium ist ebenfalls ein Open Source CNI-Plugin, das eine sehr detaillierte Netzwerkkonfiguration und beinahe unbegrenzte Skalierung erlaubt. Genau wie Calico unterstützt es diverse Möglichkeiten, das Routing z. B. mit VXLan oder BGP zu konfigurieren und setzt sogar eBPF per Default ein. Durch die tiefgreifenden Konfigurationsmöglichkeiten können mit Cilium sogar Richtlinien erstellt werden, die den Datenverkehr auf Applikationsebene steuern. Mit dem auf Cilium aufbauenden Überwachungstool Hubble erhält man somit sehr einfach Einblick in den Datenverkehr des Clusters. Außerdem unterstützt es nicht nur Netzwerkrichtlinien, sondern erweiterte diese mit Cilium Network Policies.

Seit Oktober 2023 gilt Cilium als CNCF „graduated“, wird also von der CNCF als stabil und etabliert anerkannt. Vor allem die Beliebtheit in der Community ist auch an den GitHub Sternen ablesbar, da das Projekt mit mittlerweile fast 18.000 Sternen weit mehr Sterne besitzt als die anderen CNI-Plugins, die ich hier vorstelle. Googles „GKE Dataplane V2“ basiert ebenfalls auf Cilium.

Cilium kann mit Hilfe von CNI Chaining auch mit anderen CNIs kombiniert werden, um diese mit den eigenen Funktionalitäten zu erweitern.

AWS VPC CNI

AWS VPC CNI ist das Default CNI von Amazons EKS. Out-of-the-box ist es auch das einzige offiziell unterstützte CNI-Plugin dieser Cloud. Sofern kein Fargate genutzt wird, können andere CNI-Plugins mit Hilfe von externem Support jedoch ebenfalls eingerichtet werden. Ein großer Vorteil von AWS VPC ist, dass es ohne gesonderte Konfiguration das native AWS-Netzwerk nutzen kann, während die nicht Cloud-spezifischen CNIs ein neues virtuelles Netz aufspannen. Von AWS VPC erhält also jeder Pod eine IP-Adresse aus dem bereits existierenden Subnetz. Dadurch werden die Pods leichter erreichbar und Netzwerkrichtlinien vereinfacht. Andererseits verbraucht dieses Vorgehen mehr IP-Adressen, was bei hohen Skalierungen zu Problemen führen kann.

Wie die meisten anderen CNI-Plugins unterstützt auch dieses die Integration eines Service Meshs. Darunter auch das hauseigene AWS APP Mesh. Netzwerkrichtlinien können mit dem Network Policy Manager ebenfalls eingerichtet werden.

Azure CNI

Azure CNI ist der Default des Azure Kubernetes Service (AKS) und gleichzeitig neben Kubenet das einzige offiziell unterstützte CNI-Plugin. Calico wird ebenfalls unterstützt, allerdings nur für Netzwerkrichtlinien. Im Januar 2024 hat Microsoft zudem einen Beitrag auf seiner Lernplattform veröffentlicht, in dem der Hersteller beschreibt, wie Azure CNI mit Cilium kombiniert werden kann, um von dessen Vorteilen zu profitieren.

Wie auch AWS VPC ermöglicht Azure CNI es den Containern, im Subnetz der Azure Cloud zu laufen und bietet somit die entsprechenden Vor- und Nachteile für AKS.

Weave

Weave von Weaveworks setzt ebenfalls auf Einfachheit. Allerdings bekam das Plugin bereits seit zwei Jahren kein Update und im Februar 2024 verkündete Weaveworks offiziell, den Handelsbetrieb künftig einzustellen.

Übersicht

Zur besseren Übersicht habe ich die Plugins mit ein paar mehr Details in einer Tabelle gegenübergestellt:

Um einige potenzielle Fragen vorwegzunehmen, hier ein paar Erklärungen zu der Tabelle:

Canal taucht in der Tabelle nicht explizit auf, da damit nur noch die Kombination aus Calico und Flannel referenziert wird.

Die in der Tabelle aufgelistete Unterstützung bezieht sich lediglich auf die vom Cloud-Anbieter unterstützten Plugins. Oftmals ist es aber dennoch möglich ein beliebiges CNI-Plugin zu nutzen. Dies geschieht dann jedoch in Eigenverantwortung oder mit externem Support. Die Cloud-Anbieter nennen unter Umständen Kooperationspartner. Dennoch scheint dies seine Grenzen zu haben, denn AWS schreibt explizit in seiner Dokumentation, dass die Installation anderer Plugins auf Fargate Knoten scheitert.

Fazit

Nachdem wir uns nun die bekanntesten CNI-Plugins angeschaut haben, wird eines schnell klar: Welches Plugin ihr wählt, hängt stark ab

• von den Rahmenbedingungen,
• von den Anforderungen an das Cluster,
• von den deployten Applikationen.

Eine allgemeingültige Empfehlung gibt es also wie so häufig nicht. Generell ist jedoch erkennbar, dass Flannel bevorzugt genutzt wird, wenn keine besonderen Anforderungen an das Netzwerk gestellt werden. Werden jedoch Netzwerkrichtlinien benötigt, muss man es mit Calico kombinieren oder gleich eine alternative CNI-Implementierung wählen.

Calico hingegen ist bereits deutlich vielseitiger und unterstützt mittlerweile auch tiefgreifendere Funktionalitäten, wie Netzwerkrichtlinien, Service Mesh Integration und eBPF-Support. Mit Calico Enterprise seid ihr auf der sicheren Seite und könnt im Notfall auf professionellen Support zurückgreifen. Calico ist daher in vielen Szenarien eine gute Wahl, um ein funktionalitätsreiches Netzwerk zu konfigurieren.

Stößt ihr selbst mir Calico auf Limitierungen oder greift vorzugsweise auf ein CNCF Graduated Plugin zurück, erfüllt Cilium die Anforderungen. Mit den detailreichen Konfigurationsmöglichkeiten und der hohen Skalierbarkeit ist Cilium das beliebteste der hier vorgestellten CNI-Plugins auf GitHub. Gründe dafür könnten die tiefgreifende Kontrolle über Datenverkehr, sogar auf Applikationsschicht und das vereinfachte Monitoring sein.

Bewegt man sich in der Cloud, bieten die Cloud-eigenen Lösungen zu Teilen besondere, Cloud-spezifische Funktionalitäten, die mit anderen Plugins gar nicht oder nur mit hohem Aufwand zu erzielen sind. Der allgemeine Funktionsumfang ist jedoch geringer als der  Funktionsumfang anderer CNIs.

Möchtet ihr den Aufwand des Deployments und der Updates besonders niedrig halten, vereinfachen die out-of-the-box unterstützten Plugins die Arbeit, da diese Aufgaben mit wenigen Klicken in der Benutzeroberfläche der Clouds erledigt sind.