Modernisierung der verwalteten Steuerungsebene

Sie müssen Ihre Cloud Service Mesh-Flotten vor dem Ende des Supports von der eingestellten ISTIOD-Steuerungsebene zur TRAFFIC_DIRECTOR-Implementierung migrieren. Sie können die Modernisierung selbst planen oder Google sie automatisch planen lassen, sobald Ihre Organisation kompatibel ist.

Es gibt zwei Modernisierungspfade, die Sie auch kombinieren können:

  • Vom Kunden ausgelöste Modernisierung (Selfservice): Sie initiieren und steuern den genauen Zeitpunkt der Flottenmodernisierung selbst über die Google Cloud CLI, unabhängig von Google-gesteuerten Zeitplänen.
  • Von Google gesteuerte Modernisierung (Standard): Google bewertet die Flottenkompatibilität und plant die Modernisierung automatisch für Ihre Organisation gemäß Wartungsfenstern und Vorabbenachrichtigungen. Google wartet, bis alle Flotten in Ihrer Organisation kompatibel sind. Eine einzelne inkompatible Flotte kann die Modernisierung also blockieren.

Unabhängig davon, welchen Pfad Sie wählen, müssen Sie die folgenden grundlegenden Schritte ausführen, um Ihre Steuerungsebene zu modernisieren:

  1. Kompatibilität prüfen: Aktivieren Sie Kompatibilitätsprüfungen und sehen Sie sich die Kompatibilität Ihrer Flotten mit der Modernisierung an.
  2. Modernisierung planen und konfigurieren: Wählen Sie Ihren Pfad aus, konfigurieren Sie die Reihenfolge für die Einführung von Clustern und Flotten oder verschieben Sie bestimmte Flotten.
  3. Kompatibilitätslücken beheben: Achten Sie darauf, dass Ihre Flotten alle Kompatibilitätsanforderungen erfüllen, bevor Sie mit der Modernisierung beginnen.
  4. Modernisierung einleiten: Sie können die vom Kunden ausgelöste Modernisierung nach Ihrem Zeitplan auslösen oder auf die von Google festgelegte Planung warten.
  5. Aktive Clustermodernisierung: Während der konfigurierten Wartungsfenster werden zwei Steuerungsebenen parallel ausgeführt und Bereitstellungen (Arbeitslasten und Gateways) werden automatisch auf die neue Steuerungsebene umgestellt. Sie müssen StatefulSet- und DaemonSet-Arbeitslasten manuell neu starten.
  6. Status, Soak und Finalisierung überwachen: Überwachen Sie den Fortschritt des Zustands, beheben Sie alle Verzögerungen und beobachten Sie die Arbeitslasten während des Soak-Zeitraums (mindestens 6 Arbeitstage). Vor der Finalisierung auf Flottenebene ist eine vollständige Zurücksetzung möglich.

Kompatibilität der Flotte prüfen und Lücken beheben

Bevor eine Flotte modernisiert werden kann – entweder durch den Kunden oder durch Google –, muss sie als kompatibel bestätigt werden. Sie müssen die Kompatibilitätsberichte aktivieren, um potenzielle Blockierungsbedingungen zu prüfen und Konfigurationslücken zu beheben. Weitere Informationen finden Sie unter Cloud Service Mesh-Kompatibilität.

  • Bei der Google-gesteuerten Modernisierung plant Google nur Organisationen, in denen alle nicht aufgeschobenen Flotten kompatibel sind.
  • Bei der vom Kunden ausgelösten Modernisierung müssen Sie prüfen, ob für Ihre Zielflotte MODERNIZATION_COMPATIBLE gemeldet wird, bevor Sie die Modernisierung starten.

Bei Kompatibilitätsprüfungen werden die Istio-CRD-Konfigurationen, Pod-Annotationen, Infrastrukturabhängigkeiten (z. B. Workload Identity) und Skalierungsparameter Ihrer Flotte ausgewertet.

Nicht unterstützte Funktionen

Im Rahmen der ISTIOD-Steuerungsebene Google Cloud werden Funktionen, die nicht mit der TRAFFIC_DIRECTOR-Steuerungsebene kompatibel sind, nicht mehr unterstützt. Details zur API-Unterstützung

Wenn Sie nicht unterstützte Funktionen verwenden, müssen Sie vor dem Ende des Supports eine der folgenden Maßnahmen ergreifen (siehe Einstellung):

  • Konfiguration refaktorieren (empfohlen): Entfernen Sie die nicht unterstützten Felder oder ersetzen Sie sie durch unterstützte Cloud Service Mesh-Alternativen, damit für Ihre Flotte MODERNIZATION_COMPATIBLE gemeldet wird. Modernisieren Sie dann die Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene.
  • Zu Open-Source-Istio (OSS) migrieren: Wenn für Ihre Arbeitslasten unbedingt Funktionen erforderlich sind, die das verwaltete Cloud Service Mesh mit TRAFFIC_DIRECTOR nicht unterstützt, können Sie diese Cluster nicht auf TRAFFIC_DIRECTOR umstellen. Sie müssen diese Arbeitslasten zu selbstverwaltetem Open-Source-Istio migrieren.
  • Cloud Service Mesh deinstallieren: Sie können verwaltetes Cloud Service Mesh deinstallieren.

Modernisierung planen und konfigurieren

Erstellen Sie einen Plan für die Modernisierung Ihrer Flotte(n). Wenn Sie das nicht tun, wird die von Google gesteuerte Modernisierung standardmäßig angewendet. Sie müssen Maßnahmen ergreifen, um sicherzustellen, dass Ihre Nichtproduktionsflotten zuerst und Ihre kritischen Flotten zuletzt modernisiert werden. Außerdem wird die Modernisierung Ihrer Organisation erst geplant, wenn 100% der nicht aufgeschobenen Gerätepools in Ihrer gesamten Organisation kompatibel sind. Die Modernisierung kann also durch lokale Inkompatibilitäten blockiert werden.

Bevor Sie mit der Modernisierung beginnen, sollten Sie Ihre Optionen prüfen und die Roll-out-Einstellungen für die Flotten und Cluster Ihrer Organisation konfigurieren.

Verfügbare Lernpfade

Ansatz Beschreibung Optimal für Umfang Vorbereitung Vorankündigung Rollback-Funktion
Vom Kunden ausgelöste Modernisierung Sie initiieren die Modernisierung flottenweise nach Ihrem eigenen Zeitplan. Granulare Kontrolle über den Zeitpunkt der Flottenmodernisierung: Sie entscheiden, wann die Modernisierung auf Flottenebene gestartet und wann sie zurückgesetzt wird. Sie können Ihr vorhandenes Anwendungsmonitoring nutzen, um sich benachrichtigen zu lassen, wenn ein Rollback erforderlich ist. Flottenweise (FLEET_PROJECT_ID). Die Zielflotte muss für die Modernisierung geeignet sein. n/a Sofortiges Self-Service-Rollback mit der Google Cloud CLI.
Google-Driven Modernization (Standard) Google plant die Modernisierung in Ihrer Organisation automatisch. Automatisierte Modernisierung, sobald alle Flotten in Ihrer Organisation kompatibel sind. Gesamte Google Cloud Organisation (alle nicht aufgeschobenen Flotten). Alle nicht aufgeschobenen Flotten in der Organisation müssen modernisierungskompatibel sein. Benachrichtigung für die Flotte mindestens 14 Tage vor Beginn und Benachrichtigung für den Cluster mindestens 24 Stunden vor Beginn. Google führt ein Rollback durch, wenn bei der standardisierten Überwachung ein Fehler auftritt. Wenn bei der Anwendungsüberwachung ein Fehler angezeigt wird, müssen Sie sich an Cloud Customer Care wenden.

Verwaltung mehrerer Flotten in einer Organisation

Wenn Ihre Google Cloud Organisation mehrere Flotten verwaltet, müssen Sie nicht für alle einen einzelnen Ansatz wählen. Sie können Strategien kombinieren, z. B.:

  • Komplexe oder kritische Flotten zurückstellen: Pinnen Sie bestimmte Flotten mit --modernization-strategy deferred an die Legacy-Implementierung, damit sie von der Google-gesteuerten Planung ausgeschlossen werden, während Sie Abhängigkeiten beheben oder die vom Kunden ausgelöste Ausführung planen.
  • Beginnen Sie mit der vom Kunden ausgelösten Modernisierung ausgewählter Flotten: Modernisieren Sie zuerst Test-, Entwicklungs- oder Bewertungsflotten, um das Verhalten nach Ihrem eigenen Zeitplan zu validieren.
  • Google erlauben, verbleibende Flotten zu modernisieren: Alle kompatiblen, nicht aufgeschobenen Flotten bleiben für die von Google gesteuerte Planung aktiviert.

Flottenmodernisierung aufschieben (Opt-out)

Wenn Sie eine einzelne Flotte von der von Google gesteuerten Modernisierung ausschließen möchten, legen Sie die Strategie auf DEFERRED fest:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Ersetzen Sie FLEET_PROJECT_ID durch die ID des Flotten-Hostprojekts.

Die Einstellung --modernization-strategy deferred ist die empfohlene Methode, um:

  • Sie möchten bestimmte Flotten von der von Google gesteuerten Planung ausschließen, weil Sie sie selbst nach Ihrem eigenen Zeitplan modernisieren möchten.
  • Sie können die Modernisierung komplexer oder kritischer Flotten vorübergehend zurückstellen, während Sie Abhängigkeiten beheben. So können andere kompatible Flotten in Ihrer Organisation mit der von Google gesteuerten Planung fortfahren.

Das alte Projektlabel mesh-modernization-mode=manual wird weiterhin berücksichtigt, aber --modernization-strategy deferred wird empfohlen. Andere nicht aufgeschobene Flotten in Ihrer Organisation können weiterhin von Google geplant werden, sobald sie alle kompatibel sind.

Reihenfolge für die Einführung konfigurieren

Mit dem Label mesh-modernization-order (early, default oder late) können Sie die Reihenfolge des sequenziellen Rollouts für Ihre Cluster und Flotten steuern.

Reihenfolge der Cluster-Einführung (gilt für beide Wege)

Wenn eine Flotte mehrere Cluster enthält, können Sie die Reihenfolge steuern, in der die Cluster modernisiert werden, indem Sie das Label mesh-modernization-order auf jeden Cluster anwenden. Wenn Sie oder Google die Modernisierung einer Flotte auslösen, wird jede Clustergruppe sequenziell modernisiert. Es wird gewartet, bis die automatischen Modernisierungsschritte für die aktuelle Gruppe abgeschlossen sind, bevor mit der nächsten begonnen wird:

gcloud container clusters update CLUSTER_NAME \
  --location LOCATION \
  --update-labels="mesh-modernization-order=VALUE"

Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, LOCATION durch den Standort des Clusters und VALUE durch einen der folgenden Werte:

  • early: Der Cluster wird in der ersten Modernisierungswelle modernisiert.
  • default: Der Cluster wird in der zweiten Modernisierungswelle modernisiert.
  • late: Der Cluster wird in der dritten und letzten Modernisierungswelle modernisiert.

Reihenfolge des Flotten-Roll-outs (nur von Google festgelegt)

In Organisationen mit mehreren Flotten, die von Google modernisiert werden, können Sie die Reihenfolge steuern, in der Google Ihre Flotten modernisiert, indem Sie das Label auf Projektebene für das Flottenhostprojekt festlegen:

gcloud alpha projects update FLEET_PROJECT_ID \
  --update-labels="mesh-modernization-order=VALUE"

Ersetzen Sie FLEET_PROJECT_ID durch die ID des Flotten-Hostprojekts und VALUE durch einen der folgenden Werte:

  • early: Die Flotte wird in der ersten Modernisierungswelle modernisiert.
  • default: Die Flotte wird in der zweiten Modernisierungswelle modernisiert.
  • late: Die Flotte wird in der dritten und letzten Modernisierungswelle modernisiert.

Google schließt die Modernisierung jeder Flottenstufe ab, bevor die nächste beginnt: zuerst früh, dann standardmäßig (und ohne Label) und schließlich spät. Flotten, die als „aufgeschoben“ markiert sind, sind in dieser Reihenfolge nicht enthalten.

Sie können beispielsweise Ihre Nicht-Produktionsflotten auf early und eine besonders wichtige Flotte auf late festlegen und die anderen Flotten auf dem Standardwert belassen.

Wenn Sie keine Google Cloud Organisationen verwenden, werden Ihre Flotten unabhängig voneinander geplant und modernisiert. Sie können die Reihenfolge nicht steuern.

Vom Kunden ausgelöste Modernisierung (Selfservice)

Bei der vom Kunden ausgelösten Modernisierung haben Sie die direkte Kontrolle darüber, wann die Modernisierung für eine einzelne Flotte beginnt.

Flottenmodernisierung auslösen

Sobald Ihre Zielflotte Berichte MODERNIZATION_COMPATIBLE erstellt, lösen Sie die Modernisierung mit dem folgenden Befehl aus:

gcloud alpha container fleet mesh update \
  --modernization-strategy automatic \
  --project FLEET_PROJECT_ID

Ersetzen Sie FLEET_PROJECT_ID durch die ID des Flotten-Hostprojekts.

  • Wartungsfenster: Google berücksichtigt konfigurierte Wartungsfenster und ‑ausschlüsse für Cluster. Die Clustermodernisierung beginnt während des nächsten offenen Wartungsfensters des Clusters.
  • Clusterreihenfolge: Wenn Sie mesh-modernization-order-Labels für Ihre Cluster konfiguriert haben, wird diese Reihenfolge von Google berücksichtigt.

Fortschritt im Blick behalten

Folgen Sie der Anleitung unter Modernisierungsstatus prüfen, um den Fortschritt der Flotten- und Clustermodernisierung zu überwachen.

Von Kunden ausgelöste Modernisierung rückgängig machen

Wenn Sie während der aktiven Clustermodernisierung oder während der Betriebszeit der Flotte (vor der Finalisierung auf Flottenebene) Probleme feststellen, können Sie einen sofortigen Rollback auslösen:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Ersetzen Sie FLEET_PROJECT_ID durch die ID des Flotten-Hostprojekts.

Dadurch bleibt Ihr Gerätepool im Status „Aufgeschoben“, d. h., er wird nicht für die von Google initiierte Modernisierung berücksichtigt. Wenn Sie bereit sind, die Modernisierung noch einmal zu versuchen, führen Sie den Befehl zum Auslösen der Flottenmodernisierung noch einmal aus.

Von Google initiierte Modernisierung (automatisierte Standardeinstellung)

Wenn Sie keine vom Kunden ausgelöste Modernisierung einleiten, übernimmt Google die Modernisierung in Ihrer gesamten Organisation automatisch.

Organisationsweite Terminplanung

Google überwacht Ihre Flotten kontinuierlich. Sobald alle Mesh-fähigen Flotten in Ihrer Organisation (mit Ausnahme aller aufgeschobenen Flotten) für die Modernisierung geeignet sind, plant Google die Modernisierung Ihrer Organisation.

Vorabbenachrichtigungen und Planung

Google bietet zwei Stufen der Vorabbenachrichtigung vor Beginn der Modernisierung:

Benachrichtigung auf Flottenebene

Zuerst werden Sie benachrichtigt, wenn Ihre Flotten als modernisierungsfähig eingestuft und für eine zukünftige Google-gesteuerte Modernisierung ausgewählt wurden.

  • Die Modernisierung Ihres Clusters kann frühestens 14 Tage nach dem ersten US-Geschäftstag des Monats nach Ihrer Benachrichtigung beginnen. Wenn Google beispielsweise am 10. Januar 2027 feststellt, dass Ihre Organisation bereit ist, werden Sie bis zum 31. Januar 2027 darüber informiert, dass das frühestmögliche Modernisierungsstartdatum der 15. Februar 2027 ist.

  • Sie werden gleichzeitig für jede Flotte in Ihrer Organisation benachrichtigt, mit Ausnahme der Flotten, die Sie aufgeschoben haben. Diese Benachrichtigung ist in den Statusbedingungen für Features auf Flottenebene (MODERNIZATION_WILL_BE_SCHEDULED) verfügbar.

Benachrichtigung auf Clusterebene

Sie werden mindestens einen Tag (24 Stunden) vor Beginn der Cluster-Modernisierung auf Clusterebene über das geschätzte Startdatum für die von Google durchgeführte Modernisierung des Clusters benachrichtigt.

Nach der Benachrichtigung auf Flottenebene erhalten Sie so eine viel genauere Zeitplanung für die Modernisierung einzelner Cluster. Diese Benachrichtigung ist in den Bedingungen für den Funktionsstatus auf Clusterebene (MODERNIZATION_SCHEDULED) verfügbar.

Rollback für die von Google durchgeführte Modernisierung beantragen

Wenn während der aktiven Modernisierung oder des Soak-Tests einer von Google betriebenen Modernisierungsflotte Probleme auftreten, wenden Sie sich an Cloud Customer Care, um ein Rollback anzufordern.

Was passiert während der aktiven Modernisierung?

In diesem Abschnitt wird beschrieben, was während der aktiven Modernisierung von Flotten und Clustern passiert.

Flotten modernisieren

Für jede Flotte, die modernisiert wird (unabhängig davon, ob die Modernisierung von Google oder vom Kunden ausgelöst wird), aktivieren wir die neue Implementierung der Steuerungsebene für alle Cluster basierend auf der Reihenfolge (früh → Standard → spät).

Sobald die Steuerungsebene für alle Cluster aktiviert ist, leiten wir den Traffic für alle Cluster basierend auf der Reihenfolge (früh → Standard → spät) zur neuen Implementierung der Steuerungsebene um.

Aktuellen Status prüfen

Zeitraum des Flotten-Betriebs

Sobald der Traffic für alle Cluster umgeleitet wurde, beginnt die Einlaufphase für die Flotte. Die Flotte verbleibt für mindestens 6 Arbeitstage im Übergangszeitraum (MODERNIZATION_MODERNIZED), nachdem alle Cluster modernisiert wurden, bevor sie zu MODERNIZATION_FINALIZED übergeht. Die Möglichkeit zum vollständigen Rollback bleibt während des gesamten Testzeitraums erhalten. Nach Abschluss der Modernisierung ist ein Rollback nicht mehr möglich und ISTIOD-Komponenten werden möglicherweise deaktiviert.

Cluster modernisieren

Während der aktiven Modernisierung eines Clusters werden beide Implementierungen der Steuerungsebene vorübergehend parallel ausgeführt. Die folgenden Aufgaben werden sicher und kontrolliert verarbeitet:

  1. Aktivieren Sie die neue Implementierung der Steuerungsebene. Wenn Sie Wartungsfenster für Ihren Cluster konfiguriert haben, beginnt dieser Schritt während eines Wartungsfensters und wird fortgesetzt, bis er abgeschlossen ist. Beachten Sie Folgendes:
    • Damit Systemdiagnosen möglich sind, wird das snk-DaemonSet im kube-system-Namespace des Clusters und eine Firewallregel pro Cluster erstellt.
    • Damit die Aufnahme von Netzwerk-Endpunktgruppen (NEGs) möglich ist, wird allen Kubernetes-Diensten die Annotation cloud.google.com/neg hinzugefügt.
    • Neue Google Cloud Ressourcen wie Mesh, Routen, Backend-Dienste und Systemdiagnosen werden im Cluster erstellt.
    • Für einige der neuen Ressourcen gilt ein Kontingent. Sie können Kontingente ansehen und bei Bedarf mehr anfordern.
    • Der Cluster wird während der Übergangszeit überwacht, bevor mit dem nächsten Schritt fortgefahren wird.
  2. Traffic auf die neue Implementierung der Steuerungsebene umleiten Wenn Sie Wartungsfenster für Ihren Cluster konfiguriert haben, beginnt dieser Schritt während eines Wartungsfensters und wird bis zum Abschluss fortgesetzt. Beachten Sie Folgendes:
    • Pods, die von der Kubernetes-Bereitstellung verwaltet werden und Cloud Service Mesh-Proxys haben, werden neu gestartet, damit sie sich wieder mit der neuen Steuerungsebene verbinden.
    • Pods werden in immer größeren Wellen neu gestartet. Nach jeder Welle gibt es eine Betriebszeit zur Überwachung.

  3. Manuelle Neustarts von Arbeitslasten für Nicht-Bereitstellungen (Kundenaktion erforderlich).

    • Google startet Arbeitslasten, die von Kubernetes-Deployments verwaltet werden, automatisch neu. Arbeitslasten, die von anderen Arten von Kubernetes-Ressourcen wie StatefulSets und DaemonSets verwaltet werden, müssen manuell neu gestartet werden.
    • Starten Sie diese Arbeitslasten neu, nachdem der Clusterstatus MODERNIZATION_COMPLETED gemeldet wurde (d. h. wenn sich der Cluster in der Einlaufphase befindet).
    • Sie müssen diese Arbeitslasten neu starten, bevor die Modernisierung der Flotte abgeschlossen ist. Andernfalls bleiben die Proxys mit der alten Istiod-Steuerungsebene verbunden, die deaktiviert werden soll.
    • Arbeitslasten mit Standard-Kubernetes-Methoden neu starten, z. B. kubectl rollout restart ...

  4. Sobald alle Arbeitslasten in einem Cluster migriert wurden, wartet der Cluster auf den Betriebszeitraum der Flotte.

Informationen zum Überwachen des aktiven Modernisierungsstatus Ihrer Cluster finden Sie unter Modernisierungsstatus prüfen.

Modernisierungsstatus prüfen und Maßnahmen ergreifen

Sie können den Modernisierungsfortschritt Ihrer Flotten und Cluster mit der Google Cloud CLI überwachen:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Ersetzen Sie FLEET_PROJECT_ID durch die ID des Flotten-Hostprojekts.

Die Ausgabe sieht etwa so aus:

  membershipStates:
    projects/123456789/locations/global/memberships/cluster-1:
      servicemesh:
        conditions:
        - code: MODERNIZATION_MIGRATING_WORKLOADS
          documentationLink: https://cloud.google.com/service-mesh/docs/...
          severity: INFO
  state:
    servicemesh:
      conditions:
      - code: MODERNIZATION_MODERNIZING
        documentationLink: https://cloud.google.com/service-mesh/docs/...
        severity: INFO

Der Modernisierungsstatus wird in den Feldern state.servicemesh.conditions (auf Flottenebene) und membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (auf Clusterebene) angegeben:

Status einer erfolgreichen Flottenmodernisierung

Bei einer erfolgreichen Flottenmodernisierung beginnt der Status der Flotte mit MODERNIZATION_MODERNIZING.

Jeder Cluster durchläuft dann die folgenden Status:

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • MODERNIZATION_COMPLETED

Sobald alle Cluster in der Flotte modernisiert wurden, durchläuft die Flotte die folgenden Status:

  • MODERNIZATION_MODERNIZED
  • MODERNIZATION_FINALIZED

Rollbacks

Bei der von Google gesteuerten Modernisierung wird die Bereitstellungsvorbereitung und der Zustand während des gesamten Modernisierungsprozesses überwacht. Wenn Probleme erkannt werden, wird automatisch ein Rollback ausgelöst. Wenn Sie ein Problem feststellen, wenden Sie sich an Cloud Customer Care, um ein Rollback anzufordern.

Bei einer vom Kunden ausgelösten Modernisierung können Sie jederzeit ein Rollback auslösen.

Während eines Rollbacks wird für die Flotte der Status MODERNIZATION_ROLLING_BACK_FLEET und für den Cluster der Status MODERNIZATION_ROLLING_BACK_CLUSTER angezeigt.

Nach Abschluss eines Cluster-Rollbacks wird vorübergehend der Status MODERNIZATION_ABORTED angezeigt.

Fehlerbehebung und Behebung von Verzögerungen (nur durch Kunden ausgelöst)

Wenn bei einer vom Kunden ausgelösten Modernisierung in einem Cluster ein Problem auftritt, das den Fortschritt verhindert, ändert sich der Status in MODERNIZATION_STALLED. Google löst keine Rollbacks für die vom Kunden ausgelöste Modernisierung aus. Sie müssen das Problem priorisieren und entscheiden, ob Sie es beheben oder ein Rollback auslösen möchten.

Wenn für einen Cluster MODERNIZATION_STALLED gemeldet wird, sehen Sie sich die Bedingungsdetails an. Dort finden Sie einen direkten Link zum entsprechenden Fehlerabschnitt:

Fehler, die Nutzer beheben können

Wenn wir eine inkompatible Mesh- oder Clusterkonfiguration erkennen, wird die Modernisierung angehalten. Prüfen Sie, ob die Kompatibilitätsberichterstellung aktiviert ist, und sehen Sie sich die Bedingungen auf Flotten- und Clusterebene an, um Lücken zu finden, wie unter Cloud Service Mesh-Kompatibilität verstehen beschrieben.

  • Sofortiger Wiederholungsversuch: Sobald das Problem behoben ist, erkennen wir die Änderung und setzen die Modernisierung sofort fort, ohne auf das nächste Wartungsfenster zu warten.

Interne Fehler

Probleme mit internen Google-Diensten werden von Google-Entwicklern überprüft. Wenn möglich, setzen sie die Modernisierung fort. Die Modernisierung kann auch außerhalb eines Wartungsfensters fortgesetzt werden, genau wie bei Fehlern, die Nutzer beheben können. Um dies zu vermeiden, können Sie ein Rollback auslösen.

Wenn die Modernisierung länger als 24 Stunden dauert und keine Kompatibilitätslücken vorhanden sind, wenden Sie sich an Cloud Customer Care, um weitere Informationen zu erhalten, oder führen Sie ein Rollback aus, wenn Produktionsarbeitslasten betroffen sind.

Referenz für Bedingungen auf Flottenebene

Bedingung Beschreibung
MODERNIZATION_COMPATIBLE Die Flotte ist mit der neuen Implementierung der Steuerungsebene kompatibel.
MODERNIZATION_WILL_BE_SCHEDULED Von Google initiierte Modernisierung: Alle nicht aufgeschobenen Flotten in der Organisation sind kompatibel und wurden für die Planung in die Warteschlange gestellt.
MODERNIZATION_MODERNIZING Die Modernisierung wird für einen oder mehrere Cluster in der Flotte aktiv ausgeführt.
MODERNIZATION_MODERNIZED Alle Cluster wurden aktiv modernisiert. Die Flotte befindet sich in der Testphase.
MODERNIZATION_FINALIZED Die Modernisierung ist abgeschlossen. Alte Istiod-Komponenten werden entfernt. Ein Rollback ist nicht mehr möglich.
MODERNIZATION_ROLLING_BACK_FLEET Ein Rollback auf Flottenebene wird ausgeführt.

Referenz für Bedingungen auf Clusterebene

Bedingung Beschreibung
MODERNIZATION_SCHEDULED Der Cluster ist für die Modernisierung am oder nach dem im Zustand angegebenen Datum geplant. Wenn Wartungsfenster/-ausschlüsse für Ihren Cluster konfiguriert sind, wird das Zieldatum des Wartungsfensters angezeigt.
MODERNIZATION_PREPARING Aktivieren der neuen Implementierung der Steuerungsebene
MODERNIZATION_PREPARED Die neue Implementierung der Steuerungsebene ist aktiviert. Die Migration der Arbeitslast wurde noch nicht gestartet.
MODERNIZATION_MIGRATING_WORKLOADS Im Cluster werden Arbeitslasten aktiv zur neuen Implementierung der Steuerungsebene migriert.
MODERNIZATION_COMPLETED Die Modernisierung des Clusters ist abgeschlossen und er befindet sich in der Betriebszeit.
MODERNIZATION_STALLED Die Modernisierung ist aufgrund eines Fehlers ins Stocken geraten (nur vom Kunden ausgelöst). Details zur Bedingung ansehen, um das Problem zu beheben.
MODERNIZATION_ROLLING_BACK_CLUSTER Der Cluster wird aktiv zurückgesetzt.
MODERNIZATION_ABORTED Der Cluster wurde auf die alte Steuerungsebene zurückgesetzt. Sie werden für kurze Zeit gemeldet.