IP-Adressen planen

Dieses Dokument enthält ein Beispiel für die Zuweisung von IP-Adressen für einen Hochverfügbarkeits-Administratorcluster und zwei HA-Nutzercluster.

Hinweise

Weitere 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 das Zuweisen von IP-Adressen in einer Installation, die diese Elemente enthält:

  • 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. Der Load-Balancer wird auf den Clusterknoten ausgeführt, sodass keine zusätzlichen Maschinen für das Load-Balancing erforderlich sind.

Subnetze

In diesem Beispiel wird davon ausgegangen, dass sich jeder Cluster in einer eigenen Ebene-2-Domain und die Cluster in diesen Subnetzen befinden:

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. Beispiel: In Nutzercluster 1 könnte ein Knoten 172.16.21.52 ankündigen und ein anderer Knoten 172.16.21.53.

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-Adressen: Administratorclusterknoten

Sie benötigen drei IP-Adressen für die Knoten Ihres Administratorclusters, auf denen alle Komponenten der Steuerungsebene ausgeführt werden. Sie können beispielsweise die folgenden IP-Adressen für Knoten in Ihrem Administratorcluster verwenden. Die Adressen in diesem Beispiel sind aufeinanderfolgend, das ist jedoch nicht erforderlich:

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 virtuelle IP-Adresse für den Kubernetes API-Server des Administratorclusters reservieren. In der Clusterkonfigurationsdatei heißt dieser controlPlaneVIP. Sie können beispielsweise die folgende IP-Adresse als virtuelle IP-Adresse der Steuerungsebene für den Administratorcluster reservieren:

Virtuelle IP-Adresse der Steuerungsebene für den Administratorcluster
172.16.20.50

Beispiel-IP-Adressen: Nutzercluster 1-Knoten

Beispiel: Sie können 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. Das ist jedoch nicht erforderlich:

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 können. Die VIPs in diesem Beispiel sind aufeinanderfolgende, aber das ist 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.
Das ist eine Voraussetzung 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, das ist jedoch nicht erforderlich:

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 können. Die VIPs in diesem Beispiel sind aufeinanderfolgende, aber das ist keine Voraussetzung.

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:

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.0.0/20
Dienste im Nutzercluster 110.96.0.0/20
Dienste im Nutzercluster 210.96.0.0/20

Die obigen Beispiele veranschaulichen diese Punkte:

  • Der Pod-CIDR-Bereich kann für mehrere Cluster im standardmäßigen Netzwerkmodell im Inselmodus gleich sein. In einem Flat-Modus-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 oder im Inselmodus.

  • Der Dienst-CIDR-Bereich kann für mehrere Cluster gleich sein.

  • In der Regel benötigen Sie mehr Pods als Dienste, sodass Sie für einen bestimmten Cluster wahrscheinlich einen Pod-CIDR-Bereich benötigen, 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

Ihre CIDR-Bereiche dürfen sich 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, Ihr Dienstbereich ist 10.96.0.0/20 und Ihr Pod-Bereich 192.168.0.0/16. Jeglicher 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.

Varianten bei der Zuweisung von IP-Adressen

Das in diesem Dokument gezeigte Beispiel zeigt eine Möglichkeit, IP-Adressen für einen bestimmten Installationstyp zuzuweisen. Es gibt jedoch verschiedene Möglichkeiten, GKE on Bare Metal zu installieren. Die gewählte Variante wirkt sich auf die Planung Ihrer IP-Adressen aus.

Beispielsweise können Sie Cluster ohne Hochverfügbarkeit verwenden oder Ihre Clusterknoten auf mehrere Ebene-2-Domains verteilen. Möglicherweise entscheiden Sie sich für die Verwendung eines Netzwerks im flachen Modus anstelle eines Netzwerks im Inselmodus.

Beispiele für die Angabe von IP-Adressen in Clusterkonfigurationsdateien für verschiedene Arten von Installationen finden Sie unter Beispiele für Clusterkonfiguration.

Weitere Informationen zum Planen Ihrer IP-Adressen für verschiedene Installationsarten finden Sie in den folgenden Dokumenten: