IP-Adressen planen (kubeception)

In diesem Dokument wird beschrieben, wie Sie Ihre IP-Adressen für eine Installation von Google Distributed Cloud planen, die Nutzercluster enthält, die kubeception verwenden.

Was ist kubeception?

Mit dem Begriff kubeception wird das Konzept vermittelt, dass ein Kubernetes-Cluster zum Erstellen und Verwalten anderer Kubernetes-Cluster verwendet wird. Im Kontext von Google Distributed Cloud bezieht sich Kubeception auf den Fall, dass die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten in einem Administratorcluster ausgeführt wird.

Wir raten davon ab, kubeception zu verwenden. Wir empfehlen stattdessen die Verwendung von Steuerungsebene v2. Bei Steuerungsebene V2 befinden sich die Knoten der Steuerungsebene für den Nutzercluster im Nutzercluster selbst.

Hinweise

Lesen Sie die Übersicht über Google Distributed Cloud und die Übersicht über die Installation.

Beispiel für die Zuweisung von IP-Adressen

Dieser Abschnitt enthält ein Beispiel für die Zuweisung statischer IP-Adressen in einer Installation, die diese Elemente enthält:

  • Eine Administrator-Workstation

  • Einen Administratorcluster

  • Ein Hochverfügbarkeits-Nutzercluster (HA) mit fünf Worker-Knoten

  • Ein Nicht-HA-Nutzercluster mit vier Worker-Knoten

Administratorcluster-Knoten

Der Administratorcluster hat sieben Knoten:

  • Einen Knoten, auf dem die Steuerungsebene für den Administratorcluster ausgeführt wird
  • Zwei Knoten, die Add-ons für den Administratorcluster ausführen
  • Drei Knoten, auf denen die Steuerungsebene für den HA-Nutzercluster ausgeführt wird
  • Einen Knoten, auf dem die Steuerungsebene für den Nicht-HA-Nutzercluster ausgeführt wird

Load-Balancing

Angenommen, die Cluster verwenden den Load-Balancer MetalLB. Dieser Load-Balancer wird auf den Clusterknoten ausgeführt, sodass keine zusätzlichen VMs für das Load-Balancing erforderlich sind

Subnetze

In diesem Beispiel wird davon ausgegangen, dass sich jeder Cluster in einem eigenen VLAN befindet und die Cluster sich in diesen Subnetzen befinden:

VMs Subnetz Standardgateway
Administrator-Workstation und Administratorcluster 172.16.20.0/24 172.16.20.1
Nutzercluster 1 172.16.21.0/24 172.16.21.1
Nutzercluster 2 172.16.22.0/24 172.16.22.1

Das folgende Diagramm zeigt die drei VLANs und Subnetze. Beachten Sie, dass VIPs nicht in Verbindung mit einem bestimmten Knoten in einem Cluster angezeigt werden. Das liegt daran, dass der MetalLB-Load-Balancer wählen kann, welcher Knoten das VIP für einen einzelnen Dienst ankündigt. In Nutzercluster 1 könnte beispielsweise ein Worker-Knoten 172.16.21.31 und ein anderer Worker-Knoten 172.16.21.32 bekannt geben.

Screenshot: IP-Adressen für einen Administratorcluster und zwei Nutzercluster.
IP-Adressen für einen Administratorcluster und zwei Nutzercluster (zum Vergrößern klicken)

Beispiel-IP-Adresse: Administrator-Workstation

In diesem Beispiel befindet sich die Administrator-Workstation im selben Subnetz wie der Administratorcluster: 172.16.20.0/24. Eine Adresse in der Nähe der Knotenadressen wäre für die Administrator-Workstation geeignet. Beispiel: 172.16.20.20.

Beispiel-IP-Adressen: Administratorclusterknoten

Für einen Administratorcluster mit sieben Knoten müssen Sie acht IP-Adressen festlegen. Die zusätzliche Adresse ist erforderlich, da sie während des Clusterupgrades, -updates und der automatischen Reparatur benötigt wird. Sie können beispielsweise die folgenden IP-Adressen für Knoten in Ihrem Administratorcluster reservieren:

IP-Adressen für Knoten im Administratorcluster
172.16.20.2–172.16.20.9

Beispiel-IP-Adressen: VIPs im Subnetz des Administratorclusters

Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs festlegen können, die auf dem Load-Balancer für den Administratorcluster konfiguriert werden sollen. Beachten Sie, dass sich die VIPs für die Kubernetes API-Server der Nutzercluster im Subnetz des Administratorclusters befinden. Das liegt daran, dass in diesem Beispiel der Kubernetes API-Server für einen Nutzercluster auf einem Knoten im Administratorcluster ausgeführt wird. Beachten Sie, dass in den Clusterkonfigurationsdateien das Feld, in dem Sie die VIP für einen Kubernetes API-Server angeben, controlPlaneVIP heißt:

VIP IP-Adresse
VIP für den Kubernetes API-Server des Administratorclusters 172.16.20.30
Add-ons-VIP des Administratorclusters 172.16.20.31
VIP für den Kubernetes API-Server des Nutzerclusters 1 172.16.20.32
VIP für den Kubernetes API-Server des Nutzerclusters 2 172.16.20.33

Beispiel-IP-Adressen: Nutzercluster 1-Knoten

Für einen Nutzercluster mit fünf Knoten müssen Sie sechs IP-Adressen reservieren. Die zusätzliche Adresse ist erforderlich, da sie während des Clusterupgrades, -updates und der automatischen Reparatur benötigt wird. Sie können beispielsweise die folgenden IP-Adressen für Knoten im Nutzercluster 1 reservieren:

IP-Adressen für Knoten im Nutzercluster 1
172.16.21.2–172.16.21.7

Beispiel-IP-Adressen: VIPs im Subnetz des Nutzerclusters 1

Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs festlegen, die auf dem Load-Balancer für Nutzercluster 1 konfiguriert werden sollen:

VIP Beschreibung IP-Adresse
Ingress-VIP für Nutzercluster 1 Konfiguriert auf dem Load-Balancer für Nutzercluster 1 172.16.21.30
Dienst-VIPs für Nutzercluster 1 Zehn Adressen für Dienste vom Typ LoadBalancer.
Ist je nach Bedarf auf dem Load-Balancer für Nutzercluster 1 konfiguriert.
Beachten Sie, dass dieser Bereich die Ingress-VIP enthält.
Dies ist eine Anforderung für den MetalLB-Load-Balancer.
172.16.21.30–172.16.21.39

Beispiel-IP-Adressen: Nutzercluster 2-Knoten

Für einen Nutzercluster mit vier Knoten müssen Sie fünf IP-Adressen reservieren. Die zusätzliche Adresse ist erforderlich, da sie während des Clusterupgrades, -updates und der automatischen Reparatur benötigt wird. Sie können beispielsweise die folgenden IP-Adressen für Knoten im Nutzercluster 2 reservieren:

IP-Adressen für Knoten im Nutzercluster 2
172.16.22.2–172.16.22.6

Beispiel-IP-Adressen: VIPs im Subnetz des Nutzerclusters 2

Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs festlegen, die auf dem Load-Balancer für Nutzercluster 2 konfiguriert werden sollen:

VIP Beschreibung IP-Adresse
Ingress-VIP für Nutzercluster 2 Auf dem Load-Balancer für Nutzercluster 2 konfiguriert 172.16.22.30
Dienst-VIPs für Nutzercluster 2 Zehn Adressen für Dienste vom Typ LoadBalancer.
Ist je nach Bedarf auf dem Load-Balancer für Nutzercluster 2 konfiguriert.
Beachten Sie, dass dieser Bereich die Ingress-VIP enthält.
Dies ist eine Anforderung für den MetalLB-Load-Balancer.
172.16.22.30–172.16.22.39

Beispiel-IP-Adressen: Pods und Dienste

Bevor Sie einen Cluster erstellen, müssen Sie einen CIDR-Bereich für Pod-IP-Adressen und einen anderen CIDR-Bereich für die ClusterIP-Adressen von Kubernetes-Diensten angeben.

Legen Sie fest, welche CIDR-Bereiche Sie für Pods und Dienste verwenden möchten. Beispiel:

ZweckCIDR-Bereich
Pods im Administratorcluster192.168.0.0/16
Pods in Nutzercluster 1192.168.0.0/16
Pods in Nutzercluster 2192.168.0.0/16
Dienste im Administratorcluster10.96.232.0/24
Dienste im Nutzercluster 110.96.0.0/20
Dienste im Nutzercluster 210.96.128.0/20

Die obigen Beispiele veranschaulichen diese Punkte:

  • Der Pod-CIDR-Bereich kann für mehrere Cluster identisch sein.

  • In der Regel benötigen Sie mehr Pods als Dienste. Daher benötigen Sie für einen bestimmten Cluster wahrscheinlich einen Pod-CIDR-Bereich, der größer als der Dienst-CIDR-Bereich ist. Der Beispiel-Pod-Bereich für einen Nutzercluster ist 192.168.0.0/16 mit 2^(32 - 16) = 2^16 Adressen. Ein Beispiel für den Dienstbereich für einen Nutzercluster ist 10.96.0.0/20, der nur 2^(32 - 20) = 2^12 Adressen umfasst.

Überlappung vermeiden

Es kann sinnvoll sein, nicht standardmäßige CIDR-Bereiche zu verwenden, um eine Überschneidung mit IP-Adressen zu vermeiden, die in Ihrem Netzwerk erreichbar sind. Die Dienst- und Pod-Bereiche dürfen sich nicht mit einer Adresse außerhalb des Clusters überschneiden, die Sie von innerhalb des Clusters erreichen möchten.

Angenommen, der Dienstbereich lautet 10.96.232.0/24 und der Pod-Bereich lautet 192.168.0.0/16 (192.168.0.1–192.168.255.254). Traffic, der von einem Pod an eine Adresse in einem dieser Bereiche gesendet wird, wird als clusterintern behandelt und erreicht kein Ziel außerhalb des Clusters.

Insbesondere dürfen sich die Bereiche für Dienste und Pods nicht überschneiden mit:

  • IP-Adressen von Knoten in einem beliebigen Cluster

  • Von Load-Balancer-Maschinen verwendete IP-Adressen

  • Von Knoten der Steuerungsebene und Load-Balancern verwendete VIPs

  • IP-Adressen von vCenter-Servern, DNS-Servern und NTP-Servern

Wir empfehlen, dass sich Ihre Dienst- und Pod-Bereiche im privaten Adressbereich RFC 1918 befinden.

Dies ist ein Grund für die Empfehlung, RFC 1918-Adressen zu verwenden. Angenommen, Ihr Pod- oder Dienstbereich enthält externe IP-Adressen. Traffic von einem Pod an eine dieser externen Adressen wird als clusterinterner Traffic behandelt und erreicht das externe Ziel nicht.

DNS-Server und Standardgateway

Bevor Sie Ihre Konfigurationsdateien ausfüllen, müssen Sie die IP-Adresse eines DNS-Servers kennen, der von Ihrer Administrator-Workstation und Ihren Clusterknoten verwendet werden kann.

Sie müssen außerdem die IP-Adresse des Standardgateways für jedes Ihrer Subnetze kennen. In den vorherigen Beispielen ist das Standardgateway für jedes Subnetz die erste Adresse im Bereich. Im Subnetz für den Administratorcluster wird beispielsweise das Standardgateway als 172.16.20.1 angezeigt.

Weitere Informationen

Knoten-IP-Adressen verwalten