IP-Adressen planen

In diesem Dokument wird beschrieben, wie Sie Ihre IP-Adressen für eine Installation von Google Distributed Cloud planen.

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 Hochverfügbarkeits-Administratorcluster

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

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

In diesem Beispiel ist für die Nutzercluster Controlplane V2 aktiviert. Bei Controlplane V2 befinden sich die Knoten der Steuerungsebene für einen Nutzercluster im Nutzercluster selbst.

Wenn Sie Controlplane V2 nicht für Ihre Nutzercluster aktivieren möchten, finden Sie weitere Informationen unter IP-Adressen planen (kubeception). Der Begriff kubeception bezieht sich auf den Fall, in dem die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt wird. Wir raten von der Verwendung von kubeception ab. Wir empfehlen, Controlplane V2 zu aktivieren.

Administratorcluster-Knoten

Ein Administratorcluster besteht aus drei Knoten, auf denen jeweils Komponenten der Steuerungsebene ausgeführt werden.

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

Der Administratorcluster in diesem Beispiel hat drei Knoten. Daher müssen Sie drei IP-Adressen festlegen. Sie können beispielsweise die folgenden IP-Adressen für Knoten im Administratorcluster reservieren:

Administratorcluster IP-Adressen
Hochverfügbarkeits-Administratorcluster 172.16.20.2–172.16.20.4

Beispiel-IP-Adressen: VIP für den Administratorcluster

Sie müssen eine virtuelle IP-Adresse für den Kubernetes API-Server des Administratorclusters reservieren. In der Clusterkonfigurationsdatei heißt das Feld für diese VIP controlPlaneVIP. Sie können beispielsweise die folgende VIP für den Kubernetes API-Server des Administratorclusters reservieren:

VIP IP-Adresse
VIP für den Kubernetes API-Server des Administratorclusters 172.16.20.30

Beispiel-IP-Adressen: Nutzercluster 1-Knoten

Für einen Nutzercluster mit acht Knoten müssen Sie neun IP-Adressen reservieren. Die zusätzliche Adresse ist erforderlich, da sie während des Clusterupgrades, der Aktualisierung und der automatischen Reparatur des Clusters 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.10

Beispiel-IP-Adressen: VIPs für Nutzercluster 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
Virtuelle IP-Adresse für den Kubernetes API-Server von Nutzercluster 1 Konfiguriert auf dem Load-Balancer für Nutzercluster 1 172.16.21.30
Ingress-VIP für Nutzercluster 1 Konfiguriert auf dem Load-Balancer für Nutzercluster 1 172.16.21.31
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.31–172.16.21.40

Beispiel-IP-Adressen: Nutzercluster 2-Knoten

Bei einem Nutzercluster mit fünf Knoten müssen Sie sechs IP-Adressen reservieren. Die zusätzliche Adresse ist erforderlich, da sie während des Clusterupgrades, der Aktualisierung und der automatischen Reparatur des Clusters 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.7

Beispiel-IP-Adressen: VIPs für Nutzercluster 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
VIP für den Kubernetes API-Server für Nutzercluster 2 Auf dem Load-Balancer für Nutzercluster 2 konfiguriert 172.16.22.30
Ingress-VIP für Nutzercluster 2 Auf dem Load-Balancer für Nutzercluster 2 konfiguriert 172.16.22.31
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.31–172.16.22.40

Beispiel-IP-Adressen: Pods und Dienste

Bevor Sie einen Cluster erstellen, müssen Sie einen CIDR-Bereich für Pod-IP-Adressen und einen weiteren 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 einen Dienstbereich für einen Nutzercluster ist 10.96.0.0/20, also nur 2^(32 - 20) = 2^12 Adressen.

Ü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