Oracle Cloud Infrastructure-Dokumentation

VCN-native Podnetzwerkressourcen erstellen

In Compute Cloud@Customer können Sie mit VCN-nativem Podnetzwerk den Traffic von Pods direkt verwalten, da Pod-IP-Adressen direkt aus dem VCN-CIDR-Block und nicht aus einem Netzwerk-Overlay wie Flannel Overlay stammen. VCN-natives Podnetzwerk bietet mehr Flexibilität und Kontrolle über den Traffic und ermöglicht die Verwendung verschiedener Sicherheitsregeln.

VCN-natives Podnetzwerk verbindet Knoten in einem Kubernetes-Cluster mit Podsubnetzen im OKE-VCN. Pod-IP-Adressen innerhalb des OKE-VCN können direkt von anderen VCNs, die mit dem OKE-VCN verbunden (peered) sind, und von On-Premise-Netzwerken geroutet werden.

Wenn Sie ein Cluster erstellen, das beim Erstellen eines Clusters VCN-natives Podnetworking verwendet, muss das angegebene VCN ein Subnetz mit dem Namen pod aufweisen. Sie müssen ein Subnetz namens pod angeben, damit das System dieses Subnetz finden kann. Das Podsubnetz enthält Sicherheitsregeln, mit denen Pods auf Control-Plane-Knoten direkt mit Pods auf Worker-Knoten und mit anderen Pods und anderen Ressourcen kommunizieren können. Siehe Podsubnetz erstellen (VCN-nativer Pod). Wenn Sie "VCN-natives Podnetzwerk" auswählen und kein Subnetz mit dem Namen pod aufweisen, verläuft die Clustererstellung nicht erfolgreich.

Wenn Sie einen Knotenpool für ein Cluster erstellen, das VCN-natives Podnetworking verwendet, dient das von Ihnen angegebene Podsubnetz (Podkommunikation > Podkommunikationssubnetz oder --pod-subnet-ids) der Funktion eines Podsubnetzes für Pods auf Worker-Knoten. Dieses Podsubnetz sollte Sicherheitsregeln enthalten, mit denen Pods auf Worker-Knoten direkt mit anderen Pods auf Worker-Knoten und Control-Plane-Knoten kommunizieren können. Sie können optional das Worker-Knotensubnetz als Podsubnetz angeben. Das CIDR des von Ihnen angegebenen Podsubnetzes muss größer als /25 sein. Das Podsubnetz muss größer als das Worker-Knotensubnetz sein.

Wenn Sie VCN-natives Podnetzwerk verwenden, können Sicherheitsregeln es Pods ermöglichen, direkt mit anderen Pods auf demselben Knoten oder auf anderen Knoten im Cluster, mit anderen Clustern, mit anderen Services und mit dem Internet zu kommunizieren.

Knotenausprägungen und Anzahl Pods

Wenn Sie das CNI-Plug-in für OCI-VCN-natives Podnetzwerk verwenden, benötigt jeder Pod eine private IP-Adresse. Standardmäßig werden einer VNIC 31 IP-Adressen zur Verwendung durch Pods zugewiesen, die auf dem Worker-Knoten ausgeführt werden.

Sie können die maximale Anzahl von Pods angeben, die auf einem Worker-Knoten ausgeführt werden sollen. Das Standardmaximum beträgt 31 Pods pro Worker-Knoten. Angabe von maximal 110.

Eine Knotenausprägung und somit ein Worker-Knoten haben mindestens zwei VNICs. Die erste VNIC ist mit dem Worker-Subnetz verbunden. Die zweite VNIC ist mit dem Podsubnetz verbunden. Daher kann ein Worker-Knoten mindestens 31 Pods unterstützen. Wenn Sie mehr als 31 Pods auf einem einzelnen Worker-Knoten verwenden möchten, geben Sie eine Ausprägung für den Knotenpool an, die drei oder mehr VNICs unterstützt: eine VNIC für die Verbindung zum Worker-Knotensubnetz und mindestens zwei VNICs für die Verbindung zum Podsubnetz.

Eine VM.PCAStandard1.4-Standardknotenausprägung kann maximal vier VNICs aufweisen. Der Worker-Knoten kann bis zu 93 Pods unterstützen. Eine VM.PCAStandard.E5. Flex-Knotenausprägung mit fünf OCPUs kann maximal fünf VNICs enthalten, und der Worker-Knoten kann bis zu 110 Pods unterstützen. Ein Knoten darf nicht mehr als 110 Pods enthalten (siehe Limits für Ressourcen, die von Compute Cloud@Customer bereitgestellt werden).

Die folgende Formel fasst die maximale Anzahl von Pods zusammen, die pro Knoten unterstützt werden:

MIN( (Number of VNICs - 1) * 31 ), 110)

Informationen zu allen Knotenausprägungen finden Sie unter Compute-Ausprägungen.

VCN-native Podnetworking-Ressourcen

Mit den Ressourcendefinitionen in den folgenden Abschnitten in diesem Thema wird ein Beispielset mit Netzwerkressourcen für Workload-Cluster erstellt, wenn Sie VCN-natives Podnetworking verwenden. Verwenden Sie diese Konfiguration als Richtlinie, wenn Sie diese Ressourcen erstellen. Sie können die Werte von Eigenschaften wie CIDR-Blöcken und IP-Adressen ändern. Ändern Sie nicht die Werte von Eigenschaften wie das Netzwerkprotokoll, die zustandsbehaftete Einstellung oder die private/öffentliche Einstellung.

Informationen zu bestimmten Ports, die für bestimmte Zwecke geöffnet sein müssen, finden Sie unter Workload-Clusternetzwerkports (VCN-nativer Pod).

Erstellen Sie die folgenden Netzwerkressourcen. Informationen zur Verwendung von Terraform finden Sie unter Terraform-Beispielskripte (VCN-nativer Pod).

Hinweis

Erstellen Sie alle Netzwerkressourcen im selben Compartment.