אתם קוראים את מאמרי העזרה של Service Mesh בגרסה 1.19 מדור קודם.

גרסאות זמינות

הגרסה האחרונה של Cloud Service Mesh
ארכיון של Cloud Service Mesh 1.26
ארכיון של Cloud Service Mesh 1.24
ארכיון של Cloud Service Mesh 1.24
ארכיון של Cloud Service Mesh 1.23
ארכיון של Cloud Service Mesh 1.22
ארכיון של Cloud Service Mesh 1.21
ארכיון של Cloud Service Mesh 1.20
ארכיון של Anthos Service Mesh 1.19

שדרוג Cloud Service Mesh

בדף הזה נסביר איך:

מריצים את הפקודה asmcli כדי לשדרג מ-Cloud Service Mesh ל-Cloud Service Mesh 1.19.10.
אפשר גם לפרוס שער כניסה.
מבצעים שדרוג גרסה ראשונית (canary) כדי להעביר את עומסי העבודה למישור הבקרה החדש.

הגרסה של Cloud Service Mesh שאפשר לשדרג ממנה משתנה בהתאם לפלטפורמה.

GKE

אפשר לשדרג ישירות ל-Cloud Service Mesh‏ 1.19.10-asm.9 ב-Google Kubernetes Engine מהגרסאות הבאות:

1.17+

מקומי

אפשר לשדרג ישירות ל-Cloud Service Mesh‏ 1.19.10-asm.9 ב-Google Distributed Cloud וב-Google Distributed Cloud מהגרסאות הבאות:

1.17+

‫GKE ב-AWS

אפשר לשדרג ישירות ל-Cloud Service Mesh 1.19.10-asm.9 ב-GKE ב-AWS מהגרסאות הבאות:

1.17+

‫GKE ב-Azure

‫GKE ב-Azure תומך רק ב-Cloud Service Mesh 1.16. אין תמיכה בשדרוגים מגרסאות קודמות של Cloud Service Mesh.

Amazon EKS

אם התקנתם את Cloud Service Mesh 1.7 ב-EKS, תצטרכו להתקין את Cloud Service Mesh 1.19 באשכול חדש. שדרוגים מ-Cloud Service Mesh 1.7 ל-Cloud Service Mesh1.19 לא נתמכים.

Microsoft AKS

אם התקנתם את Cloud Service Mesh 1.7 ב-AKS, תצטרכו להתקין את Cloud Service Mesh 1.19 באשכול חדש. שדרוגים מ-Cloud Service Mesh 1.7 ל-Cloud Service Mesh1.19 לא נתמכים.

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

לפני שמתחילים, חשוב לבצע את הפעולות הבאות:

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

התאמות אישיות של מישור הבקרה

אם התאמתם אישית את ההתקנה הקודמת, תצטרכו לבצע את אותן התאמות אישיות כשמשדרגים לגרסה חדשה של Cloud Service Mesh או כשמבצעים מיגרציה מ-Istio. אם התאמתם אישית את ההתקנה על ידי הוספת הדגל --set values ל-istioctl install, אתם צריכים להוסיף את ההגדרות האלה לקובץ YAML‏ IstioOperator, שנקרא קובץ שכבת-על. מציינים את קובץ השכבה באמצעות האפשרות --custom_overlay עם שם הקובץ כשמריצים את הסקריפט. הסקריפט מעביר את קובץ השכבות לשירות istioctl install.

רשות אישורים

שינוי רשות האישורים (CA) במהלך שדרוג גורם להשבתה. במהלך השדרוג, התנועה ב-mTLS מופסקת עד שכל עומסי העבודה עוברים לשימוש במישור הבקרה החדש עם רשות האישורים החדשה.

שדרוג של Anthos Service Mesh

בקטעים הבאים מוסבר איך לשדרג את Cloud Service Mesh:

אם משדרגים רשת משולבת של כמה אשכולות ב-GKE שמשתמשת ברשות אישורים של Cloud Service Mesh, מריצים את הפקודה asmcli create-mesh כדי להגדיר את הרשת המשולבת של כמה אשכולות כך שתיתן אמון בWorkload Identity של Fleet כדי לאפשר איזון עומסים בין אשכולות ללא השבתה במהלך השדרוג.
מריצים את הפקודה asmcli install כדי להתקין את Cloud Service Mesh באשכול יחיד. בקטעים הבאים מפורטות דוגמאות לשורת פקודה. הדוגמאות מכילות ארגומנטים נדרשים וגם ארגומנטים אופציונליים שיכולים להיות שימושיים. מומלץ לציין תמיד את הארגומנט output_dir כדי שתוכלו לאתר בקלות שערים וכלים לדוגמה, כמו istioctl. רשימת הדוגמאות מופיעה בסרגל הניווט משמאל.
אופציונלי: התקנה או שדרוג של שער כניסה. כברירת מחדל, asmcli לא מתקין את istio-ingressgateway. מומלץ לפרוס ולנהל את רמת הבקרה ואת השערים בנפרד. אם אתם צריכים להתקין את istio-ingressgateway כברירת מחדל עם מישור הבקרה באשכול, צריך לכלול את הארגומנט --option legacy-default-ingressgateway.
כדי להשלים את ההגדרה של Cloud Service Mesh, צריך להפעיל הוספה אוטומטית של sidecar ולפרוס או לפרוס מחדש עומסי עבודה.

הגדרת רשת מרובת אשכולות כדי לתת אמון בזהות של עומס עבודה ב-Fleet

אם אתם משדרגים רשת משולבת מרובת אשכולות ב-GKE שמשתמשת ברשות האישורים של Cloud Service Mesh כרשות האישורים, אתם צריכים להריץ את הפקודה asmcli create-mesh לפני שאתם משדרגים כל אשכול. הפקודה הזו מגדירה את רשות האישורים של Cloud Service Mesh כך שתשתמש במאגר הזהויות של עומס העבודה של ה-Fleet,‏ FLEET_PROJECT_ID.svc.id.goog, כדומיין האמון אחרי השדרוג. הפקודה asmcli create-mesh:

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

אפשר לציין את ה-URI של כל אשכול או את הנתיב של קובץ ה-kubeconfig.

‫URI של האשכול

בפקודה הבאה, מחליפים את FLEET_PROJECT_ID במזהה הפרויקט של פרויקט המארח של ה-Fleet, ואת ה-URI של האשכול בשם האשכול, באזור או באזור ובמזהה הפרויקט של כל אשכול.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

קובץ kubeconfig

בפקודה הבאה, מחליפים את FLEET_PROJECT_ID במזהה הפרויקט של פרויקט המארח של ה-Fleet ואת PATH_TO_KUBECONFIG בנתיב לכל קובץ kubeconfig.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

שדרוג עם תכונות ברירת מחדל ורשות אישורים של רשת Mesh

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

GKE

מריצים את הפקודה הבאה כדי לשדרג את מישור הבקרה עם תכונות ברירת מחדל ורשות אישורים של Cloud Service Mesh. מזינים את הערכים במחזיקי המקום שמופיעים.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

‫--project_id,‏ --cluster_name ו---cluster_location מציינים את מזהה הפרויקט שבו נמצא האשכול, את שם האשכול ואת האזור או האזור של האשכול.
‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי. אם לא כוללים את האפשרות הזו,‏ asmcli משתמש בפרויקט שבו נוצר האשכול כשרושמים את האשכול.
--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
הערה: חשוב לשים לב לספרייה --output_dir. תצטרכו להפנות אליו כשפורסים שערים.
--enable_all מאפשר לסקריפט:
- מעניקים את הרשאות ה-IAM הנדרשות.
- מפעילים את ממשקי Google API הנדרשים.
- מגדירים תווית באשכול שמזהה את הרשת.
- רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
--ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של fleet

אשכולות אחרים של GKE Enterprise

מריצים את הפקודות הבאות באשכולות אחרים של GKE Enterprise כדי לשדרג את מישור הבקרה עם תכונות ברירת מחדל ורשות אישורים של Cloud Service Mesh. מזינים את הערכים ב-placeholders שמופיעים.

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```
מריצים את asmcli install:
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של fleet

שדרוג תכונות ברירת המחדל באמצעות שירות CA

בקטע הזה מוסבר איך להריץ את הפקודה asmcli כדי לשדרג את Cloud Service Mesh עם התכונות הנתמכות שמוגדרות כברירת מחדל לפלטפורמה שלכם, ולהפעיל את Certificate Authority Service.

GKE

מריצים את הפקודה הבאה כדי לשדרג את מישור הבקרה עם תכונות ברירת מחדל ו-Certificate Authority Service. מזינים את הערכים במחזיקי המקום שמופיעים.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

‫--project_id,‏ --cluster_name ו---cluster_location מציינים את מזהה הפרויקט שבו נמצא האשכול, את שם האשכול ואת האזור או האזור של האשכול.
‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי. אם לא כוללים את האפשרות הזו,‏ asmcli משתמש בפרויקט שבו נוצר האשכול כשרושמים את האשכול.
--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
הערה: חשוב לשים לב לספרייה --output_dir. תצטרכו להפנות אליו כשפורסים שערים.
--enable_all מאפשר לסקריפט:
- מעניקים את הרשאות ה-IAM הנדרשות.
- מפעילים את ממשקי Google API הנדרשים.
- מגדירים תווית באשכול שמזהה את הרשת.
- רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
--ca gcp_cas שימוש ב-Certificate Authority Service כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את Certificate Authority Service לשימוש בזהות עומס עבודה של צי
‫--ca_pool המזהה המלא של שירות Certificate Authority CA Pool.

מקומי

מריצים את הפקודות הבאות ב-Google Distributed Cloud או ב-Google Distributed Cloud כדי לשדרג את מישור הבקרה עם תכונות ברירת מחדל ושירות רשות האישורים. מזינים את הערכים במחזיקי המקום שמופיעים.

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```
מריצים את asmcli install:
```
./asmcli install \
 --kubeconfig KUBECONFIG_FILE \
 --fleet_id FLEET_PROJECT_ID \
 --output_dir DIR_PATH \
 --enable_all \
 --ca gcp_cas \
 --platform multicloud \
 --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca gcp_cas שימוש ב-Certificate Authority Service כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את Certificate Authority Service לשימוש בזהות עומס עבודה של צי
- --ca_pool המזהה המלא של מאגר רשויות האישורים ב-Certificate Authority Service.

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

בקטע הזה מוסבר איך להריץ את הפקודה asmcli כדי לשדרג את Cloud Service Mesh עם התכונות הנתמכות שמוגדרות כברירת מחדל לפלטפורמה שלכם, ולהפעיל את Istio CA.

GKE

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

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

‫--project_id,‏ --cluster_name ו---cluster_location מציינים את מזהה הפרויקט שבו נמצא האשכול, את שם האשכול ואת האזור או האזור של האשכול.
‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי. אם לא כוללים את האפשרות הזו,‏ asmcli משתמש בפרויקט שבו נוצר האשכול כשרושמים את האשכול.
--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
הערה: חשוב לשים לב לספרייה --output_dir. תצטרכו להפנות אליו כשפורסים שערים.
--enable_all מאפשר לסקריפט:
- מעניקים את הרשאות ה-IAM הנדרשות.
- מפעילים את ממשקי Google API הנדרשים.
- מגדירים תווית באשכול שמזהה את הרשת.
- רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
--ca citadel שימוש ב-Istio CA. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה.

מקומי

מריצים את הפקודות הבאות ב-Google Distributed Cloud או ב-Google Distributed Cloud כדי לשדרג את מישור הבקרה עם תכונות ברירת מחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים.

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```
מריצים את asmcli install:
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca citadel שימוש ב-Istio CA כרשות האישורים.
- --ca_cert אישור הביניים
- --ca_key המפתח של אישור הביניים
- --root_cert אישור הבסיס
- --cert_chain שרשרת האישורים

AWS

מריצים את הפקודות הבאות ב-GKE ב-AWS כדי לשדרג את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים. אתם יכולים לבחור להפעיל את Ingress עבור רשת המשנה הציבורית או רשת המשנה הפרטית.

גלוי לכולם

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```
מריצים את asmcli install:
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca citadel שימוש ב-Istio CA כרשות האישורים.
- --ca_cert אישור הביניים
- --ca_key המפתח של אישור הביניים
- --root_cert אישור הבסיס
- --cert_chain שרשרת האישורים

פרטי

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```

שומרים את קובץ ה-YAML הבא בקובץ בשם istio-operator-internal-lb.yaml:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - enabled: true
      k8s:
        serviceAnnotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: "true"
      name: istio-ingressgateway

מריצים את asmcli install:
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
  --custom_overlay istio-operator-internal-lb.yaml
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca citadel שימוש ב-Istio CA כרשות האישורים.
- --ca_cert אישור הביניים
- --ca_key המפתח של אישור הביניים
- --root_cert אישור הבסיס
- --cert_chain שרשרת האישורים

Amazon EKS

מריצים את הפקודות הבאות ב-Amazon EKS כדי לשדרג את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים.

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```
מריצים את asmcli install:
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca citadel שימוש ב-Istio CA כרשות האישורים.
- --ca_cert אישור הביניים
- --ca_key המפתח של אישור הביניים
- --root_cert אישור הבסיס
- --cert_chain שרשרת האישורים

Microsoft AKS

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```
מריצים את asmcli install:
```
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca citadel שימוש ב-Istio CA כרשות האישורים.
- --ca_cert אישור הביניים
- --ca_key המפתח של אישור הביניים
- --root_cert אישור הבסיס
- --cert_chain שרשרת האישורים

שדרוג עם תכונות אופציונליות

קובץ שכבת-על הוא קובץ YAML שמכיל IstioOperator משאב בהתאמה אישית (CR) שמעבירים אל asmcli כדי להגדיר את מישור הבקרה. אפשר לבטל את הגדרות ברירת המחדל של מישור הבקרה ולהפעיל תכונה אופציונלית על ידי העברת קובץ ה-YAML אל asmcli. אפשר להוסיף עוד שכבות-על, וכל קובץ שכבת-על מבטל את ההגדרה בשכבות הקודמות.

GKE

מריצים את הפקודה הבאה כדי להתקין את מישור הבקרה עם תכונה אופציונלית. כדי להוסיף כמה קבצים, מציינים --custom_overlay ואת שם הקובץ, לדוגמה: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml מזינים את הערכים ב placeholders שמופיעים.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

‫--project_id,‏ --cluster_name ו---cluster_location מציינים את מזהה הפרויקט שבו נמצא האשכול, את שם האשכול ואת האזור או האזור של האשכול.
‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי. אם לא כוללים את האפשרות הזו,‏ asmcli משתמש בפרויקט שבו נוצר האשכול כשרושמים את האשכול.
--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
הערה: חשוב לשים לב לספרייה --output_dir. תצטרכו להפנות אליו כשפורסים שערים.
--enable_all מאפשר לסקריפט:
- מעניקים את הרשאות ה-IAM הנדרשות.
- מפעילים את ממשקי Google API הנדרשים.
- מגדירים תווית באשכול שמזהה את הרשת.
- רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
--ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של fleet
--custom_overlay מציינים את השם של קובץ השכבה.

מחוץ ל-Google Cloud

מריצים את הפקודות הבאות ב-Google Distributed Cloud,‏ Google Distributed Cloud,‏ GKE ב-AWS,‏ Amazon EKS או Microsoft AKS. מזינים את הערכים במשתני המיקום שמופיעים.

מגדירים את ההקשר הנוכחי לאשכול המשתמשים:
```
kubectl config use-context CLUSTER_NAME
```
מריצים את asmcli install:
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE
```
- ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
- ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
- --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת ‫asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
- --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
- --enable_all מאפשר לסקריפט:
  - מעניקים את הרשאות ה-IAM הנדרשות.
  - מפעילים את ממשקי Google API הנדרשים.
  - מגדירים תווית באשכול שמזהה את הרשת.
  - רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
- --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של fleet
- --custom_overlay מציינים את השם של קובץ השכבה.

שדרוג שערים

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

מעבר למישור הבקרה החדש

קבלת תווית הגרסה שנמצאת ב-istiod.
```
kubectl get pod -n istio-system -L istio.io/rev
```
הפלט של הפקודה אמור להיראות כך:
```
NAME                                                 READY   STATUS    RESTARTS   AGE   REV
istiod-asm-11910-9-67998f4b55-lrzpz           1/1     Running   0          68m   asm-11910-9
istiod-asm-11910-9-67998f4b55-r76kr           1/1     Running   0          68m   asm-11910-9
istiod-1187-26-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-11910-9
istiod-1187-26-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-11910-9
```
1. בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה עבור הגרסה החדשה. בדוגמה הזו, הערך הוא asm-11910-9.
2. שימו לב גם לערך בתווית הגרסה של הגרסה הישנה של istiod. תצטרכו את זה כדי למחוק את הגרסה הישנה של istiod אחרי שתסיימו להעביר את עומסי העבודה לגרסה החדשה. בדוגמת הפלט, הערך של תווית הגרסה של הגרסה הישנה הוא asm-11910-9.
מוסיפים את תווית הגרסה למרחב השמות של האפליקציה ומסירים את התווית istio-injection (אם היא קיימת). בפקודה הבאה, משנים את REVISION לערך שתואם לגרסה החדשה של istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
אם רואים את התו "istio-injection not found" בפלט, אפשר להתעלם ממנו. כלומר, במרחב השמות לא הייתה קודם התווית istio-injection. ההתנהגות של הזרקה אוטומטית לא מוגדרת כשמרחב שמות כולל גם את התווית istio-injection וגם את תווית הגרסה. לכן, כל הפקודות kubectl label במסמכי Cloud Service Mesh מוודאות במפורש שרק אחת מהן מוגדרת.
מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.

אזהרה: חשוב להפעיל מחדש את כל ה-Pods כדי להפעיל את ההחדרה מחדש של ה-Sidecars. אחרת, יכול להיות שיהיו אי-התאמות בדוחות המדדים של Cloud Service Mesh בין ה-proxy הקודם ל-proxy החדש באותו אשכול.
```
kubectl rollout restart deployment -n NAMESPACE
```
בודקים את האפליקציה כדי לוודא שעומסי העבודה פועלים בצורה תקינה.
אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי להוסיף תווית למרחב השמות ולהפעיל מחדש את ה-Pods.
אם אתם מרוצים מהאופן שבו האפליקציה פועלת, אתם יכולים להמשיך לשלבים של המעבר לגרסה החדשה של istiod. אם יש בעיה בבקשה שלכם, פועלים לפי השלבים לביטול השינויים.
השלמת המעבר
אם אתם מרוצים מהאופן שבו האפליקציה פועלת, אתם יכולים להסיר את מישור הבקרה הישן כדי להשלים את המעבר לגרסה החדשה.
1. עוברים לספרייה שבה נמצאים הקבצים ממאגר anthos-service-mesh ב-GitHub.
2. מגדירים את ה-webhook לאימות כך שישתמש במישור הבקרה החדש:
  kubectl apply -f asm/istio/istiod-service.yaml
3. להעביר את תג ברירת המחדל:
  <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
4. מוחקים את הגרסה הישנה של istiod. הפקודה שבה משתמשים תלויה בשאלה אם אתם מעבירים נתונים מ-Istio או משדרגים מגרסה קודמת של Cloud Service Mesh.
  העברה
  אם ביצעתם העברה מ-Istio, ל-istio-ingressgateway הישן אין תווית של גרסה:
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  שדרוג
  1. אם שדרגתם מגרסה קודמת של Cloud Service Mesh, חשוב לוודא שהערך OLD_REVISION בפקודה הבאה זהה לתווית התיקון של הגרסה הקודמת של istiod:
    
    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
  2. מחיקת המשאב validatingwebhookconfiguration לגרסה ישנה:
    
    kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
5. מסירים את הגרסה הישנה של ההגדרה IstioOperator:
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  הפלט הצפוי אמור להיראות כך:
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
חזרה לגרסה קודמת
אם נתקלתם בבעיה כשבדקתם את האפליקציה עם הגרסה החדשה של istiod, תוכלו לבצע את השלבים הבאים כדי לחזור לגרסה הקודמת:
1. כדי להפעיל הוספה אוטומטית באמצעות הגרסה הקודמת של istiod, צריך לשנות את התווית של מרחב השמות. הפקודה שבה משתמשים תלויה בשאלה אם השתמשתם בתווית של עדכון או ב-istio-injection=enabled עם הגרסה הקודמת.
  - אם השתמשתם בתווית של עדכון לביצוע הוספה אוטומטית:
    
    kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  - אם השתמשתם ב-istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  הפלט אמור להיראות כך:
  namespace/NAMESPACE labeled
2. מוודאים שתווית השינוי במרחב השמות זהה לתווית השינוי בגרסה הקודמת של istiod:
  kubectl get ns NAMESPACE --show-labels
3. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה, כך שלפרוקסי תהיה הגרסה הקודמת:
  kubectl rollout restart deployment -n NAMESPACE
4. מסירים את הגרסה החדשה של istiod. מוודאים שהערך של REVISION בפקודה הבאה נכון.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
5. מסירים את הגרסה החדשה של ההגדרה IstioOperator.
  kubectl delete IstioOperator installed-state-REVISION -n istio-system
  הפלט הצפוי אמור להיראות כך:
  istiooperator.install.istio.io "installed-state-REVISION" deleted
6. אם לא כללתם את הדגל --disable_canonical_service,‏ asmcli הפעלתם את בקר השירות הקנוני. מומלץ להשאיר את ההגדרה הזו מופעלת, אבל אם אתם צריכים להשבית אותה, תוכלו לעיין במאמר הפעלה והשבתה של בקר שירות קנוני.
7. אם יש לכם שערים פרוסים, הקפידו לשנות את תווית הגרסה במרחב השמות או בפריסה כך שתתאים לגרסה הקודמת של istiod. פועלים לפי אותו תהליך שמתואר בקטע 'שדרוגים במקום' במדריך התקנה ושדרוג של שערים.

פריסה ופריסה מחדש של עומסי עבודה

ההתקנה (או השדרוג) לא תושלם עד שתפעילו הוספה אוטומטית של פרוקסי מסוג sidecar. העברות מ-OSS Istio ושדרוגים מתבצעים לפי תהליך שדרוג מבוסס-גרסה (שנקרא 'שדרוגי גרסה ראשונית (canary)' בתיעוד של Istio). במהלך שדרוג מבוסס-עדכון, הגרסה החדשה של מישור הבקרה מותקנת לצד מישור הבקרה הקיים. לאחר מכן מעבירים חלק מעומסי העבודה לגרסה החדשה, וכך אפשר לעקוב אחרי ההשפעה של השדרוג על אחוז קטן מעומסי העבודה לפני העברת כל התנועה לגרסה החדשה.

התסריט מגדיר תווית של תיקון בפורמט istio.io/rev=asm-11910-9 בתאריך istiod. כדי להפעיל הוספה אוטומטית, צריך להוסיף תווית תואמת של עדכון למרחבי השמות. תווית התיקון משמשת את ה-webhook של ה-sidecar injector כדי לשייך sidecars מוזרקים לתיקון מסוים של istiod. אחרי שמוסיפים את התווית, מפעילים מחדש את ה-Pods במרחב השמות כדי להחדיר את ה-sidecars.

מעתיקים את תווית הגרסה שמופיעה ב-istiod וב-istio-ingressgateway.

kubectl get pod -n istio-system -L istio.io/rev

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

NAME                                                READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk               1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz               1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb      1/1     Running   0          5s    asm-11910-9
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-11910-9
istiod-asm-11910-9-67998f4b55-lrzpz          1/1     Running   0          68m   asm-11910-9
istiod-asm-11910-9-67998f4b55-r76kr          1/1     Running   0          68m   asm-11910-9
istiod-asm-1187-26-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-11910-9
istiod-asm-1187-26-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-11910-9

בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה עבור הגרסה החדשה. בדוגמה הזו, הערך הוא asm-11910-9.
שימו לב גם לערך בתווית הגרסה של הגרסה הישנה של istiod. תצטרכו את זה כדי למחוק את הגרסה הישנה של istiod אחרי שתסיימו להעביר את עומסי העבודה לגרסה החדשה. בדוגמת הפלט, הערך של תווית הגרסה של הגרסה הישנה הוא asm-11910-9.

מעבירים את istio-ingressgateway לגרסה החדשה. בפקודה הבאה, משנים את REVISION לערך שמתאים לתווית הגרסה של הגרסה החדשה.
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'
```
הפלט הצפוי: service/istio-ingressgateway patched
מוסיפים את תווית הגרסה למרחב שמות ומסירים את התווית istio-injection (אם היא קיימת). בפקודה הבאה, משנים את REVISION לערך שתואם לגרסה החדשה של istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
אם רואים את התו "istio-injection not found" בפלט, אפשר להתעלם ממנו. כלומר, במרחב השמות לא הייתה קודם התווית istio-injection. ההתנהגות של הזרקה אוטומטית לא מוגדרת כשמרחב שמות כולל גם את התווית istio-injection וגם את תווית הגרסה. לכן, כל הפקודות kubectl label במסמכי Cloud Service Mesh מוודאות במפורש שרק אחת מהן מוגדרת.
מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.

אזהרה: חשוב להפעיל מחדש את כל ה-pods כדי להפעיל את ההחדרה מחדש של ה-sidecars. אחרת, יכול להיות שיהיו אי-התאמות בדוחות המדדים של Cloud Service Mesh בין ה-proxy הישן לחדש באשכול.
```
kubectl rollout restart deployment -n NAMESPACE
```
בודקים את האפליקציה כדי לוודא שעומסי העבודה פועלים בצורה תקינה.
אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי להוסיף תווית למרחב השמות ולהפעיל מחדש את ה-Pods.
אם אתם מרוצים מהאופן שבו האפליקציה פועלת, אתם יכולים להמשיך לשלבים של המעבר לגרסה החדשה של istiod. אם יש בעיה בבקשה שלכם, פועלים לפי השלבים לביטול השינויים.
השלמת המעבר
אם אתם מרוצים מהאופן שבו האפליקציה פועלת, אתם יכולים להסיר את מישור הבקרה הישן כדי להשלים את המעבר לגרסה החדשה.
1. עוברים לספרייה שבה נמצאים הקבצים ממאגר anthos-service-mesh ב-GitHub.
2. מגדירים את ה-webhook לאימות לשימוש במישור הבקרה החדש.
  kubectl apply -f asm/istio/istiod-service.yaml
3. מעבירים את תג ברירת המחדל.
  <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite
4. מוחקים את istio-ingressgatewayהפריסה הישנה. הפקודה שמריצים תלויה בשאלה אם מבצעים מיגרציה מ-Istio או משדרגים מגרסה קודמת של Cloud Service Mesh:
  העברה
  אם ביצעתם העברה מ-Istio, ל-istio-ingressgateway הישן אין תווית של גרסה.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  שדרוג
  אם שדרגתם מגרסה קודמת של Cloud Service Mesh, בפקודה הבאה, מחליפים את OLD_REVISION בתווית של הגרסה הקודמת של istio-ingressgateway.
  
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
5. מוחקים את הגרסה הישנה של istiod. הפקודה שבה משתמשים תלויה בשאלה אם אתם מעבירים נתונים מ-Istio או משדרגים מגרסה קודמת של Cloud Service Mesh.
  העברה
  אם ביצעתם העברה מ-Istio, ל-istio-ingressgateway הישן אין תווית של גרסה.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  שדרוג
  אם שדרגתם מגרסה קודמת של Cloud Service Mesh, ודאו שבפקודה הבאה OLD_REVISION תואם לתווית התיקון של הגרסה הקודמת של istiod.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
6. מסירים את הגרסה הישנה של ההגדרה IstioOperator.
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  הפלט הצפוי אמור להיראות כך:
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
חזרה לגרסה קודמת
אם נתקלתם בבעיה כשבדקתם את האפליקציה עם הגרסה החדשה של istiod, תוכלו לבצע את השלבים הבאים כדי לחזור לגרסה הקודמת:
1. כדי להפעיל הוספה אוטומטית באמצעות הגרסה הקודמת של istiod, צריך לשנות את התווית של מרחב השמות. הפקודה שבה משתמשים תלויה בשאלה אם השתמשתם בתווית של עדכון או ב-istio-injection=enabled עם הגרסה הקודמת.
  - אם השתמשתם בתווית של עדכון לביצוע הוספה אוטומטית:
    
    kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  - אם השתמשתם ב-istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  הפלט אמור להיראות כך:
  namespace/NAMESPACE labeled
2. מוודאים שתווית השינוי במרחב השמות זהה לתווית השינוי בגרסה הקודמת של istiod:
  kubectl get ns NAMESPACE --show-labels
3. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה, כך שלפרוקסי תהיה הגרסה הקודמת:
  kubectl rollout restart deployment -n NAMESPACE
4. מסירים את הפריסה החדשה של istio-ingressgateway. מוודאים שהערך של REVISION בפקודה הבאה נכון.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
5. מסירים את הגרסה החדשה של istiod. מוודאים שהערך של REVISION בפקודה הבאה נכון.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
6. מסירים את הגרסה החדשה של ההגדרה IstioOperator.
  kubectl delete IstioOperator installed-state-REVISION -n istio-system
  הפלט הצפוי אמור להיראות כך:
  istiooperator.install.istio.io "installed-state-REVISION" deleted
7. אם לא כללתם את הדגל --disable_canonical_service, הסקריפט הפעיל את בקר השירות הקנוני. מומלץ להשאיר את ההגדרה הזו מופעלת, אבל אם אתם צריכים להשבית אותה, תוכלו לעיין במאמר הפעלה והשבתה של בקר שירות קנוני.

שדרוג Cloud Service Mesh

GKE

מקומי

‫GKE ב-AWS

‫GKE ב-Azure

Amazon EKS

Microsoft AKS

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

התאמות אישיות של מישור הבקרה

רשות אישורים

שדרוג של Anthos Service Mesh

הגדרת רשת מרובת אשכולות כדי לתת אמון בזהות של עומס עבודה ב-Fleet

‫URI של האשכול

קובץ kubeconfig

שדרוג עם תכונות ברירת מחדל ורשות אישורים של רשת Mesh

GKE

אשכולות אחרים של GKE Enterprise

שדרוג תכונות ברירת המחדל באמצעות שירות CA

GKE

מקומי

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

GKE

מקומי

AWS

גלוי לכולם

פרטי

Amazon EKS

Microsoft AKS

שדרוג עם תכונות אופציונליות

GKE

מחוץ ל-Google Cloud

שדרוג שערים

מעבר למישור הבקרה החדש

השלמת המעבר

העברה

שדרוג

חזרה לגרסה קודמת

פריסה ופריסה מחדש של עומסי עבודה

השלמת המעבר

העברה

שדרוג

העברה

שדרוג

חזרה לגרסה קודמת