Clustermigration zu empfohlenen Funktionen planen

Übersicht

Google Distributed Cloud basiert auf Kubernetes und vielen anderen ähnlichen Technologien, die kontinuierlich aktualisiert und verbessert werden, um die Skalierbarkeit, Leistung, Sicherheit und Integrationsmöglichkeiten zu verbessern. Die Google Distributed Cloud wird daher ständig angepasst und verbessert.

In Version 1.30 sind die Änderungen und Updates so weit fortgeschritten, dass wir Ihnen dringend empfehlen, ältere Bereitstellungen zu migrieren, um von den erheblichen Verbesserungen zu profitieren. Auf dieser Seite werden die Vorteile der Migration von veralteten zu den neuesten empfohlenen Funktionen beschrieben.

Für jeden Funktionsbereich stehen Ihnen die folgenden Optionen zur Verfügung:

Funktionsbereich	Empfohlene Optionen	Ursprüngliche Optionen
Container Network Interface (CNI)	Dataplane V2 (enableDataplaneV2: true)	Dataplane V1 (Calico) (enableDataplaneV2: false)
Load-Balancer	ManualLB (funktioniert mit F5 Big-IP-Agents) (loadBalancer.kind: "ManualLB") MetalLB (loadBalancer.kind: "MetalLB")	F5 Big-IP-Integration^1 (loadBalancer.kind: "F5BigIP") Seesaw (loadBalancer.kind: "Seesaw")
Administratorcluster-Steuerungsebene	Administratorcluster mit Hochverfügbarkeit (HA) (adminMaster.replicas: 3)	Administratorcluster ohne Hochverfügbarkeit (HA) (adminMaster.replicas: 1)
Nutzercluster-Steuerungsebene	Controlplane V2 (enableControlplaneV2: true)	Kubeception-Nutzercluster (enableControlplaneV2: false)

^{1 F5 BIG-IP-Integration bezieht sich auf loadBalancer.kind: "F5BigIP" und die zugehörigen Einstellungen im Abschnitt loadBalancer.f5BigIP in Ihrer Clusterkonfigurationsdatei.}

In den folgenden Tabellen finden Sie die Supportmatrix für diese Funktionen in Administrator- und Nutzerclustern:

Clustertyp	Veraltete Funktion	Für neuen Cluster hinzufügen	Clusterupgrade zulassen	Migration zur neuen Funktion
Version 1.30
Admin	Ohne Hochverfügbarkeit	Nein	Ja	Ja
	Seesaw	Nein	Ja	Ja
	F5 Big IP-Integration	Nein	Ja	Ja
Nutzer	Kubeception	Nein	Ja	Ja
	Seesaw	Nein	Ja	Ja
	F5 Big IP-Integration	Nein	Ja	Ja
	Dataplane V1	Nein	Ja	Ja
Version 1.29
Admin	Ohne Hochverfügbarkeit	Nein	Ja	Ja (Vorschau)
	Seesaw	Nein	Ja	Ja
	F5 Big IP-Integration	Ja	Ja	Ja (Vorschau)
Nutzer	Kubeception	Ja	Ja	Ja (Vorschau)
	Seesaw	Ja	Ja	Ja
	F5 Big IP-Integration	Ja	Ja	Ja (Vorschau)
	Dataplane V1	Ja	Ja	Nein
Version 1.28
Admin	Ohne Hochverfügbarkeit	Nein	Ja	Nein
	Seesaw	Nein	Ja	Ja
	F5 Big IP-Integration	Ja	Ja	Nein
Nutzer	Kubeception	Ja	Ja	Nein
	Seesaw	Ja	Ja	Ja
	F5 Big IP-Integration	Ja	Ja	Nein
	Dataplane V1	Ja	Ja	Nein

Wichtige Fakten:

• Ab Version 1.30 sind alle Migrationslösungen verfügbar, um Cluster zu den empfohlenen Alternativen zu migrieren.

• Bei der Erstellung neuer Cluster sind die folgenden Versionen nicht zulässig:

  • Administratorcluster:

    • Steuerungsebene ohne Hochverfügbarkeit: 1.28 und höher
    • Seesaw-Load Balancing: 1.28 und höher
    • F5 Big-IP-Integration: 1.30 und höher

  • Nutzercluster:

    • Kubeception: 1.30 und höher
    • Seesaw: 1.30 und höher
    • F5 Big-IP-Integration: 1.30 und höher
    • Dataplane V1: 1.30 und höher

• Sie können vorhandene Cluster weiterhin mit den ursprünglichen Funktionen aktualisieren.

Nutzercluster zu Dataplane V2 migrieren

Sie können ein Container Network Interface (CNI) auswählen, das Containernetzwerkfunktionen bietet, entweder Calico oder Dataplane V2. Dataplane V2, die CNI-Implementierung von Google, basiert auf Cilium und wird sowohl in der Google Kubernetes Engine (GKE) als auch in der Google Distributed Cloud verwendet.

Dataplane V2 bietet ein optimiertes Design und eine effiziente Ressourcennutzung, was zu einer verbesserten Netzwerkleistung und einer besseren Skalierbarkeit führt, insbesondere bei großen Clustern oder Umgebungen mit hohem Netzwerkverkehr. Wir empfehlen Ihnen dringend, Cluster zu Dataplane V2 zu migrieren, um die neuesten Funktionen, Netzwerkinnovationen und Möglichkeiten nutzen zu können.

Ab Version 1.30 ist Dataplane V2 die einzige CNI-Option zum Erstellen neuer Cluster.

Die Umstellung von Calico auf Dataplane V2 erfordert Planung und Koordination, sollte aber keine Ausfallzeiten für vorhandene Arbeitslasten verursachen. Wenn Sie proaktiv zu Dataplane V2 migrieren, profitieren Sie von folgenden Vorteilen:

• Erhöhte Leistung und Skalierbarkeit: Das optimierte Design und die effiziente Ressourcennutzung von Dataplane V2 können zu einer verbesserten Netzwerkleistung und einer besseren Skalierbarkeit führen, insbesondere in großen Clustern oder Umgebungen mit hohem Netzwerkverkehr. Das liegt daran, dass EBPF anstelle von IPTables verwendet wird, wodurch der Cluster mithilfe von BPF-Maps skaliert werden kann.

• Vereinfachte Verwaltung und Support: Wenn Sie Dataplane V2 in der Google Distributed Cloud und in GKE standardisieren, können Sie die Clusterverwaltung und Fehlerbehebung vereinfachen, da Sie auf eine einheitliche Reihe von Tools und Dokumentationen zurückgreifen können.

• Erweiterte Netzwerkfunktionen: EgressNAT und andere erweiterte Netzwerkfunktionen werden nur von Dataplane V2 unterstützt. Alle zukünftigen Netzwerkanfragen werden in der Dataplane V2-Ebene implementiert.

	Vor der Migration	Nach der Migration
kube-proxy	Erforderlich und automatisch bereitgestellt	Nicht erforderlich und nicht bereitgestellt
Routing	kube-proxy + iptables	eBPF

Load Balancer-Typ migrieren

Die empfohlenen Load Balancer-Typen (loadBalancer.kind) sind "ManualLB" und "MetalLB". Verwenden Sie "ManualLB", wenn Sie einen Load Balancer eines Drittanbieters wie F5 BIG-IP oder Citrix verwenden. Verwenden Sie "MetalLB" für unsere gebündelte Load Balancing-Lösung.

Ab Version 1.30 sind dies die einzigen Optionen zum Erstellen neuer Cluster. Für bestehende Cluster, die die F5 Big-IP-Integration oder den gebündelten Seesaw-Load Balancer verwenden, stellen wir Migrationsanleitungen zur Verfügung, um die "F5BigIP"-Konfigurationseinstellungen zu "ManualLB" und den gebündelten Load Balancer von Seesaw zu MetalLB zu migrieren.

Konfigurationseinstellungen für den F5 BIG-IP-Load-Balancer migrieren

Planen Sie die Migration aller Cluster, die die F5 Big-IP-Integration verwenden, zu "ManualLB". Bei der F5 Big-IP-Integration wird F5 BIG-IP mit Load Balancer-Agents verwendet, die aus den folgenden beiden Controllern bestehen:

• F5-Controller (pod prefix: load-balancer-f5): Kubernetes-Dienste vom Typ „Load Balancer“ werden im ConfigMap-Format der F5 Common Controller Core Library (CCCL) abgeglichen.
• F5 BIG-IP CIS Controller v1.14 (pod prefix: k8s-bigip-ctlr-deployment): wandelt ConfigMaps in F5-Load-Balancer-Konfigurationen um.

Die ursprüngliche F5 Big-IP-Integration hat die folgenden Einschränkungen:

• Eingeschränkte Aussagekraft: Die F5 Big-IP-Integration schränkt das volle Potenzial von F5 BIG-IP ein, da die Aussagekraft der Service API eingeschränkt wird. Dies kann dazu führen, dass Sie den BIG-IP-Controller nicht an Ihre spezifischen Anforderungen anpassen oder erweiterte F5-Funktionen nutzen können, die für Ihre Anwendung entscheidend sein könnten.
• Alte Komponente: Die aktuelle Implementierung basiert auf älteren Technologien wie der CCCL ConfigMap API und der 1.x-CIS. Diese älteren Komponenten sind möglicherweise nicht mit den neuesten Entwicklungen in den Angeboten von F5 kompatibel, was zu verpassten Chancen für Leistungs- und Sicherheitsverbesserungen führen kann.

Nach der Migration von der F5 BIG-IP-Integration zu ManualLB sind folgende Änderungen zu beachten:

	Vor der Migration	Nach der Migration
F5-Agents-Komponenten	F5-Controller OSS CIS-Controller	F5-Controller (keine Änderung) OSS-CIS-Controller (keine Änderung)
Upgrade der F5-Komponentenversion	Sie müssen Cluster aktualisieren, um F5-Komponenten zu aktualisieren. Die verfügbaren Komponentenversionen sind wie bereits erwähnt begrenzt.	Sie können die F5-Komponentenversionen bei Bedarf aktualisieren.
Dienst erstellen	Von F5-Agents bearbeitet	Von F5-Agents bearbeitet (keine Änderung)

Hinweis: Nach der Migration können Sie Dienste auf die gleiche Weise erstellen, da die F5-Agents weiterhin als Arbeitslasten in Ihrem Cluster ausgeführt werden. Der einzige Unterschied besteht darin, dass Sie nach der Migration den Lebenszyklus der F5-Agents verwalten.

Von Seesaw zu MetalLB migrieren

MetalLB bietet im Vergleich zu Seesaw folgende Vorteile:

• Vereinfachte Verwaltung und reduzierte Ressourcen: Im Gegensatz zu Seesaw wird MetalLB direkt auf Clusterknoten ausgeführt. So können Clusterressourcen dynamisch für das Load Balancing genutzt werden.
• Automatische IP-Zuweisung: Der MetalLB-Controller führt eine IP-Adressverwaltung für Services durch, sodass Sie nicht für jeden Service manuell eine IP-Adresse auswählen müssen.
• Lastverteilung auf LB-Knoten: Aktive Instanzen von MetalLB für verschiedene Services können auf verschiedenen Knoten ausgeführt werden.
• Erweiterte Funktionen und Zukunftssicherheit: Die aktive Entwicklung von MetalLB und die Einbindung in das breitere Kubernetes-Ökosystem machen es im Vergleich zu Seesaw zu einer zukunftsfähigeren Lösung. Mit MetalLB können Sie die neuesten Fortschritte in der Load Balancing-Technologie nutzen.

	Vor der Migration	Nach der Migration
LB-Knoten	Zusätzliche Seesaw-VMs (außerhalb des Clusters)	Clusterinterne LB-Knoten mit benutzerdefinierter Auswahl
Beibehalten der Client-IP-Adresse	Erreichbar über externalTrafficPolicy: Local	Kann über den DSR-Modus von DataplaneV2 erreicht werden
Dienst erstellen	Manuell angegebene Service-IP	Automatisch zugewiesene Service-IP aus Adresspool

Nutzercluster zu Controlplane V2 und Administratorcluster zu HA migrieren

Die empfohlene Steuerungsebene für Nutzercluster ist die Controlplane V2. Bei Controlplane V2 wird die Steuerungsebene auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Bei der bisherigen Steuerungsebene, die als Kubeception bezeichnet wird, wird die Steuerungsebene für einen Nutzercluster in einem Administratorcluster ausgeführt. Wenn Sie einen hochverfügbaren Administratorcluster erstellen möchten, muss Controlplane V2 in Ihren Nutzerclustern aktiviert sein.

Ab Version 1.30 muss für neue Nutzercluster Controlplane V2 aktiviert sein und neue Administratorcluster sind HA-Cluster. Upgrades von Nutzerclustern mit der bisherigen Steuerungsebene werden weiterhin unterstützt, ebenso wie Upgrades von Administratorclustern ohne Hochverfügbarkeit.

Nutzercluster zu Controlplane V2 migrieren

Bisher wurde für Nutzercluster kubeception verwendet. In Version 1.13 wurde Controlplane V2 als Vorabversion eingeführt, die in Version 1.14 zur GA-Version wurde. Seit Version 1.15 ist Controlplane V2 die Standardoption zum Erstellen von Nutzerclustern. In Version 1.30 ist Controlplane V2 die einzige Option.

Im Vergleich zu kubeception bietet Controlplane V2 folgende Vorteile:

• Architektonische Einheitlichkeit: Administratorcluster und Nutzercluster verwenden dieselbe Architektur.
• Fehlerisolierung: Ein Fehler im Admincluster wirkt sich nicht auf Nutzercluster aus.
• Betriebliche Trennung: Ein Upgrade des Administratorclusters führt nicht zu einer Ausfallzeit für Nutzercluster.
• Bereitstellungstrennung: Sie können die Administrator- und Nutzercluster in verschiedenen Topologiedomänen oder an mehreren Standorten platzieren. Bei einem Edge-Computing-Bereitstellungsmodell befindet sich ein Nutzercluster beispielsweise möglicherweise an einem anderen Ort als der Administratorcluster.

Während der Migration kommt es zu keinen Ausfallzeiten für die Arbeitslasten des vorhandenen Nutzerclusters. Je nach zugrunde liegender vSphere-Umgebung kommt es bei der Steuerungsebene während des Wechsels zu Controlplane V2 zu minimalen Ausfallzeiten. Bei der Migration geschieht Folgendes:

• Erstellt eine neue Steuerungsebene im Nutzercluster.
• Kopiert die etcd-Daten aus der alten Steuerungsebene.
• Stellt vorhandenen Knoten des Knotenpools (auch Worker-Knoten genannt) auf die neue Steuerungsebene um.

	Vor der Migration	Nach der Migration
Kubernetes-Knotenobjekte der Steuerungsebene	Administratorclusterknoten	Nutzerclusterknoten
Pods der Kubernetes-Steuerungsebene	Statefulsets-/Deployments-Administratorcluster (Nutzercluster-Namespace)	Statische Pods des Nutzerclusters (Namespace „kube-system“)
Andere Pods der Steuerungsebene	Statefulsets-/Deployments-Administratorcluster (Nutzercluster-Namespace)	Statefulsets/Deployments-Nutzercluster (Namespace „kube-system“)
Virtuelle IP-Adresse der Steuerungsebene	Load Balancer-Dienst des Administratorclusters	keepalived + haproxy (statische Pods des Nutzerclusters)
Etcd-Daten	Persistentes Volume des Administratorclusters	Datenlaufwerk
IP-Verwaltung für Maschinen der Steuerungsebene	IPAM oder DHCP	IPAM
Steuerungsebenen-Netzwerk	Administratorcluster-VLAN	Nutzercluster-VLAN

Zu einem HA-Administratorcluster migrieren

Bisher konnte im Administratorcluster nur ein einzelner Knoten der Steuerungsebene ausgeführt werden, was das inhärente Risiko eines Single Point of Failures darstellte. Neben dem Knoten der Steuerungsebene haben Administratorcluster ohne Hochverfügbarkeit auch zwei Add-on-Knoten. Ein Hochverfügbarkeits-Administratorcluster hat drei Knoten der Steuerungsebene ohne Add-on-Knoten. Die Anzahl der VMs, die für einen neuen Administratorcluster erforderlich sind, hat sich also nicht geändert, die Verfügbarkeit wird jedoch deutlich verbessert. Ab Version 1.16 können Sie einen Hochverfügbarkeits-Administratorcluster verwenden. Diese Option ist seit Version 1.28 die einzige Möglichkeit, neue Cluster zu erstellen.

Die Migration zu einem Hochverfügbarkeits-Administratorcluster bietet folgende Vorteile:

• Höhere Zuverlässigkeit und Betriebszeit: Durch die Hochverfügbarkeitskonfiguration wird der Single Point of Failure eliminiert, sodass der Administratorcluster auch dann betriebsbereit bleibt, wenn bei einem der Knoten der Steuerungsebene ein Problem auftritt.
• Verbesserte Umstellung und Aktualisierung: Alle erforderlichen Schritte zum Umstellen und Aktualisieren eines Administratorclusters werden jetzt im Cluster und nicht in einer separaten Administrator-VM ausgeführt. So wird sichergestellt, dass Upgrades und Updates fortgesetzt werden, auch wenn die erste Sitzung mit der Administrator-VM unterbrochen wird.
• Zuverlässige „Source of Truth“ für Clusterstatus: Bei Administratorclustern ohne Hochverfügbarkeit wird der Administratorclusterstatus in einer Out-of-Band-Prüfpunktdatei gespeichert. Im Gegensatz dazu speichert der HA-Administratorcluster den aktuellen Clusterstatus im Administratorcluster selbst und bietet so eine zuverlässigere Quelle für den Clusterstatus.

Sie können Ihren Administratorcluster ohne Hochverfügbarkeit zu einem hochverfügbaren Administratorcluster migrieren. Dabei kommt es zu keiner Ausfallzeit für Nutzerarbeitslasten. Der Vorgang führt zu minimalen Ausfallzeiten und Unterbrechungen bei bestehenden Nutzerclustern, die hauptsächlich mit dem Wechsel der Steuerungsebene zusammenhängen. Bei der Migration geschieht Folgendes:

• Erstellt neue HA-Steuerungsebene.
• Stellt etcd-Daten aus dem vorhandenen Cluster ohne Hochverfügbarkeit wieder her.
• Stellt die Nutzercluster auf den neuen HA-Administratorcluster um.

	Vor der Migration	Nach der Migration
Replikate für Knoten der Steuerungsebene	1	3
Add-on-Knoten	2	0
Größe des Datenlaufwerks	100GB * 1	25GB * 3
Pfad zu Datenlaufwerken	Festgelegt durch vCenter.dataDisk in der Konfigurationsdatei des Administratorclusters	Automatisch generiert im Verzeichnis: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Virtuelle IP-Adresse der Steuerungsebene	Festgelegt durch loadBalancer.kind in der Konfigurationsdatei des Administratorclusters	keepalived + haproxy
Zuweisung von IP-Adressen für Knoten der Steuerungsebene des Administratorclusters	DHCP oder statisch, je nach network.ipMode.type	3 statische IP-Adressen