Notiz. übersetzen: Dieser Artikel, geschrieben von einem SRE-Ingenieur von LinkedIn, geht detailliert auf die innere Magie in Kubernetes ein – genauer gesagt auf das Zusammenspiel von CRI, CNI und kube-apiserver – das passiert, wenn dem nächsten Pod eine IP-Adresse zugewiesen werden muss.
Eine der Grundvoraussetzungen besteht darin, dass jeder Pod eine eigene IP-Adresse haben muss und jeder andere Pod im Cluster in der Lage sein muss, ihn über diese Adresse zu kontaktieren. Es gibt viele Netzwerk-„Anbieter“ (Flannel, Calico, Canal usw.), die bei der Umsetzung dieses Netzwerkmodells helfen.
Als ich anfing, mit Kubernetes zu arbeiten, war mir nicht ganz klar, wie genau Pods ihre IP-Adressen bekommen. Selbst wenn man die Funktionsweise der einzelnen Komponenten verstand, konnte man sich nur schwer vorstellen, dass sie zusammenarbeiten würden. Ich wusste zum Beispiel, wofür CNI-Plugins gedacht sind, hatte aber keine Ahnung, wie sie genau heißen. Aus diesem Grund habe ich beschlossen, diesen Artikel zu schreiben, um Wissen über die verschiedenen Netzwerkkomponenten und deren Zusammenarbeit in einem Kubernetes-Cluster zu teilen, wodurch jeder Pod seine eigene eindeutige IP-Adresse erhält.
Es gibt verschiedene Möglichkeiten, Netzwerke in Kubernetes zu organisieren, ebenso wie es verschiedene Laufzeitoptionen für Container gibt. Diese Veröffentlichung wird verwendet ein Netzwerk in einem Cluster und als ausführbare Umgebung zu organisieren - . Ich gehe außerdem davon aus, dass Sie wissen, wie die Vernetzung zwischen Containern funktioniert, deshalb werde ich nur kurz darauf eingehen, nur um den Kontext zu erhöhen.
Einige grundlegende Konzepte
Container und das Netzwerk: Ein kurzer Überblick
Es gibt viele hervorragende Veröffentlichungen im Internet, die erklären, wie Container über das Netzwerk miteinander kommunizieren. Daher werde ich nur einen allgemeinen Überblick über die Grundkonzepte geben und mich auf einen Ansatz beschränken, der das Erstellen einer Linux-Brücke und das Kapseln von Paketen beinhaltet. Auf Einzelheiten wird verzichtet, da das Thema Container-Vernetzung selbst einen eigenen Artikel verdient. Nachfolgend finden Sie Links zu einigen besonders aufschlussreichen und lehrreichen Veröffentlichungen.
Container auf einem Host
Eine Möglichkeit, die Kommunikation über IP-Adressen zwischen Containern zu organisieren, die auf demselben Host ausgeführt werden, besteht darin, eine Linux-Bridge zu erstellen. Zu diesem Zweck werden virtuelle Geräte in Kubernetes (und Docker) erstellt. . Ein Ende des Veth-Geräts stellt eine Verbindung zum Netzwerk-Namespace des Containers her, das andere Ende mit im Host-Netzwerk.
Alle Container auf demselben Host sind an einem Ende des Veth mit einer Bridge verbunden, über die sie über IP-Adressen miteinander kommunizieren können. Die Linux-Bridge verfügt außerdem über eine IP-Adresse und fungiert als Gateway für ausgehenden Datenverkehr von den Pods, der für andere Knoten bestimmt ist.
Container auf verschiedenen Hosts
Paketkapselung ist eine Methode, die es Containern auf verschiedenen Knoten ermöglicht, über IP-Adressen miteinander zu kommunizieren. Bei Flannel ist die Technologie für diese Chance verantwortlich. , der das Originalpaket in ein UDP-Paket „verpackt“ und es dann an sein Ziel sendet.
In einem Kubernetes-Cluster erstellt Flannel ein VXLAN-Gerät und aktualisiert die Routentabelle auf jedem Knoten entsprechend. Jedes Paket, das für einen Container auf einem anderen Host bestimmt ist, durchläuft das VXLAN-Gerät und wird in ein UDP-Paket gekapselt. Am Zielort wird das verschachtelte Paket extrahiert und an den gewünschten Pod weitergeleitet.
Hinweis: Dies ist nur eine Möglichkeit, die Netzwerkkommunikation zwischen Containern zu organisieren.
Was ist CRI?
ist ein Plugin, das es Kubelet ermöglicht, verschiedene Container-Laufzeitumgebungen zu verwenden. Die CRI-API ist in verschiedene Laufzeiten integriert, sodass Benutzer die Laufzeit ihrer Wahl auswählen können.
Was ist CNI?
Es stellt eine universelle Netzwerklösung für Linux-Container zu organisieren. Darüber hinaus beinhaltet es , verantwortlich für verschiedene Funktionen beim Aufbau eines Pod-Netzwerks. Das CNI-Plugin ist eine ausführbare Datei, die der Spezifikation entspricht (wir werden einige Plugins weiter unten besprechen).
Zuweisung von Subnetzen an Knoten zur Zuweisung von IP-Adressen an Pods
Da jeder Pod in einem Cluster eine IP-Adresse haben muss, ist es wichtig sicherzustellen, dass diese Adresse eindeutig ist. Dies wird erreicht, indem jedem Knoten ein eindeutiges Subnetz zugewiesen wird, von dem aus den Pods auf diesem Knoten dann IP-Adressen zugewiesen werden.
Knoten-IPAM-Controller
Wenn nodeipam als Flag-Parameter übergeben --controllers , weist es jedem Knoten aus dem Cluster-CIDR (d. h. dem IP-Adressbereich für das Cluster-Netzwerk) ein separates Subnetz (podCIDR) zu. Da sich diese PodCIDRs nicht überschneiden, kann jedem Pod eine eindeutige IP-Adresse zugewiesen werden.
Einem Kubernetes-Knoten wird ein podCIDR zugewiesen, wenn er zum ersten Mal beim Cluster registriert wird. Um den podCIDR von Knoten zu ändern, müssen Sie die Registrierung aufheben und sie dann erneut registrieren und zwischendurch entsprechende Änderungen an der Konfiguration der Kubernetes-Kontrollschicht vornehmen. Sie können den podCIDR eines Knotens mit dem folgenden Befehl anzeigen:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, Container Runtime und CNI-Plugins: So funktioniert alles
Das Planen eines Pods pro Knoten erfordert viele vorbereitende Schritte. In diesem Abschnitt werde ich mich nur auf diejenigen konzentrieren, die in direktem Zusammenhang mit der Einrichtung eines Pod-Netzwerks stehen.
Das Planen eines Pods für einen bestimmten Knoten löst die folgende Ereigniskette aus:
Information: .
Interaktion zwischen Container-Laufzeit und CNI-Plugins
Jeder Netzwerkanbieter verfügt über ein eigenes CNI-Plugin. Die Laufzeit des Containers führt ihn aus, um das Netzwerk für den Pod beim Start zu konfigurieren. Im Fall von Containerd wird das CNI-Plugin vom Plugin gestartet .
Darüber hinaus verfügt jeder Anbieter über einen eigenen Agenten. Es wird auf allen Kubernetes-Knoten installiert und ist für die Netzwerkkonfiguration von Pods verantwortlich. Dieser Agent ist entweder in der CNI-Konfiguration enthalten oder erstellt ihn unabhängig auf dem Knoten. Mithilfe der Konfiguration kann das CRI-Plugin festlegen, welches CNI-Plugin aufgerufen werden soll.
Der Speicherort der CNI-Konfiguration kann angepasst werden; standardmäßig ist es in /etc/cni/net.d/<config-file>. Clusteradministratoren sind auch für die Installation von CNI-Plugins auf jedem Clusterknoten verantwortlich. Ihr Standort ist ebenfalls anpassbar; Standardverzeichnis - /opt/cni/bin.
Bei Verwendung von Containerd können im Abschnitt die Pfade für die Plugin-Konfiguration und Binärdateien festgelegt werden [plugins.«io.containerd.grpc.v1.cri».cni] в .
Da wir Flannel als unseren Netzwerkanbieter verwenden, sprechen wir ein wenig über die Einrichtung:
- Flanneld (Flannels Daemon) wird normalerweise in einem Cluster als DaemonSet mit installiert
install-cnials . Install-cnierstellt (/etc/cni/net.d/10-flannel.conflist) auf jedem Knoten.- Flanneld erstellt ein VXLAN-Gerät, ruft Netzwerkmetadaten vom API-Server ab und überwacht Pod-Updates. Beim Erstellen werden Routen an alle Pods im gesamten Cluster verteilt.
- Diese Routen ermöglichen es Pods, über IP-Adressen miteinander zu kommunizieren.
Für detailliertere Informationen zur Arbeit von Flannel empfehle ich die Nutzung der Links am Ende des Artikels.
Hier ist ein Diagramm der Interaktion zwischen dem Containerd CRI-Plugin und den CNI-Plugins:
Wie Sie oben sehen können, ruft das Kubelet das CRI-Plugin von Containerd auf, um den Pod zu erstellen, das dann das CNI-Plugin aufruft, um das Netzwerk des Pods zu konfigurieren. Dabei ruft das CNI-Plugin des Netzwerkanbieters andere Kern-CNI-Plugins auf, um verschiedene Aspekte des Netzwerks zu konfigurieren.
Interaktion zwischen CNI-Plugins
Es gibt verschiedene CNI-Plugins, deren Aufgabe es ist, beim Aufbau der Netzwerkkommunikation zwischen Containern auf dem Host zu helfen. In diesem Artikel werden drei davon besprochen.
CNI-Plugin Flannel
Bei Verwendung von Flannel als Netzwerkanbieter ruft die CRI-Komponente von Containerd auf unter Verwendung der CNI-Konfigurationsdatei /etc/cni/net.d/10-flannel.conflist.
$ cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cni0",
"plugins": [
{
"type": "flannel",
"delegate": {
"ipMasq": false,
"hairpinMode": true,
"isDefaultGateway": true
}
}
]
}
Das Flannel CNI-Plugin funktioniert in Verbindung mit Flanneld. Beim Start ruft Flanneld podCIDR und andere netzwerkbezogene Details vom API-Server ab und speichert sie in einer Datei /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Das Flannel CNI-Plugin verwendet Daten von /run/flannel/subnet.env um das CNI-Bridge-Plugin zu konfigurieren und aufzurufen.
CNI-Plugin Bridge
Dieses Plugin wird mit der folgenden Konfiguration aufgerufen:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Beim ersten Aufruf erstellt es eine Linux-Bridge mit «name»: «cni0», was in der Konfiguration angegeben ist. Anschließend wird für jeden Pod ein Veth-Paar erstellt. Ein Ende davon ist mit dem Netzwerk-Namespace des Containers verbunden, das andere Ende ist in der Linux-Bridge im Host-Netzwerk enthalten. verbindet alle Host-Container mit einer Linux-Bridge im Host-Netzwerk.
Nachdem die Einrichtung des Veth-Paares abgeschlossen ist, ruft das Bridge-Plugin das hostlokale IPAM-CNI-Plugin auf. Der IPAM-Plugin-Typ kann in der CNI-Konfiguration konfiguriert werden, die das CRI-Plugin zum Aufrufen des Flannel-CNI-Plugins verwendet.
Hostlokale IPAM-CNI-Plugins
Überbrücken Sie CNI-Anrufe mit folgender Konfiguration:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Host-lokales IPAM-Plugin (IP Address MManagement - IP-Adressverwaltung) gibt die IP-Adresse für den Container aus dem Subnetz zurück und speichert die zugewiesene IP auf dem Host in dem im Abschnitt angegebenen Verzeichnis dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Diese Datei enthält die ID des Containers, dem diese IP-Adresse zugeordnet ist.
Beim Aufruf des hostlokalen IPAM-Plugins werden folgende Daten zurückgegeben:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Zusammenfassung
Kube-Controller-Manager weist jedem Knoten einen podCIDR zu. Die Pods jedes Knotens erhalten IP-Adressen aus dem Adressraum im zugewiesenen podCIDR-Bereich. Da sich die PodCIDRs der Knoten nicht überschneiden, erhalten alle Pods eindeutige IP-Adressen.
Der Kubernetes-Clusteradministrator konfiguriert und installiert Kubelet, Container Runtime und Netzwerkanbieter-Agent und kopiert die CNI-Plugins auf jeden Knoten. Beim Start generiert der Netzwerkanbieter-Agent eine CNI-Konfiguration. Wenn ein Pod für einen Knoten geplant ist, ruft das Kubelet das CRI-Plugin auf, um ihn zu erstellen. Wenn Containerd verwendet wird, ruft das Containerd-CRI-Plugin als Nächstes das in der CNI-Konfiguration angegebene CNI-Plugin auf, um das Netzwerk des Pods zu konfigurieren. Dadurch erhält der Pod eine IP-Adresse.
Ich brauchte einige Zeit, um alle Feinheiten und Nuancen all dieser Interaktionen zu verstehen. Ich hoffe, dass diese Erfahrung Ihnen hilft, die Funktionsweise von Kubernetes besser zu verstehen. Wenn ich in irgendetwas falsch liege, kontaktieren Sie mich bitte unter oder an der Adresse . Wenn Sie Aspekte dieses Artikels oder etwas anderes besprechen möchten, können Sie sich gerne an uns wenden. Ich würde gerne mit Ihnen chatten!
Referenzen
Container und Netzwerk
Wie funktioniert Flanell?
CRI und CNI
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- „Ein illustrierter Leitfaden zum Netzwerken in Kubernetes“: , ;
- «".
Source: habr.com