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 ein VCN-natives Podnetzwerk als Netzwerktyp eines Clusters angeben, führen das Cluster und seine Knotenpools zunächst die neueste Version des CNI-Plug-ins für OCI-VCN-natives Podnetzwerk aus.

Updates am CNI-Plug-in für OCI-VCN-natives Podnetworking werden in regelmäßigen Abständen veröffentlicht.

In CNI-Plug-in-Versionen für OCI-VCN-natives Podnetworking vor Version 2.3.0 (August 2025) können Sie angeben, dass Oracle die Updates automatisch im Cluster bereitstellen soll. Alternativ können Sie angeben, dass Sie die bereitzustellende Version auswählen möchten. Wenn Sie sich für eine Version entscheiden (und die Version liegt vor Version 2.3.0), übernehmen Sie die Verantwortung, das Add-on auf dem neuesten Stand zu halten. Das CNI-Plug-in für OCI-VCN-natives Podnetzwerk verwendet die Aktualisierungsstrategie RollingUpdate, sodass vorhandene CNI-Plug-in-Pods automatisch beendet werden und neue Pods mit der neuen CNI-Plug-in-Version erstellt werden (weitere Informationen zur Aktualisierungsstrategie RollingUpdate finden Sie unter DaemonSet Updatestrategie in der Kubernetes-Dokumentation). Die Aktualisierungen werden angewendet, wenn die Worker-Knoten das nächste Mal neu gestartet werden.

In OCI VCN-Native Pod Networking CNI-Plug-in Version 2.3.0 (August 2025) und späteren Versionen werden CNI-Plug-in-Updates nie automatisch im Cluster bereitgestellt. Das CNI-Plug-in für OCI-VCN-natives Podnetzwerk verwendet die Aktualisierungsstrategie OnDelete. Daher kann das CNI-Plug-in nur durch explizites Löschen der CNI-Plug-in-Pods aktualisiert werden (weitere Informationen zur Aktualisierungsstrategie OnDelete finden Sie unter DaemonSet-Aktualisierungsstrategie in der Kubernetes-Dokumentation). Mit diesem Ansatz werden unerwartete Neustarts von CNI-Plug-in-Pods bei Clusterupdates vermieden. Version 2.3.0 führt auch eine validierende Zulassungsrichtlinie ein, die das Löschen von CNI-Plugin-Pods einschränkt. Um das CNI-Plugin auf eine neuere Version zu aktualisieren, wenn Sie Version 2.3.0 oder höher verwenden, verwenden Sie eine der folgenden Techniken:

(empfohlen) Neue Knoten im Cluster bereitstellen: Wenn Sie neue Knoten im Cluster bereitstellen, erhalten sie automatisch CNI-Plug-in-Pods, auf denen die neueste CNI-Plug-in-Version ausgeführt wird. Sie können optional Knoten mit CNI-Plug-in-Pods entfernen, auf denen ältere Versionen ausgeführt werden.
Vorhandene Knoten im Cluster aktualisieren: Sie können die CNI-Plug-in-Version auf vorhandenen Knoten aktualisieren, indem Sie die vorhandenen CNI-Plug-in-Pods löschen. Sie müssen die validierende Zulassungsrichtlinie entfernen, die das Löschen von CNI-Plug-in-Pods einschränkt, die vorhandenen CNI-Plug-in-Pods löschen und dann die Richtlinie wiederherstellen. Mit DaemonsetController werden die CNI-Plug-in-Pods neu erstellt, wobei die neueste CNI-Plug-in-Version ausgeführt wird. Führen Sie die folgenden Schritte aus:
1. Identifizieren Sie die CNI-Plug-in-Pods der vorhandenen Knoten, die aktualisiert werden sollen, indem Sie Folgendes eingeben:
```
kubectl get pods -n kube-system -l app=vcn-native-ip-cni
```
2. Löschen Sie die Validierungszulassungs-Policy, damit Sie die CNI-Plug-in-Pods wie folgt löschen können:
  1. Speichern Sie die validierende Zulassungs-Policy und das validierende Zulassungs-Policy-Binding unter vap-policy.yaml und vap-binding.yaml, damit Sie sie später wiederherstellen können, indem Sie die folgenden Befehle eingeben:
```
kubectl get validatingadmissionpolicy npn-pod-deletion-deny-policy -o yaml > vap-policy.yaml
```
```
kubectl get validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding -o yaml > vap-binding.yaml
```
  2. Löschen Sie die validierende Zulassungs-Policy und das validierende Zulassungs-Policy Binding, indem Sie die folgenden Befehle eingeben:
```
kubectl delete validatingadmissionpolicy npn-pod-deletion-deny-policy
```
```
kubectl delete validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding
```
3. Löschen Sie die CNI-Plug-in-Pods, die Sie zuvor identifiziert haben, indem Sie den folgenden Befehl für jeden Pod eingeben:
```
kubectl delete pod <cni-pod-name> -n kube-system
```
4. Stellen Sie mithilfe der zuvor erstellten Dateien vap-policy.yaml und vap-binding.yaml die Validierungs-Policy und das Policy Binding wieder her, indem Sie die folgenden Befehle eingeben:
```
kubectl apply -f vap-policy.yaml
```
```
kubectl apply -f vap-binding.yaml
```

Um zu bestimmen, ob Updates bereitgestellt wurden und auf die Anwendung 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: