VPC-native Cluster zu GKE Dataplane V2 migrieren

In diesem Dokument wird beschrieben, wie Sie Ihre vorhandenen VPC-nativen Google Kubernetes Engine-Cluster (GKE) von Dataplane V1 zu GKE Dataplane V2 migrieren, die Migration beobachten und sie bei Bedarf rückgängig machen.

Dieses Dokument richtet sich an Plattformadministratoren und ‑operatoren sowie Netzwerkspezialisten, die Netzwerkkonfigurationen für ihre GKE-Cluster verwalten.

Bevor Sie beginnen, erfahren Sie unter Informationen zur Migration zu GKE Dataplane V2, was in den einzelnen Migrationsphasen geschieht und wie Sie Arbeitslastunterbrechungen planen.

Hinweis

Prüfen Sie vor dem Start der Migration, ob Ihr Cluster die Voraussetzungen erfüllt, und berücksichtigen Sie die Auswirkungen auf Ihre Arbeitslasten.

Ihr Cluster muss die folgenden Anforderungen erfüllen:

  • Der Cluster ist ein VPC-nativer Cluster.
  • Auf dem Cluster wird Version 1.35.3-gke.1155000 oder höher ausgeführt.
  • Auf den Knotenpools wird Version 1.35.1-gke.1516000 oder höher ausgeführt.
  • Wenn Sie Cloud Service Mesh oder Open-Source-Istio verwenden, muss Ihre Istio-Version 1.23 oder höher sein.

Cluster vorbereiten

Führen Sie die folgenden Aufgaben aus, bevor Sie mit der Migration beginnen:

  • NetworkPolicy entfernen: Entfernen Sie Ihre vorhandenen Netzwerkrichtlinien. Wenn GKE beim Neuerstellen Ihrer Knoten plötzlich Netzwerkrichtlinien erzwingt, kann es zu unbeabsichtigten Netzwerkunterbrechungen kommen.
  • Calico-Netzwerkrichtlinien: Wenn Sie einen GKE Standardcluster mit aktivierter Netzwerkrichtlinie (Calico) verwenden, deaktivieren Sie die Durchsetzung von Netzwerkrichtlinien. Diese Cluster können nicht direkt migriert werden.
  • Active Assist-Empfehlungen: Suchen Sie in Active Assist oder auf der Cluster-Detailseite nach Empfehlungen, die mit der Migration in Konflikt stehen könnten.
  • IP-Adresskapazität: Prüfen Sie, ob der Pod-IP-Adressbereich Ihres Clusters genügend Kapazität für Ihre Upgradestrategien für Knotenpools hat. Weitere Informationen finden Sie unter Statistiken zur GKE-IP-Adressauslastung.
    • Netzwerkfunktionen: Aktivieren Sie Netzwerkfunktionen wie NodeLocal DNSCache oder die knoteninterne Sichtbarkeit, bevor Sie mit der Migration beginnen oder nachdem die Migration abgeschlossen ist. Während der Migration können Sie sie nicht aktivieren.

Einschränkungen

  • Gesperrte Netzwerkkonfigurationen: Nachdem Sie die Migration gestartet haben, können Sie keine clusterweiten Netzwerkkonfigurationen mehr ändern, bis die Migration abgeschlossen ist.
  • Wartungsfenster: Die Migration folgt Ihren Wartungsfenstern und ‑ausschlüssen. Daher kann es so aussehen, als würde sie ins Stocken geraten. Sie können Knotenpools manuell patchen, um die Migration zu beschleunigen. Eine Anleitung finden Sie unter Migration beschleunigen.
  • Optionale GKE Dataplane V2-Funktionen: Konfigurieren Sie optionale GKE Dataplane V2 Funktionen wie die Beobachtbarkeit von GKE Dataplane V2 oder die Unterstützung mehrerer Netzwerke für Pods, nachdem die Migration abgeschlossen ist.
  • Terraform: Sie können Terraform nicht verwenden, um zu GKE Dataplane V2 zu migrieren.

Migration starten

Wenn Sie die Migration manuell starten und automatische Diagnosetests umgehen möchten, können Sie den Cluster mit der Google Cloud CLI patchen.

Führen Sie dazu diesen Befehl aus:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-dataplane-v2

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION ist der Compute-Standort des Clusters.

Migrationsfortschritt beobachten

Sie können den Migrationsstatus prüfen, indem Sie das Feld datapathProvider prüfen. Während der Umstellung wird in diesem Feld MIGRATE_TO_ADVANCED_DATAPATH angezeigt.

  1. Prüfen Sie den Clusterstatus:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • LOCATION ist der Compute-Standort des Clusters.

  2. Prüfen Sie den Knotenpoolstatus:

    gcloud container node-pools list \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value(name, networkConfig.datapathProvider)'

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • LOCATION ist der Compute-Standort des Clusters.

  3. Prüfen Sie das anetd-DaemonSet, um zu prüfen, ob die Agents ausgeführt werden:

    kubectl get ds -n kube-system anetd

Migration beschleunigen

Wenn Sie den automatischen Roll-out-Zeitplan umgehen möchten, können Sie Knotenpools manuell patchen.

Führen Sie den folgenden Befehl aus, um einen Knotenpool manuell zu patchen:

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --datapath-provider=advanced-datapath

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des Knotenpools.
  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION ist der Compute-Standort des Clusters.

Migration abschließen

Nachdem alle Knotenpools zu GKE Dataplane V2 migriert wurden, schließt GKE die Migration automatisch ab. Wenn die Migration abgeschlossen ist, wird in der Befehlsausgabe der Status ADVANCED_DATAPATH angezeigt und auf dem Cluster wird GKE Dataplane V2 ausgeführt.

Prüfen Sie den Clusterstatus, um zu sehen, wann die Migration abgeschlossen ist:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION ist der Compute-Standort des Clusters.

Wenn die Migration abgeschlossen ist, wird in der Ausgabe ADVANCED_DATAPATH angezeigt.

Migration rückgängig machen

Sie können die Migration jederzeit vor Abschluss der Finalisierungsphase zu Dataplane V1 zurückkehren. Das Rückgängigmachen der Migration ist ein symmetrischer Prozess zur Migration: Nachdem Sie den Rollback gestartet haben, patcht GKE die Knotenpools automatisch wieder auf den alten Datenpfad und finalisiert dann den Cluster.

  1. **anetdStatus beobachten** : Prüfen Sie vor dem Rollback der Migration, ob die Agents ausgeführt werden, um festzustellen, ob der Fehler behoben werden kann.

    kubectl get ds -n kube-system anetd

  2. Laufende Knotenpoolvorgänge abbrechen:

    1. Suchen Sie nach laufenden Knotenpoolvorgängen, die die Clusterpatchanfrage blockieren würden, und brechen Sie sie ab.

      gcloud container operations list \
    --location=LOCATION \
    --filter="operationType=UPGRADE_NODES AND status=RUNNING AND targetLink:*/clusters/CLUSTER_NAME"

      Ersetzen Sie Folgendes:

      • LOCATION ist der Compute-Standort des Clusters.
      • CLUSTER_NAME ist der Name des Clusters.

    2. Brechen Sie den Vorgang mit der Vorgangs-ID ab:

      gcloud container operations cancel OPERATION_ID \
    --location=LOCATION

      Ersetzen Sie Folgendes:

      • OPERATION_ID ist die ID des laufenden Vorgangs.
      • LOCATION ist der Compute-Standort des Clusters.

  3. Rollback starten: Senden Sie eine Clusterpatchanfrage, um die Migration zu Dataplane V1 zurückzukehren.

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-dataplane-v2

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • LOCATION ist der Compute-Standort des Clusters.

  4. Roll-out des Knotenpools beobachten: Prüfen Sie den Knotenpoolstatus, um die Migration zum alten Datenpfad zu bestätigen.

    gcloud container node-pools list \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value(name, networkConfig.datapathProvider)'

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • LOCATION ist der Compute-Standort des Clusters.

    Während des Rollbacks wird in der Befehlsausgabe für gepatchte Knotenpools der Status LEGACY_DATAPATH angezeigt.

  5. Finalisierung beobachten: Nachdem alle Knotenpools zu Dataplane V1 migriert wurden, schließt GKE die Migration automatisch ab. Prüfen Sie den Clusterstatus, um zu sehen, wann die Migration abgeschlossen ist:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • LOCATION ist der Compute-Standort des Clusters.

    Wenn der Rollback abgeschlossen ist, wird in der Befehlsausgabe der Status LEGACY_DATAPATH angezeigt.

Fehler bei der Migration beheben

In diesem Abschnitt finden Sie Informationen zur Problembehebung und Behebung häufiger Probleme, die bei der Migration zu GKE Dataplane V2 auftreten können.

Migration des Knotenpools schlägt fehl

Bei der Migration von Knotenpools verwendet GKE die konfigurierte Strategie für Surge-Upgrades oder Blau/Grün-Upgrades, um neue Knoten zu erstellen, bevor die alten gelöscht werden. Wenn in Ihrer Google Cloud Zone nicht genügend Ressourcen zur Bereitstellung der neuen Knoten vorhanden sind, schlägt die Migration mit dem Fehler GCE_STOCKOUT oder ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS fehl. GKE versucht automatisch noch einmal, diese Knotenpools zu migrieren. Wenn Sie die Knotenpools manuell patchen, warten Sie und versuchen Sie es später noch einmal, wenn Ressourcen verfügbar sind.

Nächste Schritte