Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

פריסת אשכול Redis ב-GKE

רגילה

במדריך הזה מפורטות שיטות מומלצות ליצירת אפליקציה עם שמירת מצב ולשדרוג אשכול Google Kubernetes Engine‏ (GKE) שבו האפליקציה פועלת. במדריך הזה נעשה שימוש ב-Redis כדוגמה לפריסה של אפליקציה עם שמירת מצב, אבל אותם מושגים רלוונטיים גם לסוגים אחרים של אפליקציות עם שמירת מצב שנפרסות ב-GKE.

מטרות

במדריך הזה מוסבר איך:

יוצרים אשכול GKE שרשום לערוץ הפצה.
יוצרים אשכול Redis ב-GKE.
פורסים את אפליקציית הלקוח של Redis ב-GKE.
כדאי לפעול לפי השיטות המומלצות הבאות לשדרוג מאגר צמתים:
1. מגדירים את התקציב לשיבוש Pod‏ (PDB).
2. מגדירים את חלון זמן לתחזוקה וההחרגות.
3. מגדירים את שיטת השדרוג של הצומת לשדרוג בהדרגה או לשדרוג כחול-ירוק.
בודקים את האפליקציה.
משדרגים את האשכול.
בדיקת שיבוש בעומס העבודה.

התרשים הבא מציג סקירה כללית של ארכיטקטורת האשכול במדריך הזה:

דיאגרמת ארכיטקטורה

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

לפני שמתחילים

הגדרת הפרויקט

נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

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

הגדרת ברירות מחדל ל-Google Cloud CLI

במסוף Google Cloud , מפעילים מכונת Cloud Shell:
פתיחת Cloud Shell

מורידים את קוד המקור של האפליקציה לדוגמה:

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

מגדירים את משתני הסביבה שמוגדרים כברירת מחדל:
```
 gcloud config set project PROJECT-ID
 gcloud config set compute/zone COMPUTE-ZONE
```
מחליפים את הערכים הבאים:
- ‫PROJECT_ID: מזהה הפרויקט ב-Google Cloud.
- ‫COMPUTE_ZONE: אזור Compute Engine.

יצירת אשכול GKE שרשום לערוץ הפצה

כדי ליצור את אשכול GKE, מבצעים את השלבים הבאים:

יוצרים אשכול בשם redis-test עם שלושה צמתים:
```
gcloud container clusters create redis-test \
    --location CONTROL_PLANE_LOCATION \
    --num-nodes=3 \
    --release-channel regular
```
מחליפים את CONTROL_PLANE_LOCATION במיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

אחרי שיוצרים את האשכול, אמור להופיע פלט שדומה לדוגמה הבאה:
```
  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
```
מגדירים את kubectl לתקשורת עם האשכול:
```
gcloud container clusters get-credentials redis-test
```

יצירת אשכול Redis ב-GKE

בקטע הזה מוסיפים Redis Cluster על גבי GKE Cluster שיצרתם קודם, באמצעות פריסה של ConfigMap,‏ StatefulSet ו-headless Service.

כדי ליצור אשכול Redis:

מעיינים בקובץ ConfigMap ‏ (redis-configmap.yaml) שבו מאוחסנת ההגדרה של Redis. בקטע הקוד הבא מוצגים הסקריפטים של בקשת בדיקת התקינות של המוכנות ובקשת בדיקת התקינות של מצב הפעילות.
```
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
```
הסקריפטים readiness.sh ו-liveness.sh משתמשים ב-redis-cli ping כדי לבדוק אם שרת Redis פועל או לא. אם התוצאה היא PONG, שרת Redis פועל. הסקריפטים האלה ישמשו בredis-cluster.yaml.

מידע נוסף על פרמטרי Redis ב-ConfigMap הזה זמין בקטע בנושא פרמטרים של הגדרת Redis Cluster במדריך בנושא Redis Cluster.
פורסים את ה-ConfigMap:
```
kubectl apply -f redis-configmap.yaml
```
אפשר לעיין בקטע הקוד של StatefulSet (redis-cluster.yaml) שבהמשך, שבו מוצג השימוש בבקשה לבדיקת תקינות של מוכנות ובבקשה לבדיקת תקינות של מצב פעילות.

מידע על הגדרת בדיקות ב-Kubernetes זמין במאמר הגדרת בדיקות.
```
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"]
```
מומלץ מאוד להשתמש בבדיקות מוכנות ובבדיקות פעילות כשמשדרגים מאגרי צמתים. כך מוודאים שה-Pods מוכנים במהלך השדרוג.
פורסים את ה-StatefulSet:
```
kubectl apply -f redis-cluster.yaml
```
השירות חסר הראש שנקרא redis-service.yaml הוא לחיבור של צמתי Redis. השדה clusterIP מוגדר לערך None כדי ליצור שירות ללא GUI.

פורסים את השירות:
```
kubectl apply -f redis-service.yaml
```

ממתינים כשתי דקות ומוודאים שכל ה-Pods פועלים באמצעות הפקודה הבאה:

kubectl get pods

הפלט אמור להיראות כך:

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

מריצים את הפקודה הבאה כדי לוודא שהנפחים הקבועים נוצרו:

kubectl get pv

הפלט אמור להיראות כך:

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

בפלט הזה, HASH מייצג גיבוב שמצורף לכל שם של נפח אחסון קבוע.

הקצאת תפקידים ל-Redis Cluster

אחרי שמסיימים את ההגדרה, מקצים תפקידים ל-Redis Cluster.

הסקריפט הבא מקבל את כתובות ה-IP של ה-Pod, ואז מקצה את התפקידים leader ו-follower על ידי העברת כל אחת מכתובות ה-IP של ה-Pod לפקודה:

#!/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

כדי להקצות תפקידים לאשכול Redis, צריך לבצע את השלבים הבאים:

מריצים את הסקריפט:
```
chmod +x ./roles.sh
./roles.sh
```
מקלידים yes כשמוצגת בקשה.
מתחברים לצומת Redis כדי לבדוק את התפקיד שלו. לדוגמה, כדי לוודא של-redis-0 יש תפקיד מוביל, מריצים את הפקודה הבאה:
```
kubectl exec -it redis-0 -- redis-cli role
```
הפלט אמור להיראות כך:
```
1) "master"
2) (integer) 574
3) 1) 1) "10.28.2.3"
       2) "6379"
       3) "574"
```

פריסת אפליקציית לקוח Redis

כדי לפרוס את האפליקציה לאשכול GKE שיצרתם, צריך להגדיר Deployment לאפליקציה. הקובץ בשם app-deployment.yaml מכיל את הגדרת הפריסה של האפליקציה.

מידע נוסף על הבדיקות ועל כללי ההתאמה של ה-Pod שמשמשים בפריסה הזו זמין במאמר שיטות מומלצות ל-GKE: תכנון ובנייה של אשכולים עם זמינות גבוהה.

כדי ליצור את הפריסה, מבצעים את השלבים הבאים:

מחילים את הפריסה:
```
kubectl apply -f app-deployment.yaml
```

חשיפת האפליקציה דרך מאזן עומסים:

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

מחכים בערך דקה ומריצים את הפקודה הבאה כדי לאחזר את כתובת ה-IP החיצונית של האפליקציה:
```
kubectl get service
```
מהפלט, מעתיקים את הערך שמופיע בעמודה hello-web's EXTERNAL-IP:
```
NAME             TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)              AGE
hello-web        LoadBalancer   10.13.10.55   EXTERNAL_IP   80:30703/TCP         166m
```
כדי לוודא שהאפליקציה פועלת, מדביקים את EXTERNAL_IP בדפדפן האינטרנט. הפלט אמור להיראות כך:
```
I have been hit [1] times since deployment!
```
רושמים את מספר הביקור. צריך להשתמש בו בקטע בדיקת השיבוש של האפליקציה.
מגדירים משתנה עבור EXTERNAL_IP שהעתקתם. משתמשים בערך הזה כשיוצרים סקריפטים לבדיקת האפליקציה, כמו שמוסבר בקטע הבא:
```
export IP=EXTERNAL_IP
```

שיטות מומלצות להגדרת שדרוגים של מאגרי צמתים

כדי לבצע אופטימיזציה לזמינות טובה יותר במהלך שדרוגים של מאגרי צמתים, מומלץ לפעול לפי השיטות המומלצות הבאות לאפליקציות עם שמירת מצב.

הגדרת תקציב לשיבוש Pod‏ (PDB)

כדי להגביל את מספר ה-Pods המשוכפלים שמושבתים בו-זמנית במהלך שיבוש רצוני, צריך ליצור תקציב לשיבוש Pod. זה שימושי באפליקציות עם מצב (stateful), שבהן צריך להגיע לקוורום כדי שמספר הרפליקות יהיה זמין במהלך שדרוג.

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

בהגדרת PDB:

‫app מציין לאיזו אפליקציה חל ה-PDB הזה.
‫minAvailable מגדיר את המספר המינימלי של ה-Pods שיהיו זמינים במהלך שיבוש. אפשר להזין ערך או אחוז (למשל, 30%).
‫maxUnavailable מגדיר את המספר המקסימלי של פודים שלא יכולים להיות זמינים במהלך שיבוש. אפשר להזין גם ערך או אחוז.

כדי להגדיר את PDB, מבצעים את השלבים הבאים:

פורסים את PDB:
```
kubectl apply -f pdb-minavailable.yaml
```
מוודאים שנוצר PDB:
```
kubectl get pdb
```

הגדרת חלונות התחזוקה וההחרגות

שדרוגים אוטומטיים של צמתים מייעלים את תהליך השדרוג ושומרים על הצמתים באשכול מעודכנים כשרמת הבקרה משודרגת בשבילכם. התכונה הזו מופעלת כברירת מחדל. מידע נוסף זמין במאמר בנושא שדרוג אוטומטי של צמתים.

כדי להגדיר מסגרות זמן ולשלוט מתי אפשר לבצע תחזוקה באשכולות GKE ומתי אי אפשר, משתמשים בחלונות תחזוקה ובאי הכללות של תחזוקה:

הגדרת חלון זמן לתחזוקה שמתחיל ב-19 באוגוסט 2022 בשעה 2:00 (UTC) ומסתיים ארבע שעות לאחר מכן. חלון זמן לתחזוקה זה פועל מדי יום. במהלך פרק הזמן הזה, מותר לבצע תחזוקה אוטומטית.
```
gcloud container clusters update redis-test \
   --maintenance-window-start 2022-08-19T02:00:00Z \
   --maintenance-window-duration 4H \
   --maintenance-window-recurrence FREQ=DAILY
```
הגדרת חלון החרגה שמונע תחזוקה במהלך חופשת השנה החדשה. החרגת התחזוקה הזו משתמשת בהיקף no_upgrades. במהלך התקופה הזו, אסור לבצע תחזוקה אוטומטית מכל סוג שהוא. מידע נוסף זמין במאמר בנושא הגדרת היקף התחזוקה להחרגה.
```
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
```
בודקים שחלון זמן לתחזוקה וההחרגות הוחלו. מסתכלים בקטע maintenancePolicy:
```
gcloud container clusters describe redis-test
```

מידע נוסף זמין במאמר הגדרת חלונות תחזוקה והחרגות.

הגדרת אסטרטגיית שדרוג של צומת

יש שתי אסטרטגיות לשדרוג צמתים שבהן אפשר להשתמש במאגרי הצמתים באשכול GKE: שדרוגים מסוג Blue-green ושדרוגים מסוג Surge. מידע נוסף זמין במאמר בנושא שיטות לשדרוג Node.

שדרוגים כחול-ירוק

כדאי לבחור בשדרוגים כחול-ירוק אם עומסי העבודה פחות סובלניים להפרעות, ועלייה זמנית בעלויות בגלל שימוש גבוה יותר במשאבים היא דבר מקובל.

מריצים את הפקודה הבאה כדי לשנות את מאגרי הצמתים הנוכחיים לאסטרטגיית שדרוג blue-green.

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

במדריך הזה, משך ההרצה של מאגר הצמתים מוגדר לשתי דקות כדי לחסוך זמן במהלך שלב ההרצה של מאגר הצמתים. השלב הזה משמש לאימות תקינות עומס העבודה אחרי שמתבצע ניקוז של הצמתים במאגר הכחול. מומלץ להגדיר את משך ההרצה של מאגר הצמתים לשעה אחת (3,600 שניות) או למשך זמן שמתאים ביותר לאפליקציה.

מידע נוסף על ניהול הקצאת פודים זמין במאמרים פריסת פוד למאגר צמתים ספציפי ופריסת שירותים למאגרי צמתים ספציפיים.

מידע נוסף על הגדרת שדרוגים מסוג blue-green זמין במאמר הגדרת שדרוגים מסוג blue-green.

שדרוגים של Surge

כדאי לבחור בשדרוגים מהירים אם אופטימיזציה של העלויות חשובה לכם, ואם עומסי העבודה יכולים לעמוד בהשבתה מסודרת תוך פחות מ-60 דקות (GKE מכבד את ה-PDB עד 60 דקות).

מריצים את הפקודה הבאה כדי לשנות את מאגרי הצמתים הנוכחיים לאסטרטגיית שדרוג עם שימוש מוגבר במשאבים.

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

בהגדרה הזו (maxSurge=1 ו-maxUnavailable=0), אפשר להוסיף רק צומת אחד של עלייה פתאומית בביקוש למאגר הצמתים במהלך שדרוג, ולכן אפשר לשדרג רק צומת אחד בכל פעם. ההגדרה הזו מאיצה את ההפעלה מחדש של ה-Pod במהלך שדרוגים, תוך שמירה על התקדמות מדורגת.

מידע נוסף על הגדרת שדרוגים בתקופות של ביקוש גבוה זמין במאמר הגדרת שדרוגים בתקופות של ביקוש גבוה.

בודקים את ההגדרה הנוכחית של מאגר הצמתים:

   gcloud container node-pools describe default-pool \
   --cluster redis-test \
   --location CONTROL_PLANE_LOCATION

מידע נוסף על הצגת מאגרי צמתים זמין במאמר הצגת מאגרי צמתים באשכול.

בדיקת האפליקציה

בקטע הזה משתמשים בשני סקריפטים: אחד ששולח בקשות לאפליקציה, ואחד שמודד את שיעור ההצלחה של הבקשות. הסקריפטים האלה משמשים למדידת הפעולות שמתבצעות כשמשדרגים את האשכול.

כדי ליצור את הסקריפטים:

עוברים לספרייה שמכילה את הסקריפטים:

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

הפניה לסקריפט בשם generate_load.sh ששולח בקשה של שאילתות לשנייה (QPS) לאפליקציה. הסקריפט שומר את קוד התגובה של ה-HTTP בספרייה הנוכחית בקובץ בשם output. הערך של output משמש בסקריפט שיוצרים בשלב הבא.
```
#!/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
```

אפשר לעיין בסקריפט שנקרא print_error_rate.sh שבו מחושב שיעור ההצלחה על סמך הפלט שנוצר על ידי generate_load.sh.

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

נותנים לעצמכם הרשאה להריץ את הסקריפטים:
```
chmod u+x generate_load.sh print_error_rate.sh
```
מגדירים משתנה למספר השאילתות לשנייה. הערך הזה משמש בסקריפט generate_load.sh, כמו המשתנה שהגדרתם עבור EXTERNAL_IP. מומלץ להגדיר ערך של 40.
```
export QPS=40
```
מריצים את הסקריפט generate_load.sh כדי להתחיל לשלוח QPS:
```
./generate_load.sh $IP $QPS 2>&1
```
משאירים את סקריפט generate_load.sh פועל ופותחים חלון חדש של Terminal. בטרמינל החדש, מריצים את הסקריפט print_error_rate.sh כדי לבדוק את שיעור השגיאות:
```
cd
cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
watch ./print_error_rate.sh
```
אמורים לראות שיעור הצלחה של 100% ושיעור שגיאות של 0% כשמתבצעות בקשות QPS.
משאירים את שני הסקריפטים פועלים ופותחים טרמינל שלישי כדי להתכונן לקטע הבא.

שדרוג האשכול

כדי לשדרג את האשכול, מבצעים את השלבים הבאים:

כדי לברר באיזו גרסת GKE משתמש אשכול redis-test:
```
V=$(gcloud container clusters describe redis-test | grep "version:" | sed "s/version: //")
echo $V
```
הפלט שיוצג אמור להיות דומה לדוגמה הבאה: 1.22.9-gke.2000.
אחזור רשימה של גרסאות Kubernetes זמינות:
```
gcloud container get-server-config
```
ברשימת הגרסאות, מחפשים את הקטע validMasterVersions: ואת הגרסה redis-test שאותרה בשלב הקודם. כדי להימנע מהפרה של מדיניות ההטיה של גרסאות GKE על ידי בחירת גרסה שלא תואמת לצמתים, מעתיקים את הגרסה מהרשימה שמופיעה מיד לפני גרסה redis-test.
משדרגים את רמת הבקרה של האשכול לגרסה שבחרתם ומקלידים y כשהמערכת מבקשת:
```
gcloud container clusters upgrade redis-test \
    --master \
    --cluster-version VERSION
```
מחליפים את VERSION בגרסה שבחרתם מהרשימה בשלב הקודם.

שדרוג מישור הבקרה נמשך כמה דקות.
משדרגים את הצמתים של האשכול לגרסה שבחרתם ומקלידים y כאשר מוצגת ההנחיה:
```
gcloud container clusters upgrade redis-test \
    --cluster-version=VERSION \
    --node-pool=default-pool
```
מחליפים את VERSION בגרסה שבחרתם מהרשימה.

בדיקת שיבוש בעומס העבודה

בקטע הזה, בודקים את הסטטוס של האפליקציה ומתבוננים בשיבוש של עומס העבודה.

חוזרים לחלון הטרמינל שבו פועלת הפקודה ./print_error_rate.sh ומתבוננים בשינוי שחל בשיעור ההצלחה במהלך השדרוג. אפשר לצפות לירידה קלה בשיעור ההצלחה ולעלייה קלה בשיעור השגיאות ברשת של האפליקציה בזמן שהצמתים מושבתים לצורך שדרוג.

בשדה Success rate תוכלו לראות כמה ביקורים באתר בוצעו בהצלחה. חשוב לרשום את הערך הזה.
כדי להפסיק את ההרצה של שני הסקריפטים, מזינים CTRL+C במסופים הרלוונטיים.
חוזרים לאתר של האפליקציה על ידי הזנת כתובת ה-IP שלה (זוהי EXTERNAL_IP שהעתקתם במהלך השלב פריסת אפליקציית הלקוח של Redis) בדפדפן.
בודקים את מספר הביקור באפליקציה. המספר שמופיע צריך להיות שווה ל:

ORIGINAL_VISIT_NUMBER + SUCCESSFUL_VISIT_NUMBER

כאשר ORIGINAL_VISIT_NUMBER הוא המספר שרשמתם בשלב האחרון של פריסת אפליקציית לקוח Redis ו-SUCCESSFUL_VISIT_NUMBER הוא הערך שרשמתם בשלב הראשון של הקטע הזה.

הסרת המשאבים

אחרי שמסיימים את המדריך, אפשר למחוק את המשאבים שנוצרו, כדי שהם יפסיקו להשתמש במכסה ולצבור חיובים. בסעיפים הבאים מוסבר איך למחוק או להשבית את המשאבים האלו.

מחיקת הפרויקט

הדרך הקלה ביותר לבטל את החיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך הזה.

כדי למחוק את הפרויקט:

זהירות: כשמוחקים פרויקט:

התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

אם אתם מתכננים להיעזר בכמה ארכיטקטורות, מדריכים או מדריכים למתחילים, מומלץ להשתמש שוב באותו פרויקט כדי לא לחרוג ממכסות הפרויקטים.

במסוף Google Cloud , נכנסים לדף Manage resources.
כניסה לדף Manage resources
ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת האשכול

כדי למחוק את האשכול שיצרתם במדריך הזה, מריצים את הפקודה הבאה:

gcloud container clusters delete redis-test