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

In Version 1.30 sind die Änderungen und Updates so weit fortgeschritten, dass wir dringend empfehlen, Legacy-Bereitstellungen zu migrieren, um von den erheblichen Verbesserungen zu profitieren. Auf dieser Seite werden die Vorteile der Migration von veralteten Funktionen zu den neuesten empfohlenen Funktionen 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-IP1
    (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 Integriertes F5 BIG-IP bezieht sich auf loadBalancer.kind: "F5BigIP" und die zugehörigen Einstellungen im Abschnitt loadBalancer.f5BigIP in Ihrer Clusterkonfigurationsdatei.

In den folgenden Tabellen sehen 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.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.

  • Beim Erstellen neuer Cluster sind Originalfunktionen 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 Funktionen 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 besseren Skalierbarkeit führt, insbesondere für große Cluster 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 es für vorhandene Arbeitslasten zu keinen Ausfallzeiten kommt. 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 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. So kann der Cluster mithilfe von BPF-Maps skaliert werden.

  • Vereinfachte Verwaltung und Unterstützung:Die Standardisierung auf Dataplane V2 in Google Distributed Cloud und GKE kann die Clusterverwaltung und Fehlerbehebung vereinfachen, da Sie sich auf eine einheitliche Reihe von Tools und Dokumentationen verlassen können.

  • Erweiterte Netzwerkfunktionen: Die 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

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 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-Load Balancer 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-Lösung 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 der 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-Lösung hat die folgenden Einschränkungen:

  • Eingeschränkte Aussagekraft: Das integrierte F5 Big-IP schränkt das volle Potenzial von F5 BIG-IP ein, da die Aussagekraft der Service API eingeschränkt wird. Dadurch können Sie den BIG-IP-Controller möglicherweise nicht an Ihre spezifischen Anforderungen anpassen oder erweiterte F5-Funktionen nutzen, die für Ihre Anwendung entscheidend sein könnten.
  • 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 im Angebot von F5 kompatibel, was zu verpassten Möglichkeiten für Leistungsverbesserungen und Sicherheitserweiterungen führen kann.

Nach der Migration vom integrierten F5 BIG-IP zu ManualLB gelten die folgenden Änderungen:

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 upgraden, um F5-Komponenten zu aktualisieren. Die verfügbaren Komponentenversionen sind wie oben beschrieben begrenzt. Sie können F5-Komponentenversionen nach Bedarf aktualisieren.
Dienst erstellen Von F5-Agents bearbeitet Von F5-Agents bearbeitet (keine Änderung)

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. So können Clusterressourcen dynamisch für den Lastenausgleich verwendet 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 Integration in das breitere Kubernetes-Ökosystem machen es zu einer zukunftssicheren Lösung im Vergleich zu Seesaw. 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
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 Controlplane V2. Bei Controlplane V2 wird die Steuerungsebene auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Bei der alten Steuerungsebene, die als kubeception bezeichnet wird, wird die Steuerungsebene für einen Nutzercluster in einem Administratorcluster ausgeführt. Wenn Sie einen Administratorcluster mit Hochverfügbarkeit (HA) 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 wurde für Nutzercluster Kubeception verwendet. In Version 1.13 wurde Controlplane V2 als Vorschaufunktion eingeführt, die in Version 1.14 in den GA-Status überging. 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: Administrator- und Nutzercluster verwenden dieselbe Architektur.
  • Fehlerisolation:Ein Fehler im Administratorcluster hat keine Auswirkungen auf Nutzercluster.
  • Betriebliche Trennung:Das Upgrade eines Administratorclusters führt nicht zu Ausfallzeiten für Nutzercluster.
  • 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 Arbeitslasten des vorhandenen Nutzerclusters. Abhängig von Ihrer zugrunde liegenden vSphere-Umgebung kommt es bei der Steuerungsebene während der Umstellung auf Controlplane V2 zu minimalen Ausfallzeiten. Bei der Migration wird Folgendes ausgeführt:

  • 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-Adressenverwaltung für Maschinen der Steuerungsebene IPAM oder DHCP IPAM
Netzwerk der Steuerungsebene VLAN für Administratorcluster VLAN für Nutzercluster

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 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. In Version 1.28 wurde dies zur einzigen Option für das Erstellen 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 ursprüngliche 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 im HA-Administratorcluster selbst gespeichert. Dies bietet eine zuverlässigere „Source of Truth“ 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 Prozess führt zu minimalen Ausfallzeiten und Unterbrechungen bei bestehenden Nutzerclustern, die hauptsächlich mit der Umstellung der Steuerungsebene zusammenhängen. Bei der Migration wird Folgendes ausgeführt:

  • Erstellt neue HA-Steuerungsebene.
  • Stellt die 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 für Datenlaufwerke 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

Load-Balancer- und Steuerungsebenenmigrationen gruppieren

Wenn Sie Cluster aktualisieren, 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 Ihren Load Balancer als auch für die Steuerungsebene gruppieren und den Cluster dann nur einmal aktualisieren, um beide Änderungen vorzunehmen.

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

  • 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üssen.
  • Gesamtausfallzeiten reduzieren: Bei bestimmten Migrationen kommt es zu Ausfallzeiten der Steuerungsebene. Wenn Sie diese Migrationen in einem Updatevorgang zusammenfassen, werden die Gesamtausfallzeiten im Vergleich zu sequenziellen einzelnen Updates reduziert.

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

  1. Migrieren Sie jeden Nutzercluster zur Verwendung des empfohlenen CNI, Dataplane V2.

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

  2. Migrieren Sie jeden Nutzercluster vom alten Load Balancer (LB) und der alten Steuerungsebene (CP) zur Verwendung des empfohlenen Load Balancers und von 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, damit er den empfohlenen Load Balancer verwendet und die Steuerungsebene hochverfügbar ist.

    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. das Bereinigen der Steuerungsebene-VM ohne HA.

Das folgende Diagramm veranschaulicht die Migrationsschritte:

Schritte für die Migration zu empfohlenen Funktionen

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