Diese Seite wurde von der Cloud Translation API übersetzt.

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.

Ziele

Diese Anleitung umfasst die folgenden Schritte:

Erstellen Sie einen GKE-Cluster, der in einer Release-Version registriert ist.
Erstellen Sie einen Redis-Cluster in GKE.
Stellen Sie die Redis-Clientanwendung in GKE bereit.
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.
Testen Sie die Anwendung.
Aktualisieren Sie den Cluster.
Testen Sie die Unterbrechung der Arbeitslast.

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

Architekturaufbau

Kosten

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

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Neuen Nutzern von Google Cloud steht möglicherweise ein kostenloser Testzeitraum 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.

Hinweise

Projekt einrichten

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Roles required to create a project

To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Roles required to create a project

To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

Standardeinstellungen für die Google Cloud CLI festlegen

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

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

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:

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

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

Ersetzen Sie CONTROL_PLANE_LOCATION durch den Standort der Steuerungsebene Ihres Clusters in Compute Engine. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

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

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:

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.

Stellen Sie die ConfigMap bereit:
```
kubectl apply -f redis-configmap.yaml
```

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.

Stellen Sie das StatefulSet bereit:
```
kubectl apply -f redis-cluster.yaml
```
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
```

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

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:

Führen Sie das Skript aus:
```
chmod +x ./roles.sh
./roles.sh
```
Geben Sie yes ein, wenn Sie dazu aufgefordert werden.
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:

Wenden Sie das Deployment an:
```
kubectl apply -f app-deployment.yaml
```

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

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

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

So richten Sie das PDB ein:

Stellen Sie das PDB bereit:
```
kubectl apply -f pdb-minavailable.yaml
```
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.

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

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
```
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 \
--location CONTROL_PLANE_LOCATION \
--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 \
   --location CONTROL_PLANE_LOCATION

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:

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

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

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
```

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}%)"

Erteilen Sie sich selbst die Berechtigung zum Ausführen der Skripts:
```
chmod u+x generate_load.sh print_error_rate.sh
```
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
```
Führen Sie das Skript generate_load.sh aus, um pro Sekunde eine Abfrage zu senden:
```
./generate_load.sh $IP $QPS 2>&1
```
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.
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:

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.
Rufen Sie eine Liste der verfügbaren Kubernetes-Versionen ab:
```
gcloud container get-server-config
```
Gehen Sie in der Liste der Versionen zum Abschnitt validMasterVersions: und suchen Sie nach der Version redis-test, die Sie im vorherigen Schritt abgerufen haben. Um einen Verstoß gegen die Richtlinie zur Versionsinkompatibilität in GKE zu vermeiden, indem Sie eine mit den Knoten inkompatible Version auswählen, kopieren Sie die Version aus der Liste, die unmittelbar vor der Version redis-test aufgeführt ist.
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.
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.

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.
Beenden Sie beide Skripts, indem Sie CTRL+C in die entsprechenden Terminals eingeben.
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.
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, zum Beispiel eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt 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.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

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