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 Controlplane V2 aktiviert ist. Bei Controlplane 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, in dem die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt wird. Wenn Controlplane V2 nicht aktiviert ist, verwendet ein Nutzercluster kubeception.
Auf dieser Seite werden die Schritte beschrieben, die Sie ausführen müssen, wenn Sie den manuellen Load-Balancing-Modus verwenden.
In diesem Thema reservieren Sie IP-Adressen für Knoten der Steuerungsebene und Worker-Knoten für die spätere Verwendung. Sie reservieren auch IP-Adressen für virtuelle IP-Adressen (VIPs) und legen nodePort
-Werte fest. Sie wählen die gewünschten IP-Adressen und nodePort
-Werte aus und notieren sie in einer Tabelle oder einem anderen Tool. Wenn Sie zum Erstellen der Cluster bereit sind, benötigen Sie die IP-Adressen und nodePort
-Werte, um die Konfigurationsdateien für Ihren Administratorcluster und Ihren Nutzercluster sowie die IP-Blockdateien für Ihre Cluster auszufüllen.
Sie benötigen auch die IP-Adressen und nodePort
-Werte, 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. Informationen dazu, wie viele Knoten-IP-Adressen reserviert werden müssen, finden Sie unter IP-Adressen planen (Controlplane V2) und IP-Adressen planen (kubeception).
IP-Adressen konfigurieren
Wo Sie die statischen IP-Adressen konfigurieren, hängt vom Clustertyp ab und davon, ob Controlplane V2 in Ihren Nutzerclustern aktiviert ist.
Hochverfügbarkeits-Administratorcluster
In der folgenden Tabelle wird beschrieben, wofür die IP-Adressen bestimmt sind und wo Sie sie für Hochverfügbarkeits-Administratorcluster konfigurieren.
Statische IP-Adressen | Configuration |
---|---|
Knoten der Steuerungsebene | Konfigurationsdatei des Administratorclusters im Bereich network.controlPlaneIPBlock.ips |
1.16 und niedriger: Add-on-Knoten | Administratorcluster-IP-Blockdatei und fügen den Pfad in das Feld network.ipMode.ipBlockFilePath der Konfigurationsdatei des Administratorclusters hinzu |
In Version 1.28 und höher haben neue Hochverfügbarkeits-Administratorcluster 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 bestimmt sind und wo Sie sie für Administratorcluster ohne Hochverfügbarkeit konfigurieren.
Statische IP-Adressen | Configuration |
---|---|
Knoten der Steuerungsebene | Administratorcluster-IP-Blockdatei und fügen den Pfad in das Feld network.ipMode.ipBlockFilePath der Konfigurationsdatei des Administratorclusters hinzu |
Add-on-Knoten | Datei mit IP-Blockade 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 bestimmt sind und wo Sie sie für Nutzercluster mit aktivierter Controlplane V2 konfigurieren.
Statische IP-Adressen | Configuration |
---|---|
Knoten der Steuerungsebene | Nutzercluster-Konfigurationsdatei im Abschnitt network.controlPlaneIPBlock.ips |
Worker-Knoten | Nutzercluster-IP-Blockdatei aus und fügen Sie den Pfad in das Feld network.ipMode.ipBlockFilePath der Konfigurationsdatei des Nutzerclusters ein |
Kubeception-Nutzercluster
In der folgenden Tabelle wird beschrieben, wofür die IP-Adressen bestimmt sind und wo Sie sie für Nutzercluster konfigurieren, die kubeception verwenden.
Statische IP-Adressen | Configuration |
---|---|
Knoten der Steuerungsebene | Administratorcluster-IP-Blockdatei und fügen den Pfad in das Feld network.ipMode.ipBlockFilePath der Konfigurationsdatei des Administratorclusters hinzu |
Worker-Knoten | Nutzercluster-IP-Blockdatei aus und fügen Sie den Pfad in das Feld network.ipMode.ipBlockFilePath 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. Mit diesen 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 sie für Hochverfügbarkeits-Administratorcluster konfigurieren.
VIPs | 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 zwischen den Versionen:
In Version 1.16 und höher müssen Sie für Hochverfügbarkeits-Administratorcluster keine Add-on-VIP konfigurieren.
In Version 1.28 und höher haben neue Hochverfügbarkeits-Administratorcluster 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.
VIPs | 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 zwischen den Versionen:
In Version 1.16 und höher müssen Sie für Administratorcluster ohne Hochverfügbarkeit keine Add-on-VIP konfigurieren.
CP V2-Nutzercluster
In der folgenden Tabelle wird beschrieben, wofür die VIPs sind und wo Sie sie für Nutzercluster mit aktivierter Controlplane V2 konfigurieren.
VIPs | Configuration |
---|---|
VIP für den Kubernetes API-Server des Nutzerclusters | Nutzercluster-Konfigurationsdatei im Feld loadBalancer.vips.controlPlaneVIP |
VIP für den Dienst für eingehenden Traffic im Nutzercluster | Nutzercluster-Konfigurationsdatei im Feld loadBalancer.vips.ingressVIP |
Kubeception-Nutzercluster
In der folgenden Tabelle wird beschrieben, wofür die VIPs sind und wo Sie sie für Nutzercluster konfigurieren, die kubeception verwenden.
VIPs | Configuration |
---|---|
VIP für den Kubernetes API-Server des Nutzerclusters | Nutzercluster-Konfigurationsdatei im Feld loadBalancer.vips.controlPlaneVIP |
VIP für den Dienst für eingehenden Traffic im Nutzercluster | Nutzercluster-Konfigurationsdatei 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 verfügbar gemacht.
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 der nodePort
ist und wo Sie ihn für Hochverfügbarkeits-Administratorcluster konfigurieren.
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 bestimmt sind und wo Sie sie für Administratorcluster ohne Hochverfügbarkeit konfigurieren.
nodePort |
Configuration |
---|---|
1.16 und niedriger: nodePort für den Kubernetes API-Server des Administratorclusters |
1.15 und niedriger: Konfigurationsdatei des Administratorclusters im Feld loadBalancer.vips.controlPlaneNodePort |
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 Administratorcluster ohne Hochverfügbarkeit konfigurieren.
CP V2-Nutzercluster
In der folgenden Tabelle wird beschrieben, wofür die nodePorts
bestimmt sind und wo Sie sie für Nutzercluster mit aktiviertem Controlplane 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 für die virtuelle IP-Adresse der Steuerungsebene keinen nodePort
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 bestimmt sind und wo Sie sie für Nutzercluster konfigurieren, die kubeception verwenden.
nodePort |
Configuration |
---|---|
nodePort für den Kubernetes API-Server des Nutzerclusters |
Nutzercluster-Konfigurationsdatei im Feld loadBalancer.manualLB.controlPlaneNodePort |
nodePort für den Konnectivity-Server des Nutzerclusters (der Konnectivity-Server verwendet die virtuelle IP-Adresse der Steuerungsebene) |
Nutzercluster-Konfigurationsdatei 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 Konfigurationsdatei für Administrator- und Nutzercluster:
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
Version 1.15 und niedriger erfordern eine VIP und
nodeport
für Add-on-Knoten.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
Version 1.15 und niedriger erfordern eine VIP und
nodeport
für Add-on-Knoten.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 dabei vorgehen, hängt vom Load-Balancer ab.
Hochverfügbarkeits-Administratorcluster
Traffic zu Knoten der Steuerungsebene
Google Distributed Cloud übernimmt das Load-Balancing des Traffics der Steuerungsebene für Hochverfügbarkeits-Administratorcluster automatisch. Sie müssen zwar keine Zuordnung im Load-Balancer konfigurieren, aber Sie müssen im Feld loadBalancer.vips.controlPlaneVIP
eine IP-Adresse angeben.
Traffic zu Diensten in den Add-on-Knoten
1.15 und niedriger: Im Folgenden wird die Zuordnung zu den IP-Adressen und nodePort
-Werten für den Traffic zu Diensten in Add-on-Knoten gezeigt:
- (
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.
Ab Version 1.16 müssen Sie diese Zuordnung für Add-on-Knoten für Administratorcluster mit Hochverfügbarkeit nicht konfigurieren.
Administratorcluster ohne Hochverfügbarkeit
Traffic der Steuerungsebene
Die folgende Abbildung zeigt die Zuordnung zur IP-Adresse und dem 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 niedriger: Im Folgenden wird die Zuordnung zu den IP-Adressen und nodePort
-Werten für Dienste gezeigt, 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.
Ab Version 1.16 müssen Sie diese Zuordnung für Add-on-Knoten für Administratorcluster ohne Hochverfügbarkeit nicht konfigurieren.
CP V2-Nutzercluster
Traffic der Steuerungsebene
Google Distributed Cloud übernimmt das Load-Balancing des Traffics der Steuerungsebene für Nutzercluster mit aktiviertem Controlplane V2 automatisch. Sie müssen zwar keine Zuordnung im Load-Balancer konfigurieren, aber Sie müssen im Feld loadBalancer.vips.controlPlaneVIP
eine IP-Adresse angeben.
Traffic auf Datenebene
Im Folgenden sehen Sie die Zuordnung zu den IP-Adressen und nodePort
-Werten für den Traffic 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 im Cluster konfiguriert haben, öffnet Kubernetes die NodePorts auf allen Clusterknoten. Dadurch kann jeder Knoten im Cluster den Traffic der Datenebene verarbeiten.
Nachdem Sie die Zuordnungen konfiguriert haben, überwacht der Load-Balancer den Traffic an der IP-Adresse, die Sie für die virtuelle IP-Adresse des Nutzerclusters für eingehenden Traffic auf Standard-HTTP- und HTTPS-Ports konfiguriert haben. Der Load-Balancer leitet Anfragen an einen beliebigen Knoten im Cluster weiter. Nachdem eine Anfrage an einen der Clusterknoten weitergeleitet wurde, übernimmt das interne Kubernetes-Netzwerk die Anfrage und leitet die Anfrage 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 den Traffic 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.
Verbindungen zu fehlerhaften Knoten zurücksetzen (empfohlen)
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
- Load-Balancing mit Citrix
- F5 BIG-IP ADC für GKE in VMware mithilfe von manuellem Load Balancing installieren