Kubernetes-Netzwerke: Bewährte Methoden und Herausforderungen

Wie Kubernetes-Netzwerke funktionieren

Kubernetes ist eine Plattform zur Orchestrierung von Containern, die die Planung, Bereitstellung, Überwachung und den laufenden Betrieb von virtualisierten Containern in Computer-Clustern am eigenen Standort oder in der Cloud verwaltet. Der Open-Source-Code von Kubernetes ist die Grundlage für viele Containerverwaltungsplattformen, wie Amazon Elastic Kubernetes Service, Red Hat OpenShift und SUSE Rancher.

Ein Kubernetes-Implementierung besteht aus den folgenden Hauptelementen:

• Pod. Ein Pod ist ein grundlegendes logisches Objekt in Kubernetes, das zusammengehörige Container in Funktionsgruppen organisiert. Jeder Pod hat seine eigene IP-Adresse und kann einen oder mehrere Container enthalten.
• Services. Kubernetes bietet mehrere dedizierte Dienste, darunter einen Proxy und einen Load Balancer, für die Verwaltung des Datenverkehrs zwischen Pods.
• Worker Node. Ein Worker Node ist ein Server, der Pods hostet und Dienste wie kubelet, etcd und kube-proxy ausführt. Ein Worker Node kann einen oder mehrere Pods hosten.
• Control Node. Der Kontroll- oder Primärknoten ist ein Server, der alle Worker Nodes und Pod-Bereitstellungen in einem Kubernetes-Cluster verwaltet.

Die Elemente einer Kubernetes-Bereitstellung sind zur Steuerung und Kommunikation auf Netzwerke angewiesen. Kubernetes stützt sich auf softwaredefinierte Funktionen zur Konfiguration und Verwaltung der Netzwerkkommunikation im gesamten Cluster.

Kubernetes-Netzwerke umfassen in der Regel vier Hauptkommunikationsvorgänge:

• Container-to-Container. Die Kommunikation zwischen Containern, die innerhalb desselben Pods laufen, ist schnell und effizient; alle Container in einem Pod teilen sich denselben Netzwerk-Namespace, einschließlich Ressourcen wie IP-Adressen und Ports.
• Pod-to-Pod. Diese Kategorie umfasst die Kommunikation zwischen Pods auf demselben Worker Node (Intra-Node-Kommunikation) und zwischen verschiedenen Worker Nodes (Inter-Node-Kommunikation). Kubernetes verwaltet die Details, die erforderlich sind, um Pods zu finden und den Datenverkehr zwischen ihnen zu verwalten.
• Pod-to-Service. Kubernetes-Dienste verfolgen Pods und ihre Details, wie IP-Adressen, Adressänderungen und die Erstellung oder Beendigung von Containern und Pods. Dadurch wird sichergestellt, dass eine Anwendung nur die IP-Adresse des Dienstes und nicht die Details der einzelnen Pods kennen muss.
• External-to-Service. Kubernetes-Regeln und -Richtlinien steuern die eingehende Kommunikation mit dem Kubernetes Cluster, in der Regel aus dem Internet und gesichert mit HTTPS.

All diese Vorgänge hängen von drei grundlegenden Kubernetes-Netzwerkanforderungen ab: Pods müssen in der Lage sein, ohne Netzwerkadressübersetzung miteinander zu kommunizieren; ebenso müssen die Knoten in der Lage sein, ohne NAT mit allen Pods zu kommunizieren. Schließlich muss die IP-Adresse eines Pods auch die gleiche Adresse sein, auf die sich andere Pods und Nodes beziehen, wenn sie mit diesem Pod kommunizieren.

Kubernetes-Netzwerkdienste

Eine Vielzahl von Kubernetes-Netzwerkdiensten ermöglicht es Unternehmen, eine containerisierte Anwendung an die geschäftlichen Anforderungen anzupassen. So kann ein Unternehmen beispielsweise eine Anwendung für externe Benutzer verfügbar machen oder den Zugriff auf einen Cluster beschränken.

Es gibt vier gängige Kubernetes-Netzwerkdienste, die bei der Definition und Anpassung von Workloads helfen:

• ClusterIP. Dieser Dienst erstellt eine virtuelle IP-Adresse in einem Cluster, die die Kommunikation zwischen verschiedenen Diensten innerhalb des Clusters ermöglicht. ClusterIP wird häufig verwendet, um den Ressourcenzugriff auf eine bestimmte Anwendung, zum Beispiel eine Datenbank, zu beschränken.
• ExternalName. Dieser Dienst ermöglicht es einer Arbeitslast, einen Namen anstelle einer ClusterIP zu verwenden.
• LoadBalancer. Dieser Dienst ermöglicht externen Load Balancern die Weiterleitung des eingehenden Datenverkehrs und wird häufig für den externen Zugriff auf Workloads mit Frontends verwendet, um externen Benutzern die Interaktion mit dem Workload zu ermöglichen. Kubernetes erstellt automatisch die Dienste LoadBalancer, NodePort und ClusterIP, um den externen Load Balancer zu unterstützen.
• NodePort. Ähnlich wie ClusterIP hört der NodePort-Dienst einen Port auf einem Node ab und leitet den Datenverkehr an den Port des Pods weiter, auf dem die Arbeitslast ausgeführt wird. Dies ist jedoch keine sichere Methode und wird oft zugunsten von ClusterIP verworfen.

Richtlinien für den Netzwerkverkehr in Kubernetes

Das Kubernetes-Netzwerk unterstützt auch die Verwendung von Netzwerkrichtlinien, die den Verkehrsfluss für Clusteranwendungen steuern und detailliert festlegen, wie Pods und Dienste über das Netzwerk kommunizieren können.

Mehrere Hauptkriterien definieren die Pod-Kommunikation. Pods können mit anderen erlaubten Pods und mit erlaubten Namespaces kommunizieren. Sie können auch mit zulässigen IP-Adressblöcken kommunizieren, die auf Classless-Inter-Domain Routing-Bereichen und Netzwerk-Plug-ins basieren, die zur Unterstützung von Richtlinien entwickelt wurden.

Netzwerkrichtlinien, die Pods und Namespaces einbeziehen, können auch den Datenverkehr zwischen Pods festlegen, um nur zugelassenen Datenverkehr zuzulassen. Dies ist eine wichtige Funktion, da Pods standardmäßig nicht isoliert sind und Datenverkehr von jeder Quelle akzeptieren. Sobald eine Richtlinie implementiert ist, wird der Pod isoliert und verarbeitet nur den Datenverkehr, den die Richtlinie zulässt, und lehnt jeden anderen Datenverkehr ab.

Kubernetes-Netzwerkrichtlinien sind kumulativ, das heißt, wenn mehrere Richtlinien einem Pod unterschiedliche Beschränkungen auferlegen, sieht der Pod die kombinierten Beschränkungen und befolgt sie. Es gibt keine anerkannte Reihenfolge oder Sequenz für die Anwendung von Richtlinien.

Potenzielle Herausforderungen für Kubernetes-Netzwerke

Obwohl Kubernetes der de-facto-Standard für Container-Orchestrierung und -Automatisierung ist, birgt sein Netzwerk-Framework potenzielle Herausforderungen für Anwender.

Häufige Änderungen

Traditionelle Netzwerke neigen dazu, statische IP-Adressen zu verwenden. Sobald beispielsweise eine Instanz wie eine VM oder ein Client-Computer in einem Netzwerk konfiguriert ist, läuft sie normalerweise über einen langen Zeitraum und muss im Idealfall nie geändert werden.

Bei Containern verhält es sich anders: Sie erfordern häufig eine dynamische Netzwerkadressierung für Containermigrationen und ephemere Containerlaufzeiten. Dies kann Probleme im Zusammenhang mit der Containeradressierung und -verwaltung aufwerfen, und die dynamische Änderung von Netzwerkrichtlinien kann für die Kubernetes-Netzwerkverwaltung problematisch sein.

Sicherheitsschwachstellen

Container müssen erheblichen Netzwerkverkehr austauschen. Standardmäßig ist der Verkehr jedoch weder verschlüsselt noch durch Netzwerkrichtlinien eingeschränkt.

Daher müssen Kubernetes-Anwender die Kubernetes-Bereitstellungen mit zusätzlichen Sicherheitsebenen versehen. Verwaltete Kubernetes-Plattformen, Cloud-basierte Kubernetes-Dienste und andere Kubernetes-Plattformen von Drittanbietern können zusätzliche Sicherheitsmaßnahmen bieten, aber Unternehmen müssen unbedingt sicherstellen, dass ihre Sicherheitsanforderungen erfüllt werden.

Bedarf an Automatisierung

Kubernetes-Bereitstellungen hängen von einer umfassenden Automatisierung ab, um die unzähligen dynamischen, oft kurzlebigen Container zu verwalten. Die Automatisierung ist entscheidend für die Definition von Richtlinien für den Containerverkehr, Sicherheitsrichtlinien und den Lastausgleich.

Da menschliche Administratoren nicht in der Lage sind, all diese Details dynamisch zu verwalten, erfordert Kubernetes eine sorgfältige Implementierung der Automatisierungsschicht. Verwaltete Kubernetes-Plattformen, Cloud-basierte Kubernetes-Dienste und andere Kubernetes-Plattformen von Drittanbietern können helfen, indem sie einen gut unterstützten Automatisierungsmechanismus bereitstellen.

Anforderungen an Konnektivität und Kommunikation

Kubernetes-Umgebungen können groß und komplex werden. Dies stellt eine enorme Belastung für containerbasierte Netzwerke in Bezug auf Zuverlässigkeit und Leistungsanforderungen dar.

Jede Unterbrechung des Service- oder Pod-Zugriffs kann die Workload-Leistung ernsthaft beeinträchtigen. Ein Kubernetes-Service-Mesh kann bei der Erkennung von Diensten, der Sichtbarkeit von Anwendungen, dem Routing und dem Fehlermanagement helfen, aber ein gutes Kubernetes-Netzwerkmanagement erfordert dennoch eine sorgfältige Überwachung und Alarmierung, um einen zuverlässigen Netzwerkbetrieb zu gewährleisten.

Kubernetes-Netzwerk-Plug-ins

Kubernetes stützt sich im Wesentlichen auf softwaredefinierte Netzwerkschnittstellen. Der Prozess der manuellen Definition und Erstellung von Netzwerkschnittstellen kann jedoch problematisch und fehleranfällig sein.

Um diese Herausforderung zu bewältigen, haben Containerplattformen eine standardisierte Spezifikation zur Konfiguration von Netzwerkschnittstellen durch Netzwerk-Plug-ins eingeführt. Die am weitesten verbreitete Spezifikation ist CNI, ein Projekt, das von der Cloud Native Computing Foundation entwickelt und gepflegt wird. Kubernetes ist nicht die einzige Containerplattform, die CNI einsetzt. Andere Containerlaufzeiten, die CNI unterstützen, sind Amazon Elastic Container Service, Apache Mesos, Cloud Foundry, OpenShift, OpenSVC und rkt.

Nach der Erstellung kann ein CNI-Plug-in eine Netzwerkdefinition generieren, die Pod-to-Pod- und andere Kommunikationsanforderungen festlegt. CNI verwendet das Plug-in, um die Verbindung herzustellen, Netzwerkressourcen zuzuweisen und diese Ressourcen freizugeben, wenn der Container zerstört wird.

Derzeit gibt es Dutzende von etablierten CNI-Plugins von Drittanbietern, die für die Netzwerkkonfiguration und -sicherheit in containerbasierten Umgebungen entwickelt wurden. Zu den beliebtesten Optionen gehören Calico, Weave, Flannel und Cilium. Unternehmen können auch ihre eigenen CNI-kompatiblen Plug-ins entwickeln und einsetzen, um ihre spezifischen Anforderungen zu erfüllen.