Auf dieser Seite erfahren Sie, wie Sie GKE-Clusterupgrades mithilfe von Roll-out-Sequenzierung verwalten. Weitere Informationen finden Sie unter Clusterupgrades mit Roll-out-Sequenzierung.
Hinweis
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit
gcloud components update
ab.
- Achten Sie darauf, dass die erforderlichen APIs für Flotten aktiviert sind. Diese APIs müssen in Ihren Flotten-Hostprojekten aktiviert sein, um eine beliebige Art von Roll-out-Sequenz zu erstellen.
- Achten Sie darauf, dass Sie GKE Enterprise in Ihren Flotten-Hostprojekten aktiviert haben, wenn Sie eine teambasierte Roll-out-Sequenz erstellen möchten (Vorschau).
- Für eine Terraform-Anleitung benötigen Sie die Version 5.13.0 oder höher des Anbieters
google
.
Erforderliche Rollen
- Prüfen Sie, ob Sie die erforderlichen IAM-Berechtigungen für die Clusterregistrierung haben. Sie müssen die folgenden Berechtigungen erteilen:
- Berechtigungen zur Clusterregistrierung in Ihren Flotten-Hostprojekten
- Cluster-Administratorberechtigungen für alle zu registrierenden GKE-Cluster.
- Projektübergreifende Berechtigungen zur Clusterregistrierung für alle GKE-Cluster, die in einer Flotte in einem anderen Projekt registriert werden sollen.
Roll-out-Sequenz konfigurieren
In diesem Dokument wird erläutert, wie Sie eine Roll-out-Sequenz mit Gruppen von Clustern erstellen, die nach Flotten oder Teambereichen organisiert sind. In diesem Dokument wird der Begriff Gruppe verwendet, um sich sowohl auf Flotten als auch auf Teambereiche zu beziehen, da Sie eine Roll-out-Sequenz erstellen können, die mit einer der beiden Gruppierungsmethoden organisiert ist.
Sie können eine Sequenz von bis zu drei Gruppen von Clustern erstellen und auswählen, wie viel Betriebstestzeit nach Abschluss von Clusterupgrades in einer Gruppe gewünscht ist (maximal 30 Tage). Sie können sowohl Autopilot- als auch Standard-Cluster verwenden.
Zum Erstellen einer Roll-out-Sequenz müssen Ihre Cluster in Gruppen von Flotten oder Teambereichen organisiert sein. Eine Anleitung zum Organisieren Ihrer Cluster finden Sie im Beispiel der Community-Bank. Nachdem sie in Gruppen organisiert wurden, können Sie eine Roll-out-Sequenz erstellen, indem Sie die vorgelagerten Gruppenbeziehungen und die Betriebszeit jeder Gruppe definieren. Bezieht sich in einer Roll-out-Sequenz vorgelagert auf die vorherige Gruppe und nachgelagert auf die nächste Gruppe.
Cluster in Gruppen organisieren
Bei einer Roll-out-Sequenz müssen alle Cluster in allen Gruppen in derselben Release-Version registriert sein und dieselbe Nebenversion haben. Wenn diese Anforderungen nicht erfüllt werden und Versionsabweichungen zwischen Clustern auftreten, kann dies zu Problemen mit dem Roll-out der Version führen. Weitere Informationen finden Sie unter Roll-out-Berechtigung.
Sie können Roll-out-Sequenzen zwischen Flotten oder Roll-out-Sequenzen zwischen den Teambereichen eines Teams erstellen (Vorschau).
Wie Sie unter Clusterupgrades mit Roll-out-Sequenzierung gesehen haben, sind Teambereiche ein Konstrukt auf Flottenebene für Unternehmen, um Teilmengen von Flottenclustern bestimmten Anwendungsteams zuzuordnen. Sie müssen GKE Enterprise aktivieren, um Teambereiche zu verwenden. Die folgenden Einschränkungen gelten, wenn Sie Teambereiche für die Roll-out-Sequenzierung verwenden oder erstellen:
Teambasierte Sequenzen erfordern Cluster mit einem einzelnen Mandanten. Das heißt, jeder einzelne Cluster ist nur einem einzigen Team zugeordnet. Freigegebene Cluster, die in der allgemeinen Verwaltung des Flottenteams unterstützt werden, werden für die Roll-out-Sequenzierung nicht unterstützt.
Jeder Teambereich muss sich in einer anderen Flotte befinden, damit eine Roll-out-Sequenz zwischen ihnen erstellt werden kann. Das Erstellen einer Roll-out-Sequenz zwischen verschiedenen Teambereichen innerhalb derselben Flotte wird nicht unterstützt.
Wenn Sie Ihre Cluster bereits in Gruppen organisiert haben, können Sie die folgenden Schritte überspringen und mit Roll-out-Sequenz erstellen fortfahren.
Flotten
Zum Erstellen einer flottenbasierten Roll-out-Sequenz müssen Sie zuerst Ihre Cluster in Flotten gruppieren. Sie können Ihre Cluster nach Bereitstellungsumgebungen wie Test, Staging und Produktion organisieren, wie in der beispielhaften flottenbasierten Roll-out-Sequenz gezeigt.
Registrieren Sie jeden Cluster anhand der ausgewählten Gruppierung bei einer Flotte.
Teams
Zum Erstellen einer teambasierten Roll-out-Sequenz müssen Sie Ihre Cluster in Teambereichen gruppieren. Organisieren Sie dazu zuerst Ihre Cluster nach Bereitstellungsumgebungen wie Test, Staging und Produktion in Flotten, wie in der beispielhaften bereichsbasierten Roll-out-Sequenz gezeigt. Anschließend können Sie Ihre Cluster weiter in Bereiche für die Cluster verschiedener Teams unterteilen.
- Registrieren Sie für jeden Cluster in der Sequenz Ihren Cluster bei einer Flotte. Der Cluster sollte bei der Flotte in dem Projekt registriert sein, in dem Sie den Teambereich für diesen Cluster erstellen. Wenn Sie einen Cluster bei einer Flotte in einem anderen Hostprojekt registrieren möchten, müssen Sie die erforderlichen Berechtigungen für die projektübergreifende Registrierung festlegen.
Erstellen Sie 2 bis 3 Teambereiche, um Ihre Cluster zu organisieren. Erstellen Sie jeden Bereich im Hostprojekt der entsprechenden Flotte des Teams. Sie können bis zu drei Teambereiche in einer Roll-out-Sequenz verwenden.
Eine vollständige Liste der Flags finden Sie in der Referenz zu
gcloud alpha container fleet scopes create
. Mit dem Befehlcreate
können Sie die Flags in der Anleitung verwenden, um eine Roll-out-Sequenz zu erstellen.
Roll-out-Sequenz erstellen
Eine Roll-out-Sequenz ist als verknüpfte Liste mit bis zu drei Elementen organisiert.
Wenn Sie eine Roll-out-Sequenz erstellen, legen Sie die folgenden Attribute für jede Gruppe von Clustern fest, entweder als Flotte oder als Teambereich:
- Vorgelagerte Gruppe: Die vorgelagerte Flotte oder der vorgelagerte Teambereich, der neue Versionen für die nachgelagerte Gruppe qualifiziert. Sie legen keine vorgelagerte Gruppe für die erste Gruppe in einer Sequenz fest.
- Betriebszeit: Die Betriebszeit für eine Gruppe ist die Zeit zwischen dem Abschluss von Upgrades (oder der Dauer von 30 Tagen eines Roll-outs) und dem Zeitpunkt, zu dem Upgrades in der nachgelagerten Gruppe beginnen können. Weitere Informationen finden Sie unter So funktioniert die Versionsqualifizierung in einem Roll-out.
Ersetzen Sie für jeden der folgenden Befehle SOAK_TIME
durch die Betriebszeit für die Gruppe, die Sie aktualisieren.
Flotten – gcloud
In der folgenden Anleitung wird der Befehl gcloud container fleet clusterupgrade update
verwendet. Sie können jedoch dieselben Attribute mit dem Befehl gcloud container fleet clusterupgrade create
festlegen.
Erstellen Sie eine Roll-out-Sequenz:
Legen Sie die Betriebszeit für die erste Flotte in der Sequenz fest:
gcloud container fleet clusterupgrade update \ --default-upgrade-soaking=SOAK_TIME \ --project=FIRST_FLEET_PROJECT_ID
Ersetzen Sie
FIRST_FLEET_PROJECT_ID
durch die Projekt-ID des Flottenhostprojekts.Legen Sie die vorgelagerte Flotte und die Betriebszeit für die zweite Flotte in der Sequenz fest:
gcloud container fleet clusterupgrade update \ --upstream-fleet=FIRST_FLEET_PROJECT_ID \ --default-upgrade-soaking=SOAK_TIME \ --project=SECOND_FLEET_PROJECT_ID
Ersetzen Sie
FIRST_FLEET_PROJECT_ID
durch die Projekt-ID des Hostprojekts der ersten Flotte undSECOND_FLEET_PROJECT_ID
durch die Projekt-ID des Flottenhostprojekts.Optional: Wenn Sie drei Flotten in einer Roll-out-Sequenz verwenden möchten, legen Sie die vorgelagerte Flotte für die dritte Flotte in der Sequenz fest:
gcloud container fleet clusterupgrade update \ --upstream-fleet=SECOND_FLEET_PROJECT_ID \ --default-upgrade-soaking=SOAK_TIME \ --project=THIRD_FLEET_PROJECT_ID
Ersetzen Sie
SECOND_FLEET_PROJECT_ID
durch die Projekt-ID des Hostprojekts der zweiten Flotte undTHIRD_FLEET_PROJECT_ID
durch die Projekt-ID des Flottenhostprojekts.
Flotten – Terraform
In diesem Abschnitt erfahren Sie, wie Sie mit Terraform eine flottenbasierte Sequenz erstellen. Sie können diese Ressource auch verwenden, um die Sequenz zu aktualisieren. Weitere Informationen finden Sie in der Referenzdokumentation zu google_gke_hub_feature
.
Erstellen Sie eine Roll-out-Sequenz:
Fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu, um die Übergangszeit für die erste Flotte in der Sequenz festzulegen:
resource "google_gke_hub_feature" "feature" { name = "clusterupgrade" location = "global" spec { clusterupgrade { upstream_fleets = [] post_conditions { soaking = "SOAK_TIME" } } } project = "FIRST_FLEET_PROJECT_ID" }
Ersetzen Sie
FIRST_FLEET_PROJECT_ID
durch die Projekt-ID des Flottenhostprojekts.Fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu, um die vorgelagerte Flotte und die Übergangszeit für die zweite Flotte in der Sequenz festzulegen:
resource "google_gke_hub_feature" "feature" { name = "clusterupgrade" location = "global" spec { clusterupgrade { upstream_fleets = ["FIRST_FLEET_PROJECT_ID"] post_conditions { soaking = "SOAK_TIME" } } } project = "SECOND_FLEET_PROJECT_ID" }
Ersetzen Sie
FIRST_FLEET_PROJECT_ID
durch die Projekt-ID des Hostprojekts der ersten Flotte undSECOND_FLEET_PROJECT_ID
durch die Projekt-ID des Flottenhostprojekts.Optional: Wenn Sie drei Flotten in einer Roll-out-Sequenz verwenden möchten, fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu, um die vorgelagerte Flotte für die Flotte in der Sequenz festzulegen:
resource "google_gke_hub_feature" "feature" { name = "clusterupgrade" location = "global" spec { clusterupgrade { upstream_fleets = ["SECOND_FLEET_PROJECT_ID"] post_conditions { soaking = "SOAK_TIME" } } } project = "THIRD_FLEET_PROJECT_ID" }
Ersetzen Sie
SECOND_FLEET_PROJECT_ID
durch die Projekt-ID des Hostprojekts der zweiten Flotte undTHIRD_FLEET_PROJECT_ID
durch die Projekt-ID des Flottenhostprojekts.
Teams – gcloud
Sie können diese Attribute beim Erstellen oder Aktualisieren eines Teambereichs festlegen. In der folgenden Anleitung wird der Befehl gcloud alpha container fleet scopes update
verwendet. Sie können jedoch dieselben Attribute festlegen, wenn Sie einen Teambereich mit dem Befehl gcloud alpha container fleet scopes create
erstellen.
Ersetzen Sie bei jedem dieser Befehle die Variablen durch den Namen des jeweiligen Teambereichs oder die Flotten-Hostprojekt-ID des Teambereichs.
Erstellen Sie eine Roll-out-Sequenz:
Legen Sie die Betriebszeit für den ersten Bereich in der Sequenz fest:
gcloud alpha container fleet scopes update projects/FIRST_SCOPE_PROJECT_ID/locations/global/scopes/FIRST_SCOPE_NAME \ --default-upgrade-soaking=SOAK_TIME \ --project=FIRST_SCOPE_PROJECT_ID
Legen Sie den vorgelagerten Bereich und die Betriebszeit für den zweiten Bereich in der Sequenz fest:
gcloud alpha container fleet scopes update projects/SECOND_SCOPE_PROJECT_ID/locations/global/scopes/SECOND_SCOPE_NAME \ --upstream-scope=projects/FIRST_SCOPE_PROJECT_ID/locations/global/scopes/FIRST_SCOPE_NAME \ --default-upgrade-soaking=SOAK_TIME \ --project=SECOND_SCOPE_PROJECT_ID
Optional: Wenn Sie drei Teambereiche in einer Roll-out-Sequenz haben möchten, legen Sie den vorgelagerten Bereich für den dritten Bereich in der Sequenz fest:
gcloud alpha container fleet scopes update projects/THIRD_SCOPE_PROJECT_ID/locations/global/scopes/THIRD_SCOPE_NAME \ --upstream-scope=projects/SECOND_SCOPE_PROJECT/locations/global/scopes/SECOND_SCOPE_NAME \ --default-upgrade-soaking=SOAK_TIME \ --project=THIRD_SCOPE_PROJECT_ID
Status einer Roll-out-Sequenz prüfen
Verwenden Sie diese Befehle in den folgenden Abschnitten, um zu prüfen, wie die Upgrades in einer Roll-out-Sequenz durchlaufen werden. Weitere Informationen zu den angegebenen Details finden Sie unter Statusinformationen für eine Roll-out-Sequenz.
Achten Sie darauf, dass Sie zum Ausführen dieser Befehle die erforderlichen Berechtigungen für jedes Flotten-Hostprojekt haben. Wenn die Sequenz beispielsweise projektübergreifende Bereiche in verschiedenen Flotten hat, benötigen Sie in jedem Projekt Berechtigungen zum Beschreiben der Sequenz.
Wenn Sie für die folgenden Befehle nur Informationen zu einer einzigen Flotte oder einem einzigen Bereich in der Sequenz benötigen, ersetzen Sie das Flag --show-linked-cluster-upgrade
durch --show-cluster-upgrade
.
Flotten
Prüfen Sie den Status einer flottenbasierten Roll-out-Sequenz:
gcloud container fleet clusterupgrade describe \
--show-linked-cluster-upgrade --project=FLEET_PROJECT_ID
Ersetzen Sie FLEET_PROJECT_ID
durch die Projekt-ID des Hostprojekts für eine beliebige Flotte in der Sequenz.
Eine vollständige Liste der Flags finden Sie in der Referenz zu gcloud container fleet clusterupgrade
describe
.
Teams
Prüfen Sie den Status einer teambereichsbasierten Roll-out-Sequenz:
gcloud alpha container fleet scopes describe SCOPE_NAME \
--show-linked-cluster-upgrade
--project=SCOPE_PROJECT_ID
Ersetzen Sie SCOPE_NAME
durch den Namen eines beliebigen Teambereichs in der Roll-out-Sequenz und SCOPE_PROJECT_ID
durch die Projekt-ID dieses Teambereichs.
Eine vollständige Liste der Flags finden Sie in der Referenz zu gcloud alpha container fleet scopes
describe
.
Führen Sie den folgenden Befehl im Flotten-Hostprojekt aus und sehen Sie sich den Abschnitt membershipStates
an, um den Status einzelner Cluster innerhalb einer Flotte oder eines Teambereichs anzuzeigen:
gcloud container fleet features describe clusterupgrade
Statusinformationen für eine Roll-out-Sequenz
Wenn Sie den Status eines Versions-Roll-outs prüfen, können Sie den Fortschritt jeder Gruppe und jedes Clusters innerhalb dieser Gruppe sehen.
In der folgenden Tabelle sind die möglichen Status eines Clusters oder einer Gruppe aufgeführt:
Status | Für Cluster | Für Gruppe |
---|---|---|
INELIGIBLE | Dieser Cluster ist für dieses Upgrade nicht berechtigt. | Einer oder mehrere Cluster in dieser Gruppe sind für das Upgrade nicht berechtigt. |
PENDING | Das Upgrade wurde nicht gestartet oder das Upgrade wird aktuell für den Cluster ausgeführt. | Das Upgrade wurde in keinem der Cluster in der Gruppe gestartet. |
IN_PROGRESS | – | Das Upgrade hat bei mindestens einem Cluster begonnen, ist aber noch nicht für alle Cluster abgeschlossen. |
SOAKING | Das Upgrade ist auf dem Cluster abgeschlossen, befindet sich aber noch in der Betriebszeit. | Das Upgrade ist auf allen Clustern abgeschlossen, befindet sich aber noch in der Betriebszeit. |
FORCED_SOAKING | Das Upgrade dauerte länger als die maximale Upgrade-Zeit (30 Tage) und wurde daher in die Betriebsphase übertragen. Das Upgrade kann auf dem Cluster andauern. | Das Upgrade dauerte länger als die maximale Upgrade-Zeit (30 Tage) und wurde daher in die Betriebsphase übertragen. Das Upgrade kann auf den Clustern andauern. |
COMPLETE | Das Upgrade wird als "Fertig" betrachtet, was bedeutet, dass das Upgrade in diesem Cluster abgeschlossen ist. | Das Upgrade wird als "Fertig" und bereit für die nachgelagerte Gruppe betrachtet. Dies bedeutet, dass die Betriebszeit des Upgrades abgelaufen ist. |
In der Ausgabe dieser Befehle enthalten die Attribute clusterUpgrade(s).spec
und clusterUpgrade(s).state
zusätzliche Informationen zum Clusterupgrade, z. B. Betriebszeit, Überschreibungen von Clusterupgrades und Upgradestatus.
Roll-out-Sequenz verwalten
Sie können automatische Clusterupgrades mit Roll-out-Sequenzierung auf verschiedene Arten steuern, die in den folgenden Abschnitten erläutert werden.
Betriebszeit für eine Gruppe ändern
Sie können die Standardbetriebszeit für eine Gruppe oder die Betriebszeit für das Upgrade dieser Gruppe auf eine bestimmte Version ändern.
Standardbetriebszeit aktualisieren
Wenn Sie die Standardbetriebszeit für eine Gruppe ändern möchten, verwenden Sie die Befehle aus der Anleitung zum Erstellen einer Roll-out-Sequenz und lassen Sie die Flags weg, mit denen die vorgelagerte Gruppe festgelegt wird.
Standardbetriebszeit überschreiben
Sie können die Betriebszeit für ein bestimmtes Version-Roll-out ändern, sodass sie von der Standardbetriebszeit der Gruppe abweicht. Wenn Sie beispielsweise bereits eine neue Version qualifiziert haben und bereit sind, mit Upgrades in der nächsten Gruppe zu beginnen, können Sie die Betriebszeit auf null setzen. Sie können sie auch verwenden, wenn Sie mehr Zeit als die Standardbetriebszeit benötigen, um eine bestimmte Version zu qualifizieren.
Wenn die Betriebszeit für einzelne Gruppen festgelegt wird und Sie die Betriebszeit für andere Gruppen in dieser Sequenz überschreiben möchten, aktualisieren Sie sie mit demselben Befehl, wobei der Flotten- oder Bereichsname je nach Sequenztyp ersetzt wird.
Ersetzen Sie für die Anleitung in diesem Abschnitt die folgenden Variablen:
SOAK_TIME
: die Betriebszeit, die nicht der Standardeinstellung entspricht (z. B. "0d", wenn Sie die Betriebszeit für ein Roll-out einer Version überspringen möchten).UPGRADE_NAME
: der Upgradetyp, entwederk8s_control_plane
für Upgrades der Steuerungsebene oderk8s_node
für Knotenupgrades.VERSION
: die GKE-Version, in der Sie die Standardübergangszeit nach der Version (z. B. 1.25.2-gke.400) überschreiben möchten, die in dieser Gruppe eingeführt wurde.
Flotten – gcloud
Führen Sie diesen Befehl im Hostprojekt der Flotte aus, in der Sie die Betriebszeit für das Versions-Roll-out einer bestimmten Version überschreiben möchten.
Ändern Sie die Betriebszeit einer Flotte:
gcloud container fleet clusterupgrade update
--add-upgrade-soaking-override=SOAK_TIME \
--upgrade-selector=name=UPGRADE_NAME,version=VERSION
Flotten – Terraform
Fügen Sie Ihrer Terraform-Konfiguration innerhalb des clusterupgrade
-Blocks den folgenden gke_upgrades_overrides
-Block hinzu, um die Übergangszeit zu überschreiben, die für das Versions-Roll-out einer bestimmten Version verwendet wird:
gke_upgrade_overrides {
upgrade {
name = "UPGRADE_NAME"
version = "VERSION"
}
post_conditions {
soaking = "SOAK_TIME"
}
}
Teams – gcloud
Führen Sie diesen Befehl im Hostprojekt der Flotte des Teambereichs aus. Ersetzen Sie SCOPE_NAME
durch den Namen des Teambereichs, für den Sie die Betriebszeit überschreiben möchten, die für das Versions-Roll-out einer bestimmten Version verwendet wird.
Ändern Sie die Betriebszeit eines Teambereichs:
gcloud alpha container fleet scopes update SCOPE_NAME \
--add-upgrade-soaking-override=SOAK_TIME \
--upgrade-selector=name=UPGRADE_NAME,version=VERSION
Reihenfolge einer Sequenz ändern
Wenn Sie die Reihenfolge einer Sequenz ändern möchten, verwenden Sie die Befehle aus der Anleitung unter Roll-out-Sequenz erstellen, um die vorgelagerten Gruppen zu aktualisieren.
Abschluss des Versions-Roll-outs der Gruppe verzögern
Wenn Sie vorübergehend verhindern möchten, dass eine Gruppe das Roll-out einer neuen Version in ihren Clustern abschließt, können Sie einen Wartungsausschluss zu jedem Cluster hinzufügen, für den noch kein Upgrade auf die Zielversion ausgeführt wurde. Dadurch kann eine Gruppe bis zu 30 Tage lang nicht zur Betriebszeit oder zur nachgelagerten Gruppe übergehen. Nach 30 Tagen beginnt die Betriebszeit der Gruppe.
Sie können auch die Betriebszeit für diese Gruppe in 30 Tage ändern, um die Betriebszeit der Roll-out-Sequenz bis zur Fortsetzung mit der nächsten Gruppe zu maximieren.
Wenn Sie Upgrades für die nächste Gruppe weiter verzögern müssen, können Sie für die Cluster in der nächsten Gruppe Wartungsausschlüsse verwenden.
Zwischen flottenbasierten und teambasierten Roll-out-Sequenzen wechseln
Sie können von flottenbasierten Sequenzen zu teambasierten Sequenzen oder von teambasierten Sequenzen zu flottenbasierten Sequenzen wechseln. In der Anleitung wird davon ausgegangen, dass Sie zwischen den Sequenzen übertragen, die so wie in den Beispieldiagrammen dargestellt organsiert sind.
Flotten zu Teams
So ändern Sie Ihre Cluster von einer flottenbasierten Roll-out-Sequenz zu einer teambasierten Roll-out-Sequenz:
- Konfigurieren Sie Wartungsausschlüsse für alle Cluster in jeder Flotte, um Upgrades zu verhindern, während Sie die Konfiguration ändern.
- Achten Sie darauf, dass in Ihren Flotten-Hostprojekten GKE Enterprise aktiviert ist.
- Erstellen Sie in jeder Ihrer Flotten einen oder mehrere Teambereiche, um die Clustergruppen in dieser Flotte zu unterteilen.
- Erstellen Sie eine oder mehrere Roll-out-Sequenzen zwischen den übereinstimmenden Teambereichen in jeder Flotte.
- Fügen Sie Ihre Cluster zu ihren neuen Teambereichen hinzu.
- Entfernen Sie die Wartungsausschlüsse, die Sie für diese Änderung konfiguriert haben.
Von Teams zu Flotten
So ändern Sie Ihre Cluster von einer teambasierten Roll-out-Sequenz zu einer flottenbasierten Roll-out-Sequenz:
- Konfigurieren Sie Wartungsausschlüsse für alle Cluster in jeder Flotte, um Upgrades zu verhindern, während Sie die Konfiguration ändern.
- Erstellen Sie eine Roll-out-Sequenz zwischen Ihren Flotten.
- Entfernen Sie die Cluster aus ihren Teambereichen. Diese Cluster werden jetzt nur für die entsprechenden Flotten ihres Bereichs registriert, die Sie im vorherigen Schritt in einer Roll-out-Sequenz zusammengeführt haben.
- Löschen Sie die Teambereiche.
- Entfernen Sie die Wartungsausschlüsse, die Sie für diese Änderung konfiguriert haben.
Sequenz löschen
Zum Löschen einer Sequenz entfernen Sie die vorgelagerten Verknüpfungen für die zweite und dritte Gruppe (sofern die Roll-out-Sequenz drei Gruppen hat).
Für Flotten
Führen Sie den folgenden Befehl im Flotten-Hostprojekt der zweiten und dritten Flotte in der Roll-out-Sequenz aus:
gcloud container fleet clusterupgrade update --reset-upstream-fleet
Für Teams
Führen Sie den folgenden Befehl im Flotten-Hostprojekt des zweiten und dritten Teambereichs in der Roll-out-Sequenz aus:
gcloud alpha container fleet scopes update SCOPE_NAME --reset-upstream-scope
Ersetzen Sie SCOPE_NAME
durch die Namen des zweiten und dritten Bereichs.
Fehlerbehebung
Fehler bei der Roll-out-Berechtigung beheben
Wenn nicht alle Cluster in einer Roll-out-Sequenz dasselbe Upgradeziel haben, kann GKE möglicherweise nicht mit Clusterupgrades fortfahren. Automatische Upgrades können nicht fortgesetzt werden, wenn eine vorgelagerte Gruppe nicht genau ein Upgrade-Ziel qualifiziert, das an die nachgelagerte Gruppe übergeben werden soll. Automatische Upgrades können auch nicht fortgesetzt werden, wenn Cluster in der vorgelagerten Gruppe ein ungültiges Upgrade-Ziel für Cluster in der nachgelagerten Gruppe qualifizieren.
Prüfen Sie den Status der Roll-out-Sequenz, um festzustellen, ob bei Ihrer Roll-out-Sequenz Probleme auftreten. Wenn eine Gruppe nicht berechtigt ist, folgen Sie der Anleitung, um den Status einzelner Cluster in einer Gruppe anzuzeigen.
Entfernen Sie alle Cluster mit dem Status INELIGIBLE
, indem Sie der Anleitung unter Teilweise berechtigte Roll-outs voranbringen folgen, um Clusterupgrades sofort fortzusetzen.
Berechtigung in einer Gruppe korrigieren
Wenn in einer Gruppe ein Cluster nicht berechtigt ist, da er eine frühere Version hat (z. B. wird für die meisten Cluster in der Gruppe ein Upgrade von 1.23 auf 1.24 ausgeführt und ein Cluster hat Version 1.22), können Sie manuell ein Upgrade auf 1.24 ausführen, um die Versionsabweichung zu beheben.
Wenn ein Cluster in einer Gruppe nicht berechtigt ist, da er eine neuere Version hat (z. B. werden die meisten Cluster in der Gruppe von 1.23 auf 1.24 aktualisiert und ein Cluster hat Version 1.25), können Sie den Cluster nicht manuell herunterstufen, um die Versionsabweichung zu beheben, und müssen den Cluster entfernen.
Berechtigung zwischen Gruppen korrigieren
Wenn es zwischen Gruppen eine Abweichung bei den Upgradezielen gibt, wobei die nachgelagerte Gruppe eine neuere Version hat (z. B. wird die vorgelagerte Gruppe von 1.23 auf 1.24 aktualisiert und die Cluster in der nachgelagerten Gruppe haben Version 1.25), können Sie die Cluster in der vorgelagerten Gruppe manuell auf 1.25 aktualisieren, um sicherzustellen, dass die Upgrades fortgesetzt werden.
Wenn es zwischen Gruppen Abweichung bei den Upgradezielen gibt, wobei die nachgelagerte Gruppe eine frühere Version hat (z. B. wird die vorgelagerte Gruppe von 1.24 auf 1.25 aktualisiert und die Cluster in der nachgelagerten Gruppe haben Version 1.23), können Sie die Cluster in der nachgelagerten Gruppe manuell auf 1.24 oder 1.25 aktualisieren, um sicherzustellen, dass die Upgrades fortgesetzt werden.
Teilweise berechtigte Roll-outs voranbringen
Wenn Clusterupgrades in einer Gruppe aufgrund von Problemen mit der Roll-out-Berechtigung nicht abgeschlossen werden (z. B. Versionsabweichungen innerhalb einer Gruppe), können Sie Cluster, die nicht für das Upgradeziel der Gruppe berechtigt sind, aus einer Gruppe entfernen, um das Versions-Roll-out abzuschließen und mit der Betriebszeit zu beginnen, oder mit der nächsten Gruppe in der Roll-out-Sequenz fortfahren. Sie können einen Cluster auch aus anderen Gründen aus einer Gruppe entfernen, z. B. wenn die Nutzung dieses Clusters nicht mehr mit den anderen Clustern in der Gruppe zusammenhängt.
Folgen Sie der Anleitung unter Registrierung eines Clusters bei einer Flotte aufheben oder Cluster aus Teambereichen entfernen, je nach der Art der Roll-out-Sequenz.
Nachdem Sie alle Cluster entfernt haben, die den Abschluss des Versions-Roll-outs einer Gruppe verhindern, wird das Versions-Roll-out der Gruppe abgeschlossen. Bestätigen Sie dies mithilfe der Anleitung unter Status eines Versions-Roll-outs prüfen.