Modernisierung der verwalteten Steuerungsebene

Sie müssen Ihre Cloud Service Mesh-Flotten vor dem Ende des Supports von der eingestellten ISTIOD-Implementierung der Steuerungsebene auf die TRAFFIC_DIRECTOR-Implementierung umstellen. Sie können die Modernisierung nach Ihrem eigenen Zeitplan initiieren oder sie automatisch von Google planen lassen, sobald Ihre Organisation kompatibel ist.

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

  • Vom Kunden ausgelöste Modernisierung (Self-Service): Sie initiieren und steuern den genauen Zeitpunkt der Flottenmodernisierung selbst über die Google Cloud CLI, unabhängig von den von Google vorgegebenen Zeitplänen.
  • Von Google gesteuerte Modernisierung (Standard): Google bewertet die Flottenkompatibilität und plant die Modernisierung in Ihrer Organisation automatisch gemäß den Wartungsfenstern und Vorankündigungen. Google wartet, bis alle Flotten in Ihrer Organisation kompatibel sind. Eine einzige inkompatible Flotte blockiert also die Modernisierung.

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 die Kompatibilitätsprüfungen und machen Sie sich mit der Kompatibilität Ihrer Flotten mit der Modernisierung vertraut.
  2. Modernisierung planen und konfigurieren: Wählen Sie Ihren Pfad aus, konfigurieren Sie die Reihenfolge des Cluster- und Flotten-Roll-outs oder verschieben Sie bestimmte Flotten.
  3. Kompatibilitätslücken schließen: Sorgen Sie dafür, dass Ihre Flotten alle Kompatibilitätsanforderungen erfüllen, bevor Sie mit der Modernisierung beginnen.
  4. Modernisierung initiieren: Sie können die vom Kunden ausgelöste Modernisierung nach Ihrem Zeitplan auslösen oder auf die von Google gesteuerte 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 Abschluss überwachen: Überwachen Sie den Fortschritt der Bedingungen, beheben Sie eventuelle Blockierungen, beobachten Sie die Arbeitslasten während der Soak-Phase (mindestens 6 Arbeitstage) und nutzen Sie die vollständige Rollback-Unterstützung vor dem Abschluss auf Flottenebene.

Flottenkompatibilität prüfen und Lücken schließen

Bevor eine Flotte modernisiert werden kann – entweder durch eine vom Kunden ausgelöste oder eine von Google gesteuerte Modernisierung –, muss die Kompatibilität der Flotte überprüft 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.

  • Für die von Google gesteuerte Modernisierung: Google plant nur Organisationen, bei denen alle nicht zurückgestellten Flotten kompatibel sind.
  • Für die vom Kunden ausgelöste Modernisierung: Sie müssen prüfen, ob Ihre Zielflotte MODERNIZATION_COMPATIBLE meldet, bevor Sie die Modernisierung initiieren.

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

Nicht unterstützte Funktionen

Im Rahmen der Einstellung der ISTIOD-Steuerungsebene beendet Google Cloud die Unterstützung für Features, die mit der Implementierung der TRAFFIC_DIRECTOR-Steuerungsebene nicht kompatibel sind. 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 Einstellungen):

  • Konfiguration refaktorieren (empfohlen): Entfernen Sie die nicht unterstützten Felder oder ersetzen Sie sie durch unterstützte Cloud Service Mesh-Alternativen, damit Ihre Flotte MODERNIZATION_COMPATIBLE meldet, und modernisieren Sie dann auf die Implementierung der Steuerungsebene TRAFFIC_DIRECTOR.
  • Zu Open-Source-Istio (OSS) migrieren: Wenn Ihre Arbeitslasten unbedingt Features erfordern, die von verwaltetem Cloud Service Mesh mit TRAFFIC_DIRECTOR nicht unterstützt werden, können Sie diese Cluster nicht auf TRAFFIC_DIRECTOR modernisieren. Sie müssen diese Arbeitslasten zu selbstverwaltetem Open-Source-Istio migrieren.
  • Cloud Service Mesh deinstallieren: Sie können das verwaltete Cloud Service Mesh deinstallieren.

Modernisierung planen und konfigurieren

Erstellen Sie einen Plan für die Modernisierung Ihrer Flotte(n). Andernfalls wird die von Google gesteuerte Modernisierung standardmäßig angewendet. Sie müssen Maßnahmen ergreifen, damit Ihre Nicht-Produktionsflotten zuerst und Ihre kritischen Flotten zuletzt modernisiert werden. Außerdem wird die von Google gesteuerte Modernisierung erst dann geplant, wenn 100 % der nicht zurückgestellten Gerätepools in Ihrer gesamten Organisation kompatibel sind. Ihre Modernisierung könnte also durch lokale Inkompatibilitäten blockiert werden.

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

Verfügbare Pfade

Ansatz Beschreibung Optimal für Umfang Vorbereitung Vorabankündigung Rollback-Funktion
Vom Kunden ausgelöste Modernisierung Sie initiieren die Modernisierung Flotte für Flotte nach Ihrem eigenen Zeitplan. Detaillierte Kontrolle über den Zeitpunkt der Modernisierung der Flotte (Sie entscheiden, wann Sie die Modernisierung auf Flottenebene initiieren und wann Sie ein Rollback durchführen). Nutzung Ihres vorhandenen Anwendungsmonitorings, um Sie zu benachrichtigen, wenn ein Rollback erforderlich ist. Flotte für Flotte (FLEET_PROJECT_ID). Die Zielflotte muss modernisierungskompatibel sein. n/a Sofortiger Selfservice-Rollback mit der Google Cloud CLI.
Google-gestützte Modernisierung (Standard) Google plant die Modernisierung für Ihre gesamte Organisation automatisch. Automatisierte Modernisierung, sobald alle Flotten in Ihrer Organisation kompatibel sind. Gesamte Organisation von Google Cloud (alle nicht zurückgestellten Flotten). Alle nicht zurückgestellten Flotten in der Organisation müssen mit der Modernisierung kompatibel sein. Benachrichtigung über die Flotte mindestens 14 Tage vor dem Start und Benachrichtigung über den Cluster mindestens 24 Stunden vor dem Start. Google führt ein Rollback durch, wenn das standardisierte Monitoring einen Fehler zeigt. Wenn das Anwendungsmonitoring einen Fehler anzeigt, müssen Sie sich an Cloud Customer Care wenden.

Verwalten mehrerer Flotten in einer Organisation

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

  • Komplexe oder kritische Flotten zurückstellen: Bestimmte Flotten mit --modernization-strategy deferred an die Legacy-Implementierung anpinnen, damit sie von der von 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, die verbleibenden Flotten zu modernisieren: Alle kompatiblen, nicht zurückgestellten Flotten bleiben für die von Google gesteuerte Planung aktiviert.

Flottenmodernisierung verschieben (Deaktivierung)

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 wird für Folgendes empfohlen:

  • Bestimmte Flotten von der von Google gesteuerten Planung ausschließen, da Sie sie nach Ihrem eigenen Zeitplan mithilfe der vom Kunden ausgelösten Modernisierung modernisieren möchten.
  • Sie können die Modernisierung komplexer oder kritischer Flotten vorübergehend aussetzen, während Sie Abhängigkeiten beheben. Andere kompatible Flotten in Ihrer Organisation können dann mit der von Google gesteuerten Planung fortfahren.

Das Legacy-Projektlabel mesh-modernization-mode=manual wird weiterhin berücksichtigt, aber --modernization-strategy deferred wird empfohlen. Andere nicht zurückgestellte Flotten in Ihrer Organisation bleiben für die von Google gesteuerte Planung berechtigt, sobald sie alle kompatibel sind.

Reihenfolge des Roll-outs konfigurieren

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

Reihenfolge des Cluster-Roll-outs (gilt für beide Pfade)

Wenn eine Flotte mehrere Cluster enthält, können Sie die Reihenfolge, in der Cluster modernisiert werden, steuern, indem Sie das Label mesh-modernization-order auf jeden Cluster anwenden. Wenn Sie oder Google die Modernisierung einer Flotte auslösen, wird jede Clustergruppe nacheinander modernisiert. Dabei wird gewartet, bis die automatisierten 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 Modernisierungsphase modernisiert.

Reihenfolge des Roll-outs für die Flotte (nur von Google gesteuert)

In Organisationen mit mehreren Flotten, die von Google modernisiert werden, können Sie die Reihenfolge, in der Google Ihre Flotten modernisiert, steuern, 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 Modernisierungsphase modernisiert.
  • late: Die Flotte wird in der dritten und letzten Modernisierungswelle modernisiert.

Google schließt die Modernisierung jeder Flottenstufe ab, bevor die nächste gestartet wird: zuerst „Früh“, dann „Standard“ (und ohne Label), dann „Spät“. Als zurückgestellt markierte Flotten sind in dieser Reihenfolge nicht enthalten.

Sie können beispielsweise Ihre Nicht-Produktionsflotten auf early und eine besonders kritische Flotte auf late festlegen und die anderen 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 MODERNIZATION_COMPATIBLE meldet, 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 Clusterwartungsfenster und -ausschlüsse. 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, berücksichtigt Google diese Reihenfolge.

Fortschritt überwachen

Folgen Sie der Anleitung unter Modernisierungsstatus prüfen, um den Fortschritt der Modernisierung von Flotten und Clustern zu beobachten. Beobachten Sie das Anwendungsmonitoring, um festzustellen, ob ein Rollback erforderlich ist, insbesondere während der Status MODERNIZATION_PREPARING und MODERNIZATION_MIGRATING_WORKLOADS.

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

Wenn Sie während der aktiven Clustermodernisierung oder während der Betriebszeit der Flotte (vor dem Abschluss 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 Fleet im zurückgestellten Zustand, d. h. er wird nicht für die von Google gesteuerte Modernisierung berücksichtigt. Wenn Sie die Modernisierung noch einmal versuchen möchten, führen Sie den Befehl zum Auslösen der Flottenmodernisierung noch einmal aus.

Von Google gesteuerte Modernisierung (automatisierte Standardeinstellung)

Wenn Sie die vom Kunden ausgelöste Modernisierung nicht initiieren, verwaltet Google die Modernisierung in Ihrer Organisation automatisch.

Organisationsweite Planung

Google überwacht Ihre Flotten kontinuierlich. Sobald alle Mesh-fähigen Flotten in Ihrer Organisation (mit Ausnahme von zurückgestellten Flotten) für die Modernisierung bereit sind, plant Google die Modernisierung für Ihre Organisation.

Vorabankündigungen und Planung

Google bietet zwei Stufen der Vorabankündigung, bevor die Modernisierung beginnt:

Benachrichtigung auf Flottenebene

Zuerst werden Sie benachrichtigt, wenn Ihre Flotten als modernisierungskompatibel identifiziert und für eine von Google durchgeführte Modernisierung ausgewählt wurden.

  • Die Modernisierung Ihres Clusters kann frühestens 14 Tage nach dem ersten US-Arbeitstag 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 Startdatum für die Modernisierung der 15. Februar 2027 ist.

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

Benachrichtigung auf Clusterebene

Sie werden auf Clusterebene mindestens 1 Tag (24 Stunden) vor Beginn der Clustermodernisierung über das voraussichtliche Startdatum der von Google gesteuerten Modernisierung dieses Clusters benachrichtigt.

Nach der Benachrichtigung auf Flottenebene erhalten Sie so einen viel genaueren Zeitplan für die Modernisierung einzelner Cluster. Diese Benachrichtigung ist in den Feature-Statusbedingungen auf Clusterebene (MODERNIZATION_SCHEDULED) verfügbar.

Rollback für die von Google gesteuerte Modernisierung anfordern

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

Was geschieht während der aktiven Modernisierung?

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

Flotten modernisieren

Für jede Flotte, die modernisiert wird (unabhängig davon, ob von Google oder vom Kunden ausgelöst), 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, wird der Traffic für alle Cluster basierend auf der Reihenfolge (früh → Standard → spät) auf die neue Implementierung der Steuerungsebene umgestellt.

Informationen zum aktuellen Status finden Sie unter Status der Flottenmodernisierung prüfen.

Flotten-Betriebszeitraum

Sobald der Traffic für alle Cluster umgestellt wurde, beginnt für die Flotte eine Testphase. Die Flotte verbleibt nach der Modernisierung aller Cluster mindestens 6 Arbeitstage lang im Einlaufzeitraum (MODERNIZATION_MODERNIZED), bevor sie in den Status MODERNIZATION_FINALIZED übergeht. Während der gesamten Testphase bleibt die vollständige Rollback-Funktion erhalten. Nach Abschluss der Modernisierung ist ein Rollback nicht mehr möglich und die Bereitstellung von ISTIOD-Komponenten kann aufgehoben werden.

Cluster modernisieren

Während der aktiven Modernisierung eines Clusters werden beide Implementierungen der Steuerungsebene vorübergehend parallel ausgeführt. Die folgenden Aufgaben werden auf sichere und kontrollierte Weise 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 bis zum Abschluss fortgesetzt. Hinweise:
    • Um die Systemdiagnose zu aktivieren, wird das DaemonSet snk im Namespace kube-system des Clusters und eine Firewallregel pro Cluster erstellt.
    • Um die Aufnahme von Netzwerk-Endpunktgruppen (NEGs) zu aktivieren, wird die Annotation cloud.google.com/neg allen Kubernetes-Diensten hinzugefügt.
    • Im Cluster werden neue Google Cloud -Ressourcen wie Mesh, Routen, Backend-Dienste und Systemdiagnosen erstellt.
    • Einige der neuen Ressourcen sind kontingentiert. Sie können Kontingente einsehen und bei Bedarf weitere anfordern.
    • Der Cluster wird während der Übergangszeit überwacht, bevor mit dem nächsten Schritt fortgefahren wird.
  2. Leiten Sie den Traffic zur neuen Implementierung der Steuerungsebene um. Wenn Sie Wartungsfenster für Ihren Cluster konfiguriert haben, beginnt dieser Schritt während eines Wartungsfensters und wird fortgesetzt, bis er abgeschlossen ist. Hinweise:
    • Von einem Kubernetes-Deployment verwaltete Pods mit Cloud Service Mesh-Proxys werden neu gestartet, damit sie sich wieder mit der neuen Steuerungsebene verbinden.
    • Pods werden in immer größeren Wellen neu gestartet, wobei nach jeder Welle eine Übergangszeit für das Monitoring eingeplant wird.

  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.
    • Wenn nach dem Neustart von Deployment-Arbeitslasten noch Arbeitslasten im Cluster vorhanden sind, deren Cloud Service Mesh-Proxys mit ISTIOD verbunden sind, meldet der Cluster MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART zusammen mit MODERNIZATION_MIGRATING_WORKLOADS.
    • Starten Sie die verbleibenden Arbeitslasten manuell neu, damit ihre Proxys eine Verbindung zur Implementierung der Steuerungsebene TRAFFIC_DIRECTOR herstellen. Google wartet mindestens 60 Tage, bis Sie alle Arbeitslasten neu gestartet haben, bevor mit nachfolgenden Clustern (in einer Multi-Cluster-Flotte) fortgefahren oder die Flotten-Soak-Zeit gestartet wird.
    • Wenn Sie prüfen möchten, welche Proxys noch mit ISTIOD verbunden sind, führen Sie den Befehl gcloud beta container fleet mesh debug proxy-status aus, wie unter Status der Steuerungsebene ansehen beschrieben. Proxys mit einer Istiod-Instanz-ID in der Spalte ISTIOD der Befehlsausgabe stellen weiterhin eine Verbindung zu ISTIOD her und erfordern einen manuellen Neustart.
    • Nachdem alle Mesh-Arbeitslasten im Cluster eine Verbindung zu TRAFFIC_DIRECTOR hergestellt haben, wird MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART automatisch gelöscht und der Clusterstatus wechselt zu MODERNIZATION_COMPLETED.

  4. Sobald alle Arbeitslasten in einem Cluster umgestellt wurden, wartet der Cluster auf die Betriebszeit 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 (Flottenebene) und membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (Clusterebene) gemeldet:

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
  • (optional) MODERNIZATION_MIGRATING_WORKLOADS mit MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART
  • 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 werden die Bereitstellungsbereitschaft 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 einen 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.

Nachdem ein Cluster-Rollback abgeschlossen ist, wird vorübergehend der Status MODERNIZATION_ABORTED angezeigt.

Fehler und Verzögerungen beheben (nur vom Kunden ausgelöst)

Wenn während der vom Kunden ausgelösten Modernisierung ein Problem auftritt, das den Fortschritt verhindert, wechselt der Status zu MODERNIZATION_STALLED. Google löst keine Rollbacks für vom Kunden ausgelöste Modernisierungen aus. Sie müssen das Problem priorisieren und entscheiden, ob Sie es beheben oder ein Rollback auslösen möchten.

Wenn ein Cluster MODERNIZATION_STALLED meldet, prüfen Sie die Bedingungsdetails, um einen direkten Link zum relevanten Fehlerabschnitt zu erhalten:

Vom Nutzer behebbare Fehler

Wenn wir eine inkompatible Mesh- oder Clusterkonfiguration erkennen, wird die Modernisierung angehalten. Prüfen Sie, ob die Kompatibilitätsberichte aktiviert sind, und prüfen Sie die Bedingungen auf Flotten- und Clusterebene auf Lücken, wie unter Cloud Service Mesh-Kompatibilität beschrieben.

  • Sofortige Wiederholung: Sobald der Blocker 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 und die Modernisierung wird nach Möglichkeit fortgesetzt. Beachten Sie, dass die Modernisierung außerhalb eines Wartungsfensters fortgesetzt werden kann, genau wie bei Fehlern, die vom Nutzer behoben werden können. Um dies zu vermeiden, können Sie einen Rollback auslösen.

Wenn die Modernisierung länger als 24 Stunden ins Stocken gerät und keine Kompatibilitätslücken vorhanden sind, wenden Sie sich an Cloud Customer Care, um weitere Informationen zu erhalten, oder lösen 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 gesteuerte Modernisierung: Alle nicht zurückgestellten Flotten in der Organisation sind kompatibel und wurden für die Planung in die Warteschlange gestellt.
MODERNIZATION_MODERNIZING Für einen oder mehrere Cluster in der Flotte wird derzeit eine Modernisierung durchgeführt.
MODERNIZATION_MODERNIZED Alle Cluster haben die aktive Modernisierung abgeschlossen. Die Flotte befindet sich in der Testphase.
MODERNIZATION_FINALIZED Die Modernisierung ist abgeschlossen. Legacy-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 wird am oder nach dem in der Bedingung angegebenen Datum modernisiert. Wenn für Ihren Cluster Wartungsfenster/-ausschlüsse konfiguriert sind, gibt das Datum das Zielwartungsfenster an.
MODERNIZATION_PREPARING Aktivieren der neuen Implementierung der Steuerungsebene.
MODERNIZATION_PREPARED Die neue Implementierung der Steuerungsebene ist aktiviert. Die Arbeitslastmigration wurde noch nicht gestartet.
MODERNIZATION_MIGRATING_WORKLOADS Der Cluster migriert aktiv Arbeitslasten zur neuen Implementierung der Steuerungsebene.
MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART Die automatisierte Migration von Arbeitslasten ist abgeschlossen. Starten Sie Mesh-Arbeitslasten, die nicht vom Typ Deployment sind, z. B. StatefulSets, DaemonSets oder Jobs, neu, damit ihre Proxys eine Verbindung zur Implementierung der Steuerungsebene TRAFFIC_DIRECTOR herstellen.
MODERNIZATION_COMPLETED Die Modernisierung des Clusters ist abgeschlossen und er befindet sich in der Betriebszeit.
MODERNIZATION_STALLED Die Modernisierung wurde aufgrund eines Fehlers angehalten (nur vom Kunden ausgelöst). Details zur Behebung des Problems finden Sie in den Bedingungsdetails.
MODERNIZATION_ROLLING_BACK_CLUSTER Der Cluster wird aktiv zurückgesetzt.
MODERNIZATION_ABORTED Der Cluster wurde auf die Legacy-Steuerungsebene zurückgesetzt. Vor Kurzem gemeldet.