Eine der Grundanforderungen des Kubernetes-Netzwerkmodells besteht darin, dass jeder Pod eine eigene IP-Adresse haben muss und jeder andere Pod im Cluster diese unter dieser Adresse erreichen kann. Es gibt viele Netzwerkanbieter (Flannel, Calico, Canal usw.), die bei der Implementierung dieses Netzwerkmodells helfen.
Als ich anfing, mit Kubernetes zu arbeiten, war mir nicht ganz klar, wie genau Pods ihre IP-Adressen erhalten. Selbst mit einem Verständnis der Funktionsweise der einzelnen Komponenten war es schwer vorstellbar, dass sie zusammenarbeiten. Ich wusste zum Beispiel, wofür CNI-Plugins gedacht waren, hatte aber keine Ahnung, wie sie heißen. Aus diesem Grund habe ich beschlossen, diesen Artikel zu schreiben, um mein Wissen über verschiedene Netzwerkkomponenten und deren Zusammenarbeit in einem Kubernetes-Cluster zu teilen, sodass jeder Pod seine eigene eindeutige IP-Adresse erhalten kann.
Es gibt verschiedene Möglichkeiten, das Netzwerk in Kubernetes zu organisieren, ebenso wie es verschiedene Laufzeitoptionen für Container gibt. In diesem Beitrag wird Flannel für Cluster-Netzwerke und Containerd als Laufzeit verwendet . Ich gehe auch davon aus, dass Sie wissen, wie die Vernetzung zwischen Containern funktioniert, und werde daher nur kurz darauf eingehen, nur für den Kontext.
Einige grundlegende Konzepte
Container und Vernetzung auf einen Blick
Im Internet gibt es zahlreiche hervorragende Veröffentlichungen, in denen erläutert wird, wie Container über das Netzwerk miteinander kommunizieren. Daher werde ich nur einen allgemeinen Überblick über die grundlegenden Konzepte geben und mich auf einen Ansatz beschränken, der das Erstellen einer Linux-Bridge und das Einkapseln von Paketen umfasst. Die Details werden weggelassen, da das Thema Containernetzwerk einen separaten Artikel verdient. Links zu einigen besonders informativen und informativen Veröffentlichungen finden Sie weiter unten.
Container auf einem einzelnen Host
Eine Möglichkeit, die IP-Adresskommunikation zwischen Containern herzustellen, die auf demselben Host ausgeführt werden, besteht darin, eine Linux-Bridge zu erstellen. Zu diesem Zweck werden in Kubernetes (und Docker ) virtuelle Geräte von veth (virtuelles Ethernet) erstellt . Ein Ende des veth-Geräts stellt eine Verbindung zum Netzwerk-Namespace des Containers her, das andere Ende stellt eine Verbindung zur Linux-Bridge im Host-Netzwerk her.
Alle Container auf demselben Host haben ein Ende des veth mit einer Brücke verbunden, über die sie über IP-Adressen miteinander kommunizieren können. Die Linux-Bridge hat auch eine IP-Adresse und fungiert als Gateway für den Datenverkehr von Pods zu anderen Knoten.
Container auf verschiedenen Hosts
Die Paketkapselung ist eine der Möglichkeiten, mit denen Container auf verschiedenen Hosts über IP-Adressen miteinander kommunizieren können. In Flannel ist die vxlan- Technologie für diese Funktion verantwortlich , die das Originalpaket in ein UDP-Paket "packt" und es dann an sein Ziel sendet.
In einem Kubernetes-Cluster erstellt Flannel ein vxlan-Gerät und erweitert 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 ist in einem UDP-Paket gekapselt. Am Ziel wird das verschachtelte Paket extrahiert und zum gewünschten Pod umgeleitet.
Hinweis: Dies ist nur eine Möglichkeit, die Vernetzung zwischen Containern zu organisieren.
Was ist CRI?
CRI (Container Runtime Interface) ist ein Plugin, mit dem kubelet verschiedene Container-Laufzeitumgebungen verwenden kann. Die CRI-API ist in verschiedene Laufzeitumgebungen integriert, sodass Benutzer die Laufzeit ihrer Wahl auswählen können.
Was ist CNI?
Das CNI-Projekt ist eine Spezifikation für die Organisation einer universellen Netzwerklösung für Linux-Container. Darüber hinaus enthält es Plugins, die für verschiedene Funktionen beim Einrichten des Netzwerks eines Pods verantwortlich sind. Das CNI-Plugin ist eine ausführbare Datei, die der Spezifikation entspricht (wir werden einige der Plugins unten diskutieren).
Subnetz-Hosts zum Zuweisen von IP-Adressen zu Pods
Da jeder Pod im Cluster eine IP-Adresse haben muss, ist es wichtig sicherzustellen, dass diese Adresse eindeutig ist. Dies wird erreicht, indem jedem Host ein eindeutiges Subnetz zugewiesen wird, von dem aus den Pods auf diesem Host IP-Adressen zugewiesen werden.
Host IPAM Controller
Wenn es
nodeipamals Parameter an das --controllers kube-controller-manager-Flag übergeben wird, weist es jedem Knoten aus dem CIDR-Cluster ein separates Subnetz (podCIDR) zu (d. H. Den IP-Adressbereich für das Clusternetzwerk). Da sich diese podCIDRs nicht überlappen, kann jedem Pod eine eindeutige IP-Adresse zugewiesen werden.
Einem Kubernetes-Knoten wird bei der ersten Registrierung beim Cluster ein podCIDR zugewiesen. Um die podCIDR der Knoten zu ändern, müssen Sie sie abmelden und anschließend neu registrieren. In der Zwischenzeit müssen Sie die entsprechenden Änderungen an der Konfiguration der Kubernetes-Steuerungsschicht vornehmen. Sie können die podCIDR eines Knotens mit dem folgenden Befehl anzeigen:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, Container Launcher und CNI Plugins: wie alles funktioniert
Das Planen eines Pods pro Knoten umfasst viele vorbereitende Schritte. In diesem Abschnitt werde ich mich nur auf diejenigen konzentrieren, die in direktem Zusammenhang mit Pod-Netzwerken stehen.
Das Planen eines Pods für einen Knoten löst die folgende Ereigniskette aus:
Hilfe: Containerd CRI Plugin Architecture .
Interaktion zwischen dem Container Launcher und CNI Plugins
Jeder Netzwerkanbieter verfügt über ein eigenes CNI-Plugin. Die Container-Laufzeit startet es, um das Netzwerk für den Pod beim Start zu konfigurieren. Im Falle von Containerd ist das Containerd CRI- Plugin für den Start des CNI-Plugins verantwortlich .
Darüber hinaus hat jeder Anbieter seinen eigenen Agenten. Es ist auf allen Kubernetes-Knoten installiert und für die Vernetzung der Pods verantwortlich. Dieser Agent wird entweder mit der CNI-Konfiguration geliefert oder erstellt sie selbst auf dem Knoten. Die Konfiguration hilft dem CRI-Plugin zu bestimmen, welches CNI-Plugin aufgerufen werden soll.
Der Speicherort der CNI-Konfiguration kann angepasst werden. standardmäßig liegt 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. Das Standardverzeichnis ist /opt/cni/bin.
Bei Verwendung von Containerd können die Pfade für die Konfigurations- und Plugin-Binärdateien in einem Abschnitt
[plugins.«io.containerd.grpc.v1.cri».cni]in der Containerd-Konfigurationsdatei festgelegt werden .
Da wir Flannel als unseren Netzwerkanbieter verwenden, lassen Sie uns ein wenig über die Einrichtung sprechen:
- Flanneld (Flanells Daemon) wird normalerweise als DaemonSet mit
install-cnieinem Init-Container im Cluster installiert . Install-cnischafft eine CNI (/etc/cni/net.d/10-flannel.conflist) Konfigurationsdatei auf jedem Knoten.- Flanneld erstellt ein vxlan-Gerät, ruft Netzwerkmetadaten vom API-Server ab und überwacht Pods auf Aktualisierungen. Beim Erstellen werden Routen für alle Pods im gesamten Cluster verteilt.
- Diese Routen ermöglichen es Pods, über IP-Adressen miteinander zu kommunizieren.
Für weitere Informationen zur Funktionsweise von Flannel empfehle ich die Verwendung 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 kubelet das Containerd CRI-Plugin auf, um einen Pod zu erstellen, der bereits das CNI-Plugin aufruft, um das Netzwerk des Pods zu konfigurieren. Dabei ruft das CNI-Plugin des Netzwerkanbieters andere grundlegende CNI-Plugins auf, um verschiedene Aspekte des Netzwerks zu konfigurieren.
Interaktion zwischen CNI-Plugins
Es gibt verschiedene CNI-Plugins, mit denen das Netzwerk zwischen Containern auf einem Host eingerichtet werden kann. Dieser Artikel konzentriert sich auf drei von ihnen.
Flanell CNI Plugin
Bei Verwendung von Flannel als Netzwerkanbieter ruft die Containerd CRI-Komponente das Flannel CNI-Plugin mithilfe der CNI-Konfigurationsdatei auf
/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 arbeitet mit Flanneld zusammen. Beim Start extrahiert Flanneld die podCIDR und andere netzwerkbezogene Details vom API-Server 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 die Daten von
/run/flannel/subnet.env, um das Bridge-CNI-Plugin zu konfigurieren und aufzurufen.
CNI Plugin Bridge
Dieses Plugin wird mit folgender 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 eine Linux-Bridge mit erstellt
«name»: «cni0», die in der Konfiguration angegeben ist. Dann wird für jede Kapsel ein veth-Paar erstellt. Ein Ende stellt eine Verbindung zum Netzwerk-Namespace des Containers her, das andere Ende geht in die Linux-Bridge im Netzwerk des Hosts. Das CNI Bridge-Plugin verbindet alle Host-Container mit einer Linux-Bridge im Host-Netzwerk.
Nach Abschluss der Konfiguration des veth-Paares ruft das Bridge-Plugin das hostlokale CNI-IPAM-Plugin auf. Der IPAM-Plugin-Typ kann in der CNI-Konfiguration konfiguriert werden, mit der das CRI-Plugin das Flannel-CNI-Plugin aufruft.
Host-lokale IPAM-CNI-Plugins
Bridge CNI ruft das hostlokale IPAM CNI-Plugin mit der folgenden Konfiguration auf:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Host-local IPAM-Stecker ( IP A ddress M anagement - IP-Adress - Management) gibt die IP-Adresse für das Subnetz des Behälters und speichert die ausgewählte IP in dem Host in einem Verzeichnis in Abschnitt
dataDir- /var/lib/cni/networks/<network-name=cni0>/<ip>. Diese Datei enthält die ID des Containers, dem diese IP-Adresse zugewiesen wurde.
Wenn das hostlokale IPAM-Plugin aufgerufen wird, werden die folgenden Daten zurückgegeben:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Zusammenfassung
Kube-Controller-Manager weist jedem Knoten podCIDR zu. Die Pods jedes Knotens erhalten IP-Adressen aus dem Adressraum im zugewiesenen podCIDR-Bereich. Da sich die podCIDRs der Knoten nicht überlappen, erhalten alle Pods eindeutige IP-Adressen.
Der Kubernetes-Clusteradministrator konfiguriert und installiert Kubelet, Container Launcher, Netzwerkprovider-Agent und kopiert CNI-Plugins auf jeden Knoten. Während des Startvorgangs generiert der Agent des Netzwerkanbieters die CNI-Konfiguration. Wenn ein Pod für einen Knoten geplant ist, ruft kubelet das CRI-Plugin auf, um ihn zu erstellen. Wenn Containerd verwendet wird, ruft das Containerd-CRI-Plugin das in der CNI-Konfiguration angegebene CNI-Plugin auf, um das Pod-Netzwerk zu konfigurieren. Dies gibt dem Pod eine IP-Adresse.
Ich habe eine Weile gebraucht, um alle Feinheiten und Nuancen all dieser Interaktionen herauszufinden. Ich hoffe, die gesammelten Erfahrungen werden Ihnen helfen, die Funktionsweise von Kubernetes besser zu verstehen. Wenn ich mich in irgendetwas irre, kontaktiere mich bitte auf Twitter oder unter hello@ronaknathani.com . Sie können sich gerne an uns wenden, wenn Sie Aspekte dieses Artikels oder etwas anderes besprechen möchten. Ich werde gerne mit Ihnen sprechen!
Links
Container und Netzwerk
Wie Flanell funktioniert
CRI und CNI
PS vom Übersetzer
Lesen Sie auch in unserem Blog: