‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שדרוג סביבת GKE מרובת אשכולות באמצעות Multi Cluster Ingress

Last reviewed 2022-12-15 UTC

טייס אוטומטי רגילה

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

במאמר בחירת ה-API לאיזון עומסים בכמה אשכולות ב-GKE תוכלו לקרוא השוואה מפורטת בין Multi Cluster Ingress ‏ (MCI),‏ Multi-cluster Gateway ‏(MCG) ומאזן עומסים עם קבוצות עצמאיות של נקודות קצה ברשת (LB ו-NEGs עצמאיות).

המסמך הזה מיועד Google Cloud לאדמינים שאחראים על תחזוקת צי של אשכולות GKE.

מומלץ לשדרג אוטומטית את אשכולות GKE. שדרוג אוטומטי הוא דרך מנוהלת לחלוטין לעדכן אוטומטית את האשכולות (מישור הבקרה והצמתים) לפי לוח זמנים לפרסום שנקבע על ידיGoogle Cloud. הפעולה הזו לא דורשת התערבות של המפעיל. עם זאת, אם אתם רוצים יותר שליטה על האופן שבו האשכולות משודרגים ועל מועד השדרוג, במדריך הזה נסביר איך לשדרג כמה אשכולות שבהם האפליקציות פועלות בכל האשכולות. לאחר מכן, הוא משתמש ב-Multi Cluster Ingress כדי לרוקן אשכול אחד בכל פעם לפני השדרוג.

ארכיטקטורה

המדריך הזה משתמש בארכיטקטורה הבאה. יש שלושה אשכולות בסך הכול: שני אשכולות (blue ו-green) פועלים כאשכולות זהים עם אותה אפליקציה שמוצבת בהם, ואשכול אחד (ingress-config) פועל כאשכול של מישור הבקרה שמגדיר את Multi Cluster Ingress. במדריך הזה תפרסו אפליקציה לדוגמה בשני אשכולות של אפליקציות (אשכולות blue ו-green).

ארכיטקטורה של שני אשכולות זהים ואשכול אחד של מישור בקרה.

מטרות

יוצרים שלושה אשכולות GKE ורושמים אותם כ-fleet.
מגדירים אשכול GKE אחד (ingress-config) כאשכול ההגדרות המרכזי.
פורסים אפליקציה לדוגמה באשכולות GKE האחרים.
מגדירים Multi Cluster Ingress כדי לשלוח תנועת לקוחות לאפליקציה שפועלת בשני אשכולות האפליקציות.
מגדירים מחולל עומסים לאפליקציה ומגדירים מעקב.
מסירים (מרוקנים) אשכול אפליקציות אחד מ-Ingress מרובה האשכולות ומשדרגים את האשכול המרוקן.
העברת תנועה חזרה לאשכול המשודרג באמצעות Multi Cluster Ingress.

עלויות

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

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

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

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

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

כדי לבצע את ההדרכה הזו, צריך להגדיר Multi Cluster Ingress כך שההגדרות הבאות יהיו מוגדרות:
- שני אשכולות או יותר עם אותן אפליקציות, כמו מרחבי שמות, פריסות ושירותים, שפועלים בכל האשכולות.
- השדרוג האוטומטי מושבת בכל האשכולות.
- אשכולות הם אשכולות מקוריים של VPC שמשתמשים בטווחי כתובות IP של כינויים
- להפעיל איזון עומסים ב-HTTP (מופעל כברירת מחדל).
- הערך של gcloud --version חייב להיות 369 ומעלה. שלבי הרישום של אשכול GKE תלויים בגרסה הזו או בגרסה חדשה יותר.
בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
- יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.

כניסה לדף לבחירת הפרויקט
מוודאים שהחיוב מופעל בפרויקט Google Cloud .
במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

מגדירים את פרויקט ברירת המחדל:

export PROJECT=$(gcloud info --format='value(config.project)')
gcloud config set project ${PROJECT}

מפעילים את ממשקי ה-API של GKE,‏ Hub ו-multiclusteringress:

gcloud services enable container.googleapis.com \
                       gkehub.googleapis.com \
                       multiclusteringress.googleapis.com \
                       multiclusterservicediscovery.googleapis.com

הגדרת הסביבה

ב-Cloud Shell, משכפלים את המאגר כדי לקבל את הקבצים של המדריך הזה:
```
cd ${HOME}
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
```

יוצרים ספרייה בשם WORKDIR:

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

יצירה ורישום של אשכולות GKE ב-Hub

בקטע הזה יוצרים שלושה אשכולות GKE ורושמים אותם ב-GKE Hub.

יצירת אשכולות GKE

יוצרים שלושה אשכולות GKE ב-Cloud Shell:

gcloud container clusters create ingress-config --location us-west1-a \
--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 \
--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 \
--no-enable-autoupgrade --enable-ip-alias \
--workload-pool=${PROJECT}.svc.id.goog --quiet

לצורך המדריך הזה, יוצרים את האשכולות באזור אחד, בשלושה אזורים שונים: us-west1-a,‏ us-west1-b ו-us-west1-c. מידע נוסף על אזורים ותחומים זמין במאמר מיקום גיאוגרפי ואזורים.

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

gcloud container clusters list

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

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

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

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}

משתמשים בקובץ kubeconfig כדי ליצור אימות לאשכולות על ידי יצירת משתמש והקשר לכל אשכול. אחרי שיוצרים את הקובץ kubeconfig, אפשר לעבור במהירות בין הקלאסטרים.

מוודאים שיש שלושה אשכולות בקובץ kubeconfig:

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

הפלט שיתקבל:

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

מקבלים את ההקשר של שלושת האשכולות לשימוש מאוחר יותר:

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

הפלט שיתקבל:

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 ל-Fleet

רישום האשכולות לצי מאפשר לכם להפעיל את אשכולות Kubernetes בסביבות היברידיות. אשכולות שרשומים ל-fleet יכולים להשתמש בתכונות מתקדמות של GKE, כמו Multi Cluster Ingress. כדי לרשום אשכול GKE ל-fleet, אתם יכולים להשתמש ישירות בחשבון שירות של Google Cloud, או להשתמש בגישה המומלצת של איחוד זהויות של עומסי עבודה ל-GKE, שמאפשרת לחשבון שירות של Kubernetes באשכול GKE לפעול כחשבון שירות של ניהול זהויות והרשאות גישה (IAM).

רושמים את שלושת האשכולות כ-Fleet:

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

מוודאים שהאשכולות רשומים:

gcloud container fleet memberships list

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

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

מגדירים את אשכול ingress-config כאשכול ההגדרות של Multi Cluster Ingress על ידי הפעלת התכונה multiclusteringress דרך Hub:
```
gcloud container fleet ingress enable --config-membership=ingress-config
```
הפקודה שלמעלה מוסיפה את MulticlusterIngress ואת MulticlusterService CRD (הגדרות משאבים בהתאמה אישית) לאשכול ingress-config. השלמת הפקודה הזו נמשכת כמה דקות. מחכים לפני שממשיכים לשלב הבא.

מוודאים שאשכול ingress-cluster הוגדר בהצלחה ל-Multi Cluster Ingress:

watch gcloud container fleet ingress describe

ממתינים עד שהפלט ייראה כך:

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'

כדי לצאת מהפקודה watch, מקישים על Control+C.

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

ב-Cloud Shell, פורסים את אפליקציית הדוגמה whereami באשכולות blue ו-green:

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

מחכים כמה דקות ומוודאים שלכל ה-Pods באשכולות blue ו-green יש סטטוס Running:

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

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

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

בקטע הזה יוצרים Ingress מרובה אשכולות ששולח תנועה לאפליקציה שפועלת באשכולות blue ו-green. משתמשים ב-Cloud Load Balancing כדי ליצור מאזן עומסים שמשתמש באפליקציית whereami גם באשכולות blue וגם באשכולות green כבק-אנד. כדי ליצור את מאזן העומסים, צריך שני משאבים: MultiClusterIngress ומשאב אחד או יותר של MultiClusterServices. האובייקטים MultiClusterIngress ו-MultiClusterService הם אנלוגיים מרובי-אשכולות למשאבי ה-Ingress והשירות הקיימים של Kubernetes שמשמשים בהקשר של אשכול יחיד.

ב-Cloud Shell, פורסים את המשאב MulticlusterIngress לאשכול ingress-config:

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

הפלט שיתקבל:

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

פורסים את המשאב MulticlusterService באשכול ingress-config:

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

הפלט שיתקבל:

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

כדי להשוות בין שני המשאבים:
- בודקים את המשאב MulticlusterIngress:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusteringress -o yaml
```
  הפלט מכיל את הפרטים הבאים:
```
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080
```
  המשאב MulticlusterIngress דומה למשאב Kubernetes Ingress, אלא שהמפרט serviceName מפנה למשאב MulticlusterService.
- בודקים את המשאב MulticlusterService:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice -o yaml
```
  הפלט מכיל את הפרטים הבאים:
```
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
```
  המשאב MulticlusterService דומה למשאב Kubernetes Service, אבל יש לו מפרט clusters. הערך clusters הוא רשימת האשכולות הרשומים שבהם נוצר המשאב MulticlusterService.
- מוודאים שמשאב MulticlusterIngress יצר מאזן עומסים עם שירות קצה עורפי שמפנה למשאב MulticlusterService:
```
watch kubectl --context ${INGRESS_CONFIG_CLUSTER} \
      get multiclusteringress -o jsonpath="{.items[].status.VIP}"
```
  התהליך עשוי להימשך עד 10 דקות. מחכים עד שהפלט יהיה דומה לזה:
```
34.107.246.9
```
  כדי לצאת מהפקודה watch, לוחצים על Control+C.

ב-Cloud Shell, מאתרים את ה-VIP של Cloud Load Balancing:

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

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

34.107.246.9

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

curl ${GCLB_VIP}

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

{
  "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"
}

מריצים את הפקודה curl שוב ושוב. שימו לב שהבקשות מאוזנות בעומס בין האפליקציה whereami שנפרסה בשני אשכולות, blue ו-green.

הגדרת מחולל העומסים

בקטע הזה מגדירים שירות loadgenerator שיוצר תנועת לקוחות ל-VIP של Cloud Load Balancing. קודם כל, התנועה נשלחת לאשכולות blue ו-green כי המשאב MulticlusterService מוגדר לשליחת תנועה לשני האשכולות. בהמשך, מגדירים את MulticlusterServiceהמשאב לשליחת תנועה לאשכול יחיד.

מגדירים את קובץ המניפסט loadgenerator כדי לשלוח תעבורת לקוחות אל Cloud Load Balancing:
```
TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}
```

פורסים את loadgenerator באשכול ingress-config:

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

מוודאים שבכל ה-Pods של loadgenerator באשכול ingress-config הסטטוס הוא Running:

kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods

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

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

אם לאף אחד מה-Pods אין סטטוס של Running, צריך להמתין כמה דקות ואז להריץ את הפקודה שוב.

מעקב אחר התנועה

בקטע הזה, תנטרו את התעבורה לאפליקציית whereami באמצעות מסוףGoogle Cloud .

בקטע הקודם הגדרתם פריסה של loadgenerator שמדמה תנועת לקוחות על ידי גישה לאפליקציית whereami דרך ה-VIP של Cloud Load Balancing. אפשר לעקוב אחרי המדדים האלה דרך מסוףGoogle Cloud . קודם מגדירים את המעקב כדי שאפשר יהיה לעקוב אחרי אשכולות בזמן ההוצאה שלהם משימוש לצורך שדרוגים (כפי שמתואר בקטע הבא).

יוצרים מרכז בקרה להצגת התנועה שמגיעה ל-Multi Cluster Ingress:

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

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

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

מדדים מ-Cloud Load Balancing זמינים במסוףGoogle Cloud . יוצרים את כתובת ה-URL:

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

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

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

בדפדפן, עוברים לכתובת ה-URL שנוצרה על ידי הפקודה הקודמת.

התנועה לאפליקציית הדוגמה מגיעה ממחולל העומסים אל שני האשכולות blue ו-green (כפי שמצוין בשני האזורים שבהם נמצאים האשכולות). בתרשים המדדים של ציר הזמן מוצגת התנועה שעוברת לשני הקצוות העורפיים.הערכים שמוצגים כשמעבירים את העכבר מעל k8s1- מציינים שקבוצות נקודות הקצה ברשת (NEG) של שני הקצוות הקדמיים MulticlusterServices פועלות באשכולות blue ו-green.

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

הוצאת צומתי עבודה (drain) ושדרוג של אשכול `blue`

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

כדי לרוקן את האשכול blue, מעדכנים את המשאב MulticlusterService באשכול ingress-cluster ומסירים את האשכול blue מהמפרט של clusters.

לרוקן את האוסף הכחול

ב-Cloud Shell, מעדכנים את המשאב MulticlusterService באשכול ingress-config:

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

מוודאים שרק אשכול green מופיע במפרט clusters:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
        -o json | jq '.items[].spec.clusters'
```
הפלט שיתקבל:
```
[
  {
    "link": "us-west1-c/green"
  }
]
```
רק האשכול green מופיע במפרט של clusters, ולכן רק האשכול green נמצא במאגר איזון העומסים.
אפשר לראות את המדדים של Cloud Load Balancing במסוףGoogle Cloud . יוצרים את כתובת ה-URL:
```
echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
```
בדפדפן, עוברים לכתובת ה-URL שנוצרה מהפקודה הקודמת.

התרשים מראה שרק אשכול green מקבל תנועה.

שדרוג אשכול `blue`

עכשיו, כשלא מתקבלת יותר תעבורת נתונים של לקוחות באשכול blue, אפשר לשדרג את האשכול (מישור הבקרה והצמתים).

ב-Cloud Shell, בודקים את הגרסה הנוכחית של האשכולות:

gcloud container clusters list

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

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

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

כדי לקבל את רשימת הגרסאות הזמינות של MasterVersions באזור:

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

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

[
  "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"
]

כדי לקבל רשימה של גרסאות NodeVersions שזמינות באזור:

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

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

[
  "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"
]

מגדירים משתנה סביבה לגרסה של MasterVersion ושל NodeVersion שמופיעה ברשימות MasterVersions וNodeVersions, ושגבוהה מהגרסה הנוכחית של אשכול blue, לדוגמה:
```
export UPGRADE_VERSION="1.22.10-gke.600"
```
במדריך הזה נעשה שימוש בגרסה 1.22.10-gke.600. יכול להיות שגרסאות האשכולות שלכם יהיו שונות, בהתאם לגרסאות שזמינות כשתסיימו את המדריך הזה. מידע נוסף על שדרוג זמין במאמר בנושא שדרוג אשכולות ומאגרי צמתים.

הערה: מומלץ לא לדלג על גרסאות משניות של אשכולות כדי למנוע בעיות פוטנציאליות של חוסר תאימות במישור הבקרה או בצומת. למידע נוסף, קראו את המאמר האם אפשר לדלג על כמה גרסאות של GKE במהלך שדרוג של אשכול?
משדרגים את הצומת control plane באשכול blue:
```
gcloud container clusters upgrade blue \
    --location us-west1-b --master --cluster-version ${UPGRADE_VERSION}
```
כדי לאשר את השדרוג, לוחצים על Y.

התהליך הזה נמשך כמה דקות. צריך לחכות שהשדרוג יסתיים לפני שממשיכים.

אחרי שהעדכון מסתיים, הפלט הוא:
```
Updated
[https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
```

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

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

כדי לאשר את העדכון, לוחצים על Y.

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

אחרי שהשדרוג מסתיים, הפלט הוא:

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

מוודאים ששודרג האשכול blue:

gcloud container clusters list

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

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

הוספת האשכול `blue` בחזרה למאגר איזון העומסים

בסעיף הזה מוסיפים את אשכול blue בחזרה למאגר של מאזן העומסים.

ב-Cloud Shell, מוודאים שפריסת האפליקציה פועלת באשכול blue לפני שמוסיפים אותה בחזרה למאגר איזון העומסים:
```
kubectl --context ${BLUE_CLUSTER} get pods
```
הפלט אמור להיראות כך:
```
NAME                                   READY   STATUS    RESTARTS   AGE
whereami-deployment-756c7dc74c-xdnb6   1/1     Running   0          17m
```
מעדכנים את משאב MutliclusterService כדי להוסיף את אשכול blue בחזרה למאגר איזון העומסים:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} apply \
        -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml
```

מוודאים שיש לכם אשכולות blue ו-green במפרט האשכולות:

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

הפלט שיתקבל:

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

אשכולות blue ו-green מופיעים עכשיו במפרט clusters.

מדדים מ-Cloud Load Balancing זמינים במסוףGoogle Cloud . יוצרים את כתובת ה-URL:

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

בדפדפן, עוברים לכתובת ה-URL שנוצרה על ידי הפקודה הקודמת.

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

הערה: יכול להיות שיחלפו כמה דקות עד שתנועת הגולשים תתאזן מחדש.

כל הכבוד. שדרגתם בהצלחה אשכול GKE בארכיטקטורה מרובת אשכולות באמצעות Multi Cluster Ingress.
כדי לשדרג את האשכול green, חוזרים על התהליך של ניקוז ושדרוג האשכול הכחול, ומחליפים את blue ב-green לאורך כל התהליך.

הסרת המשאבים

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

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

מחיקת המקבצים

ב-Cloud Shell, מבטלים את הרישום של אשכולות blue ו-green ומוחקים אותם:

gcloud container fleet memberships unregister blue --gke-cluster=us-west1-b/blue
gcloud container clusters delete blue --location us-west1-b --quiet

gcloud container fleet memberships unregister green --gke-cluster=us-west1-c/green
gcloud container clusters delete green --location us-west1-c --quiet

מוחקים את המשאב MuticlusterIngress מהאשכול ingress-config:
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} delete -f ${WORKDIR}/multicluster-manifests/mci.yaml
```
הפקודה הזו מוחקת את המשאבים של Cloud Load Balancing מהפרויקט.

מבטלים את הרישום של אשכול ingress-config ומוחקים אותו:

gcloud container fleet memberships unregister ingress-config --gke-cluster=us-west1-a/ingress-config
gcloud container clusters delete ingress-config --location us-west1-a --quiet

מוודאים שכל האשכולות נמחקו:
```
gcloud container clusters list
```
הפלט שיתקבל:
```
*&lt;null&gt;*
```
מאפסים את הקובץ kubeconfig:
```
unset KUBECONFIG
```
מסירים את התיקייה WORKDIR:
```
cd ${HOME}
rm -rf ${WORKDIR}
```

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

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

המאמרים הבאים

מידע נוסף על Multi Cluster Ingress
איך פורסים Multi Cluster Ingress על פני אשכולות
כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.

שדרוג סביבת GKE מרובת אשכולות באמצעות Multi Cluster Ingress קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

ארכיטקטורה

מטרות

עלויות

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

הגדרת הסביבה

יצירה ורישום של אשכולות GKE ב-Hub

יצירת אשכולות GKE

רישום אשכולות GKE ל-Fleet

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

הגדרת Multi Cluster Ingress

הגדרת מחולל העומסים

מעקב אחר התנועה

הוצאת צומתי עבודה (drain) ושדרוג של אשכול blue

לרוקן את האוסף הכחול

שדרוג אשכול blue

הוספת האשכול blue בחזרה למאגר איזון העומסים

הסרת המשאבים

מחיקת המקבצים

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

המאמרים הבאים

שדרוג סביבת GKE מרובת אשכולות באמצעות Multi Cluster Ingress

הוצאת צומתי עבודה (drain) ושדרוג של אשכול `blue`

שדרוג אשכול `blue`

הוספת האשכול `blue` בחזרה למאגר איזון העומסים