OCI-VCN-natives Podnetworking-CNI-Plug-in für Podnetworking verwenden

Informieren Sie sich über das CNI-Plug-in für OCI-VCN-native Podnetworking für die Podkommunikation auf Worker-Knoten in Clustern, die mit der Kubernetes Engine (OKE) erstellt wurden.

Das OCI-VCN-native Podnetzwerk-CNI-Plug-in stellt IP-Adressen für Pods aus dem CIDR-Block eines VCN bereit. Mit dem CNI-Plug-in für OCI-VCN-native Podnetworking können andere Ressourcen innerhalb desselben Subnetzes (oder eines anderen Subnetzes) direkt mit Pods in einem Kubernetes-Cluster kommunizieren. Pod-IP-Adressen können direkt von anderen VCNs, die mit diesem VCN verbunden sind (Peered) und von On-Premise-Netzwerken weitergeleitet werden.

Da Pods direkt routbar sind, können Sie die native VCN-Funktionalität verwenden, um:

Steuern Sie den Zugriff auf und von Pods mit Sicherheitsregeln, die als Teil von Netzwerksicherheitsgruppen (empfohlen) oder Sicherheitslisten definiert sind. Die Sicherheitsregeln gelten für alle Pods in allen Worker-Knoten, die mit dem Podsubnetz verbunden sind, das für einen Knotenpool angegeben ist. Siehe Netzwerksicherheitsgruppen und Sicherheitslisten.
Überwachen Sie den Traffic zu, von und zwischen Pods mit VCN-Flowlogs für Fehlerbehebungs- und Complianceauditingzwecke. Siehe VCN-Flowlogs.
Leiten Sie eingehende Anforderungen basierend auf Routing-Policys, die durch Routingregeln und Routentabellen angegeben werden, an Pods weiter. Siehe VCN-Routentabellen.

Wenn Sie das CNI-Plug-in für OCI-VCN-natives Podnetzwerk verwenden, sind Worker-Knoten mit zwei Subnetzen verbunden, die für den Knotenpool angegeben sind:

Worker-Knotensubnetz: Das Worker-Knotensubnetz unterstützt die Kommunikation zwischen Prozessen, die auf der Cluster-Control Plane ausgeführt werden (wie kube-apiserver, kube-controller-manager, kube-scheduler) und Prozessen, die auf dem Worker-Knoten ausgeführt werden (wie kubelet, kube-proxy). Das Worker-Knotensubnetz kann privat oder öffentlich sein und ein regionales Subnetz (empfohlen) oder auf verschiedenen AD-spezifischen Subnetzen (eines in jeder Availability-Domain in der Region) sein.
Podsubnetz: Das Podsubnetz unterstützt die Kommunikation zwischen Pods und den direkten Zugriff auf einzelne Pods mit privaten Pod-IP-Adressen. Das Podsubnetz muss privat sein und ein regionales Subnetz sein. Mit dem Podsubnetz können Pods mit anderen Pods auf demselben Worker-Knoten, mit Pods auf anderen Worker-Knoten, mit OCI-Services (über ein Servicegateway) und mit dem Internet (über ein NAT-Gateway) kommunizieren. Sie geben ein einzelnes Podsubnetz für alle Pods an, die auf Worker-Knoten in einem Knotenpool ausgeführt werden. Sie können dasselbe Podsubnetz oder verschiedene Podsubnetze für verschiedene Knotenpools in einem Cluster angeben. Sie können dasselbe Podsubnetz für Knotenpools in verschiedenen Clustern angeben.

Das Worker-Knotensubnetz und das Podsubnetz müssen sich im selben VCN befinden. In einigen Fällen können das Worker-Knotensubnetz und das Podsubnetz dasselbe Subnetz sein (siehe Maximale Anzahl von VNICs und Pods, die von verschiedenen Ausprägungen unterstützt werden). Wenn das Worker-Knotensubnetz und das Podsubnetz dasselbe Subnetz sind, empfiehlt Oracle, Sicherheitsregeln in Netzwerksicherheitsgruppen (und nicht in Sicherheitslisten) zu definieren, um Netzwerktraffic an Worker-Knoten und Pods weiterzuleiten. Das Worker-Knotensubnetz und das Podsubnetz sind zusätzlich zum Kubernetes-API-Endpunktsubnetz und allen für das Cluster definierten Load-Balancer-Subnetzen vorhanden.

Wenn Sie das CNI-Plug-in für OCI-VCN-natives Podnetzwerk verwenden, werden jedem Worker-Knoten mindestens zwei VNICs zugeordnet. Die erste VNIC ist mit dem Worker-Knotensubnetz verbunden. Die zweite VNIC ist mit dem Podsubnetz verbunden. Standardmäßig werden der VNIC 31 IP-Adressen zur Verwendung durch Pods zugewiesen, die auf dem Worker-Knoten ausgeführt werden. Um zu verhindern, dass IP-Adressen ausgehen, werden die IP-Adressen im Podsubnetz vorab zugewiesen, bevor Pods im Cluster erstellt werden.

Wenn die für den Knotenpool ausgewählte Ausprägung mehr als zwei VNICs unterstützt, können die zusätzlichen VNICs mit dem Podsubnetz verbunden werden, um weitere IP-Adressen zur Unterstützung weiterer Pods bereitzustellen.

Sie können die maximale Anzahl von Pods angeben, die auf einem einzelnen Worker-Knoten in einem Knotenpool ausgeführt werden sollen, bis zu einem Grenzwert von 110. Der Grenzwert von 110 wird von Kubernetes festgelegt. Wenn Sie mehr als 31 Pods auf einem einzelnen Worker-Knoten wünschen, muss die für den Knotenpool angegebene Ausprägung drei oder mehr VNICs unterstützen (eine VNIC für die Verbindung mit dem Worker-Knotensubnetz und mindestens zwei VNICs für die Verbindung mit dem Podsubnetz). Siehe Maximale Anzahl von VNICs und Pods, die von verschiedenen Ausprägungen unterstützt werden.

Wenn Sie den Adressraum des Podsubnetzes sparen möchten, senken Sie die maximale Anzahl von Pods, die Sie auf einem einzelnen Worker-Knoten ausführen möchten, und reduzieren Sie so die Anzahl der IP-Adressen, die im Podsubnetz vorab zugewiesen werden.

Beachten Sie Folgendes, wenn Sie das OCI-VCN-native Podnetworking-CNI-Plug-in verwenden:

Sie können das CNI-Plug-in für OCI-VCN-natives Podnetzwerk sowohl mit virtuellen Knotenpools als auch mit verwalteten Knotenpools verwenden.
Sie können das OCI-VCN-native Podnetzwerk-CNI-Plug-in mit selbstverwalteten Knoten verwenden, vorausgesetzt, die Control-Plane-Knoten des Clusters führen Kubernetes-Version 1.27.10 (oder höher) aus. Weitere Informationen finden Sie unter Mit selbstverwalteten Knoten arbeiten.
Sie können das OCI-VCN-native Podnetworking-CNI-Plug-in nur mit Clustern verwenden, auf denen Kubernetes 1.22 oder höher ausgeführt wird (siehe CNI-Plug-in für OCI-VCN-natives Podnetworking für Podnetzwerk verwenden). Weitere Informationen finden Sie unter Pod Networking.
Wenn Sie das OCI-CNI-Plug-in für VCN-natives Podnetzwerk verwenden und ein OKE-Image als Basisimage für Worker-Knoten angeben möchten, wählen Sie kein OKE-Image aus, das vor Juni 2022 freigegeben wurde.
Wenn Sie das OCI-VCN-native Podnetzwerk-CNI-Plug-in verwenden und Traffic von einem On-Premise-Netzwerk an einen Pod weiterleiten möchten, beachten Sie, dass die IP-Adresse des Pods nicht persistent ist, wenn der Pod neu erstellt wird. Beispiel: Ein Nginx-Pod könnte zunächst 10.0.0.5 als IP-Adresse aufweisen. Wenn der Pod jedoch gelöscht und neu erstellt wird, kann der Pod eine andere IP-Adresse aufweisen (z.B. 10.0.0.8).
Service-Mesh-Produkte (wie Istio und Linkerd) werden unterstützt, wenn das OCI VCN-native Pod Networking-CNI-Plug-in für Podnetzwerke verwendet wird. Mit Ausnahme des Istio-Add-ons ist der Support derzeit auf Oracle Linux 7 beschränkt (Oracle Linux 8-Support ist geplant). Das Istio-Add-on wird sowohl mit Oracle Linux 7 als auch mit Oracle Linux 8 unterstützt. Worker-Knoten müssen Kubernetes 1.26 (oder höher) ausführen.

Sicherheitsregeln für Worker-Knoten und -Pods

Wenn Sie das OCI-VCN-native Podnetworking-CNI-Plug-in für das Podnetzwerk verwenden, sind bestimmte Sicherheitsregeln für das Podsubnetz und das Worker-Knotensubnetz erforderlich. Siehe Sicherheitsregeln für Podsubnetze.

Maximale Anzahl von VNICs und Pods, die von verschiedenen Ausprägungen unterstützt werden

Die maximale Anzahl von VNICs (und damit die maximale Anzahl von Pods) für Worker-Knoten in einem Knotenpool hängt von der Ausprägung ab, die Sie für den Knotenpool auswählen.

Informationen zur maximalen Anzahl von VNICs für eine bestimmte Ausprägung finden Sie unter Compute-Ausprägungen.

Um die maximale Anzahl von Pods in einem Knotenpool einer bestimmten Ausprägung zu berechnen, verwenden Sie die folgende Gleichung:

Maximum number of Pods per node = MIN( (Number of VNICs - 1) * 31 ), 110)

Zusätzliche IAM-Policy für den Zugriff auf Ressourcen mit IPv6-Adressen

Um das OCI-VCN-native Pod-Networking-CNI-Plug-in zu verwenden, bei dem die zugehörigen Ressourcen eines Clusters (wie Kubernetes-API-Endpunkt, Load Balancer und Worker-Knoten) IPv6-Adressen aufweisen, fügen Sie eine Policy-Anweisung ähnlich der folgenden in eine IAM-Policy ein:

Allow any-user to use ipv6s in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Zusätzliche IAM-Policy, wenn sich ein Cluster und die zugehörigen Ressourcen in verschiedenen Compartments befinden

Um das OCI-CNI-Plug-in für VCN-natives Podnetzwerk in dem ungewöhnlichen Szenario zu verwenden, in dem sich die zugehörigen Ressourcen eines Clusters (wie Knotenpools, VCN- und VCN-Ressourcen) in einem anderen Compartment als das Cluster selbst befinden, müssen Sie Policy-Anweisungen wie die folgenden in eine IAM-Policy aufnehmen:

Allow any-user to manage instances in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use private-ips in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use network-security-groups in tenancy where all { request.principal.type = 'cluster' }

Wenn Sie diese Policy-Anweisungen als zu permissiv erachten, können Sie die Berechtigungen einschränken, um explizit das Compartment anzugeben, zu dem die zugehörigen Ressourcen gehören, und/oder das Cluster mit zugehörigen Ressourcen in einem anderen Compartment explizit anzugeben. Beispiel:

Allow any-user to manage instances in compartment <compartment-ocid-of-nodepool> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use private-ips in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use network-security-groups in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Hierbei gilt:

<compartment-ocid-of-nodepool> ist die OCID des Compartments, zu dem nodepools und Compute-Instanzen gehören.
<compartment-ocid-of-network-resources> ist die OCID des Compartments, zu dem das VCN und die Subnetze gehören.

CNI-Plug-in für OCI-VCN-natives Podnetworking aktualisieren

Wenn Sie das VCN-native Podnetzwerk als Netzwerktyp eines Clusters angeben, verwenden das Cluster und seine Knotenpools zunächst die neueste Version des CNI-Plug-ins für OCI-VCN-natives Podnetzwerk.

Updates des CNI-Plug-ins für OCI-VCN-native Podnetze werden regelmäßig veröffentlicht. Sie können angeben, dass Oracle die Updates automatisch im Cluster bereitstellen soll (Standard). Alternativ können Sie angeben, dass Sie die bereitzustellende Version auswählen möchten. Wenn Sie sich für die Version entscheiden, übernehmen Sie die Verantwortung dafür, das Add-on auf dem neuesten Stand zu halten. Siehe Cluster-Add-ons konfigurieren.

Unabhängig davon, ob Sie oder Oracle für das Deployment von Updates für das OCI-CNI-Plug-in für VCN-natives Podnetzwerk verantwortlich sind, werden die Updates nur angewendet, wenn Worker-Knoten das nächste Mal neu gestartet werden. Um zu bestimmen, ob Updates bereitgestellt wurden und auf das Einspielen warten, prüfen Sie die Daemonset-Logs vcn-native-ip-cni, indem Sie Folgendes eingeben:

kubectl logs -n kube-system -l app=vcn-native-ip-cni --prefix | grep "reboot required"

Interpretieren Sie die Antwort auf den Befehl wie folgt: