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.
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:
| 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.