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 Administratorcluster mit Hochverfügbarkeit
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 die Steuerungsebene V2 aktiviert. Bei Steuerungsebene V2 befinden sich die Knoten der Steuerungsebene für einen Nutzercluster im Nutzercluster selbst.
Wenn Sie Steuerungsebene 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, dass die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt wird. Wir raten davon ab, Kubeception zu verwenden. Wir empfehlen, Steuerungsebene V2 zu aktivieren.
Administratorcluster-Knoten
Ein Administratorcluster hat drei Knoten, auf denen jeder Komponenten der Steuerungsebene ausführt.
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, sodass Sie drei IP-Adressen festlegen müssen. 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 VIP für den Kubernetes API-Server des Administratorclusters reservieren.
Beachten Sie, dass das Feld für diese VIP in der Clusterkonfigurationsdatei controlPlaneVIP heißt. Sie können beispielsweise die folgende virtuelle IP-Adresse 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, -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.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 |
|---|---|---|
| VIP 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
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 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 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:
| 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 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.