Dieses Dokument enthält ein Beispiel für die Zuweisung von IP-Adressen für einen Administratorcluster mit hoher Verfügbarkeit (HA) und zwei Hochverfügbarkeits-Nutzercluster.
Hinweise
Informationen zu Administratorclustern, Nutzerclustern und Hochverfügbarkeit finden Sie unter Bereitstellungsmodell auswählen.
Beispiel für die Zuweisung von IP-Adressen
Dieser Abschnitt enthält ein Beispiel für die Zuweisung von IP-Adressen in einer Installation mit den folgenden Elementen:
IP-Adressen für Clusterknoten
IP-Adressen für Pods
Cluster-IP-Adressen für Dienste
Virtuelle IP-Adressen (VIPs) für die Steuerungsebenen und Ingress-Proxys
VIPs, die als externe IP-Adressen für Dienste verwendet werden sollen
Administratorcluster-Knoten
Der Administratorcluster in diesem Beispiel hat drei Knoten. Auf jedem Knoten werden Komponenten der Steuerungsebene ausgeführt.
Nutzerclusterknoten
In diesem Beispiel hat jeder Nutzercluster sechs Knoten: drei Knoten der Steuerungsebene und drei Worker-Knoten.
Load Balancing
In diesem Beispiel wird davon ausgegangen, dass die Cluster den gebündelten MetalLB-Load-Balancer verwenden. Da der Load-Balancer auf den Clusterknoten ausgeführt wird, sind keine zusätzlichen Maschinen für das Load-Balancing erforderlich.
Subnetze
In diesem Beispiel wird davon ausgegangen, dass sich jeder Cluster in seiner eigenen Ebene-2-Domain befindet und die Cluster in diesen Subnetzen sind:
| Cluster | Subnetz | Standardgateway |
|---|---|---|
| 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 veranschaulicht die drei 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. Im Nutzercluster 1 könnte ein Knoten beispielsweise 172.16.21.52 und ein anderer Knoten 172.16.21.53 ankündigen.
Beispiel-IP-Adressen: Administratorclusterknoten
Sie benötigen drei IP-Adressen für Ihre Administratorclusterknoten, auf denen alle Komponenten der Steuerungsebene ausführen. Beispielsweise können Sie die folgenden IP-Adressen für Knoten in Ihrem Administratorcluster verwenden. Die Adressen in diesem Beispiel sind aufeinanderfolgend, dies ist jedoch keine Voraussetzung:
| IP-Adressen für Knoten im Administratorcluster |
|---|
| 172.16.20.2–172.16.20.4 |
Beispiel-IP-Adresse: virtuelle IP-Adresse der Steuerungsebene für den Administratorcluster
Sie müssen eine VIP für den Kubernetes API-Server des Administratorclusters reservieren.
In der Clusterkonfigurationsdatei heißt dies controlPlaneVIP.
Sie können beispielsweise die folgende IP-Adresse reservieren, die als virtuelle IP-Adresse der Steuerungsebene für den Administratorcluster verwendet wird:
| Virtuelle IP-Adresse der Steuerungsebene für den Administratorcluster |
|---|
| 172.16.20.50 |
Beispiel-IP-Adressen: Nutzercluster 1-Knoten
Beispiel: Sie könnten die folgenden IP-Adressen für drei Knoten der Steuerungsebene und drei Worker-Knoten im Nutzercluster 1 verwenden. Die Adressen in diesem Beispiel sind aufeinanderfolgend, dies ist jedoch keine Voraussetzung:
| IP-Adressen für Knoten im Nutzercluster 1 |
|---|
| 172.16.21.2–172.16.21.7 |
Beispiel-IP-Adressen: VIPs für Nutzercluster 1
Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs festlegen können, die auf dem Load-Balancer für Nutzercluster 1 konfiguriert werden sollen. Die VIPs in diesem Beispiel sind aufeinanderfolgend. Dies ist jedoch keine Voraussetzung:
| VIP | Beschreibung | IP-Adresse |
|---|---|---|
| Virtuelle IP-Adresse der Steuerungsebene für Nutzercluster 1 | Konfiguriert auf dem Load-Balancer für Nutzercluster 1 | 172.16.21.50 |
| Ingress-VIP für Nutzercluster 1 | Konfiguriert auf dem Load-Balancer für Nutzercluster 1 | 172.16.21.51 |
| 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-Balancer. |
172.16.21.51–172.16.21.60 |
Beispiel-IP-Adressen: Nutzercluster 2-Knoten
Beispiel: Sie könnten die folgenden IP-Adressen für Knoten im Nutzercluster 2 verwenden. Die Adressen in diesem Beispiel sind aufeinanderfolgend, dies ist jedoch keine Voraussetzung:
| 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 können, die auf dem Load-Balancer für Nutzercluster 2 konfiguriert werden sollen. Die VIPs in diesem Beispiel sind aufeinanderfolgend. Dies ist jedoch nicht erforderlich.
| VIP | Beschreibung | IP-Adresse |
|---|---|---|
| Virtuelle IP-Adresse der Steuerungsebene für Nutzercluster 2 | Auf dem Load-Balancer für Nutzercluster 2 konfiguriert | 172.16.22.50 |
| Ingress-VIP für Nutzercluster 2 | Auf dem Load-Balancer für Nutzercluster 2 konfiguriert | 172.16.22.51 |
| 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.51–172.16.22.60 |
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.0.0/20 |
| Dienste im Nutzercluster 1 | 10.96.0.0/20 |
| Dienste im Nutzercluster 2 | 10.96.0.0/20 |
Die obigen Beispiele veranschaulichen diese Punkte:
Der Pod-CIDR-Bereich kann für mehrere Cluster im standardmäßigen Inselmodus-Netzwerkmodell gleich sein. In einem flachen Netzwerk müssen Pods in allen Clustern eindeutige IP-Adressen haben. Weitere Informationen zu den Netzwerkmodellen, die sich auf Pods auswirken, finden Sie unter Netzwerkmodelle im flachen und im Inselmodus.
Der Dienst-CIDR-Bereich kann für mehrere Cluster gleich sein.
Normalerweise benötigen Sie mehr Pods als Dienste. Daher sollten Sie für einen bestimmten Cluster wahrscheinlich einen Pod-CIDR-Bereich verwenden, 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
Achten Sie darauf, dass sich Ihre CIDR-Bereiche nicht mit IP-Adressen überschneiden, die in Ihrem Netzwerk erreichbar sind. Die Dienst- und Pod-Bereiche dürfen sich nicht mit Adressen außerhalb des Clusters überschneiden, die Sie von innerhalb des Clusters erreichen möchten.
Angenommen, der Dienstbereich ist 10.96.0.0/20 und Ihr Pod-Bereich 192.168.0.0/16. Der gesamte Traffic, der von einem Pod an eine Adresse in einem dieser Bereiche gesendet wird, wird als clusterinterner Traffic 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 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.
Variationen bei der Zuweisung von IP-Adressen
Das Beispiel in diesem Dokument zeigt eine Möglichkeit, IP-Adressen für einen bestimmten Installationstyp zuzuweisen. Es gibt jedoch verschiedene Möglichkeiten, Google Distributed Cloud zu installieren, und die ausgewählte Variante wirkt sich auf die Planung Ihrer IP-Adressen aus.
Sie können beispielsweise Cluster ohne Hochverfügbarkeit verwenden oder Ihre Clusterknoten auf mehrere Ebene-2-Domains verteilen. Möglicherweise möchten Sie ein Netzwerk im Flat-Modus anstelle eines Insel-Modus-Netzwerks verwenden.
Beispiele dafür, wie IP-Adressen in Clusterkonfigurationsdateien für verschiedene Installationsarten angegeben werden, finden Sie unter Clusterkonfigurationsbeispiele.
Weitere Informationen zum Planen der IP-Adressen für verschiedene Installationsarten finden Sie in den folgenden Dokumenten:
Netzwerkmodell im flachen vs. Inselmodus
Im flachen Modus haben Pods eindeutige Adressen in mehr als einem Cluster. Passen Sie die Pod-CIDR-Bereiche entsprechend an.
-
Knoten, Pods und Dienste haben sowohl IPv4- als auch IPv6-Adressen. Das IPv6-Netzwerk befindet sich im flachen Modus, das IPv4-Netzwerk kann sich jedoch entweder im Inselmodus oder im flachen Modus befinden. Bei Netzwerken im flachen Modus müssen Sie die Pod-Erreichbarkeit festlegen.
Flaches Netzwerkmodell im IPv4-Modus implementieren
Sie müssen die Pod-Erreichbarkeit festlegen. Machen Sie den Pod-Bereich und den Knotenbereich zu Teilmengen eines größeren Bereichs.
Flat-Mode-Netzwerkmodell mit BGP-Unterstützung implementieren
Sie benötigen Floating-IP-Adressen für die BGP-Lautsprecher in Ihrem Cluster und müssen die IP-Adressen von Peer-Routern angeben.
Gebündelte Load-Balancer mit BGP konfigurieren
Sie benötigen Floating-IP-Adressen für die BGP-Lautsprecher in Ihrem Cluster und müssen die IP-Adressen von Peer-Routern angeben.
Netzwerkverbindungsgateway konfigurieren
Sie müssen die IP-Adressen der Peers und des lokalen Tunnels angeben.