🥇Wie erhält ein Pod in Kubernetes eine IP-Adresse

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 Kubernetes-Netzwerkmodell 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 Flanell ein Netzwerk in einem Cluster und als ausführbare Umgebung zu organisieren - Containerd. 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 zahlreiche hervorragende Online-Veröffentlichungen, die erklären, wie Container über ein Netzwerk miteinander kommunizieren. Daher werde ich hier nur einen allgemeinen Überblick über die wichtigsten Konzepte geben und mich auf einen Ansatz beschränken, der die Erstellung von Containern beinhaltet. LinuxBridging und Paketkapselung. Details werden hier ausgelassen, da das Thema Container-Netzwerke einen eigenen Artikel verdient. Links zu einigen besonders informativen und aufschlussreichen Publikationen finden Sie unten.

Container auf einem Host

Eine Möglichkeit, die Kommunikation zwischen Containern, die auf demselben Host laufen, über IP-Adressen zu organisieren, besteht darin, … Linux-Bridge. Hierfür werden virtuelle Geräte in Kubernetes (und Docker) erstellt. Veth (virtuelles Ethernet). Ein Ende des Veth-Geräts stellt eine Verbindung zum Netzwerk-Namespace des Containers her, das andere Ende mit Linux-Brücke im Host-Netzwerk.

Alle Container auf einem einzelnen Host haben ein Ende des veth, das mit einer Bridge verbunden ist, über die sie über IP-Adressen miteinander kommunizieren können. LinuxDie Bridge verfügt außerdem über eine IP-Adresse und fungiert als Gateway für ausgehenden (Egress-)Traffic von Pods, die für andere Knoten bestimmt sind.

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. vxlan, 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?

CRI (Container Runtime Interface) 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?

Projekt CNI Es stellt Spezifikation eine universelle Netzwerklösung zu organisieren für Linux-Container. Darüber hinaus umfasst es Plugins, 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 Kube-Controller-Manager, 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: Architektur der Containerd CRI-Plugins.

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 Containerd CRI.

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] в Containerd-Konfigurationsdatei.

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-cni als Init-Container.
Install-cni erstellt CNI-Konfigurationsdatei (/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 CNI-Plugin Flannelunter 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 wird Folgendes erstellt Linux-Brücke mit «name»: «cni0», was in der Konfiguration angegeben ist. Anschließend wird für jeden Pod ein veth-Paar erstellt. Ein Ende wird mit dem Netzwerk-Namespace des Containers verbunden, das andere wird eingebunden in Linux-Bridge im Host-Netzwerk. CNI-Plugin Bridge verbindet alle Host-Container mit 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 Host-lokales IPAM-Plugin CNI 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 Twitter oder an der Adresse hello@ronaknathani.com. 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!