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. Dementsprechend wird Google Distributed Cloud ständig angepasst und verbessert.

In Version 1.30 haben die Änderungen und Aktualisierungen einen Punkt erreicht, an dem wir Ihnen dringend empfehlen, Legacy-Bereitstellungen zu migrieren, um von erheblichen Verbesserungen zu profitieren. Auf dieser Seite werden die Vorteile der Migration von veralteten Features zu den neuesten empfohlenen Features beschrieben.

Für jeden Funktionsbereich haben Sie die folgenden Optionen:

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")	Integriertes F5 Big-IP^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 Integrierte F5 BIG-IP bezieht sich auf loadBalancer.kind: "F5BigIP" und zugehörige 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 zu neuer Funktion
Version 1.32 und höher
Admin	Ohne Hochverfügbarkeit	Nein	Nein	–
	Seesaw	Nein	Nein	–
	Integrierte F5 Big-IP	Nein	Nein	–
Nutzer	Kubeception	Nein	Nein	–
	Seesaw	Nein	Nein	–
	Integrierte F5 Big-IP	Nein	Nein	–
	Dataplane V1	Nein	Nein	–
Version 1.30 und 1.31
Admin	Ohne Hochverfügbarkeit	Nein	Ja	Ja
	Seesaw	Nein	Ja	Ja
	Integrierte F5 Big-IP	Nein	Ja	Ja
Nutzer	Kubeception	Nein	Ja	Ja
	Seesaw	Nein	Ja	Ja
	Integrierte F5 Big-IP	Nein	Ja	Ja
	Dataplane V1	Nein	Ja	Ja
Version 1.29
Admin	Ohne Hochverfügbarkeit	Nein	Ja	Ja (Vorschau)
	Seesaw	Nein	Ja	Ja
	Integrierte F5 Big-IP	Ja	Ja	Ja (Vorschau)
Nutzer	Kubeception	Ja	Ja	Ja (Vorschau)
	Seesaw	Ja	Ja	Ja
	Integrierte F5 Big-IP	Ja	Ja	Ja (Vorschau)
	Dataplane V1	Ja	Ja	Nein
Version 1.28
Admin	Ohne Hochverfügbarkeit	Nein	Ja	Nein
	Seesaw	Nein	Ja	Ja
	Integrierte F5 Big-IP	Ja	Ja	Nein
Nutzer	Kubeception	Ja	Ja	Nein
	Seesaw	Ja	Ja	Ja
	Integrierte F5 Big-IP	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.

• Wenn Sie neue Cluster erstellen, sind die ursprünglichen Funktionen in den folgenden Versionen nicht zulässig:

  • Administratorcluster:

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

  • Nutzercluster:

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

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

Nutzercluster zu Dataplane V2 migrieren

Sie können ein Container Network Interface (CNI) auswählen, das Container-Netzwerkfunktionen bietet, entweder Calico oder Dataplane V2. Dataplane V2, die CNI-Implementierung von Google, basiert auf Cilium und wird sowohl in Google Kubernetes Engine (GKE) als auch in 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, ist aber so konzipiert, dass für vorhandene Arbeitslasten keine Ausfallzeiten entstehen. Wenn Sie proaktiv zu Dataplane V2 migrieren, profitieren Sie von folgenden Vorteilen:

• Verbesserte Leistung und Skalierbarkeit: Das optimierte Design und die effiziente Ressourcennutzung von Dataplane V2 können zu einer verbesserten Netzwerkleistung und 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: Die Standardisierung auf Dataplane V2 in Google Distributed Cloud und GKE kann die Clusterverwaltung und Fehlerbehebung vereinfachen, da Sie sich auf einen einheitlichen Satz von Tools und Dokumentationen verlassen können.

• Erweiterte Netzwerkfunktionen: EgressNAT und andere erweiterte Netzwerkfunktionen werden nur in 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

Entfernen Sie die Annotation features.onprem.cluster.gke.io/dpv2-migration sowohl aus der benutzerdefinierten Ressource OnPremUserCluster als auch aus der benutzerdefinierten Ressource OnPremAdminCluster (wenn Ihr Administratorcluster während des Upgrades von Version 1.29 auf 1.30 von Calico migriert wurde), nachdem Sie überprüft haben, dass die Migration von Calico zu Dataplane V2 abgeschlossen ist und Sie kein Rollback zu Calico durchführen müssen. Wenn Sie diese Annotation entfernen, bevor Sie den Cluster skalieren oder upgraden, kann der Cluster-Controller die inaktiven DaemonSets calico-node und calico-route-daemon dauerhaft löschen. Für Cluster, die mit aktiviertem Dataplane V2 erstellt wurden, müssen Sie diesen Schritt nicht ausführen. Weitere Informationen finden Sie unter Inaktive Calico-DaemonSets entfernen.

Load-Balancer-Typ migrieren

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

Ab Version 1.30 sind dies die einzigen Optionen zum Erstellen neuer Cluster. Für bestehende Cluster, die den integrierten F5 Big-IP- 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 das integrierte F5 Big-IP verwenden, zu ManualLB. Bei der integrierten 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): gleicht Kubernetes-Dienste vom Typ „LoadBalancer“ mit dem Format F5 Common Controller Core Library (CCCL) ConfigMap ab.
• F5 BIG-IP CIS Controller v1.14 (pod prefix: k8s-bigip-ctlr-deployment): wandelt ConfigMaps in F5-Load-Balancer-Konfigurationen um.

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

• Eingeschränkte Aussagekraft: Die integrierte F5 Big-IP-Lösung 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 möglicherweise entscheidend sind.
• Legacy-Komponente: Die aktuelle Implementierung basiert auf älteren Technologien wie der CCCL ConfigMap API und 1.x CIS. Diese Legacy-Komponenten sind möglicherweise nicht mit den neuesten Entwicklungen in den Angeboten von F5 kompatibel, was dazu führen kann, dass Sie Chancen für Leistungsverbesserungen und Sicherheitsoptimierungen verpassen.

Die Änderungen nach der Migration von der integrierten F5 BIG-IP zu ManualLB umfassen:

	Vor der Migration	Nach der Migration
F5-Agent-Komponenten	F5-Controller OSS CIS-Controller	F5-Controller (keine Änderung) OSS CIS-Controller (keine Änderung)
Upgrade der F5-Komponentenversion	Sie müssen Cluster upgraden, um F5-Komponenten zu aktualisieren. Die verfügbaren Komponentenversionen sind wie zuvor erläutert begrenzt.	Sie können die F5-Komponentenversionen nach Bedarf aktualisieren.
Diensterstellung	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 die folgenden Vorteile:

• Vereinfachte Verwaltung und weniger Ressourcen: Im Gegensatz zu Seesaw wird MetalLB direkt auf Clusterknoten ausgeführt, sodass Clusterressourcen dynamisch für das Load Balancing verwendet werden können.
• 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 Integration in das breitere Kubernetes-Ökosystem machen es im Vergleich zu Seesaw zu einer zukunftssichereren 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	Kann über externalTrafficPolicy: Local erreicht werden	Kann über den DataplaneV2-DSR-Modus erreicht werden
Diensterstellung	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 Controlplane V2. Bei Controlplane V2 wird die Steuerungsebene auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Bei der Legacy-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 für Ihre Nutzercluster Controlplane V2 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

In der Vergangenheit haben Nutzercluster kubeception verwendet. In Version 1.13 wurde Controlplane V2 als Funktion in der Vorabversion eingeführt, die in Version 1.14 allgemein verfügbar 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:

• Einheitliche Architektur: Administratorcluster und Nutzercluster verwenden dieselbe Architektur.
• Fehlerisolation: Ein Fehler im Administratorcluster hat keine Auswirkungen auf Nutzercluster.
• Betriebliche Trennung: Das Upgrade eines Administratorclusters zieht keine Ausfallzeit für Nutzercluster nach sich.
• Bereitstellungstrennung: Sie können die Administrator- und Nutzercluster in verschiedenen Topologiedomänen oder an mehreren Standorten platzieren. In einem Edge-Computing-Bereitstellungsmodell kann sich ein Nutzercluster beispielsweise an einem anderen Standort als der Administratorcluster befinden.

Während der Migration gibt es keine Ausfallzeiten für die vorhandenen Nutzercluster-Arbeitslasten. Je nach zugrunde liegender vSphere-Umgebung kommt es während der Umstellung auf Controlplane V2 zu minimalen Ausfallzeiten der Steuerungsebene. 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	Administratorcluster-Knoten	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
Netzwerk der Steuerungsebene	VLAN für Administratorcluster	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. Zusätzlich zu dem einen Knoten für die 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 Administratorcluster mit Hochverfügbarkeit (HA) verwenden. Ab Version 1.28 ist dies die einzige Option für die Erstellung neuer Cluster.

Die Migration zu einem HA-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 auf einer separaten Administrator-Workstation ausgeführt. So wird sichergestellt, dass Upgrades und Updates auch dann fortgesetzt werden, wenn die erste Sitzung zur Administrator-Workstation 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 wird der aktuelle Clusterstatus bei einem HA-Administratorcluster im Administratorcluster selbst gespeichert, was eine zuverlässigere „Source of Truth“ für den Clusterstatus darstellt.

Sie können Ihren Administratorcluster ohne Hochverfügbarkeit zu einem hochverfügbaren Administratorcluster migrieren. Dabei kommt es zu keiner Ausfallzeit für Nutzerarbeitslasten. Der Prozess verursacht minimale Ausfallzeiten und Unterbrechungen für vorhandene Nutzercluster, 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 der Datenlaufwerke	Festgelegt durch vCenter.dataDisk in der Konfigurationsdatei des Administratorclusters	Automatisch im Verzeichnis /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk generiert
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

Load-Balancer- und Steuerungsebenen-Migrationen gruppieren

Beim Aktualisieren von Clustern empfehlen wir in der Regel, jeweils nur ein Feature oder eine Einstellung zu aktualisieren. In Version 1.30 und höher können Sie die Konfigurationsänderungen für die Migration sowohl für den Load Balancer als auch für die Steuerungsebene gruppieren und dann den Cluster nur einmal aktualisieren, um beide Änderungen vorzunehmen.

Wenn Sie Nutzercluster mit einer alten CNI haben, müssen Sie zuerst zu DataPlane V2 migrieren. Anschließend können Sie die Migration für den Load Balancer und die Steuerungsebene gruppieren. Die Gruppierung der Migration bietet folgende Vorteile:

• Ein einfacherer Prozess: Wenn Sie sowohl eine Steuerungsebene als auch einen Load Balancer migrieren müssen, aktualisieren Sie den Cluster in der Regel nur einmal. Sie müssen auch nicht entscheiden, welche Funktionen Sie zuerst migrieren möchten.
• Gesamtausfallzeit reduzieren: Bestimmte Migrationen sind mit Ausfallzeiten der Steuerungsebene verbunden. Wenn Sie diese Migrationen in einem einzigen Updatevorgang zusammenfassen, wird die Gesamtausfallzeit im Vergleich zu sequenziellen Einzelupdates reduziert.

Der Vorgang variiert je nach Clusterkonfiguration. Führen Sie die Migration für jeden Cluster wie in den folgenden Schritten beschrieben aus:

1. Migrieren Sie jeden Nutzercluster, um die empfohlene CNI, Dataplane V2, zu verwenden.

   1. Nehmen Sie die Konfigurationsänderungen vor und aktualisieren Sie den Nutzercluster, um eine Migration des Nutzerclusters von der alten CNI, Calico, zu Dataplane V2 auszulösen.

      Hinweis: Dieser Schritt ist für den Administratorcluster nicht erforderlich. Wenn Sie ein Upgrade des Administratorclusters auf Version 1.30 durchführen, wird der Cluster automatisch zu Dataplane V2 migriert.

   2. Nachdem Sie überprüft haben, ob die Dataplane V2-Migration abgeschlossen ist und Sie kein Rollback zu Calico durchführen müssen, entfernen Sie die Annotation features.onprem.cluster.gke.io/dpv2-migration aus der benutzerdefinierten Ressource OnPremUserCluster (und aus OnPremAdminCluster, wenn Ihr Administratorcluster während des Upgrades von Version 1.29 auf 1.30 von Calico migriert wurde). Wenn Sie diese Annotation entfernen, bevor Sie den Cluster skalieren oder aktualisieren, kann der Cluster-Controller die inaktiven DaemonSets calico-node und calico-route-daemon dauerhaft löschen. Eine Anleitung finden Sie unter Inaktive Calico-DaemonSets entfernen.

2. Migrieren Sie jeden Nutzercluster vom alten Load Balancer (LB) und der alten Steuerungsebene (CP) zum empfohlenen Load Balancer und zu Controlplane V2.

   1. Nehmen Sie Konfigurationsänderungen vor, um den empfohlenen Load Balancer (MetalLB oder ManualLB) zu verwenden.
   2. Nehmen Sie Konfigurationsänderungen vor, um Controlplane V2 zu aktivieren.
   3. Aktualisieren Sie den Nutzercluster, um den Load Balancer und die Steuerungsebene zu migrieren.

3. Migrieren Sie den Administratorcluster, um den empfohlenen Load Balancer zu verwenden und die Steuerungsebene hochverfügbar zu machen.

   1. Nehmen Sie Konfigurationsänderungen vor, um den empfohlenen Load Balancer (MetalLB oder ManualLB) zu verwenden.
   2. Nehmen Sie Konfigurationsänderungen vor, um die Steuerungsebene des Administratorclusters von Nicht-HA zu HA zu migrieren.
   3. Aktualisieren Sie den Administratorcluster, um den Load Balancer und die Steuerungsebene zu migrieren.

4. Führen Sie optionale Bereinigungsschritte aus, z. B. die Bereinigung der VM der Steuerungsebene ohne Hochverfügbarkeit.

Das folgende Diagramm veranschaulicht die Migrationsschritte:

Wenn Ihr Administratorcluster und alle Ihre Nutzercluster die Version 1.30 oder höher haben, können Sie den Gruppenmigrationsprozess verwenden. Eine detaillierte Anleitung finden Sie in den folgenden Leitfäden:

• Nutzercluster zu empfohlenen Funktionen migrieren
• Administratorcluster zu empfohlenen Funktionen migrieren