Manuellen Load-Balancing-Modus aktivieren

Wir empfehlen, einen der folgenden Load-Balancing-Modi zu konfigurieren:

  • Im gebündelten Modus stellt Google Distributed Cloud den Load-Balancer bereit und verwaltet ihn. Sie benötigen keine Lizenz für einen Load-Balancer und die Einrichtung ist minimal.

  • Im manuellen Modus verwendet Google Distributed Cloud einen Load-Balancer Ihrer Wahl, z. B. F5 BIG-IP oder Citrix. Der manuelle Load-Balancing-Modus erfordert mehr Konfiguration als der gebündelte Modus.

Manuelles Load-Balancing wird für die folgenden Clustertypen unterstützt:

  • Nutzercluster, für die Steuerungsebene V2 aktiviert ist. Bei Steuerungsebene V2 befinden sich die Knoten der Steuerungsebene für einen Nutzercluster im Nutzercluster selbst.

  • Nutzercluster, die kubeception verwenden. 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. Wenn Steuerungsebene V2 nicht aktiviert ist, verwendet ein Nutzercluster kubeception.

Auf dieser Seite werden die Schritte beschrieben, die Sie ausführen müssen, wenn Sie sich für den manuellen Load-Balancing-Modus entscheiden.

In diesem Thema reservieren Sie IP-Adressen für Knoten der Steuerungsebene und Worker-Knoten für die spätere Verwendung. Außerdem reservieren Sie IP-Adressen für virtuelle IP-Adressen (VIPs) und legen nodePort-Werte fest. Das Konzept besteht darin, dass Sie die zu verwendenden IP-Adressen und nodePort-Werte auswählen und dann in einer Tabelle oder einem anderen Tool notieren. Wenn Sie zum Erstellen der Cluster bereit sind, benötigen Sie die IP-Adressen und nodePort-Werte, um die Konfigurationsdateien für den Administratorcluster und den Nutzercluster sowie die IP-Blockdateien für Ihre Cluster auszufüllen.

Sie benötigen die IP-Adressen und nodePort-Werte auch, wenn Sie den Load-Balancer für Nutzercluster manuell konfigurieren.

Knoten-IP-Adressen reservieren

Beim manuellen Load-Balancing-Modus können Sie kein DHCP verwenden. Sie müssen für Ihre Clusterknoten statische IP-Adressen reservieren. Sie müssen genügend Adressen für die Knoten im Administratorcluster und die Knoten in allen Nutzerclustern reservieren, die Sie erstellen möchten. Weitere Informationen dazu, wie viele Knoten-IP-Adressen reserviert werden müssen, finden Sie unter IP-Adressen planen (Steuerungsebene V2) und IP-Adressen planen (kubeception).

IP-Adressen konfigurieren

Wo Sie die reservierten statischen IP-Adressen konfigurieren, hängt vom Clustertyp und davon ab, ob Controlplane V2 in Ihren Nutzerclustern aktiviert ist.

Hochverfügbarkeits-Administratorcluster

In der folgenden Tabelle wird beschrieben, wofür die IP-Adressen gedacht sind und wo sie für Hochverfügbarkeits-Administratorcluster konfiguriert werden.

Statische IP-Adressen Configuration
Knoten der Steuerungsebene Konfigurationsdatei des Administratorclusters im Abschnitt network.controlPlaneIPBlock.ips
1.16 und niedriger: Add-on-Knoten IP-Blockdatei des Administratorclusters und fügen Sie den Pfad in der Konfigurationsdatei des Administratorclusters in das Feld network.ipMode.ipBlockFilePath ein.

Ab Version 1.28 haben neue Hochverfügbarkeits-Admin-Cluster keine Add-on-Knoten. Daher müssen Sie wie in früheren Versionen keine IP-Adressen für Add-on-Knoten reservieren.

Administratorcluster ohne Hochverfügbarkeit

In der folgenden Tabelle wird beschrieben, wofür die IP-Adressen gedacht sind und wo Sie sie für Administratorcluster ohne Hochverfügbarkeit konfigurieren.

Statische IP-Adressen Configuration
Knoten der Steuerungsebene IP-Blockdatei des Administratorclusters und fügen Sie den Pfad in der Konfigurationsdatei des Administratorclusters in das Feld network.ipMode.ipBlockFilePath ein.
Add-on-Knoten IP-Blockdatei des Administratorclusters

Ab Version 1.28 müssen alle neuen Administratorcluster Hochverfügbarkeitscluster mit drei Knoten der Steuerungsebene sein.

CP V2-Nutzercluster

In der folgenden Tabelle wird beschrieben, wofür die IP-Adressen gedacht sind und wo sie für Nutzercluster mit aktivierter Steuerungsebene V2 konfiguriert werden.

Statische IP-Adressen Configuration
Knoten der Steuerungsebene Konfigurationsdatei des Nutzerclusters im Abschnitt network.controlPlaneIPBlock.ips
Worker-Knoten Nutzercluster-IP-Blockdatei und fügen den Pfad in das Feld network.ipMode.ipBlockFilePath in der Konfigurationsdatei des Nutzerclusters ein

Kubeception-Nutzercluster

In der folgenden Tabelle wird beschrieben, wofür die IP-Adressen gedacht sind und wo sie für Nutzercluster konfiguriert werden, die kubeception verwenden.

Statische IP-Adressen Configuration
Knoten der Steuerungsebene IP-Blockdatei des Administratorclusters und fügen Sie den Pfad in der Konfigurationsdatei des Administratorclusters in das Feld network.ipMode.ipBlockFilePath ein.
Worker-Knoten Nutzercluster-IP-Blockdatei und fügen den Pfad in das Feld network.ipMode.ipBlockFilePath in der Konfigurationsdatei des Nutzerclusters ein

IP-Adressen für VIPs reservieren

Unabhängig davon, ob Sie den integrierten, gebündelten oder manuellen Load-Balancing-Modus verwenden, müssen Sie mehrere IP-Adressen reservieren, die Sie für virtuelle IP-Adressen (VIPs) für das Load-Balancing verwenden möchten. Über diese VIPs können externe Clients die Kubernetes API-Server und Ihren Dienst für eingehenden Traffic auf Nutzerclustern erreichen.

VIPs konfigurieren

Wo Sie VIPs konfigurieren, hängt vom Clustertyp ab.

Hochverfügbarkeits-Administratorcluster

In der folgenden Tabelle wird beschrieben, wofür die VIP ist und wo sie für Hochverfügbarkeits-Administratorcluster konfiguriert wird.

VIP Configuration
VIP für den Kubernetes API-Server des Administratorclusters Konfigurationsdatei des Administratorclusters im Feld loadBalancer.vips.controlPlaneVIP
1.15 und niedriger: Add-ons VIP Konfigurationsdatei des Administratorclusters im Feld loadBalancer.vips.addonsVIP

Beachten Sie die folgenden Unterschiede bei den Versionen:

  • Ab 1.16 müssen Sie keine Add-on-VIP für Hochverfügbarkeits-Administratorcluster konfigurieren.

  • Ab Version 1.28 haben neue Hochverfügbarkeits-Admin-Cluster keine Add-on-Knoten.

Administratorcluster ohne Hochverfügbarkeit

In der folgenden Tabelle wird beschrieben, wofür die VIP ist und wo Sie sie für Administratorcluster ohne Hochverfügbarkeit konfigurieren.

VIP Configuration
VIP für den Kubernetes API-Server des Administratorclusters Konfigurationsdatei des Administratorclusters im Feld loadBalancer.vips.controlPlaneVIP
1.15 und niedriger: Add-ons VIP Konfigurationsdatei des Administratorclusters im Feld loadBalancer.vips.addonsVIP

Beachten Sie die folgenden Unterschiede bei den Versionen:

Ab 1.16 müssen Sie keine Add-on-VIP für Administratorcluster ohne Hochverfügbarkeit konfigurieren.

CP V2-Nutzercluster

In der folgenden Tabelle wird beschrieben, wofür die VIPs gedacht sind und wo Sie sie für Nutzercluster mit aktivierter Steuerungsebene V2 konfigurieren.

VIPs Configuration
VIP für den Kubernetes API-Server des Nutzerclusters Konfigurationsdatei des Nutzerclusters im Feld loadBalancer.vips.controlPlaneVIP
VIP für den Dienst für eingehenden Traffic im Nutzercluster Konfigurationsdatei des Nutzerclusters im Feld loadBalancer.vips.ingressVIP

Kubeception-Nutzercluster

In der folgenden Tabelle wird beschrieben, wofür die VIPs gedacht sind und wo Sie sie für Nutzercluster konfigurieren, die kubeception verwenden.

VIPs Configuration
VIP für den Kubernetes API-Server des Nutzerclusters Konfigurationsdatei des Nutzerclusters im Feld loadBalancer.vips.controlPlaneVIP
VIP für den Dienst für eingehenden Traffic im Nutzercluster Konfigurationsdatei des Nutzerclusters im Feld loadBalancer.vips.ingressVIP

nodePort-Werte reservieren

In Google Distributed Cloud werden der Kubernetes API-Server und der Dienst für eingehenden Traffic von Kubernetes-Diensten bereitgestellt. Im manuellen Load-Balancing-Modus müssen Sie Ihre eigenen nodePort-Werte für diese Dienste auswählen. Wählen Sie Werte im Bereich von 30.000 bis 32.767 aus.

nodePort-Werte konfigurieren

Wo Sie nodePort-Werte konfigurieren, hängt davon ab, ob für den Nutzercluster ControlPlane V2 aktiviert ist.

Hochverfügbarkeits-Administratorcluster

In der folgenden Tabelle wird beschrieben, wofür die nodePort gedacht ist und wo sie für Hochverfügbarkeits-Administratorcluster konfiguriert wird.

nodePort Configuration
1.15 und niedriger: nodePort für Add-on-Knoten Konfigurationsdatei des Administratorclusters im Feld loadBalancer.manualLB.addonsNodePort

Ab Version 1.16 müssen Sie keine nodePort für Add-on-Knoten für Hochverfügbarkeits-Administratorcluster konfigurieren.

Administratorcluster ohne Hochverfügbarkeit

In der folgenden Tabelle wird beschrieben, wofür die nodePort-Werte gelten und wo Sie sie für Administratorcluster ohne Hochverfügbarkeit konfigurieren.

nodePort Configuration
1.16 und früher: nodePort für den Kubernetes API-Server des Administratorclusters 1.15 und früher: Konfigurationsdatei des Administratorclusters im Feld loadBalancer.vips.controlPlaneNodePort
1.15 und früher: nodePort für Add-on-Knoten Konfigurationsdatei des Administratorclusters im Feld loadBalancer.manualLB.addonsNodePort

Ab Version 1.16 müssen Sie keine nodePort für Add-on-Knoten für Administratorcluster ohne Hochverfügbarkeit konfigurieren.

CP V2-Nutzercluster

In der folgenden Tabelle wird beschrieben, wofür die nodePorts vorgesehen sind und wo Sie sie für Nutzercluster mit aktivierter Steuerungsebene V2 konfigurieren.

nodePorts Configuration
HTTP nodePort für den Dienst für eingehenden Traffic im Nutzercluster Nutzercluster-Konfigurationsdatei in loadBalancer.manualLB.ingressHTTPNodePort
HTTPS nodePort für den Dienst für eingehenden Traffic im Nutzercluster Nutzercluster-Konfigurationsdatei in loadBalancer.manualLB.ingressHTTPSNodePort

Sie müssen kein nodePort für die virtuelle IP-Adresse der Steuerungsebene konfigurieren, da Google Distributed Cloud das Load-Balancing für die Knoten der Steuerungsebene für Nutzercluster mit aktivierter Steuerungsebene V2 übernimmt.

Kubeception-Nutzercluster

In der folgenden Tabelle wird beschrieben, wofür die nodePort-Werte gelten und wo Sie sie für Nutzercluster konfigurieren, die kubeception verwenden.

nodePort Configuration
nodePort für den Kubernetes API-Server des Nutzerclusters Konfigurationsdatei des Nutzerclusters im Feld loadBalancer.manualLB.controlPlaneNodePort
nodePort für den Konnectivity-Server des Nutzerclusters (der Konnectivity-Server verwendet die virtuelle IP-Adresse der Steuerungsebene) Konfigurationsdatei des Nutzerclusters im Feld loadBalancer.manualLB.konnectivityServerNodePort
HTTP nodePort für den Dienst für eingehenden Traffic im Nutzercluster Nutzercluster-Konfigurationsdatei in loadBalancer.manualLB.ingressHTTPNodePort
HTTPS nodePort für den Dienst für eingehenden Traffic im Nutzercluster Nutzercluster-Konfigurationsdatei in loadBalancer.manualLB.ingressHTTPSNodePort

Beispiel für eine Clusterkonfigurationsdatei

Das folgende Beispiel zeigt einen Teil einer Administrator- und Nutzercluster-Konfigurationsdatei:

Hochverfügbarkeits-Administratorcluster

  • Version 1.16 und höher:

    network:
  controlPlaneIPBlock:
    netmask: "255.255.248.0"
    gateway: "21.0.143.254"
    ips:
    - ip: "21.0.140.226"
      hostname: "admin-cp-vm-1"
    - ip: "21.0.141.48"
      hostname: "admin-cp-vm-2"
    - ip: "21.0.141.65"
      hostname: "admin-cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
  kind: ManualLB

  • In Version 1.15 und niedriger sind für Add-on-Knoten eine VIP und nodeport erforderlich.

    network:
  controlPlaneIPBlock:
    netmask: "255.255.248.0"
    gateway: "21.0.143.254"
    ips:
    - ip: "21.0.140.226"
      hostname: "admin-cp-vm-1"
    - ip: "21.0.141.48"
      hostname: "admin-cp-vm-2"
    - ip: "21.0.141.65"
      hostname: "admin-cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    addonsVIP: "203.0.113.4"
  kind: ManualLB
  manualLB:
    addonsNodePort: 31405

Administratorcluster ohne Hochverfügbarkeit

  • Version 1.16 und höher:

    network:
  ipMode:
    type: static
    ipBlockFilePath: "ipblock-admin.yaml"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30562

  • In Version 1.15 und niedriger sind eine VIP und nodeport für Add-on-Knoten erforderlich.

    network:
ipMode:
  type: static
  ipBlockFilePath: "ipblock-admin.yaml"
loadBalancer:
vips:
  controlPlaneVIP: "172.16.21.40"
  addonsVIP: "172.16.21.41"
kind: ManualLB
manualLB:
  controlPlaneNodePort: 30562
  addonsNodePort: 30563

CP V2-Nutzercluster

network:
  ipMode:
    type: static
    ipBlockFilePath: "ipblock1.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: ManualLB
  manualLB:
    ingressHTTPNodePort: 30243
    ingressHTTPSNodePort: 30879

Kubeception-Nutzercluster

network:
  ipMode:
    type: static
    ipBlockFilePath: "ipblock1.yaml"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: ManualLB
  manualLB:
    ingressHTTPNodePort: 30243
    ingressHTTPSNodePort: 30879
    konnectivityServerNodePort: 30563
    controlPlaneNodePort: 30562

Load-Balancer konfigurieren

Verwenden Sie die Verwaltungskonsole oder die Tools des Load-Balancers, um die folgenden Zuordnungen in Ihrem Load-Balancer zu konfigurieren. Wie Sie dies tun, hängt von Ihrem Load-Balancer ab.

Hochverfügbarkeits-Administratorcluster

Traffic zu Knoten der Steuerungsebene

Google Distributed Cloud verwaltet automatisch das Load-Balancing des Traffics der Steuerungsebene für Hochverfügbarkeits-Administratorcluster. Obwohl Sie keine Zuordnung im Load-Balancer konfigurieren müssen, geben Sie im Feld loadBalancer.vips.controlPlaneVIP eine IP-Adresse an.

Traffic zu Diensten in den Add-on-Knoten

1.15 und früher: Im Folgenden wird die Zuordnung zu den IP-Adressen und den nodePort-Werten für Traffic zu Diensten in Add-on-Knoten dargestellt:

  • (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Fügen Sie diese Zuordnung für alle Knoten im Administratorcluster hinzu, sowohl für die Knoten der Steuerungsebene als auch für die Add-on-Knoten.

In Version 1.16 und höher müssen Sie diese Zuordnung für Add-on-Knoten für Hochverfügbarkeits-Administratorcluster nicht konfigurieren.

Administratorcluster ohne Hochverfügbarkeit

Traffic der Steuerungsebene

Im Folgenden sehen Sie die Zuordnung zur IP-Adresse und zum nodePort-Wert für den Knoten der Steuerungsebene:

  • (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)

Fügen Sie diese Zuordnung für alle Knoten im Administratorcluster hinzu, sowohl für den Knoten der Steuerungsebene als auch für die Add-on-Knoten.

Traffic zu Diensten in den Add-on-Knoten

1.15 und früher: Im Folgenden sehen Sie die Zuordnung zu den IP-Adressen und nodePort-Werten für Dienste, die in Add-on-Knoten ausgeführt werden:

  • (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Fügen Sie diese Zuordnung für alle Knoten im Administratorcluster hinzu, sowohl für den Knoten der Steuerungsebene als auch für die Add-on-Knoten.

In Version 1.16 und höher müssen Sie diese Zuordnung nicht für Add-on-Knoten von Administratorclustern ohne Hochverfügbarkeit konfigurieren.

CP V2-Nutzercluster

Traffic der Steuerungsebene

Google Distributed Cloud führt automatisch das Load-Balancing des Traffics der Steuerungsebene für Nutzercluster mit aktivierter Steuerungsebene V2 durch. Sie müssen im Load-Balancer keine Zuordnung konfigurieren, geben aber im Feld loadBalancer.vips.controlPlaneVIP eine IP-Adresse an.

Traffic auf Datenebene

Im Folgenden sehen Sie die Zuordnung zu den IP-Adressen und nodePort-Werten für Traffic auf der Datenebene:

  • (ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort)
  • (ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)

Fügen Sie diese Zuordnungen für alle Knoten im Nutzercluster hinzu, sowohl für Knoten der Steuerungsebene als auch für Worker-Knoten. Da Sie NodePorts auf dem Cluster konfiguriert haben, öffnet Kubernetes die NodePorts auf allen Clusterknoten. Dadurch kann jeder Knoten im Cluster den Traffic auf der Datenebene verarbeiten.

Nachdem Sie die Zuordnungen konfiguriert haben, wartet der Load-Balancer auf Traffic an der IP-Adresse, die Sie für die virtuelle IP-Adresse des Nutzerclusters über HTTP- und HTTPS-Standardports konfiguriert haben. Der Load-Balancer leitet Anfragen an jeden Knoten im Cluster weiter. Nachdem eine Anfrage an einen der Clusterknoten weitergeleitet wurde, übernimmt das interne Kubernetes-Netzwerk die Anfrage und leitet sie an den Ziel-Pod weiter.

Kubeception-Nutzercluster

Traffic der Steuerungsebene

Im Folgenden sehen Sie die Zuordnung zu den IP-Adressen und nodePort-Werten für den Traffic der Steuerungsebene:

  • (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)
  • (controlPlaneVIP:8132) -> (NODE_IP_ADDRESSES:konnectivityServerNodePort)

Fügen Sie diese Zuordnung für alle Knoten im admin-Cluster hinzu, sowohl für den Administratorcluster als auch für die Knoten der Steuerungsebene des Nutzerclusters.

Traffic auf Datenebene

Im Folgenden sehen Sie die Zuordnung zu den IP-Adressen und nodePort-Werten für Traffic auf der Datenebene:

  • (ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort)
  • (ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)

Fügen Sie diese Zuordnungen für alle Knoten im Nutzercluster hinzu. Bei Nutzerclustern, die kubeception verwenden, sind alle Knoten im Cluster Worker-Knoten.

Zusätzlich zu den oben genannten Anforderungen empfehlen wir Ihnen, den Load-Balancer so zu konfigurieren, dass Clientverbindungen zurückgesetzt werden, wenn ein Backend-Knotenfehler auftritt. Ohne diese Konfiguration können Clients des Kubernetes API-Servers nicht mehr auf mehrere Minuten reagieren, wenn eine Serverinstanz ausfällt. Dies kann zu einer Instabilität auf der Kubernetes-Steuerungsebene führen.

  • Bei F5 BIG-IP wird diese Einstellung auf der Konfigurationsseite des Backend-Pools "Action On Service Down" genannt.
  • Bei HAProxy wird diese Einstellung in der Backend-Serverkonfiguration mit "Mark-down"-Shutdown-Sitzungen bezeichnet.
  • Wenn Sie einen anderen Load-Balancer verwenden, finden Sie in der Dokumentation die entsprechende Einstellung.

Support für das manuelle Load Balancing erhalten

Google bietet keinen Support für Load-Balancer, die mit dem manuellen Load-Balancing-Modus konfiguriert wurden. Wenn Probleme mit dem Load-Balancer auftreten, wenden Sie sich an den Anbieter des Load-Balancers.

Nächste Schritte