Auf dieser Seite werden Hochverfügbarkeitsoptionen in GKE on VMware beschrieben.
Hauptfunktion
GKE on VMware enthält einen Administratorcluster und einen oder mehrere Nutzercluster.
Der Administratorcluster verwaltet den Lebenszyklus der Nutzercluster, einschließlich Erstellen, Aktualisieren, Upgrade und Löschen von Nutzerclustern. Im Administratorcluster verwaltet der Admin-Master die Admin-Worker-Knoten, zu denen Nutzer-Master (Knoten, auf denen die Steuerebene der verwalteten Nutzercluster läuft) und Add-on-Knoten (Knoten, auf denen die Add-on-Komponenten zur Unterstützung der Funktionalität des Administratorcluster laufen) gehören.
Für jeden Nutzercluster hat der Administratorcluster einen Nicht-HA-Knoten oder drei HA-Knoten, auf denen die Steuerungsebene ausgeführt wird. Die Steuerungsebene umfasst den Kubernetes API-Server, den Kubernetes-Planer, den Kubernetes-Controller-Manager und mehrere wichtige Controller für den Nutzercluster.
Die Verfügbarkeit der Steuerungsebene des Nutzerclusters ist für Arbeitslastvorgänge wichtig, wie das Erstellen von Arbeitslasten, das Hoch- und Herunterskalieren sowie das Abbrechen. Anders ausgedrückt: Ein Ausfall der Steuerungsebene beeinträchtigt nicht die ausgeführten Arbeitslasten. Die vorhandenen Arbeitslasten verlieren jedoch die Verwaltungsfunktionen des Kubernetes API-Servers, wenn keine Steuerungsebene vorhanden ist.
Containerisierte Arbeitslasten und Dienste werden in den Worker-Knoten des Nutzerclusters bereitgestellt. Einzelne Worker-Knoten sollten nicht für die Anwendungsverfügbarkeit entscheidend sein, solange die Anwendung mit redundanten Pods bereitgestellt wird, die auf mehreren Worker-Knoten geplant sind.
Hochverfügbarkeit aktivieren
vSphere und GKE on VMware bieten eine Reihe von Features, die zu Hochverfügbarkeit beitragen.
vSphere HA und vMotion
Wir empfehlen, die folgenden beiden Features in dem vCenter-Cluster zu aktivieren, der Ihre GKE on VMware-Cluster hostet:
Diese Funktionen verbessern die Verfügbarkeit und Wiederherstellung, wenn ein ESXi-Host ausfällt.
vCenter HA verwendet mehrere ESXi-Hosts, die als Cluster konfiguriert sind, um eine schnelle Wiederherstellung nach Ausfällen und eine kostengünstige HA für Anwendungen zu ermöglichen, die in virtuellen Maschinen ausgeführt werden. Wir empfehlen, Ihren vCenter-Cluster mit zusätzlichen Hosts bereitzustellen und vS HA Host-Host-Monitoring mit Host Failure Response auf Restart VMs zu aktivieren. Ihre VMs können dann bei einem ESXi-Hostfehler automatisch auf anderen verfügbaren Hosts neu gestartet werden.
vMotion ermöglicht eine reibungslose Migration von VMs von einem ESXi-Host zu einem anderen. Für die geplante Hostwartung können Sie mit der Live-Migration von vMotion die Anwendungsausfallzeiten vermeiden und Geschäftskontinuität gewährleisten.
Administratorcluster
GKE on VMware unterstützt das Erstellen von Hochverfügbarkeits-Administratorclustern. Ein Hochverfügbarkeits-Administratorcluster hat drei Knoten, auf denen Komponenten der Steuerungsebene ausgeführt werden. Informationen zu Anforderungen und Einschränkungen finden Sie unter Administratorcluster mit Hochverfügbarkeit.
Die Nichtverfügbarkeit der Steuerungsebene des Administratorclusters hat keinen Einfluss auf die Funktionalität der vorhandenen Nutzercluster oder auf Arbeitslasten, die in Nutzerclustern ausgeführt werden.
In einem Administratorcluster gibt es zwei Add-on-Knoten. Wenn dieser ausfällt, kann der andere die Administratorclustervorgänge ausführen. Für Redundanz verteilt GKE on VMware wichtige Add-on-Dienste wie kube-dns auf beide Add-on-Knoten.
Wenn Sie antiAffinityGroups.enabled in der Konfigurationsdatei des Administratorclusters auf true setzen, erstellt GKE on VMware automatisch vSphere DRS-Anti-Affinitätsregeln für die Add-on-Knoten. Dadurch werden sie für Hochverfügbarkeit auf zwei physische Hosts verteilt.
Nutzercluster
Sie können HA für einen Nutzercluster aktivieren, indem Sie masterNode.replicas in der Nutzercluster-Konfigurationsdatei auf 3 setzen. Wenn für den Nutzercluster Controlplane V2 aktiviert ist (empfohlen), werden die drei Knoten der Steuerungsebene im Nutzercluster ausgeführt.
Legacy-kubeception-Nutzercluster führen die drei Knoten der Steuerungsebene im Administratorcluster aus. Jeder Knoten der Steuerungsebene führt außerdem ein etcd-Replikat aus. Der Nutzercluster funktioniert weiterhin, solange eine Steuerungsebene und ein etcd-Quorum ausgeführt wird. Für ein etcd Quorum müssen zwei der etcd-Replikate funktionieren.
Wenn Sie antiAffinityGroups.enabled in der Konfigurationsdatei des Administratorclusters auf true setzen, erstellt GKE on VMware automatisch vSphere DRS-Anti-Affinitätsregeln für die drei Knoten, auf denen die Steuerungsebene des Nutzerclusters ausgeführt wird.
Dadurch werden diese VMs auf drei physische Hosts verteilt.
GKE on VMware erstellt außerdem vSphere DRS-Anti-Affinitätsregeln für die Worker-Knoten in Ihrem Nutzercluster. Diese Knoten werden dann auf mindestens drei physische Hosts verteilt. Mehrere DRS-Anti-Affinitätsregeln werden pro Nutzercluster-Knotenpool basierend auf der Anzahl der Knoten verwendet. Dadurch wird gewährleistet, dass die Worker-Knoten Hosts finden, auf denen sie ausgeführt werden können, auch wenn die Anzahl der Hosts kleiner als die Anzahl der VMs im Nutzercluster-Knotenpool ist. Wir empfehlen, zusätzliche physische Hosts in Ihren vCenter-Cluster aufzunehmen. Sie sollten DRS außerdem so konfigurieren, dass der Vorgang vollständig automatisiert ist, damit in dem Fall, dass ein Host nicht mehr verfügbar ist, DRS automatisch VMs auf anderen verfügbaren Hosts neu starten kann, ohne gegen die Anti-Affinitätsregeln der VMs zu verstoßen.
GKE on VMware verwaltet das spezielle Knotenlabel onprem.gke.io/failure-domain-name, dessen Wert auf den zugrunde liegenden ESXi-Hostnamen festgelegt ist. Nutzeranwendungen, die Hochverfügbarkeit gewährleisten möchten, können podAntiAffinity-Regeln mit diesem Label als topologyKey einrichten, um sicherzustellen, dass ihre Anwendungs-Pods über verschiedene VMs sowie physische Hosts verteilt werden.
Sie können auch mehrere Knotenpools für einen Nutzercluster mit unterschiedlichen Datenspeichern und speziellen Knotenlabels konfigurieren. Ebenso können Sie Regeln vom Typ podAntiAffinity mit diesem speziellen Knotenlabel als topologyKey einrichten, um eine höhere Verfügbarkeit bei Datenspeicherfehlern zu erreichen.
Um HA für Nutzerarbeitslasten zu verwenden, muss der Nutzercluster eine ausreichende Anzahl von Replikaten unter nodePools.replicas haben, wodurch sichergestellt wird, dass die gewünschte Anzahl von Nutzercluster-Worker-Knoten in ausführbarem Zustand sind.
Sie können für Admincluster und Nutzercluster separate Datenspeicher verwenden, um deren Fehler zu isolieren.
Load-Balancer
Es gibt zwei Arten von Load-Balancern, die Sie für Hochverfügbarkeit verwenden können.
Gebündelter MetalLB-Load-Balancer
Für den gebündelten MetalLB-Load-Balancer erreichen Sie Hochverfügbarkeit, indem Sie mehr als einen Knoten mit enableLoadBalancer: true haben.
MetalLB verteilt Dienste auf die Load-Balancer-Knoten. Für einen einzelnen Dienst gibt es jedoch nur einen führenden Knoten, der den gesamten Traffic für diesen Dienst verarbeitet.
Während des Clusterupgrades kommt es zu Ausfallzeiten, wenn die Load-Balancer-Knoten aktualisiert werden. Die Dauer der Failover-Unterbrechung von MetalLB wächst mit zunehmender Anzahl der Load-Balancer-Knoten. Bei weniger als 5 Knoten erfolgt die Unterbrechung innerhalb von 10 Sekunden.
Gebündelter Seesaw-Load-Balancer
Für den Bundle-Seesaw-Load-Balancer können Sie HA aktivieren, indem Sie loadBalancer.seesaw.enableHA in der Cluster-Konfigurationsdatei auf true setzen.
Sie müssen auch eine Kombination aus MAC-Lernen, gefälschten Übertragungen und promiscous-Modus in Ihrer Load-Balancer-Portgruppe aktivieren.
Bei HA werden zwei Load-Balancer im Aktiv-Passiv-Modus eingerichtet. Wenn der aktive Load-Balancer ein Problem hat, schlägt der Traffic auf den passiven Load-Balancer um.
Während des Upgrades eines Load-Balancers kommt es zu Ausfallzeiten. Wenn für den Load-Balancer Hochverfügbarkeit aktiviert ist, beträgt die maximale Ausfallzeit zwei Sekunden.
Integrierter F5-BIG-IP-Load-Balancer
Die F5 BIG-IP-Plattform bietet verschiedene Dienste, mit denen Sie die Sicherheit, Verfügbarkeit und Leistung Ihrer Anwendungen verbessern können. Für GKE on VMware bietet BIG-IP externen Zugriff und L3/4-Load-Balancing-Dienste.
Weitere Informationen finden Sie unter BIG-IP-Hochverfügbarkeit.
Mehrere Cluster für die Notfallwiederherstellung verwenden
Das Bereitstellen von Anwendungen in mehreren Clustern auf mehreren vCenters oder GKE Enterprise-Plattformen kann eine höhere globale Verfügbarkeit bieten und den Umfang der Angriffe bei Ausfällen begrenzen.
Bei dieser Einrichtung wird der vorhandene GKE Enterprise-Cluster im sekundären Rechenzentrum für die Notfallwiederherstellung verwendet, anstatt einen neuen Cluster einzurichten. Das geht in der folgenden Zusammenfassung:
Erstellen Sie im sekundären Rechenzentrum einen weiteren Administratorcluster und einen weiteren Nutzercluster. In dieser Multi-Cluster-Architektur müssen Nutzer zwei Administratorcluster in jedem Rechenzentrum haben und jeder Administratorcluster einen Nutzercluster ausführen.
Der sekundäre Nutzercluster hat eine minimale Anzahl von Worker-Knoten (drei) und ist dabei ein Hot-Standby.
Anwendungsbereitstellungen können mithilfe von Config Sync zwischen den beiden vCenters repliziert werden. Es wird aber auch empfohlen, eine vorhandene DevOps-Toolchain (CI/CD, Spinnaker) zu verwenden.
Im Notfall kann der Nutzercluster auf die Anzahl der Knoten skaliert werden.
Außerdem ist ein DNS-Switchover erforderlich, um Traffic zwischen den Clustern an das sekundäre Rechenzentrum zu leiten.