Wozu benötigt man Container Network Interfaces?

Was ist ein Container-Netzwerk-Interface?

Die Containertechnologie nutzt virtuelle Instanzen, um hochmodulare Unternehmens-Workloads zusammenzustellen, zu betreiben und zu skalieren. Da Container auf die Kommunikation über Unternehmens- und Cloud-Netzwerke angewiesen sind, kann ein verbessertes und optimiertes Netzwerkmanagement die Leistung von Containern und Anwendungen erheblich verbessern.

Die CNI-Spezifikation – Version 1.0.0 zum Zeitpunkt der Veröffentlichung – ist ein formales Dokument, das einen hersteller- und technologieunabhängigen Netzwerkansatz für Anwendungscontainer unter Linux beschreibt. Mit dem CNI-Plug-in-Modell können IT-Administratoren eine breite Palette von Netzwerkoptionen für ihre Container erstellen und bereitstellen, so dass sich Kubernetes in verschiedenen Netzwerkumgebungen einsetzen lässt.

Die CNI-Spezifikation definiert fünf Aspekte einer Containernetzwerkumgebung:

1. Das Format, das zur Definition der Netzwerkkonfiguration verwendet wird, einschließlich Netzwerknamen, bereitzustellende Plug-ins, Schlüssel und Namen von Netzwerkobjekten;
2. Das Protokoll, das für Containerlaufzeiten – wie runc, CRI-O und containerd – verwendet wird, um mit Netzwerk-Plug-ins zu interagieren oder zu kommunizieren;
3. Das Verfahren zum Ausführen von Plug-ins;
4. Das Verfahren für Plug-ins zum Zuweisen von Funktionen oder Aufgaben an andere Plug-ins; und
5. Die Datentypdefinitionen, anhand derer Plug-ins Ergebnisse zurückgeben oder Daten an die Containerlaufzeit übergeben.

Ein neu erstellter Pod oder Container hat keine Netzwerkschnittstelle. CNI-Plug-ins fügen sie in den Container-Netzwerknamensraum ein. Dieses virtuelle Netzwerk verbindet dann Hosts und Container, weist IP-Adressen zu, konfiguriert das Routing und führt andere Aufgaben aus, um die Netzwerkumgebung zu definieren, damit die Container kommunizieren können.

Dieser Prozess ist erstaunlich komplex. Die Art der Cluster-Vernetzung, die Sie für Containern und Kubernetes benötigen, muss vier verschiedene Arten der Kommunikation abdecken: Pod-zu-Pod, Pod-zu-Service, Extern-zu-Service und Container-zu-Container in enger Kopplung.

Da Kubernetes für die gemeinsame Nutzung von Maschinen durch Anwendungen zuständig ist, müssen Sie verhindern, dass zwei Anwendungen dieselben Ports verwenden, und die Ports müssen Sie über mehrere Systeme hinweg koordinieren. Statt diese Probleme intern zu lösen, setzt Kubernetes einen Plug-in-Ansatz ein, der die Belastung für Kubernetes selbst reduziert.

CNI ist kein Kubernetes-Plug-in, sondern die Spezifikation, die definiert, wie Plug-ins mit der Container-Laufzeitumgebung kommunizieren und interagieren sollen. CNI-Plug-ins lassen sich auf jede beliebige Art und Weise erstellen und entwickeln, und sie spiegeln oft die Entwicklungs-, Test- und Lieferstandards anderer Softwareprojekte wider. Letztendlich müssen Plug-ins jedoch die CNI-Spezifikation einhalten, um mit Kubernetes in einer funktionierenden Container-Umgebung zu funktionieren.

Was verhält sich CNI zu Kubernetes?

CNI ist nicht Bestandteil von Kubernetes. Entwickler, die den CNI-Standard verwenden, erstellen Netzwerk-Plug-ins, um mit einer Vielzahl von Container-Laufzeiten zu interagieren. CNI-Netzwerke können ein gekapseltes Netzwerkmodell wie Virtual Extensible LAN (VXLAN) oder ein ungekapseltes – auch als entkapselt bezeichnetes – Netzwerkmodell wie Border Gateway Protocol (BGP) verwenden.

Kubernetes ist nur eine der Laufzeitumgebungen, die sich an die CNI-Spezifikation halten. Zu den anderen CNI-kompatiblen Laufzeitumgebungen gehören die folgenden:

• rkt
• CRI-O
• OpenShift
• Cloud Foundry
• Apache Mesos
• Amazon Elastic Container Service
• Singularity
• OpenSVC

Dutzende von Plug-ins von Drittanbietern halten sich an den CNI-Standard, darunter Calico, Cilium, Romana, Silk und Linen. Die CNI-Projektseite auf GitHub enthält eine umfassende Liste von CNI-kompatiblen Projekten.

Vor- und Nachteile von CNI-Plug-ins

Im Folgenden werden einige der Vorteile einer CNI-Plug-in-Architektur aufgeführt:

Erweiterbarkeit der Software. Mit CNI-Plug-ins müssen Entwickler keine spezifische Software für jede Einsatzsituation oder -umgebung entwickeln. Stattdessen können Nutzer einfach das Plug-in auswählen, das ihren Anforderungen am besten entspricht.

Vermeidung von Lock-in. Im Idealfall verhindert ein Plug-in-Konzept die Bindung an einen bestimmten Anbieter und ermöglicht es aus Plug-ins aus verschiedenen Quellen auszuwählen.

Einfache Änderungen. Wenn sich Einsatzanforderungen oder Umgebungen ändern, passen Sie die Plattform einfach durch die Installation neuer CNI-Plug-ins an.

CNI-Plug-ins sind jedoch nicht perfekt, und jede Plug-in-basierte Plattform kann auch potenzielle Probleme mit sich bringen. Sie sollten diese Kompromisse in Betracht ziehen, bevor sie eine Plug-in-abhängige Plattform einsetzen:

Unerwartete Bugs. Plattformentwickler testen oder validieren Plug-ins nicht immer, was zu Fehlern wie Bugs, schlechter Leistung und Sicherheitsproblemen führt. Bei jeder Prüfung oder Validierung einer Softwareplattform sollten Sie die vorgesehenen Plug-ins berücksichtigen, einschließlich einer erneuten Validierung der Plattform hinsichtlich Stabilität und Leistung, wenn ein Plug-in aktualisiert oder ersetzt wird.

Mehr bewegliche Teile. Admins müssen Updates und Patches nicht nur für Plattformen wie Kubernetes, sondern auch für alle Plug-ins verfolgen, was die Softwarebereitstellung und -verwaltung erschwert.

Sich ändernde Standards. Plug-in-Standards wie CNI sind nicht in Stein gemeißelt, und neue Versionen erfordern oft Änderungen an den Plug-ins. Das wiederum führt dazu, dass Sie neue oder aktualisierte Plug-ins benötigen, die zusätzliche Komplexität und Arbeit mit sich bringen. Ebenso gibt es keine Garantien für die Abwärtskompatibilität oder rechtzeitige Aktualisierungen wichtiger Plug-ins, um neuen Standards zu entsprechen. All das stört den reibungslosen Betrieb Ihrer Umgebung.

Vergleich der Kubernetes-CNI-Plug-ins

Es gibt zahlreiche CNI-Plug-ins für Kubernetes. Jedes Plug-in führt ähnliche Aufgaben aus und wird als Daemon installiert. Die Plug-ins unterscheiden sich jedoch in ihrem Design und ihrem Ansatz für Kapselung, Routing, Datenspeicher, Verschlüsselung und Unterstützung. Unternehmen sollten bei der Auswahl eines Kubernetes-CNI-Plug-ins jeden dieser Faktoren berücksichtigen.

Calico

Calico ist ein beliebtes Open-Source-CNI-Plug-in, das für Flexibilität, Netzwerkleistung, erweiterte Netzwerkverwaltung und Verbindungstransparenz zwischen Pods und Hosts entwickelt wurde.

Calico verwendet BGP-Routing als Underlay-Netzwerk oder IP-in-IP und VXLAN als Overlay-Netzwerk für die Verkapselung und das Routing. BGP kapselt den IP-Verkehr nicht ein, wodurch eine Kapselungsschicht überflüssig wird und die Leistung des Containernetzwerks verbessert wird. Calico übernimmt die Tunneling-Verschlüsselung mit WireGuard.

Das Plug-in unterstützt Tracing und Debugging mit Netzwerkverwaltungsfunktionen wie Richtlinienverwaltung und Zugriffskontrolllisten (ACLs). Die Netzwerkrichtlinien verwenden den Abgleich zwischen Erlauben und Verweigern, den Sie je nach Bedarf erstellten und den Pod-Netzwerkeingangsrichtlinien zuweisen können. Calico bietet Unternehmensunterstützung durch Calico Enterprise.

Flannel

Flannel ist ein ausgereiftes und stabiles Open-Source-CNI-Plug-in, das auf einem Overlay-Netzwerkmodell auf Basis von VXLAN basiert und für die meisten Kubernetes-Anwendungsfälle geeignet ist.

Flannel erstellt und verwaltet Subnetze mit einem einzigen Daemon, der jedem Kubernetes-Cluster-Knoten ein eigenes Subnetz sowie eine interne IP-Adresse zuweist. Das Plug-in verwendet etcd, um Host-Mappings und andere Konfigurationselemente zu speichern. Standard-IPsec unterstützt die Verschlüsselung.

Flannel ist eine gute Wahl für IT-Mitarbeiter, die neu in der Kubernetes-CNI-Landschaft sind und mehr Kontrolle über ihre Kubernetes-Cluster haben möchten. Flannel unterstützt jedoch keine Netzwerkrichtlinien, kann nicht mehrere Hosts über einen einzigen Daemon ausführen und bietet keinen Support für Unternehmen.

Weave Net

Weave Net, ein Produkt von Weaveworks, bietet die Installation und Konfiguration von CNI-Plug-ins in Kubernetes-Clustern.

Weave erstellt ein Mesh-Overlay-Netzwerk, das alle Clusterknoten miteinander verbindet. Das Overlay verwendet ein Kernel-System zum Verschieben von Paketen und funktioniert direkt zwischen Pods innerhalb eines einzelnen Hosts, obwohl dies keine Option ist, wenn Datenverkehr zwischen Hosts stattfinden soll.

Das Weave-Plug-in bietet andere Netzwerkfunktionen wie Fehlertoleranz, Lastausgleich und Namensauflösung über einen Weave-DNS-Server. Weave verwendet IPsec für die Verschlüsselung und VXLAN als Standardprotokoll für die Verkapselung und das Routing.

Im Gegensatz zu vielen anderen CNI-Plug-ins setzt Weave nicht etcd, sondern speichert die Netzwerkkonfigurationseinstellungen in einer nativen Datenbankdatei, die von Weave verwendet und von den Pods gemeinsam genutzt wird. Das Plug-in unterstützt Netzwerkrichtlinien durch einen speziellen weave-npc-Container, den es standardmäßig installiert und konfiguriert.

Cilium

Cilium ist eine Open-Source-CNI, die für ihre hohe Skalierbarkeit und Sicherheit bekannt ist und als Daemon auf jedem Knoten eines Kubernetes-Clusters installiert wird.

Cilium setzt VXLAN ein, um ein Overlay-Netzwerk zu bilden, und einen erweiterten Berkeley Packet Filter, um Netzwerkkonnektivität und Anwendungsregeln zu verwalten. Es unterstützt sowohl IPv4- als auch IPv6-Adressen und verwendet BGP für ungekapseltes Routing. Cilium ist in der Lage, mehrere Kubernetes-Cluster zeitgleich zu unterstützen und bietet, wie Multus, Multi-CNI-Funktionen.

Cilium behandelt Aspekte der Netzwerkverwaltung, wie zum Beispiel Netzwerkrichtlinien, über HTTP-Anfragefilter. Richtlinien können in YAML- oder JSON-Dateien geschrieben werden, die beide die Durchsetzung des Netzwerkverkehrs für eingehenden und ausgehenden Verkehr ermöglichen.

Multus

Multus ist ein CNI-Plug-in, das für die Unterstützung mehrerer Netzwerkschnittstellen für Pods entwickelt wurde.

Standardmäßig hat jeder Kubernetes-Pod nur eine Netzwerkschnittstelle und einen Loopback. Multus fungiert als Dach- oder Meta-Plug-in, das andere CNI-Plug-ins aufruft und Ihnen so erlaubt, Pods mit mehreren Netzwerkschnittstellen bereitzustellen.

Multus ist in verschiedenen Situationen nützlich, zum Beispiel beim Aufteilen des Datenverkehrs, bei der die verschiedenen Arten des Datenverkehrs sorgfältig verwaltet werden müssen, um die Qualität der Dienste zu gewährleisten. Es verbessert die Leistung für bestimmte Verkehrstypen, die von Hardware-Leistungssteigerungen profitieren, einschließlich Single-Root-I/O-Virtualisierung, und die Sicherheit verbessern, wenn Netzwerke mit mehreren Anwendern eine sorgfältige Isolierung erfordern.

Die Zukunft von CNI

Da die aktuelle CNI-Spezifikation 1.0.0 eine Vielzahl von Anforderungen an die Konfiguration von Containernetzwerken erfüllt, ist nicht zu erwarten, dass sich CNI in naher Zukunft schnell weiterentwickelt. Der CNI-Standard wird sich immer weiterentwickeln, um eine größere Autonomie und dynamischere Reaktionen auf sich ändernde Netzwerkbedingungen zu ermöglichen.

Künftige CNI-Versionen könnten beispielsweise dynamische Aktualisierungen bestehender Netzwerkkonfigurationen oder dynamische Richtlinienaktualisierungen als Reaktion auf Sicherheitsanforderungen (zum Beispiel Firewall-Regeln) oder Anforderungen an die Netzwerkleistung erlauben.