Diese Seite wurde von der Cloud Translation API übersetzt.

GKE-Umgebung mit mehreren Clustern mit Multi-Cluster-Ingress aktualisieren

In dieser Anleitung wird gezeigt, wie Sie eine Google Kubernetes Engine-Umgebung (GKE) mit mehreren Clustern mithilfe von Multi-Cluster-Ingress aktualisieren. Diese Anleitung ist eine Fortsetzung des Dokuments zu Multi-Cluster-GKE-Upgrades mit Multi-Cluster-Ingress, in dem der Prozess, die Architektur und Bedingungen ausführlicher beschrieben werden. Wir empfehlen Ihnen, das Konzeptdokument vor dieser Anleitung zu lesen.

Einen detaillierten Vergleich zwischen Multi-Cluster-Ingress (MCI), Multi-Cluster-Gateway (MCG) und dem Load Balancer mit eigenständigen Netzwerk-Endpunktgruppen (LB und eigenständige NEGs) finden Sie unter Multi-Cluster-Load-Balancing-API für GKE auswählen.

Dieses Dokument richtet sich an Google Cloud Administratoren, die für die Verwaltung von Flotten für GKE-Cluster verantwortlich sind.

Wir empfehlen ein automatisches Upgrade Ihrer GKE-Cluster. Automatische Upgrades sind eine vollständig verwaltete Methode, um Ihre Cluster (Steuerungsebene und Knoten) automatisch in einem vonGoogle Cloudfestgelegten Releasezeitplan zu aktualisieren. Dafür ist kein Eingreifen des Operators erforderlich. Wenn Sie jedoch mehr Kontrolle darüber haben möchten, wie und wann Cluster aktualisiert werden, wird in dieser Anleitung eine Methode zur Aktualisierung mehrerer Cluster beschrieben, in der Ihre Anwendungen auf allen Clustern ausgeführt werden. Hierbei wird Multi-Cluster-Ingress verwendet, um jeweils einen Cluster vor dem Upgrade per Drain zu beenden.

Architektur

In dieser Anleitung wird die folgende Architektur verwendet. Es gibt insgesamt drei Cluster: zwei Cluster (blue und green) fungieren als identische Cluster mit derselben bereitgestellten Anwendung und ein Cluster (ingress-config) fungiert als Cluster auf Steuerungsebene, der Multi-Cluster-Ingress konfiguriert. In dieser Anleitung stellen Sie eine Beispielanwendung in zwei Anwendungsclustern (blue und green) bereit.

Architektur von zwei identischen Clustern und einem Cluster der Steuerungsebene.

Umgebung einrichten

Klonen Sie in Cloud Shell das Repository, um die Dateien für diese Anleitung abzurufen:

cd ${HOME}
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

Erstellen Sie ein WORKDIR-Verzeichnis.

cd kubernetes-engine-samples/networking/gke-multicluster-upgrade-mci/
export WORKDIR=`pwd`

GKE-Cluster in einem Hub erstellen und registrieren

In diesem Abschnitt erstellen Sie drei GKE-Cluster und registrieren sie für GKE Hub.

GKE-Cluster erstellen

Erstellen Sie in Cloud Shell drei GKE-Cluster:

gcloud container clusters create ingress-config --location us-west1-a \
--release-channel=None --no-enable-autoupgrade --num-nodes=4 \
--enable-ip-alias --workload-pool=${PROJECT}.svc.id.goog --quiet --async
gcloud container clusters create blue --location us-west1-b --num-nodes=3 \
--release-channel=None --no-enable-autoupgrade --enable-ip-alias \
--workload-pool=${PROJECT}.svc.id.goog --quiet --async
gcloud container clusters create green --location us-west1-c --num-nodes=3 \
--release-channel=None --no-enable-autoupgrade --enable-ip-alias \
--workload-pool=${PROJECT}.svc.id.goog --quiet

Für diese Anleitung erstellen Sie die Cluster in einer einzelnen Region in drei verschiedenen Zonen: us-west1-a, us-west1-b und us-west1-c. Weitere Informationen zu Regionen und Zonen finden Sie unter Geografie und Regionen.

Warten Sie einige Minuten, bis alle Cluster erstellt wurden. Prüfen Sie, ob die Cluster ausgeführt werden:

gcloud container clusters list

Die Ausgabe sieht in etwa so aus:

NAME: ingress-config
LOCATION: us-west1-a
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.233.186.135
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 4
STATUS: RUNNING

NAME: blue
LOCATION: us-west1-b
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 34.82.35.222
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

NAME: green
LOCATION: us-west1-c
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.185.204.26
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

Erstellen Sie eine kubeconfig-Datei und stellen Sie eine Verbindung zu allen Clustern her, um Einträge in der Datei kubeconfig zu erstellen:

touch gke-upgrade-kubeconfig
export KUBECONFIG=gke-upgrade-kubeconfig
gcloud container clusters get-credentials ingress-config \
    --location us-west1-a --project ${PROJECT}
gcloud container clusters get-credentials blue --location us-west1-b \
    --project ${PROJECT}
gcloud container clusters get-credentials green --location us-west1-c \
    --project ${PROJECT}

Mithilfe der kubeconfig-Datei richten Sie die Authentifizierung für die Cluster ein. Dazu erstellen Sie einen Nutzer und einen Kontext für jeden Cluster. Nachdem Sie die kubeconfig-Datei erstellt haben, können Sie den Kontext zwischen Clustern schnell wechseln.

Prüfen Sie, ob die Datei kubeconfig drei Cluster enthält:

kubectl config view -ojson | jq -r '.clusters[].name'

Die Ausgabe sieht so aus:

gke_gke-multicluster-upgrades_us-west1-a_ingress-config
gke_gke-multicluster-upgrades_us-west1-b_blue
gke_gke-multicluster-upgrades_us-west1-c_green

Rufen Sie den Kontext für die drei Cluster zur späteren Verwendung ab:

export INGRESS_CONFIG_CLUSTER=$(kubectl config view -ojson | jq \
    -r '.clusters[].name' | grep ingress-config)
export BLUE_CLUSTER=$(kubectl config view -ojson | jq \
    -r '.clusters[].name' | grep blue)
export GREEN_CLUSTER=$(kubectl config view -ojson | jq \
    -r '.clusters[].name' | grep green)
echo -e "${INGRESS_CONFIG_CLUSTER}\n${BLUE_CLUSTER}\n${GREEN_CLUSTER}"

Die Ausgabe sieht so aus:

gke_gke-multicluster-upgrades_us-west1-a_ingress-config
gke_gke-multicluster-upgrades_us-west1-b_blue
gke_gke-multicluster-upgrades_us-west1-c_green

GKE-Cluster bei einer Flotte registrieren

Wenn Sie Ihre Cluster in einer Flotte registrieren, können Sie Ihre Kubernetes-Cluster in Hybridumgebungen ausführen. Cluster, die für Flotten registriert sind, können erweiterte GKE-Features wie Multi-Cluster-Ingress verwenden. Um einen GKE-Cluster bei einer Flotte zu registrieren, können Sie ein Google Cloud-Dienstkonto direkt verwenden oder den empfohlenen Workload Identity Federation for GKE-Ansatz befolgen, bei dem ein Kubernetes-Dienstkonto in Ihrem GKE-Cluster als Identity and Access Management-Dienstkonto fungieren kann.

Registrieren Sie die drei Cluster als Flotte:

gcloud container fleet memberships register ingress-config \
    --gke-cluster=us-west1-a/ingress-config \
    --enable-workload-identity

gcloud container fleet memberships register blue \
    --gke-cluster=us-west1-b/blue \
    --enable-workload-identity

gcloud container fleet memberships register green \
    --gke-cluster=us-west1-c/green \
    --enable-workload-identity

Prüfen Sie, ob die Cluster registriert sind:

gcloud container fleet memberships list

Die Ausgabe sieht in etwa so aus:

NAME: blue
EXTERNAL_ID: 401b4f08-8246-4f97-a6d8-cf1b78c2a91d

NAME: green
EXTERNAL_ID: 8041c36a-9d42-40c8-a67f-54fcfd84956e

NAME: ingress-config
EXTERNAL_ID: 65ac48fe-5043-42db-8b1e-944754a0d725

Konfigurieren Sie den Cluster ingress-config als Konfigurationscluster für Multi-Cluster-Ingress, indem Sie das Feature multiclusteringress über den Hub aktivieren:
```
gcloud container fleet ingress enable --config-membership=ingress-config
```
Mit dem vorherigen Befehl werden die benutzerdefinierten Ressourcendefinitionen (CRDs) MulticlusterIngress und MulticlusterService zum Cluster ingress-config hinzugefügt. Dieser Befehl kann einige Minuten dauern. Warten Sie, bevor Sie mit dem nächsten Schritt fortfahren.

Prüfen Sie, ob der ingress-cluster-Cluster für Multi-Cluster-Ingress erfolgreich konfiguriert wurde:

watch gcloud container fleet ingress describe

Warten Sie, bis die Ausgabe in etwa so aussieht:

createTime: '2022-07-05T10:21:40.383536315Z'
membershipStates:
  projects/662189189487/locations/global/memberships/blue:
    state:
      code: OK
      updateTime: '2022-07-08T10:59:44.230329189Z'
  projects/662189189487/locations/global/memberships/green:
    state:
      code: OK
      updateTime: '2022-07-08T10:59:44.230329950Z'
  projects/662189189487/locations/global/memberships/ingress-config:
    state:
      code: OK
      updateTime: '2022-07-08T10:59:44.230328520Z'
name: projects/gke-multicluster-upgrades/locations/global/features/multiclusteringress
resourceState:
  state: ACTIVE
spec:
  multiclusteringress:
    configMembership: projects/gke-multicluster-upgrades/locations/global/memberships/ingress-config
state:
  state:
    code: OK
    description: Ready to use
    updateTime: '2022-07-08T10:57:33.303543609Z'
updateTime: '2022-07-08T10:59:45.247576318Z'

Drücken Sie Strg+C, um den Befehl watch zu beenden.

Beispielanwendung für blauen und grünen Cluster bereitstellen

Stellen Sie in Cloud Shell die whereami-Beispielanwendung für die Cluster blue und green bereit:

kubectl --context ${BLUE_CLUSTER} apply -f ${WORKDIR}/application-manifests
kubectl --context ${GREEN_CLUSTER} apply -f ${WORKDIR}/application-manifests

Warten Sie einige Minuten und prüfen Sie, ob alle Pods in den Clustern blue und green den Status Running haben:

kubectl --context ${BLUE_CLUSTER} get pods
kubectl --context ${GREEN_CLUSTER} get pods

Die Ausgabe sieht etwa so aus:

NAME                                   READY   STATUS    RESTARTS   AGE
whereami-deployment-756c7dc74c-zsmr6   1/1     Running   0          74s
NAME                                   READY   STATUS    RESTARTS   AGE
whereami-deployment-756c7dc74c-sndz7   1/1     Running   0          68s.

Multi-Cluster-Ingress konfigurieren

In diesem Abschnitt erstellen Sie einen Multi-Cluster-Ingress, der Traffic an die Anwendung sendet, die in den Clustern blue und green ausgeführt wird. Sie verwenden Cloud Load Balancing, um einen Load-Balancer zu erstellen, der die App whereami in den Clustern blue und green als Back-Ends verwendet. Zum Erstellen des Load-Balancers benötigen Sie zwei Ressourcen: einen MultiClusterIngress und eine oder mehrere MultiClusterServices. MultiClusterIngress- und MultiClusterService-Objekte sind Multi-Cluster-Analoge für die vorhandenen Kubernetes Ingress- und Dienstressourcen, die im Einzelclusterkontext verwendet werden.

Stellen Sie in Cloud Shell die Ressource MulticlusterIngress im Cluster ingress-config bereit:

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mci.yaml

Die Ausgabe sieht so aus:

multiclusteringress.networking.gke.io/whereami-mci created

Stellen Sie die Ressource MulticlusterService im Cluster ingress-config bereit:

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml

Die Ausgabe sieht so aus:

multiclusterservice.networking.gke.io/whereami-mcs created

So vergleichen Sie die beiden Ressourcen:
- Prüfen Sie die Ressource MulticlusterIngress:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusteringress -o yaml
```
  Die Ausgabe enthält Folgendes:
```
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080
```
  Die Ressource MulticlusterIngress ähnelt der Kubernetes Ingress-Ressource, mit der Ausnahme, dass die Spezifikation serviceName auf eine MulticlusterService-Ressource verweist.
- Prüfen Sie die Ressource MulticlusterService:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice -o yaml
```
  Die Ausgabe enthält Folgendes:
```
spec:
  clusters:
  - link: us-west1-b/blue
  - link: us-west1-c/green
  template:
    spec:
      ports:
      - name: web
        port: 8080
        protocol: TCP
        targetPort: 8080
      selector:
        app: whereami
```
  Die Ressource MulticlusterService ähnelt einer Kubernetes-Dienstressource, enthält jedoch die Spezifikation clusters. Der Wert clusters ist die Liste der registrierten Cluster, in denen die Ressource MulticlusterService erstellt wird.
- Prüfen Sie, ob die Ressource MulticlusterIngress einen Load-Balancer mit einem Backend-Dienst erstellt hat, der auf die Ressource MulticlusterService verweist:
```
watch kubectl --context ${INGRESS_CONFIG_CLUSTER} \
      get multiclusteringress -o jsonpath="{.items[].status.VIP}"
```
  Dies kann bis zu 10 Minuten dauern. Warten Sie, bis die Ausgabe in etwa so aussieht:
```
34.107.246.9
```
  Zum Beenden des Befehls watch drücken Sie Control+C.

Rufen Sie in Cloud Shell die Cloud Load Balancing-VIP auf:

export GCLB_VIP=$(kubectl --context ${INGRESS_CONFIG_CLUSTER} \
       get multiclusteringress -o json | jq -r '.items[].status.VIP') \
       && echo ${GCLB_VIP}

Die Ausgabe sieht in etwa so aus:

34.107.246.9

Verwenden Sie curl, um auf den Load Balancer und die bereitgestellte Anwendung zuzugreifen:

curl ${GCLB_VIP}

Die Ausgabe sieht in etwa so aus:

{
  "cluster_name": "green",
  "host_header": "34.107.246.9",
  "pod_name": "whereami-deployment-756c7dc74c-sndz7",
  "pod_name_emoji": "😇",
  "project_id": "gke-multicluster-upgrades",
  "timestamp": "2022-07-08T14:26:07",
  "zone": "us-west1-c"
}

Führen Sie den Befehl curl wiederholt aus. Beachten Sie, dass das Load-Balancing für die Anfragen zwischen der whereami-Anwendung erfolgt, die in zwei Clustern bereitgestellt wird: blue und green.

Load Generator einrichten

In diesem Abschnitt richten Sie einen loadgenerator-Dienst ein, der Client-Traffic zur VIP des Cloud Load Balancing erstellt. Zuerst wird Traffic an die Cluster blue und green gesendet, da die Ressource MulticlusterService so eingerichtet ist, dass Traffic an beide Cluster gesendet wird. Später konfigurieren Sie die Ressource MulticlusterService so, dass sie Traffic an einen einzelnen Cluster sendet.

Konfigurieren Sie das Manifest loadgenerator so, dass es Client-Traffic an Cloud Load Balancing sendet:

TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}

Stellen Sie den loadgenerator im Cluster ingress-config bereit:

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/loadgen-manifests

Prüfen Sie, ob die loadgenerator-Pods im Cluster ingress-config den Status Running haben:

kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods

Die Ausgabe sieht etwa so aus:

NAME                             READY   STATUS    RESTARTS   AGE
loadgenerator-5498cbcb86-hqscp   1/1     Running   0          53s
loadgenerator-5498cbcb86-m2z2z   1/1     Running   0          53s
loadgenerator-5498cbcb86-p56qb   1/1     Running   0          53s

Wenn einer der Pods den Status Running nicht hat, warten Sie einige Minuten und führen Sie den Befehl noch einmal aus.

Traffic nachverfolgen

In diesem Abschnitt beobachten Sie den Traffic zur Anwendung whereami mithilfe derGoogle Cloud -Konsole.

Im vorherigen Abschnitt haben Sie ein loadgenerator-Deployment eingerichtet, das den Client-Traffic simuliert, indem über die Cloud Load Balancing-VIP auf die whereami-Anwendung zugegriffen wird. Sie können diese Messwerte über dieGoogle Cloud -Konsole überwachen. Richten Sie zuerst das Monitoring ein und beobachten Sie dann das Beenden von Clustern für Upgrades. Dies wird im nächsten Abschnitt beschrieben.

Erstellen Sie ein Dashboard, um den Traffic anzuzeigen, der den Multi-Cluster-Ingress erreicht:

export DASH_ID=$(gcloud monitoring dashboards create \
    --config-from-file=dashboards/cloud-ops-dashboard.json \
    --format=json | jq  -r ".name" | awk -F '/' '{print $4}')

Die Ausgabe sieht etwa so aus:

Created [721b6c83-8f9b-409b-a009-9fdf3afb82f8]

Messwerte aus Cloud Load Balancing sind in derGoogle Cloud Console verfügbar. Erstellen Sie die URL:

echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"

Die Ausgabe sieht in etwa so aus:

https://console.cloud.google.com/monitoring/dashboards/builder/721b6c83-8f9b-409b-a009-9fdf3afb82f8/?project=gke-multicluster-upgrades&timeDomain=1h"

Rufen Sie in einem Browser die URL auf, die durch den vorherigen Befehl erstellt wurde.

Der Traffic an die Beispielanwendung geht vom Load-Generator an die Cluster blue und green, angegeben durch die Zonen, in denen sich die Cluster befinden. Das Messwertdiagramm der Zeitachse zeigt den Traffic an beide Back-Ends. Die Mouseover-Werte k8s1- geben an, dass die Netzwerk-Endpunktgruppe (NEGs) für die zwei Frontend-MulticlusterServices in den Clustern blue und green ausgeführt wird.

Hinweis: Die Diagrammfarben entsprechen möglicherweise nicht den Clustern blue und green. Es kann einige Minuten dauern, bis der Traffic im Diagramm sichtbar wird.

Cluster `blue` per Drain beenden und aktualisieren

In diesem Abschnitt beenden Sie den Cluster blue. Das Beenden eines Clusters bedeutet, dass Sie ihn aus dem Load-Balancing-Pool entfernen. Nachdem Sie den Cluster blue beendet haben, wird der gesamte für die Anwendung bestimmte Client-Traffic an den Cluster green weitergeleitet. Sie können diesen Vorgang wie im vorherigen Abschnitt beschrieben überwachen. Nachdem der Cluster per Drain beendet wurde, können Sie ein Upgrade des beendeten Clusters durchführen. Nach dem Upgrade können Sie ihn wieder in den Load-Balancing-Pool verschieben. Wiederholen Sie diese Schritte, um ein Upgrade für den anderen Cluster durchzuführen. Dies wird in dieser Anleitung nicht gezeigt.

Wenn Sie den Cluster blue per Drain beenden möchten, aktualisieren Sie die Ressource MulticlusterService im Cluster ingress-cluster und entfernen den Cluster blue aus der Spezifikation clusters.

Blauen Cluster per Drain beenden

Aktualisieren Sie in Cloud Shell die Ressource MulticlusterService im Cluster ingress-config:

kubectl --context ${INGRESS_CONFIG_CLUSTER} \
          apply -f ${WORKDIR}/multicluster-manifests/mcs-green.yaml

Achten Sie darauf, dass nur der Cluster green in der Spezifikation clusters vorhanden ist:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
        -o json | jq '.items[].spec.clusters'
```
Die Ausgabe sieht so aus:
```
[
  {
    "link": "us-west1-c/green"
  }
]
```
Nur der Cluster green ist in der Spezifikation clusters aufgeführt, sodass sich nur der Cluster green im Load-Balancing-Pool befindet.
Sie können Messwerte aus den Cloud Load Balancing-Messwerten in derGoogle Cloud -Konsole ansehen. Erstellen Sie die URL:
```
echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
```
Rufen Sie in einem Browser die URL auf, die vom vorherigen Befehl erstellt wurde.

Das Diagramm zeigt, dass nur der Cluster green Traffic empfängt.

Cluster `blue` aktualisieren

Da der Cluster blue jetzt keinen Client-Traffic mehr empfängt, können Sie den Cluster aktualisieren (Steuerungsebene und Knoten).

Rufen Sie in Cloud Shell die aktuelle Version der Cluster ab:

gcloud container clusters list

Die Ausgabe sieht etwa so aus:

NAME: ingress-config
LOCATION: us-west1-a
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.233.186.135
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 4
STATUS: RUNNING

NAME: blue
LOCATION: us-west1-b
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 34.82.35.222
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

NAME: green
LOCATION: us-west1-c
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.185.204.26
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

Ihre Clusterversionen können abhängig davon, wann Sie diese Anleitung abgeschlossen haben, abweichen.

Rufen Sie die Liste der verfügbaren MasterVersions-Versionen in der Zone ab:

gcloud container get-server-config --location us-west1-b --format=json | jq \
'.validMasterVersions[0:20]'

Die Ausgabe sieht etwa so aus:

[
  "1.24.1-gke.1400",
  "1.23.7-gke.1400",
  "1.23.6-gke.2200",
  "1.23.6-gke.1700",
  "1.23.6-gke.1501",
  "1.23.6-gke.1500",
  "1.23.5-gke.2400",
  "1.23.5-gke.1503",
  "1.23.5-gke.1501",
  "1.22.10-gke.600",
  "1.22.9-gke.2000",
  "1.22.9-gke.1500",
  "1.22.9-gke.1300",
  "1.22.8-gke.2200",
  "1.22.8-gke.202",
  "1.22.8-gke.201",
  "1.22.8-gke.200",
  "1.21.13-gke.900",
  "1.21.12-gke.2200",
  "1.21.12-gke.1700"
]

Rufen Sie eine Liste der verfügbaren NodeVersions-Versionen in der Zone ab:

gcloud container get-server-config --location us-west1-b --format=json | jq \
'.validNodeVersions[0:20]'

Die Ausgabe sieht in etwa so aus:

[
  "1.24.1-gke.1400",
  "1.23.7-gke.1400",
  "1.23.6-gke.2200",
  "1.23.6-gke.1700",
  "1.23.6-gke.1501",
  "1.23.6-gke.1500",
  "1.23.5-gke.2400",
  "1.23.5-gke.1503",
  "1.23.5-gke.1501",
  "1.22.10-gke.600",
  "1.22.9-gke.2000",
  "1.22.9-gke.1500",
  "1.22.9-gke.1300",
  "1.22.8-gke.2200",
  "1.22.8-gke.202",
  "1.22.8-gke.201",
  "1.22.8-gke.200",
  "1.22.7-gke.1500",
  "1.22.7-gke.1300",
  "1.22.7-gke.900"
]

Legen Sie eine Umgebungsvariable für eine MasterVersion- und NodeVersion-Version fest, die sich in den MasterVersions- und NodeVersions-Listen befindet und höher ist als die aktuelle Version für den blue-Cluster. Beispiel:
```
export UPGRADE_VERSION="1.22.10-gke.600"
```
In dieser Anleitung wird die Version 1.22.10-gke.600 verwendet. Ihre Clusterversionen können je nach den Versionen variieren, die verfügbar sind, wenn Sie diese Anleitung durcharbeiten. Weitere Informationen zum Upgradevorgang finden Sie unter Upgrade eines Clusters oder Knotenpools.

Hinweis: Es wird empfohlen, Nebenversionen von Clustern nicht zu überspringen, um potenzielle Probleme mit der Steuerungsebene oder Knotenkompatibilität zu vermeiden. Weitere Informationen finden Sie unter Kann ich während eines Clusterupgrades mehrere GKE-Versionen überspringen?.
Aktualisieren Sie den Knoten control plane für den Cluster blue:
```
gcloud container clusters upgrade blue \
    --location us-west1-b --master --cluster-version ${UPGRADE_VERSION}
```
Drücken Sie zur Bestätigung auf Y.

Dieser Vorgang dauert einige Minuten. Warten Sie, bis das Upgrade abgeschlossen ist, bevor Sie fortfahren.

Nach Abschluss des Upgrades sieht die Ausgabe so aus:
```
Updated
[https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
```

Führen Sie ein Upgrade der Knoten im Cluster blue durch:

gcloud container clusters upgrade blue \
    --location=us-west1-b --node-pool=default-pool \
    --cluster-version ${UPGRADE_VERSION}

Drücken Sie zur Bestätigung auf Y.

Dieser Vorgang dauert einige Minuten. Warten Sie, bis das Knotenupgrade abgeschlossen ist, bevor Sie fortfahren.

Nach Abschluss des Upgrades sieht die Ausgabe so aus:

Upgrading blue... Done with 3 out of 3 nodes (100.0%): 3 succeeded...done.
Updated [https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].

Prüfen Sie, ob der Cluster blue aktualisiert wurde:

gcloud container clusters list

Die Ausgabe sieht in etwa so aus:

NAME: ingress-config
LOCATION: us-west1-a
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.233.186.135
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 4
STATUS: RUNNING

NAME: blue
LOCATION: us-west1-b
MASTER_VERSION: 1.22.10-gke.600
MASTER_IP: 34.82.35.222
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.10-gke.600
NUM_NODES: 3
STATUS: RUNNING

NAME: green
LOCATION: us-west1-c
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.185.204.26
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

Den `blue`-Cluster wieder dem Load-Balancing-Pool hinzufügen

In diesem Abschnitt fügen Sie den Cluster blue wieder dem Load-Balancing-Pool hinzu.

Prüfen Sie in Cloud Shell, ob die Anwendungsbereitstellung im Cluster blue ausgeführt wird, bevor Sie sie wieder zum Load-Balancing-Pool hinzufügen:

kubectl --context ${BLUE_CLUSTER} get pods

Die Ausgabe sieht in etwa so aus:

NAME                                   READY   STATUS    RESTARTS   AGE
whereami-deployment-756c7dc74c-xdnb6   1/1     Running   0          17m

Aktualisieren Sie die Ressource MutliclusterService, um den Cluster blue wieder dem Load-Balancing-Pool hinzuzufügen:

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply \
        -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml

Prüfen Sie, ob die Cluster blue und green in der Clusterspezifikation enthalten sind:

kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
        -o json | jq '.items[].spec.clusters'

Die Ausgabe sieht so aus:

[
  {
    "link": "us-west1-b/blue"
  },
  {
    "link": "us-west1-c/green"
  }
]

Die Cluster blue und green sind jetzt in der Spezifikation clusters enthalten.

Messwerte aus den Cloud Load Balancing-Messwerten sind in derGoogle Cloud Console verfügbar. Erstellen Sie die URL:

echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"

Rufen Sie in einem Browser die URL auf, die durch den vorherigen Befehl erstellt wurde.

Das Diagramm zeigt, dass beide Cluster (blau und grün) Traffic vom Load Generator über den Load Balancer empfangen.

Hinweis: Es kann einige Minuten dauern, bis der Traffic wieder ausgeglichen ist.

Glückwunsch! Sie haben mithilfe von Multi-Cluster-Ingress einen GKE-Cluster in einer Multi-Cluster-Architektur aktualisiert.
Zum Aktualisieren des Clusters green wiederholen Sie den Vorgang zum Beenden und Aktualisieren des blauen Clusters und ersetzen Sie blue durch green.

GKE-Umgebung mit mehreren Clustern mit Multi-Cluster-Ingress aktualisieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Architektur

Umgebung einrichten

GKE-Cluster in einem Hub erstellen und registrieren

GKE-Cluster erstellen

GKE-Cluster bei einer Flotte registrieren

Beispielanwendung für blauen und grünen Cluster bereitstellen

Multi-Cluster-Ingress konfigurieren

Load Generator einrichten

Traffic nachverfolgen

Cluster blue per Drain beenden und aktualisieren

Blauen Cluster per Drain beenden

Cluster blue aktualisieren

Den blue-Cluster wieder dem Load-Balancing-Pool hinzufügen

GKE-Umgebung mit mehreren Clustern mit Multi-Cluster-Ingress aktualisieren

Cluster `blue` per Drain beenden und aktualisieren

Cluster `blue` aktualisieren

Den `blue`-Cluster wieder dem Load-Balancing-Pool hinzufügen