In diesem Dokument wird gezeigt, wie Sie Ihre IP-Adressen für eine Installation von GKE on VMware planen.
Hinweise
Lesen Sie die Übersicht über GKE on VMware 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.
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 angeben, der für Pod-IP-Adressen verwendet werden soll, und einen weiteren CIDR-Bereich, der für die ClusterIP-Adressen von Kubernetes-Diensten verwendet wird.
Legen Sie fest, welche CIDR-Bereiche Sie für Pods und Dienste verwenden möchten. Beispiel:
| Zweck | CIDR-Bereich |
|---|---|
| Pods im Administratorcluster | 192.168.0.0/16 |
| Pods in Nutzercluster 1 | 192.168.0.0/16 |
| Pods in Nutzercluster 2 | 192.168.0.0/16 |
| Dienste im Administratorcluster | 10.96.232.0/24 |
| Dienste im Nutzercluster 1 | 10.96.0.0/20 |
| Dienste im Nutzercluster 2 | 10.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.