שדרוג Cloud Service Mesh

‪

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

  • מריצים את הפקודה asmcli כדי לשדרג מ-Cloud Service Mesh ל-Cloud Service Mesh 1.29.5.

  • אפשר גם לפרוס שער כניסה.

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

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

GKE

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

1.27+

מקומי

אתם יכולים לשדרג ישירות ל-Cloud Service Mesh 1.29.5-asm.12 ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware וב-Google Distributed Cloud (תוכנה בלבד) לשרת פיזי מהגרסאות הבאות:

1.27+

‫GKE ב-AWS

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

1.27+

‫GKE ב-Azure

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

‫Amazon EKS

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

Microsoft AKS

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

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

לפני שמתחילים, חשוב לוודא:

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

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

רשות אישורים

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

שדרוג Cloud Service Mesh

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

  1. אם אתם משדרגים רשת משולבת של כמה אשכולות ב-GKE שמשתמשת ברשות אישורים של Cloud Service Mesh, מריצים את הפקודה asmcli create-mesh כדי להגדיר את הרשת המשולבת של כמה אשכולות כך שתיתן אמון בWorkload Identity של Fleet כדי לאפשר איזון עומסים בין אשכולות ללא השבתה במהלך השדרוג.

  2. מריצים את הפקודה asmcli install כדי להתקין את Cloud Service Mesh באשכול יחיד. בקטעים הבאים מפורטות דוגמאות לשורת הפקודה. הדוגמאות מכילות ארגומנטים נדרשים וגם ארגומנטים אופציונליים שיכולים להיות שימושיים. מומלץ לציין תמיד את הארגומנט output_dir כדי שתוכלו לאתר בקלות דוגמאות לשערי תשלום וכלים כמו istioctl. רשימת הדוגמאות מופיעה בסרגל הניווט משמאל.

  3. אופציונלי: התקנה או שדרוג של שער לדואר נכנס. כברירת מחדל, asmcli לא מתקין את istio-ingressgateway. מומלץ לפרוס ולנהל את רמת הבקרה ואת השערים בנפרד. אם אתם צריכים את ברירת המחדל istio-ingressgateway מותקנת עם מישור הבקרה באשכול, צריך לכלול את הארגומנט --option legacy-default-ingressgateway.

  4. כדי להשלים את ההגדרה של 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:

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

אפשר לציין את ה-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 מזהה הפרויקט של פרויקט המארח של ה-Fleet. אם לא כוללים את האפשרות הזו,‏ asmcli משתמש בפרויקט שבו נוצר האשכול כשרושמים את האשכול.
  • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
  • --enable_all מאפשר לסקריפט:
    • מעניקים את הרשאות ה-IAM הנדרשות.
    • מפעילים את ממשקי Google API הנדרשים.
    • מגדירים תווית באשכול שמזהה את הרשת.
    • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
  • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של הצי

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

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

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

    kubectl config use-context CLUSTER_NAME

  2. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • מעניקים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של fleet

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

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

GKE

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

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

מקומי

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

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

    kubectl config use-context CLUSTER_NAME

  2. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • מעניקים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca gcp_cas שימוש ב-Certificate Authority Service כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם לזמן השבתה. asmcliמגדיר את Certificate Authority Service לשימוש בזהות עומס עבודה של Fleet
    • --ca_pool המזהה המלא של מאגר רשויות האישורים בשירות Certificate Authority Service.

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

בקטע הזה מוסבר איך להריץ את הפקודה 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet. אם לא כוללים את האפשרות הזו,‏ asmcli משתמש בפרויקט שבו נוצר האשכול כשרושמים את האשכול.
  • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
  • --enable_all מאפשר לסקריפט:
    • מעניקים את הרשאות ה-IAM הנדרשות.
    • מפעילים את ממשקי Google API הנדרשים.
    • מגדירים תווית באשכול שמזהה את הרשת.
    • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
  • --ca citadel שימוש ב-Istio CA. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה.

מקומי

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

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

    kubectl config use-context CLUSTER_NAME

  2. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 עבור רשת המשנה הציבורית או רשת המשנה הפרטית.

גלוי לכולם

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

    kubectl config use-context CLUSTER_NAME

  2. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • מעניקים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca citadel שימוש ב-Istio CA כרשות האישורים.
    • --ca_cert אישור הביניים
    • --ca_key המפתח של אישור הביניים
    • --root_cert אישור הבסיס
    • --cert_chain שרשרת האישורים

פרטי

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

    kubectl config use-context CLUSTER_NAME

  2. שומרים את קובץ ה-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

  3. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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. מזינים את הערכים במחזיקי המקום שמופיעים.

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

    kubectl config use-context CLUSTER_NAME

  2. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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

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

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

    kubectl config use-context CLUSTER_NAME

  2. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזינים את הערכים בplaceholder שמופיע.

./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 מזהה הפרויקט של פרויקט המארח של ה-Fleet. אם לא כוללים את האפשרות הזו,‏ asmcli משתמש בפרויקט שבו נוצר האשכול כשרושמים את האשכול.
  • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
  • --enable_all מאפשר לסקריפט:
    • מעניקים את הרשאות ה-IAM הנדרשות.
    • מפעילים את ממשקי Google API הנדרשים.
    • מגדירים תווית באשכול שמזהה את הרשת.
    • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
  • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של הצי
  • --custom_overlay מציינים את השם של קובץ השכבה.

מחוץ ל-Google Cloud

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

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

    kubectl config use-context CLUSTER_NAME

  2. מריצים את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • מעניקים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של הצי
    • --custom_overlay מציינים את השם של קובץ השכבה.

שדרוג שערים

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

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

  1. מקבלים את תווית הגרסה שנמצאת ב-istiod.

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

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

    NAME                                                 READY   STATUS    RESTARTS   AGE   REV
istiod-asm-1295-12-67998f4b55-lrzpz           1/1     Running   0          68m   asm-12810-4
istiod-asm-1295-12-67998f4b55-r76kr           1/1     Running   0          68m   asm-12810-4
istiod-12810-4-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1295-12
istiod-12810-4-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1295-12

    1. בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה עבור הגרסה החדשה. בדוגמה הזו, הערך הוא asm-1295-12.

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

  2. מוסיפים את תווית הגרסה למרחב השמות של האפליקציה ומסירים את התווית 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 מצוין במפורש שרק אחת מהן מוגדרת.

  3. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.

    kubectl rollout restart deployment -n NAMESPACE

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

  5. אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי להוסיף תווית למרחב השמות ולהפעיל מחדש את ה-Pods.

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

    השלמת המעבר

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

    1. עוברים לספרייה שבה נמצאים הקבצים ממאגר anthos-service-mesh ב-GitHub.

    2. להעביר את תג ברירת המחדל:

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite

    3. מוחקים את הגרסה הקודמת של istiod. הפקודה שבה משתמשים תלויה בשאלה אם אתם מעבירים נתונים מ-Istio או משדרגים מגרסה קודמת של Cloud Service Mesh.

      העברה

      אם ביצעתם העברה מ-Istio, ל-istio-ingressgateway הישן אין תווית של גרסה:

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget,sa,rolebinding,role istiod -n istio-system --ignore-not-found=true

      שדרוג

      1. אם שדרגתם מגרסה קודמת של Cloud Service Mesh, חשוב לוודא שבפקודה הבאה, OLD_REVISION תואם לתווית התיקון של הגרסה הקודמת של istiod:

        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget,sa,rolebinding,role istiod-OLD_REVISION -n istio-system --ignore-not-found=true

      2. מחיקת המשאבים validatingwebhookconfiguration, ‏ mutatingWebhookConfiguration, ‏ configMap, ‏ clusterRole ו-clusterRoleBinding של הגרסה הקודמת:

        kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system --ignore-not-found
kubectl delete mutatingWebhookConfiguration istio-sidecar-injector-OLD_REVISION --ignore-not-found
kubectl delete configMap istio-OLD_REVISION istio-sidecar-injector-OLD_REVISION -n istio-system --ignore-not-found
kubectl delete clusterRole,clusterRoleBinding istio-reader-clusterrole-OLD_REVISION-istio-system istiod-clusterrole-OLD_REVISION-istio-system istiod-gateway-controller-OLD_REVISION-istio-system --ignore-not-found

    4. מסירים את הגרסה הקודמת של ההגדרה 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 כדי להפעיל מחדש את ההזרקה, כך שה-Proxies יכללו את הגרסה הקודמת:

      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 ושדרוגים מתבצעים לפי תהליך שדרוג מבוסס-עדכון (שנקרא 'שדרוגי קנרי' בתיעוד של Istio). בשדרוג מבוסס-עדכון, הגרסה החדשה של מישור הבקרה מותקנת לצד מישור הבקרה הקיים. לאחר מכן מעבירים חלק מעומסי העבודה לגרסה החדשה, וכך אפשר לעקוב אחרי ההשפעה של השדרוג על אחוז קטן מעומסי העבודה לפני שמעבירים את כל התנועה לגרסה החדשה.

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

  1. מקבלים את תווית הגרסה שמופיעה ב-istiod וב-istio-ingressgateway. בפקודה הבאה, משנים את הערך INGRESS_NAMESPACE למרחב השמות שבו פועל שער הכניסה (ingress gateway):

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

    אם שם שער הכניסה הוא istio-ingressgateway, הפלט של הפקודה אמור להיראות כך:

    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-1295-12
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1295-12
istiod-asm-1295-12-67998f4b55-lrzpz          1/1     Running   0          68m   asm-12810-4
istiod-asm-1295-12-67998f4b55-r76kr          1/1     Running   0          68m   asm-12810-4
istiod-asm-12810-4-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1295-12
istiod-asm-12810-4-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1295-12

    1. בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה עבור הגרסה החדשה. בדוגמה הזו, הערך הוא asm-1295-12.

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

  2. מעבירים את שער הכניסה לגרסה החדשה. בפקודה הבאה, משנים את REVISION לערך שמתאים לתווית הגרסה של הגרסה החדשה. משנים את INGRESS_NAMESPACE לשטח השמות שבו פועל שער הכניסה, ואת INGRESS_NAME לשם שער הכניסה.

    kubectl patch service -n INGRESS_NAMESPACE INGRESS_NAME --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

    הפלט אמור להיראות כך: service/istio-ingressgateway patched

  3. מוסיפים את תווית התיקון למרחב שמות ומסירים את התווית 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 מצוין במפורש שרק אחת מהן מוגדרת.

  4. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.

    kubectl rollout restart deployment -n NAMESPACE

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

  6. אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי להוסיף תווית למרחב השמות ולהפעיל מחדש את ה-Pods.

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

    השלמת המעבר

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

    1. עוברים לספרייה שבה נמצאים הקבצים ממאגר anthos-service-mesh ב-GitHub.

    2. מעבירים את תג ברירת המחדל.

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite

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

      העברה

      אם ביצעתם העברה מ-Istio, ל-INGRESS_NAME הישן אין תווית של גרסה.

      kubectl delete deploy/INGRESS_NAME -n INGRESS_NAMESPACE

      שדרוג

      אם שדרגתם מגרסה קודמת של Cloud Service Mesh, בפקודה הבאה, מחליפים את OLD_REVISION בתווית של הגרסה הקודמת של INGRESS_NAME.

      kubectl delete deploy -l app=INGRESS_NAME,istio.io/rev=OLD_REVISION -n INGRESS_NAMESPACE --ignore-not-found=true

    4. מוחקים את הגרסה הישנה של istiod. הפקודה שבה משתמשים תלויה בשאלה אם אתם מעבירים נתונים מ-Istio או משדרגים מגרסה קודמת של Cloud Service Mesh.

      העברה

      אם ביצעתם העברה מ-Istio, ל-istiod הישן אין תווית של גרסה.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget,sa,rolebinding,role istiod -n istio-system --ignore-not-found=true

      אם יש לכם את מישור הבקרה הישן יותר, עם תווית התיקון OLD_REVISION, לוחצים על הכרטיסייה upgrade ומשלימים את המחיקה של מישור הבקרה istiod באמצעות OLD_REVISION.

      שדרוג

      אם שדרגתם מגרסה קודמת של Cloud Service Mesh, חשוב לוודא שבפקודה הבאה, OLD_REVISION תואם לתווית התיקון של הגרסה הקודמת של istiod.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget,sa,rolebinding,role istiod-OLD_REVISION -n istio-system --ignore-not-found=true

      מחיקת המשאבים validatingwebhookconfiguration, ‏ mutatingWebhookConfiguration, ‏ configMap, ‏ clusterRole ו-clusterRoleBinding של הגרסה הקודמת:

      kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system  --ignore-not-found
kubectl delete mutatingWebhookConfiguration istio-sidecar-injector-OLD_REVISION --ignore-not-found
kubectl delete configMap istio-OLD_REVISION istio-sidecar-injector-OLD_REVISION -n istio-system --ignore-not-found
kubectl delete clusterRole,clusterRoleBinding istio-reader-clusterrole-OLD_REVISION-istio-system istiod-clusterrole-OLD_REVISION-istio-system istiod-gateway-controller-OLD_REVISION-istio-system --ignore-not-found

    5. מסירים את הגרסה הישנה של ההגדרה IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system --ignore-not-found=true

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

      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 כדי להפעיל מחדש את ההזרקה, כך שה-Proxies יכללו את הגרסה הקודמת:

      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 --ignore-not-found=true

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

     istiooperator.install.istio.io "installed-state-REVISION" deleted

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