Modernisierung der verwalteten Steuerungsebene

Sie können Ihre Cloud Service Mesh-Flotten nach Ihrem eigenen Zeitplan von der ISTIOD-Steuerungsebene auf die TRAFFIC_DIRECTOR-Implementierung umstellen oder Google die automatische Planung überlassen.

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 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 verhindern.

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 informieren Sie sich über die Kompatibilität Ihrer Flotten mit der Modernisierung.
  2. Modernisierung planen und konfigurieren: Wählen Sie Ihren Pfad aus, konfigurieren Sie die Reihenfolge der Cluster- und Flottenbereitstellung 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 starten: Sie können die vom Kunden ausgelöste Modernisierung nach Ihrem Zeitplan starten 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 beobachten, Soak-Phase und Finalisierung: Beobachten Sie den Fortschritt des Zustands, beheben Sie alle Verzögerungen und beobachten Sie die Arbeitslasten während der Soak-Phase (mindestens 6 Arbeitstage). Vor der Finalisierung auf Flottenebene ist eine vollständige Zurücksetzung möglich.

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

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

  • Bei der von Google gesteuerten Modernisierung plant Google nur Organisationen, in denen alle nicht aufgeschobenen 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 starten.

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

Modernisierung planen und konfigurieren

Erstellen Sie einen Plan für die Modernisierung Ihrer Flotte(n). Wenn Sie dies nicht tun, wird die von Google gesteuerte Modernisierung standardmäßig angewendet. Sie müssen Maßnahmen ergreifen, damit 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. Sie haben die detaillierte Kontrolle über den Zeitpunkt der Flottenmodernisierung. Sie entscheiden, wann Sie die Modernisierung auf Flottenebene starten und wann Sie ein Rollback durchführen. 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 automatisch für Ihre gesamte Organisation. 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 der Flotte mindestens 14 Tage vor Beginn und Benachrichtigung des Clusters 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.

Mehrere Flotten in einer Organisation verwalten

Wenn Ihre Google Cloud Organisation mehrere Flotten verwaltet, müssen Sie nicht für alle Flotten denselben 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 darf die verbleibenden Flotten 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 (z. B. um die vom Kunden ausgelöste Modernisierung später durchzuführen oder komplexe Abhängigkeiten zu beheben), 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.

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 der 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 des Cluster-Roll-outs (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 Gruppe 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. Dazu legen Sie das Label auf Projektebene für das Flottenhostprojekt fest:

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. Als zurückgestellt markierte Flotten 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 Modernisierung von Flotten und Clustern zu beobachten.

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“. Das bedeutet, dass er nicht für die von Google initiierte Modernisierung infrage kommt. 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 die vom Kunden ausgelöste Modernisierung nicht selbst initiieren, ü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) modernisierungskompatibel 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 von Google durchgeführte 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 benachrichtigt, 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 Funktionen auf Flottenebene (MODERNIZATION_WILL_BE_SCHEDULED) verfügbar.

Benachrichtigung auf Clusterebene

Sie werden mindestens einen Tag (24 Stunden) vor Beginn der von Google initiierten Modernisierung des Clusters auf Clusterebene über das geschätzte Startdatum informiert.

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 Featurestatus auf Clusterebene (MODERNIZATION_SCHEDULED) verfügbar.

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

Wenn während der aktiven Modernisierung oder des Soaking auf 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.

Gerätepools 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 Flottenbetriebs

Sobald der Traffic für alle Cluster umgeleitet wurde, beginnt die Soak-Phase 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 wechselt. Die Möglichkeit zum vollständigen Rollback bleibt während des gesamten Soak-Zeitraums 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 Steuerungsebenenimplementierungen 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 bis zum Abschluss fortgesetzt. Beachten Sie Folgendes:
    • Damit Systemdiagnosen möglich sind, wird das snk-DaemonSet im Namespace kube-system 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.
    • Einige der neuen Ressourcen sind kontingentbeschränkt. Sie können Kontingente ansehen und bei Bedarf mehr anfordern.
    • Der Cluster wird während der Übergangszeit überwacht, bevor Sie mit dem nächsten Schritt fortfahren.
  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 fortgesetzt, bis er abgeschlossen ist. 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 Übergangszeit für das Monitoring.
  3. Manuelle Neustarts von Arbeitslasten für Nicht-Bereitstellungen (Kundenaktion erforderlich).

    • Google startet Arbeitslasten, die von Kubernetes-Bereitstellungen 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.
    • Starten Sie Arbeitslasten mit Standard-Kubernetes-Methoden neu, z. B. mit 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 aktiv werden

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) 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
  • 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 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 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.

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

Fehler und Unterbrechungen behandeln (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 Zustand 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. Achten Sie darauf, dass die Kompatibilitätsberichterstellung aktiviert ist, und prüfen Sie die Bedingungen auf Flotten- und Clusterebene auf Lücken, 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 geprüft. Wenn möglich, setzen sie die Modernisierung fort. Die Modernisierung kann auch außerhalb eines Wartungsfensters fortgesetzt werden, genau wie bei Fehlern, die Handlungsbedarf aufseiten des Nutzers erfordern. 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 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 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 ist für einen oder mehrere Cluster in der Flotte in vollem Gange.
MODERNIZATION_MODERNIZED Alle Cluster wurden aktiv modernisiert. Die Flotte befindet sich in der Testphase.
MODERNIZATION_FINALIZED Die Modernisierung ist abgeschlossen. Die alten Istiod-Komponenten werden entfernt. Ein Rollback ist nicht mehr möglich.
MODERNIZATION_ROLLING_BACK_FLEET Ein Rollback auf Flottenebene wird gerade 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 für Ihren Cluster Wartungsfenster oder ‑ausschlüsse konfiguriert sind, wird mit dem Datum das Zielwartungsfenster angegeben.
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). Weitere Informationen zur Lösung finden Sie in den Bedingungsdetails.
MODERNIZATION_ROLLING_BACK_CLUSTER Der Cluster wird aktiv zurückgesetzt.
MODERNIZATION_ABORTED Der Cluster wurde auf die alte Steuerungsebene zurückgesetzt. Die Meldung wird nur für kurze Zeit angezeigt.