Einführung
Kubernetes ist ein leistungsstarkes Container-Orchestrierungssystem, das die Bereitstellung und den Betrieb von containerisierten Anwendungen über mehrere Servercluster hinweg verwalten kann. Kubernetes koordiniert nicht nur die Container-Workloads, sondern stellt auch die Infrastruktur und Tools bereit, die für die Aufrechterhaltung einer zuverlässigen Netzwerkkonnektivität zwischen Ihren Anwendungen und Diensten erforderlich sind.
DieKubernetes cluster networking documentation geben an, dass die Grundanforderungen eines Kubernetes-Netzwerks sind:
Alle Container können mit allen anderen Containern ohne NAT kommunizieren
Alle Knoten können mit allen Containern (und umgekehrt) ohne NAT kommunizieren
Die IP, als die sich ein Container selbst sieht, ist dieselbe IP, als die andere sie sehen
In diesem Artikel wird erläutert, wie Kubernetes diese Netzwerkanforderungen innerhalb eines Clusters erfüllt: Wie Daten in einem Pod, zwischen Pods und zwischen Knoten verschoben werden.
Wir werden auch zeigen, wie ein KubernetesService eine einzelne statische IP-Adresse und einen DNS-Eintrag für eine Anwendung bereitstellen kann, um die Kommunikation mit Diensten zu vereinfachen, die auf mehrere ständig skalierende und wechselnde Pods verteilt werden können.
Wenn Sie mit der Terminologie von Kubernetespods undnodes oder anderen Grundlagen nicht vertraut sind, behandelt unser ArtikelAn Introduction to Kubernetes die allgemeine Architektur und die beteiligten Komponenten.
Betrachten wir zunächst die Netzwerksituation in einem einzelnen Pod.
Pod-Netzwerk
In Kubernetes ist apod die grundlegendste Organisationseinheit: eine Gruppe eng gekoppelter Container, die alle eng miteinander verbunden sind und eine einzige Funktion oder einen einzelnen Dienst ausführen.
In Bezug auf das Netzwerk behandelt Kubernetes Pods ähnlich einer herkömmlichen virtuellen Maschine oder einem einzelnen Bare-Metal-Host: Jeder Pod erhält eine einzelne eindeutige IP-Adresse, und alle Container im Pod teilen sich diese Adresse und kommunizieren überlomiteinander. s Loopback-Schnittstelle unter Verwendung des Hostnamens vonlocalhost. Dies wird erreicht, indem alle Container des Pods demselben Netzwerkstapel zugewiesen werden.
Diese Situation sollte allen bekannt sein, die vor den Tagen der Containerisierung mehrere Services auf einem einzigen Host bereitgestellt haben. Alle Dienste müssen einen eindeutigen Port zum Abhören verwenden, ansonsten ist die Kommunikation unkompliziert und mit geringem Overhead verbunden.
Pod-zu-Pod-Netzwerk
Die meisten Kubernetes-Cluster müssen mehrere Pods pro Knoten bereitstellen. Die Kommunikation von Pod zu Pod kann zwischen zwei Pods auf demselben Knoten oder zwischen zwei verschiedenen Knoten erfolgen.
Pod-to-Pod-Kommunikation auf einem Knoten
Auf einem einzelnen Knoten können mehrere Pods vorhanden sein, die direkt miteinander kommunizieren müssen. Bevor wir die Route eines Pakets zwischen Pods verfolgen, überprüfen wir die Netzwerkeinrichtung eines Knotens. Das folgende Diagramm gibt einen Überblick, den wir im Detail durchgehen werden:
Jeder Knoten verfügt über eine Netzwerkschnittstelle - in diesem Beispieleth0 -, die an das Kubernetes-Clusternetzwerk angeschlossen ist. Diese Schnittstelle befindet sich im Netzwerk-Namespacerootdes Knotens. Dies ist der Standardnamespace für Netzwerkgeräte unter Linux.
So wie Prozessnamespaces es Containern ermöglichen, laufende Anwendungen voneinander zu isolieren, isolieren Netzwerknamespaces Netzwerkgeräte wie Schnittstellen und Bridges. Jedem Pod auf einem Knoten wird ein eigener isolierter Netzwerknamespace zugewiesen.
Pod-Namespaces werden mit einemvirtual ethernet pair wieder mit dem Namespacerootverbunden, im Wesentlichen einer Pipe zwischen den beiden Namespaces mit einer Schnittstelle an jedem Ende (hier verwenden wirveth1 inroot) s Namespace undeth0 im Pod).
Schließlich sind die Pods über eine Brücke,br0, miteinander und mit dereth0-Schnittstelle des Knotens verbunden (Ihr Knoten verwendet möglicherweisecbr0 oderdocker0). Eine Bridge funktioniert im Wesentlichen wie ein physischer Ethernet-Switch, der entweder ARP (Address Resolution Protocol) oder IP-basiertes Routing verwendet, um nach anderen lokalen Schnittstellen zu suchen und den Datenverkehr zu leiten.
Verfolgen wir jetzt ein Paket vonpod1 bispod2:
-
pod1 erstellt ein Paket mit der IP vonpod2 als Ziel
-
Das Paket wird über das virtuelle Ethernet-Paar in den Stammnetzwerk-Namespace übertragen
-
Das Paket fährt mit der Brückebr0 fort
-
Da sich der Ziel-Pod auf demselben Knoten befindet, sendet die Bridge das Paket an das virtuelle Ethernet-Paar vonpod2
-
Das Paket wandert durch das virtuelle Ethernet-Paar in den Netzwerk-Namespace vonpod2und in die Netzwerkschnittstelle des Pods (eth0)
Nachdem wir ein Paket von Pod zu Pod innerhalb eines Knotens verfolgt haben, wollen wir uns ansehen, wie der Datenverkehr zwischen den Knoten verläuft.
Pod-to-Pod-Kommunikation zwischen zwei Knoten
Da jeder Pod in einem Cluster eine eindeutige IP-Adresse hat und jeder Pod direkt mit allen anderen Pods kommunizieren kann, ist ein Paket, das sich zwischen Pods auf zwei verschiedenen Knoten bewegt, dem vorherigen Szenario sehr ähnlich.
Verfolgen wir ein Paket vonpod1 bispod3, das sich auf einem anderen Knoten befindet:
-
pod1 erstellt ein Paket mit der IP vonpod3 als Ziel
-
Das Paket wird über das virtuelle Ethernet-Paar in den Stammnetzwerk-Namespace übertragen
-
Das Paket fährt mit der Brückebr0 fort
-
Die Bridge findet keine lokale Schnittstelle zum Weiterleiten, daher wird das Paket als Standardroute in Richtungeth0 gesendet
-
Optional: Wenn Ihr Cluster eine Netzwerküberlagerung benötigt, um Pakete ordnungsgemäß an Knoten weiterzuleiten, wird das Paket möglicherweise in ein VXLAN-Paket (oder eine andere Netzwerkvirtualisierungstechnik) eingekapselt, bevor Sie zum Netzwerk wechseln. Alternativ kann das Netzwerk selbst mit den richtigen statischen Routen eingerichtet werden. In diesem Fall wandert das Paket nach eth0 und verlässt das Netzwerk unverändert.
-
Das Paket gelangt in das Clusternetzwerk und wird an den richtigen Knoten weitergeleitet.
-
Das Paket tritt ameth0 in den Zielknoten ein
-
Optional: Wenn Ihr Paket eingekapselt wurde, wird es zu diesem Zeitpunkt entkapselt
-
Das Paket fährt mit der Brückebr0 fort
-
Die Bridge leitet das Paket an das virtuelle Ethernet-Paar des Ziel-Pods weiter
-
Das Paket wird über das virtuelle Ethernet-Paar an dieeth0-Schnittstelle des Pods weitergeleitet
Nachdem wir nun wissen, wie Pakete über Pod-IP-Adressen weitergeleitet werden, werfen wir einen Blick auf Kubernetesservices und wie sie auf dieser Infrastruktur aufbauen.
Pod zu Service Networking
Es ist schwierig, Datenverkehr nur mit Pod-IPs an eine bestimmte Anwendung zu senden, da aufgrund der dynamischen Natur eines Kubernetes-Clusters Pods verschoben, neu gestartet, aktualisiert oder neu skaliert werden können. Darüber hinaus verfügen einige Dienste über viele Replikate, sodass ein gewisser Lastausgleich zwischen ihnen erforderlich ist.
Kubernetes löst dieses Problem mitServices. Ein Service ist ein API-Objekt, das eine einzelne virtuelle IP (VIP) einem Satz von Pod-IPs zuordnet. Darüber hinaus stellt Kubernetes einen DNS-Eintrag für den Namen und die virtuelle IP jedes Dienstes zur Verfügung, sodass Dienste einfach nach Namen adressiert werden können.
Die Zuordnung von virtuellen IPs zu Pod-IPs innerhalb des Clusters wird durch denkube-proxy-Prozess auf jedem Knoten koordiniert. Dieser Prozess richtet entwederiptables oder IPVS ein, um VIPs automatisch in Pod-IPs zu übersetzen, bevor das Paket an das Clusternetzwerk gesendet wird. Einzelne Verbindungen werden nachverfolgt, sodass Pakete bei ihrer Rückkehr ordnungsgemäß dekonvertiert werden können. IPVS und iptables können beide den Lastenausgleich einer einzelnen virtuellen Service-IP in mehrere Pod-IPs durchführen, obwohl IPVS bei den verwendeten Lastenausgleichsalgorithmen wesentlich flexibler ist.
[.note] #Note:Diese Übersetzungs- und Verbindungsverfolgungsprozesse finden vollständig im Linux-Kernel statt. kube-proxy liest von der Kubernetes-API und aktualisiert iptables ip IPVS, befindet sich jedoch nicht im Datenpfad für einzelne Pakete. Dies ist effizienter und leistungsfähiger als frühere Versionen von kube-proxy, die als User-Land-Proxy fungierten.
#
Folgen wir der Route, die ein Paket von einem Podpod1 zu einem Dienstservice1 nimmt:
-
pod1 erstellt ein Paket mit der IP vonservice1 als Ziel
-
Das Paket wird über das virtuelle Ethernet-Paar in den Stammnetzwerk-Namespace übertragen
-
Das Paket fährt mit der Brückebr0 fort
-
Die Bridge findet keine lokale Schnittstelle, an die das Paket weitergeleitet werden kann. Daher wird das Paket als Standardroute in Richtungeth0 gesendet
-
Iptables oder IPVS, die mit
kube-proxyeingerichtet wurden, stimmen mit der Ziel-IP des Pakets überein und übersetzen sie von einer virtuellen IP in eine der Pod-IPs des Dienstes, wobei die verfügbaren oder angegebenen Lastausgleichsalgorithmen verwendet werden -
Optional: Ihr Paket ist möglicherweise zu diesem Zeitpunkt eingekapselt, wie im vorherigen Abschnitt erläutert
-
Das Paket gelangt in das Clusternetzwerk und wird an den richtigen Knoten weitergeleitet.
-
Das Paket tritt ameth0 in den Zielknoten ein
-
Optional: Wenn Ihr Paket eingekapselt wurde, wird es zu diesem Zeitpunkt entkapselt
-
Das Paket fährt mit der Brückebr0 fort
-
Das Paket wird überveth1 an das virtuelle Ethernet-Paar gesendet
-
Das Paket durchläuft das virtuelle Ethernet-Paar und gelangt über die Netzwerkschnittstelle voneth0in den Pod-Netzwerk-Namespace
Wenn das Paket aufnode1 zurückkehrt, wird die IP-Übersetzung von VIP zu Pod umgekehrt, und das Paket wird über die Brücke und die virtuelle Schnittstelle zum richtigen Pod zurückgeführt.
Fazit
In diesem Artikel haben wir die interne Netzwerkinfrastruktur eines Kubernetes-Clusters untersucht. Wir haben die Bausteine des Netzwerks besprochen und die Hop-by-Hop-Reise von Paketen in verschiedenen Szenarien detailliert beschrieben.
Weitere Informationen zu Kubernetes finden Sie unterour Kubernetes tutorials tag undthe official Kubernetes documentation.