Die Vorgängerversion von angehängten GKE-Clustern wird als angehängte GKE-Cluster (vorherige Generation) bezeichnet. Wenn Sie von der früheren Version von GKE-angehängten Clustern zur aktuellen Generation migrieren, erhalten Sie Zugriff auf diese Funktionen, einschließlich Lebenszyklusverwaltung und Flottenregistrierung. Die Migration ist ein Einwegvorgang: Wenn Sie zu der aktuellen Generation von mit GKE angehängten Clustern migriert haben, können Sie nicht mehr zu mit GKE angehängten Clustern (vorherige Generation) zurückkehren.
Richtlinie zur Versionsnummerierung
In diesen Dokumenten wird die Version des GKE-angehängten Clusters als Plattformversion bezeichnet, um sie von der Kubernetes-Version zu unterscheiden. Bei GKE-angehängten Clustern wird die gleiche Versionsnummerkonvention wie bei GKE verwendet, z. B. 1.21.5-gke.1. Wenn Sie Ihren Cluster anhängen oder aktualisieren, müssen Sie eine Plattformversion auswählen, deren Nebenversion der Kubernetes-Version Ihres Clusters entspricht oder eine Ebene darunter liegt. Sie können beispielsweise einen Cluster mit Kubernetes v1.22.* und der GKE-angehängten Clusterplattformversion 1.21.* oder 1.22.* anhängen.
Dadurch können Sie Ihren Cluster auf die nächste Nebenversion aktualisieren, bevor Sie GKE-angehängte Cluster aktualisieren.
Workload Identity muss aktiviert sein
Für vorhandene Cluster aus angehängten GKE-Clustern (vorherige Generation) muss Workload Identity aktiviert sein, bevor sie zur aktuellen Generation von angehängten GKE-Clustern migriert werden.
Führen Sie den folgenden Befehl aus und prüfen Sie die Ausgabe auf ein Workload Identity-Feld, um festzustellen, ob Workload Identity aktiviert ist:
gcloud container hub memberships describe MEMBERSHIP_NAMEWenn Workload Identity nicht aktiviert ist, muss die Mitgliedschaft aktualisiert werden, um es zu aktivieren.
Der Befehl zum Aktualisieren der Mitgliedschaft Ihres Clusters variiert geringfügig, je nachdem, ob Sie Ihren Cluster mit dem privaten OIDC-Standardaussteller oder dem experimentellen öffentlichen Aussteller konfiguriert haben. Wählen Sie den Tab aus, der auf Ihren Cluster zutrifft:Privater OIDC-Aussteller (Standard)
gcloud container hub memberships register MEMBERSHIP_NAME \
--context=KUBECONFIG_CONTEXT \
--kubeconfig=KUBECONFIG_PATH \
--enable-workload-identity \
--has-private-issuer
Ersetzen Sie:
- MEMBERSHIP_NAME: der Name der Mitgliedschaft Ihres Clusters
- KUBECONFIG_CONTEXT: Kontext in der kubeconfig für den Zugriff auf den AKS-Cluster
- KUBECONFIG_PATH: Pfad zu Ihrer kubeconfig-Datei
Öffentlicher OIDC-Aussteller
- Rufen Sie die OIDC-Aussteller-URL Ihres Clusters mit dem folgenden Befehl ab:
az aks show -n CLUSTER_NAME \
-g RESOURCE_GROUP \
--query "oidcIssuerProfile.issuerUrl" -otsv
Die Ausgabe dieses Befehls ist die URL Ihres OIDC-Ausstellers. Speichern Sie diesen Wert für die spätere Verwendung.
- Aktualisieren Sie die Mitgliedschaft:
gcloud container fleet memberships register MEMBERSHIP_NAME \
--context=KUBECONFIG_CONTEXT \
--kubeconfig=KUBECONFIG_PATH \
--enable-workload-identity \
--public-issuer-url=OIDC_URL
Ersetzen Sie:
- MEMBERSHIP_NAME: der Name der Mitgliedschaft Ihres Clusters
- KUBECONFIG_CONTEXT: Kontext in der kubeconfig für den Zugriff auf den AKS-Cluster
- KUBECONFIG_PATH: Pfad zu Ihrer kubeconfig-Datei
- OIDC_URL: die zuvor abgerufene OIDC-URL
Cluster migrieren
So migrieren Sie Ihren Cluster von angehängten GKE-Clustern (vorherige Generation) zu angehängten GKE-Clustern:
Extrahieren Sie den kubeconfig-Kontext Ihres Clusters und speichern Sie ihn in der Umgebungsvariablen KUBECONFIG_CONTEXT:
KUBECONFIG_CONTEXT=$(kubectl config current-context)Führen Sie den folgenden Befehl aus, um Ihren Cluster zur aktuellen Generation von mit GKE angehängten Clustern zu migrieren. Mit diesem Befehl werden die relevanten Details der Konfiguration Ihres Clusters extrahiert, Ihr Cluster bei Google Fleet Management registriert und alle erforderlichen Softwarekomponenten wie der Lifecycle-Agent in Ihrem Cluster installiert oder aktualisiert.
gcloud container attached clusters import \ --location=GOOGLE_CLOUD_REGION \ --fleet-membership=FLEET_MEMBERSHIP \ --platform-version=PLATFORM_VERSION \ --distribution=CLUSTER_DISTRIBUTION \ --context=KUBECONFIG_CONTEXT \ [--kubeconfig=KUBECONFIG_PATH]Ersetzen Sie:
- GOOGLE_CLOUD_REGION: der Google Cloud Standort, von dem aus Ihr Cluster verwaltet wird
- FLEET_MEMBERSHIP: Der vollständig qualifizierte Mitgliedschaftsbezeichner Ihres registrierten Clusters (siehe unten).
- PLATFORM_VERSION: die Version der angehängten GKE-Cluster, zu der Sie migrieren möchten (z. B. v1.22.0-gke.1)
- CLUSTER_DISTRIBUTION: Der Clustertyp:
eksfür den Elastic Kubernetes Service von AWS,aksfür den Azure Kubernetes Service odergenericfür eine andere Distribution. - KUBECONFIG_CONTEXT: Der Name des Kontexts in Ihrem
kubeconfig, mit dem Sie eine Verbindung zu Ihrem Cluster herstellen. - KUBECONFIG_PATH: Der Speicherort Ihrer
kubeconfig-Datei. Wenn keine Angabe erfolgt, lautet der Standardwert~/.kube/config.
Der Mitgliedschaftsbezeichner ist ein String, der Ihren angehängten Cluster eindeutig identifiziert und die Form
projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP_IDhat, wobeiPROJECT_NUMBER ist die Projektnummer Ihres Flotten-Hostprojekts. Sie müssen dieselbe Projektnummer wie für Ihren aktuellen Cluster angeben.
MEMBERSHIP_ID: Dies muss die ID der Flottenmitgliedschaft Ihres vorhandenen Clusters sein. Angehängte GKE-Cluster verwenden diesen Wert als Clusternamen.
Unterstützung von Azure-Workload Identity
Azure bietet Unterstützung für WI in der öffentlichen Vorschau. Wenn Sie dieses Feature aktivieren, ändert sich die OIDC-Aussteller-URL Ihres Clusters. Wenn Sie Ihren Cluster bereits mit einer früheren OIDC-URL registriert haben, können Sie nicht auf die neue URL aktualisieren, da dieses Feld derzeit nicht aktualisiert werden kann.
So beheben Sie dies:
- Erstellen Sie Ihren Cluster neu und aktivieren Sie Workload Identity.
- AKS-Cluster anhängen
- Migrieren Sie Ihre Arbeitslasten zum neuen Cluster.
- Löschen Sie den alten Cluster.