Redis-Cluster in GKE bereitstellen

Standard

---

In dieser Anleitung werden empfohlene Vorgehensweisens zum Erstellen einer zustandsorientierten Anwendung und zum Aktualisieren des GKE-Clusters (Google Kubernetes Engine) dargestellt, auf dem die Anwendung ausgeführt wird. In dieser Anleitung wird Redis als Beispiel für das Deployment einer zustandsorientierten Anwendung verwendet. Das gleiche Vorgehen gilt jedoch auch für andere Arten zustandsorientierter Anwendungen, die in GKE bereitgestellt werden.

Lernziele

Diese Anleitung umfasst die folgenden Schritte:

1. Erstellen Sie einen GKE-Cluster, der in einer Release-Version registriert ist.
2. Erstellen Sie einen Redis-Cluster in GKE.
3. Stellen Sie die Redis-Clientanwendung in GKE bereit.
4. Führen Sie folgende Best Practices für Knotenpool-Upgrades aus:
   1. Richten Sie das Budget für Pod-Störungen (Pod Disruption Budget, PDB) ein.
   2. Richten Sie Wartungsfenster und -ausschlüsse ein.
   3. Legen Sie als Strategie für das Knotenupgrade entweder Surge-Upgrade oder Blau/Grün-Upgrade fest.
5. Testen Sie die Anwendung.
6. Aktualisieren Sie den Cluster.
7. Testen Sie die Unterbrechung der Arbeitslast.

Das folgende Diagramm zeigt eine allgemeine Ansicht der Clusterarchitektur für diese Anleitung:

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• GKE

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweis

Projekt einrichten

1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

2. Klicken Sie in der Google Cloud Console auf der Projektauswahlseite auf Projekt erstellen, um mit der Erstellung eines neuen Google Cloud-Projekts zu starten.

   Zur Projektauswahl

3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

4. GKE API aktivieren.

   Aktivieren Sie die API

5. Klicken Sie in der Google Cloud Console auf der Projektauswahlseite auf Projekt erstellen, um mit der Erstellung eines neuen Google Cloud-Projekts zu starten.

   Zur Projektauswahl

6. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

7. GKE API aktivieren.

   Aktivieren Sie die API

Standardeinstellungen für die Google Cloud CLI festlegen

1. Starten Sie in der Google Cloud Console eine Cloud Shell-Instanz:
   Cloud Shell öffnen

2. Laden Sie den Quellcode für diese Beispielanwendung herunter:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
    cd kubernetes-engine-samples/quickstarts/hello-app-redis/manifests
   

3. Legen Sie die Standardumgebungsvariablen fest:

    gcloud config set project PROJECT-ID
    gcloud config set compute/zone COMPUTE-ZONE
   

   Ersetzen Sie die folgenden Werte:

   • PROJECT_ID: Ihre Google Cloud-Projekt-ID.
   • COMPUTE_ZONE: Die Compute Engine-Zone.

Einen in einer Release-Version registrierten GKE-Cluster erstellen

Führen Sie die folgenden Schritte aus, um den GKE-Cluster zu erstellen:

1. Erstellen Sie einen Cluster namens redis-test mit drei Knoten:

   gcloud container clusters create redis-test \
       --num-nodes=3 \
       --release-channel regular
   

   Nachdem der Cluster erstellt wurde, sollte die Ausgabe in etwa so aussehen:

     NAME: redis-test
     LOCATION: us-central1-c
     MASTER_VERSION: 1.22.10-gke.600
     MASTER_IP: 34.69.67.7
     MACHINE_TYPE: e2-medium
     NODE_VERSION: 1.22.10-gke.600
     NUM_NODES: 3
     STATUS: RUNNING
   

2. Konfigurieren Sie kubectl für die Kommunikation mit dem Cluster:

   gcloud container clusters get-credentials redis-test
   

Redis-Cluster in GKE erstellen

In diesem Abschnitt fügen Sie dem GKE-Cluster, den Sie zuvor erstellt haben, einen Redis-Cluster hinzu. Dazu stellen Sie eine ConfigMap, ein StatefulSet und einen monitorlosen Dienst bereit.

Um einen Redis-Cluster zu erstellen, führen Sie folgende Schritte aus:

1. Verweisen Sie auf die ConfigMap-Datei (redis-configmap.yaml), in der die Redis-Konfiguration gespeichert ist. Das folgende Snippet zeigt die Skripts für die Bereitschaftsprüfung und die Aktivitätsprüfung.

   readiness.sh: |-
     #!/bin/sh
   
     pingResponse="$(redis-cli -h localhost ping)"
     if [ "$?" -eq "124" ]; then
       echo "PING timed out"
       exit 1
     fi
   
     if [ "$pingResponse" != "PONG"]; then
       echo "$pingResponse"
       exit 1
     fi
   liveness.sh: |-
     #!/bin/sh
   
     pingResponse="$(redis-cli -h localhost ping | head -n1 | awk '{print $1;}')"
     if [ "$?" -eq "124" ]; then
       echo "PING timed out"
       exit 1
     fi
   
     if [ "$pingResponse" != "PONG"] && [ "$pingResponse" != "LOADING" ] && [ "$pingResponse" != "MASTERDOWN" ]; then
       echo "$pingResponse"
       exit 1
     fi

   Die Skripts readiness.sh und liveness.sh verwenden redis-cli ping, um zu prüfen, ob der Redis-Server ausgeführt wird. Wenn PONG zurückgegeben wird, ist der Redis-Server einsatzbereit. Diese Skripts werden in redis-cluster.yaml verwendet.

   Weitere Informationen zu den Redis-Parametern in dieser ConfigMap finden Sie im Abschnitt zu den Konfigurationsparametern des Redis-Clusters in derRedis-Cluster-Anleitung.

2. Stellen Sie die ConfigMap bereit:

   kubectl apply -f redis-configmap.yaml
   

3. Das folgende StatefulSet-Snippet (redis-cluster.yaml) zeigt die Verwendung der Bereitschaftsprüfung und der Aktivitätsprüfung.

   Informationen zum Konfigurieren von Prüfungen in Kubernetes finden Sie unter Prüfungen konfigurieren.

   startupProbe:
     periodSeconds: 5
     timeoutSeconds: 5
     successThreshold: 1
     failureThreshold: 20
     tcpSocket:
       port: redis
   livenessProbe:
     periodSeconds: 5
     timeoutSeconds: 5
     successThreshold: 1
     failureThreshold: 5
     exec:
       command: ["sh", "-c", "/probes/liveness.sh"]
   readinessProbe:
     periodSeconds: 5
     timeoutSeconds: 1
     successThreshold: 1
     failureThreshold: 5
     exec:
       command: ["sh", "-c", "/probes/readiness.sh"]

   Wir empfehlen dringend, beim Upgrade von Knotenpools Bereitschafts- und Aktivitätsprüfungen zu verwenden. Dadurch wird gewährleistet, dass Ihre Pods während eines Upgrades zur Verfügung stehen.

4. Stellen Sie das StatefulSet bereit:

   kubectl apply -f redis-cluster.yaml
   

5. Der monitorlose Dienst mit dem Namen redis-service.yaml dient dem Verbinden der Redis-Knoten. Für das Feld clusterIP ist None festgelegt, um einen monitorlosen Dienst zu erstellen.

   Stellen Sie den Dienst bereit:

   kubectl apply -f redis-service.yaml
   

6. Warten Sie ungefähr zwei Minuten und prüfen Sie mit dem folgenden Befehl, ob alle Pods ausgeführt werden:

   kubectl get pods
   

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   NAME      READY   STATUS              RESTARTS   AGE
   redis-0   1/1     Running             0          2m29s
   redis-1   1/1     Running             0          2m8s
   redis-2   1/1     Running             0          107s
   redis-3   1/1     Running             0          85s
   redis-4   1/1     Running             0          54s
   redis-5   1/1     Running             0          23s
   

7. Prüfen Sie mit dem folgenden Befehl, ob die nichtflüchtigen Volumes erstellt wurden:

   kubectl get pv
   

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-5   standard                75s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-1   standard                2m59s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-3   standard                2m16s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-2   standard                2m38s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-0   standard                3m20s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-4   standard                104s
   

   In dieser Ausgabe steht HASH für einen Hash, der an den Namen jedes nichtflüchtigen Volumes angehängt wird.

Redis-Cluster Rollen zuweisen

Nachdem die Konfiguration abgeschlossen ist, weisen Sie dem Redis-Cluster Rollen zu.

Das folgende Script ruft die Pod-IP-Adressen ab, weist dann die Leader- sowie Follower-Rollen zu und übergibt dafür jede Pod-IP-Adresse an den Befehl:

#!/bin/bash
# Usage: ./roles.sh

urls=$(kubectl get pods -l app=redis -o jsonpath='{range.items[*]}{.status.podIP} ')
command="kubectl exec -it redis-0 -- redis-cli --cluster create --cluster-replicas 1 "

for url in $urls
do
    command+=$url":6379 "
done

echo "Executing command: " $command
$command

Um Ihrem Redis-Cluster Rollen zuzuweisen, führen Sie folgende Schritte aus:

1. Führen Sie das Skript aus:

   chmod +x ./roles.sh
   ./roles.sh
   

2. Geben Sie yes ein, wenn Sie dazu aufgefordert werden.

3. Melden Sie sich bei einem Redis-Knoten an, um dessen Rolle zu prüfen. Wenn Sie beispielsweise prüfen möchten, ob redis-0 eine Leader-Rolle hat, führen Sie den folgenden Befehl aus:

   kubectl exec -it redis-0 -- redis-cli role
   

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   1) "master"
   2) (integer) 574
   3) 1) 1) "10.28.2.3"
          2) "6379"
          3) "574"
   

Redis-Clientanwendung bereitstellen

Um Ihre Anwendung für den von Ihnen erstellten GKE-Cluster bereitzustellen, definieren Sie ein Deployment für Ihre Anwendung. Die Datei mit dem Namen app-deployment.yaml enthält die Deployment-Definition für die Anwendung.

Weitere Informationen zu den in diesem Deployment verwendeten Prüfungen und Pod-Affinitätsregeln finden Sie unter Best Practices für den Entwurf und die Erstellung hochverfügbarer GKE-Cluster.

Führen Sie zum Erstellen des Deployments die folgenden Schritte aus:

1. Wenden Sie das Deployment an:

   kubectl apply -f app-deployment.yaml
   

2. Geben Sie die Anwendung über einen Load-Balancer frei:

   kubectl expose deployment hello-web \
       --type=LoadBalancer \
       --port 80 \
       --target-port 8080
   

3. Warten Sie ungefähr eine Minute und rufen Sie mit dem folgenden Befehl die externe IP-Adresse der Anwendung ab:

   kubectl get service
   

   Kopieren Sie aus der Ausgabe den Wert, der in der Spalte hello-web's EXTERNAL-IP aufgeführt ist:

   NAME             TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)              AGE
   hello-web        LoadBalancer   10.13.10.55   EXTERNAL_IP   80:30703/TCP         166m
   

4. Fügen Sie EXTERNAL_IP in Ihren Webbrowser ein, um zu prüfen, ob die Anwendung funktioniert. Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   I have been hit [1] times since deployment!
   

   Notieren Sie sich die Anzahl der Besuche. Sie benötigen sie im Abschnitt Unterbrechung der Anwendung testen.

5. Legen Sie eine Variable für die externe IP-Adresse (EXTERNAL_IP) fest, die Sie gerade kopiert haben. Sie verwenden diesen Wert, wenn Sie im nächsten Abschnitt Skripts zum Testen der Anwendung erstellen:

   export IP=EXTERNAL_IP
   

Best Practices für Knotenpool-Upgrades konfigurieren

Führen Sie die im Folgenden aufgeführten Best Practices für zustandsorientierte Anwendungen aus, um eine bessere Verfügbarkeit während Knotenpool-Upgrades zu erreichen.

Budget für Pod-Störungen (Pod Disruption Budget, PDB) einrichten

Erstellen Sie ein Budget für Pod-Störungen, um die Anzahl der replizierten Pods zu begrenzen, die während einer freiwilligen Unterbrechung gleichzeitig ausfallen. Das ist hilfreich für eine zustandsorientierte Anwendung, bei der ein Quorum für die Anzahl der Replikate erforderlich ist, die während eines Upgrades verfügbar sein sollen.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: redis-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: redis

Für eine PDB-Definition gilt Folgendes:

• app gibt an, auf welche Anwendung dieses PDB angewendet wird.
• minAvailable legt die Mindestanzahl an Pods fest, die während einer Unterbrechung verfügbar sein sollen. Dies kann durch einen Wert oder einen Prozentsatz (z. B. 30 %) erfolgen.
• maxUnavailable legt die maximale Anzahl an Pods fest, die während einer Unterbrechung nicht verfügbar sein können. Es kann sich dabei um einen Wert oder einen Prozentsatz handeln.

Hinweis: Wählen Sie je nach Quorum oder Einstellung der Anwendung entweder minAvailable oder maxUnavailable für das PDB aus.

Hinweis: Wenn PodDisruptionBudget festgelegt ist, werden die Pods in Ihrer Anwendung von GKE nicht beendet, wenn die Anzahl der Pods das konfigurierte Limit bis zu 60 Minuten lang nicht übersteigt.

So richten Sie das PDB ein:

1. Stellen Sie das PDB bereit:

   kubectl apply -f pdb-minavailable.yaml
   

2. Prüfen Sie, ob das PDB erstellt wurde:

   kubectl get pdb
   

Wartungsfenster und -ausschlüsse einrichten

Automatische Knoten-Upgrades optimieren den Upgradevorgang und halten die Knoten im Cluster auf dem neuesten Stand, wenn die Steuerungsebene auf Ihre Anforderung hin aktualisiert wird. Dieses Feature ist standardmäßig aktiviert. Weitere Informationen finden Sie unter Knoten automatisch aktualisieren.

Verwenden Sie Wartungsfenster und -ausschlüsse, um festzulegen, wann Wartungen für GKE-Cluster ausgeführt werden können.

1. Richten Sie ein Wartungsfenster ein, das am 19. August 2022 um 2:00 Uhr UTC beginnt und vier Stunden später endet. Dieses Wartungsfenster gilt täglich. Während dieser Zeit ist eine automatische Wartung zulässig.

   gcloud container clusters update redis-test \
      --maintenance-window-start 2022-08-19T02:00:00Z \
      --maintenance-window-end 2022-08-19T06:00:00Z \
      --maintenance-window-recurrence FREQ=DAILY
   

2. Richten Sie ein Ausschlussfenster ein, damit während der Neujahrsfeiertage keine Wartungsarbeiten ausgeführt werden. Für diesen Wartungsausschluss gilt no_upgrades. Während dieser Zeit ist keine automatische Wartung jeglicher Art zulässig. Weitere Informationen finden Sie unter Umfang des Wartungsausschlusses.

   gcloud container clusters update redis-test \
      --add-maintenance-exclusion-name new-year \
      --add-maintenance-exclusion-start 2022-12-26T00:00:00Z \
      --add-maintenance-exclusion-end 2023-01-02T02:00:00Z \
      --add-maintenance-exclusion-scope no_upgrades
   

3. Prüfen Sie, ob das Wartungsfenster und die Wartungsausschlüsse angewendet werden. Suchen Sie unter maintenancePolicy:

   gcloud container clusters describe redis-test
   

Weitere Informationen finden Sie unter Wartungsfenster und -ausschlüsse konfigurieren.

Upgradestrategie für Knoten konfigurieren

Es gibt zwei Upgradestrategien, die Sie für die Knoten in Ihrem GKE-Cluster anwenden können: Blau/Grün-Upgrades und Surge-Upgrades. Weitere Informationen finden Sie unter Strategien für das Knotenupgrade.

Blau/Grün-Upgrades

Wählen Sie Blau/Grün-Upgrades, wenn die Arbeitslasten weniger störungstolerant sind und eine vorübergehende Kostenerhöhung aufgrund einer höheren Ressourcennutzung akzeptabel ist.

Führen Sie den folgenden Befehl aus, um die aktuellen Knotenpools auf eine Strategie für ein Blau/Grün-Upgrade umzustellen.

gcloud container node-pools update default-pool \
--cluster=redis-test \
--enable-blue-green-upgrade \
--zone COMPUTE-ZONE \
--node-pool-soak-duration=120s

Die Dauer des Knotenpoolbetriebs wird auf zwei Minuten festgelegt, um während der Phase des Knotenpoolbetriebs für diese Anleitung Zeit zu sparen. In dieser Phase können Sie den Status der Arbeitslast prüfen, nachdem die blauen Poolknoten entfernt wurden. Wir empfehlen, die Dauer des Knotenpoolbetriebs auf eine Stunde (3.600 Sekunden) oder auf einen für die Anwendung am besten geeigneten Zeitraum festzulegen.

Weitere Informationen zum Verwalten der Pod-Zuweisung finden Sie unter Pod in einem bestimmten Knotenpool bereitstellen und Services in bestimmten Knotenpools bereitstellen.

Weitere Informationen zum Konfigurieren von Blau/Grün-Upgrades finden Sie unter Blau/Grün-Upgrades konfigurieren.

Surge-Upgrades

Wählen Sie Surge-Upgrades aus, wenn eine Kostenoptimierung wichtig ist und wenn Arbeitslasten ein ordnungsgemäßes Herunterfahren in weniger als 60 Minuten tolerieren können (GKE berücksichtigt PDB bis zu 60 Minuten).

Führen Sie den folgenden Befehl aus, um die aktuellen Knotenpools auf eine Strategie für ein Surge-Upgrade umzustellen.

gcloud container node-pools update default-pool \
--max-surge-upgrade=1 \
--max-unavailable-upgrade=0 \
--cluster=redis-test

Mit dieser Konfiguration (maxSurge=1 und maxUnavailable=0) kann einem Knotenpool bei einem Upgrade nur ein Surge-Knoten hinzugefügt werden, sodass nur ein Knoten gleichzeitig aktualisiert werden kann. Durch diese Einstellung wird der Neustart von Pods während eines Upgrades beschleunigt. Gleichzeitig erfolgt ein konservativer Fortschritt.

Weitere Informationen zur Konfiguration von Surge-Upgrades finden Sie unter Surge-Upgrades konfigurieren.

Prüfen Sie die aktuelle Knotenpoolkonfiguration:

   gcloud container node-pools describe default-pool \
   --cluster redis-test \
   --zone COMPUTE-ZONE

Weitere Informationen zum Aufrufen von Knotenpools finden Sie unter Knotenpools in einem Cluster ansehen.

Anwendung testen

In diesem Abschnitt verwenden Sie zwei Skripts: Ein Skript, das Anfragen an die Anwendung sendet, und ein Skript, mit dem die Erfolgsquote der Anfragen gemessen wird. Mit diesen Skripts können Sie messen, was geschieht, wenn Sie ein Upgrade des Clusters durchführen.

So erstellen Sie die Skripts:

1. Wechseln Sie in das Verzeichnis, das die Skripts enthält:

   cd
   cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
   

2. Rufen Sie das Script generate_load.sh auf, das eine QPS-Anfrage (Queries per Second, Abfragen pro Sekunde) an Ihre Anwendung sendet. Das Script speichert den HTTP-Antwortcode im aktuellen Verzeichnis in einer Datei mit dem Namen output. Der Wert von output wird im Skript verwendet, das Sie im nächsten Schritt erstellen.

   #!/bin/bash
   # Usage: ./generate_load.sh <IP> <QPS>
   
   IP=$1
   QPS=$2
   
   while true
     do for N in $(seq 1 $QPS)
       do curl -I -m 5 -s -w "%{http_code}\n" -o /dev/null http://${IP}/ >> output &
       done
     sleep 1
   done

3. Verweisen Sie auf das Script mit dem Namen print_error_rate.sh, das die Erfolgsquote auf Grundlage der von generate_load.sh generierten Ausgabe berechnet.

   #!/bin/bash
   # Usage: watch ./print_error_rate.sh
   
   TOTAL=$(cat output | wc -l);
   SUCCESS=$(grep "200" output |  wc -l);
   ERROR1=$(grep "000" output |  wc -l)
   ERROR2=$(grep "503" output |  wc -l)
   ERROR3=$(grep "500" output |  wc -l)
   SUCCESS_RATE=$(($SUCCESS * 100 / TOTAL))
   ERROR_RATE=$(($ERROR1 * 100 / TOTAL))
   ERROR_RATE_2=$(($ERROR2 * 100 / TOTAL))
   ERROR_RATE_3=$(($ERROR3 * 100 / TOTAL))
   echo "Success rate: $SUCCESS/$TOTAL (${SUCCESS_RATE}%)"
   echo "App network Error rate: $ERROR1/$TOTAL (${ERROR_RATE}%)"
   echo "Resource Error rate: $ERROR2/$TOTAL (${ERROR_RATE_2}%)"
   echo "Redis Error rate: $ERROR3/$TOTAL (${ERROR_RATE_3}%)"

4. Erteilen Sie sich selbst die Berechtigung zum Ausführen der Skripts:

   chmod u+x generate_load.sh print_error_rate.sh
   

5. Legen Sie eine Variable für die Anzahl der Abfragen pro Sekunde fest. Dieser Wert wird im Skript generate_load.sh als Variable für EXTERNAL_IP verwendet. Wir empfehlen Ihnen, den Wert auf 40 zu setzen.

   export QPS=40
   

6. Führen Sie das Skript generate_load.sh aus, um pro Sekunde eine Abfrage zu senden:

   ./generate_load.sh $IP $QPS 2>&1
   

7. Lassen Sie das Skript generate_load.sh laufen und öffnen Sie ein neues Terminal. Führen Sie im neuen Terminal das Skript print_error_rate.sh aus, um die Fehlerrate zu prüfen:

   cd
   cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
   watch ./print_error_rate.sh
   

   Bei den Abfragen pro Sekunde sollte eine Erfolgsquote von 100 % und eine Fehlerrate bei 0 % angezeigt werden.

8. Lassen Sie beide Skripts laufen und öffnen Sie als Vorbereitung für den nächsten Abschnitt ein drittes Terminal.

Cluster aktualisieren

Um den Cluster zu aktualisieren, führen Sie folgende Schritte aus:

1. Ermitteln Sie, welche GKE-Version der Cluster redis-test verwendet:

   V=$(gcloud container clusters describe redis-test | grep "version:" | sed "s/version: //")
   echo $V
   

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen: 1.22.9-gke.2000.

2. Rufen Sie eine Liste der verfügbaren Kubernetes-Versionen ab:

   gcloud container get-server-config
   

3. Gehen Sie in der Liste der Versionen zum Abschnitt validMasterVersions: und suchen Sie nach der Version redis-cluster, die Sie im vorherigen Schritt abgerufen haben. Kopieren Sie aus der Liste die Version, die sich unmittelbar über der Version redis-cluster befindet, um eine Versionsinkompatibilität zu vermeiden.

4. Führen Sie ein Upgrade der Steuerungsebene des Clusters auf die ausgewählte Version durch und geben Sie y ein, wenn Sie dazu aufgefordert werden:

   gcloud container clusters upgrade redis-test \
       --master \
       --cluster-version VERSION
   

   Ersetzen Sie VERSION durch die Version, die Sie im vorherigen Schritt aus der Liste ausgewählt haben.

   Das Upgrade der Steuerungsebene dauert einige Minuten.

5. Führen Sie ein Upgrade der Clusterknoten auf die ausgewählte Version durch und geben Sie y ein, wenn Sie dazu aufgefordert werden:

   gcloud container clusters upgrade redis-test \
       --cluster-version=VERSION \
       --node-pool=default-pool
   

   Ersetzen Sie VERSION durch die ausgewählte Version aus der Liste.

Unterbrechung von Arbeitslasten testen

In diesem Abschnitt testen Sie den Status Ihrer Anwendung und beobachten die Unterbrechung der Arbeitslast.

1. Kehren Sie zum Terminalfenster zurück, in dem ./print_error_rate.sh ausgeführt wird, und beobachten Sie, wie sich die Erfolgsquote während des Upgrades verändert hat. Sie sollten einen leichten Rückgang der Erfolgsquote und eine geringfügige Erhöhung bei der Fehlerrate des Anwendungsnetzwerks feststellen, da die Knoten heruntergefahren werden, um ein Upgrade durchzuführen.

   Im Feld Success rate sehen Sie, wie viele erfolgreiche Besuche auf der Website stattgefunden haben. Notieren Sie sich diesen Wert.

2. Beenden Sie beide Skripts, indem Sie CTRL+C in die entsprechenden Terminals eingeben.

3. Kehren Sie zur Website für Ihre Anwendung zurück. Geben Sie dazu im Browser deren IP-Adresse ein. Dies ist die externe IP-Adresse (EXTERNAL_IP), die Sie beim Bereitstellen der Redis-Clientanwendung kopiert haben.

4. Beobachten Sie die Anzahl der Besuche für Ihre Anwendung. Die angezeigte Zahl sollte diese sein:

   ORIGINAL_VISIT_NUMBER + SUCCESSFUL_VISIT_NUMBER

   Dabei ist ORIGINAL_VISIT_NUMBER die Zahl, die Sie im letzten Schritt beim Bereitstellen der Redis-Clientanwendung angegeben haben, und SUCCESSFUL_VISIT_NUMBER ist der Wert, den Sie im ersten Schritt dieses Abschnitts notiert haben.

Bereinigen

Nachdem Sie die Anleitung abgeschlossen haben, können Sie die erstellten Ressourcen bereinigen, damit sie keine Kontingente mehr nutzen und keine Gebühren mehr anfallen. In den folgenden Abschnitten erfahren Sie, wie Sie diese Ressourcen löschen oder deaktivieren.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten durch Löschen des für die Anleitung erstellten Projekts.

So löschen Sie das Projekt:

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Cluster löschen

Führen Sie den folgenden Befehl aus, um den für diese Anleitung erstellten Cluster zu löschen:

gcloud container clusters delete redis-test

Nächste Schritte

• Best Practices für das Upgrade von Clustern
• Clusterbenachrichtigungen festlegen
• Best Practices für GKE: Tag 2: Vorgänge
• Systemdiagnosen mit Prüfungen einrichten