Oracle Cloud Infrastructure - Dokumentation

IPv4 CIDR-Blöcke und Kubernetes-Engine (OKE)

Informieren Sie sich über die CIDR-Blöcke, die bei Verwendung der Kubernetes-Engine (OKE) angegeben werden sollen.

Wenn Sie das VCN und die Subnetze für die Verwendung mit der Kubernetes-Engine konfigurieren, geben Sie CIDR-Blöcke an, um die Netzwerkadressen anzugeben, die den Ressourcen zugewiesen werden können. Die CIDR-Blöcke werden für den Kubernetes-API-Endpunkt, für Worker-Knoten, für Load Balancer und (im Fall von VCN-nativem Podnetzwerk) für Pods verwendet. Siehe Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment.

IPv4 CIDR-Blöcke bei Verwendung des Flannel-CNI-Plug-ins für Podnetworking

Wenn Sie ein Cluster mit der Kubernetes-Engine erstellen und das Flannel-CNI-Plug-in für Podnetworking verwenden, geben Sie Folgendes an:

Beachten Sie Folgendes, wenn Sie das Flannel-CNI-Plug-in für das Podnetzwerk verwenden:

  • Sie können das Flannel-CNI-Plug-in für Podnetzwerke mit Clustern verwenden, die verwaltete Knotenpools haben, jedoch nicht mit Clustern, die virtuelle Knotenpools aufweisen.
  • Der CIDR-Block, den Sie für das VCN und die Subnetze angeben, darf sich nicht mit dem CIDR-Block überschneiden, den Sie für die Kubernetes-Services und -Pods angeben.
  • Das Subnetz des Kubernetes-API-Endpunkts erfordert nur einen kleinen CIDR-Block, da für das Cluster nur eine IP-Adresse in diesem Subnetz erforderlich ist. Ein /29-CIDR-Block mit Netzwerkadressen ist in der Regel für das Kubernetes-API-Endpunktsubnetz ausreichend (es sei denn, Sie möchten denselben CIDR-Block für mehrere Cluster verwenden, in diesem Fall geben Sie einen größeren CIDR-Block an).
  • Die CIDR-Blöcke, die Sie für im Cluster ausgeführte Pods angeben, dürfen sich nicht mit den CIDR-Blöcken überschneiden, die Sie für Subnetze für den Kubernetes-API-Endpunkt, die Worker-Knoten und Load Balancer angeben.
  • Jedem Pod, der auf einem Worker-Knoten ausgeführt wird, wird eine eigene Netzwerkadresse zugewiesen. Kubernetes Engine weist jedem Worker-Knoten in einem Cluster einen CIDR-Netzwerkadressblock vom Typ /25 zu, um Pods zuzuweisen, die auf diesem Knoten ausgeführt werden. Ein CIDR-Block der Größe /25 entspricht 128 eindeutigen IP-Adressen, von denen eine reserviert ist. Daher können den Pods, die auf jedem Worker-Knoten ausgeführt werden, maximal 127 Netzwerkadressen zugewiesen werden (mehr als ausreichend, da die Anzahl der Pods pro Knoten auf 110 begrenzt ist).
  • Wenn Sie ein Cluster erstellen, geben Sie einen Wert für die Eigenschaft CIDR-Block für Pods des Clusters an, entweder implizit im Workflow "Schnellerstellung" oder explizit im Fall des Workflows "Benutzerdefinierte Erstellung". Nach Erstellen des Clusters können Sie seine Eigenschaft CIDR-Block für Pods nicht mehr ändern. Die Eigenschaft CIDR-Block für Pods des Clusters begrenzt die maximale Gesamtanzahl der Netzwerkadressen, die für die Zuweisung zu Pods verfügbar sind, die auf allen Knoten im Cluster ausgeführt werden. Sie begrenzt daher effektiv die Anzahl der Knoten im Cluster. Standardmäßig ist die Eigenschaft CIDR-Block für Pods des Clusters auf einen CIDR-Block der Größe /16 festgelegt, sodass 65.536 Netzwerkadressen für alle Knoten im Cluster verfügbar sind. Da für jeden Knoten 128 Netzwerkadressen zugewiesen sind, begrenzt die Angabe eines CIDR-Blocks der Größe /16 für die Eigenschaft CIDR-Block für Pods des Clusters für das Cluster des Clusters die Anzahl der Knoten im Cluster auf 512. Dies ist in der Regel ausreichend. Um mehr als 512 Knoten in einem Cluster zu unterstützen, erstellen Sie ein Cluster im Workflow "Benutzerdefinierte Erstellung", und geben Sie einen größeren Wert für die Eigenschaft CIDR-Block für Pods des Clusters an. Beispiel:
    • Um ein Cluster mit 2.000 Knoten zu unterstützen, geben Sie einen /14-CIDR-Block für die Eigenschaft Pods-CIDR-Block des Clusters an. Dieser Block enthält 262.144 Netzwerkadressen, was ausreichend Platz für 2048/25 CIDR-Blöcke ist.
    • Um ein Cluster mit 5.000 Knoten zu unterstützen, geben Sie einen /12-CIDR-Block für die Eigenschaft Pods-CIDR-Block des Clusters an. Dieser Block enthält 1.048.576 Netzwerkadressen, was ausreichend Platz für 8192 /25 CIDR-Blöcke ist.

IPv4 CIDR-Blöcke bei Verwendung des OCI-VCN-nativen Podnetworking-CNI-Plug-ins für Podnetzwerk

Wenn Sie ein Cluster mit der Kubernetes-Engine erstellen und das OCI-VCN-native Podnetworking-CNI-Plug-in für Podnetworking verwenden, geben Sie Folgendes an:

  • CIDR-Blöcke für die Kubernetes-Services

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

  • Sie können das CNI-Plug-in für OCI-VCN-Native-Pod-Networking für Podnetzwerke mit Clustern mit verwalteten Knotenpools und Clustern mit virtuellen Knotenpools verwenden.
  • Der CIDR-Block, den Sie für das VCN und die Subnetze angeben, darf sich nicht mit dem CIDR-Block überschneiden, den Sie für die Kubernetes-Services angeben.
  • Das Subnetz des Kubernetes-API-Endpunkts erfordert nur einen kleinen CIDR-Block, da für das Cluster nur eine IP-Adresse in diesem Subnetz erforderlich ist. Ein /29-CIDR-Block mit Netzwerkadressen ist in der Regel für das Kubernetes-API-Endpunktsubnetz ausreichend (es sei denn, Sie möchten denselben CIDR-Block für mehrere Cluster verwenden, in diesem Fall geben Sie einen größeren CIDR-Block an).
  • Jeder Worker-Knoten (Instanz) in einem Knotenpool verfügt über eine primäre virtuelle Netzwerkschnittstellenkarte (VNIC) mit einer primären IP-Adresse. Je nach Ausprägung, die Sie für den Knotenpool auswählen, ist jedem Worker-Knoten möglicherweise auch eine oder mehrere sekundäre VNICs zugeordnet. Die VNICs befinden sich im Subnetz, das für die Podkommunikation ausgewählt wurde. Jede VNIC kann mit mehreren sekundären IP-Adressen verknüpft werden. Ein Pod, der auf einem Worker-Knoten ausgeführt wird, kann eine sekundäre IP-Adresse von einer VNIC abrufen, die IP-Adresse sich selbst zuweisen und diese IP-Adresse für die eingehende und ausgehende Kommunikation verwenden. Jede sekundäre VNIC, die an einen Worker-Knoten angehängt ist, kann bis zu 31 sekundäre IP-Adressen zuweisen.
  • Ein /19-CIDR-Block von Netzwerkadressen für das Podsubnetz ist in der Regel ausreichend. Ein Cluster mit einer großen Anzahl von Pods erfordert jedoch einen größeren CIDR-Block mit Netzwerkadressen (z.B. /16).