העברה מבוססת-קנרית לרשות אישורים של Cloud Service Mesh

חשוב לדעת: השימוש ב-Cloud Service Mesh בתוך האשכול באמצעות מישור הבקרה ISTIOD ב-GKE ב- Google Cloud יצא משימוש. אנחנו ממשיכים לתמוך ב-Cloud Service Mesh עם מישור בקרה בתוך האשכול ב-Google Distributed Cloud (תוכנה בלבד), כפי שמתואר במאמר פלטפורמות נתמכות.

הערה: במדריך הזה מוסבר איך להעביר את ה-CA של Istio ל-Cloud Service Mesh certificate authority באמצעות גישה מבוססת-קנריות שכוללת זמן השבתה מינימלי או ללא זמן השבתה בכלל. כדי להעביר את ה-CA עם זמן השבתה מינימלי ובלי להעביר את מישורי הבקרה, אפשר לעיין במאמר בנושא העברת CA במקום.

כדי לבצע מיגרציה אל רשות האישורים של Cloud Service Mesh (רשות האישורים של Cloud Service Mesh) מ-Istio CA (שנקראת גם Citadel), צריך להעביר את שורש המהימנות. לפני Cloud Service Mesh 1.10, אם רציתם להעביר את Istio ב-Google Kubernetes Engine ‏ (GKE) אל Cloud Service Mesh עם רשות אישורים של Cloud Service Mesh, הייתם צריכים לתזמן השבתה כי Cloud Service Mesh לא הצליח לטעון כמה אישורי בסיס. לכן, במהלך ההעברה, עומסי העבודה החדשים שהופעלו מהימנים על אישור הבסיס החדש, בעוד שעומסי עבודה אחרים מהימנים על אישור הבסיס הישן. עומסי עבודה שמשתמשים באישורים שחתומים על ידי אישורי בסיס שונים לא יכולים לבצע אימות אחד מול השני. המשמעות היא שתעבורת נתונים של TLS הדדי (mTLS) מופסקת במהלך ההעברה. האשכול כולו ישוחזר באופן מלא רק כשמישור הבקרה וכל עומסי העבודה בכל מרחבי השמות יופעלו מחדש עם האישור של רשות האישורים של Cloud Service Mesh. אם ברשת שלכם יש כמה אשכולות עם עומסי עבודה ששולחים בקשות לעומסי עבודה באשכול אחר, צריך לעדכן גם את כל עומסי העבודה באשכולות האלה.

אפשר להיעזר בשלבים שבמדריך הזה בתרחישי השימוש הבאים:

• מעבר מ-Istio ב-GKE למישור הבקרה בתוך האשכול של Cloud Service Mesh 1.19.10-asm.9 עם רשות אישורים של Cloud Service Mesh.
• שדרוג מ-Cloud Service Mesh 1.15 or a 1.16 patch release עם Istio CA אל Cloud Service Mesh 1.19.10-asm.9 in-cluster control plane עם רשות אישורים של Cloud Service Mesh.

מגבלות

• כל אשכולות GKE צריכים להיות באותו פרויקט Google Cloud .

דרישות מוקדמות

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

• התקנת הכלים הנדרשים
• הורדה asmcli
• מתן הרשאות אדמין של אשכול
• אימות הפרויקט והאשכול

כלים נדרשים

במהלך ההעברה, מריצים כלי ש-Google מספקת, migrate_ca, כדי לאמת את הפרטים הבאים לגבי כל Pod באשכול:

• אישור הבסיס של רשות האישורים של Istio ושל Cloud Service Mesh.
• אישור mTLS של עומס העבודה שהונפק על ידי Istio CA ועל ידי רשות האישורים של Cloud Service Mesh.
• דומיינים מהימנים שהוגדרו על ידי רשות האישורים של Istio ורשות האישורים של Cloud Service Mesh.

לכלי הזה יש את התלויות הבאות:

• awk
• grep
• ‫istioctl הרצת הפקודה asmcli install מורידה את הגרסה של istioctl שתואמת לגרסה של Cloud Service Mesh שאתם מתקינים.
• jq
• kubectl
• openssl

סקירה כללית על המיגרציה

כדי לבצע מיגרציה לרשות אישורים של Cloud Service Mesh, צריך לפעול לפי תהליך המיגרציה מבוסס-העדכון (שנקרא גם 'שדרוג קנרי'). בהעברה מבוססת-עדכון, מתבצעת פריסה של עדכון חדש של מישור הבקרה לצד מישור הבקרה הקיים. לאחר מכן, מעבירים בהדרגה את עומסי העבודה לגרסה החדשה, וכך אפשר לעקוב אחר ההשפעה של ההעברה במהלך התהליך. במהלך תהליך ההעברה, האימות וההרשאה פועלים באופן מלא בין עומסי עבודה באמצעות רשות האישורים של Cloud Service Mesh ועומסי עבודה באמצעות רשות האישורים של Istio.

בהמשך מפורט תהליך ההעברה לרשות אישורים של Cloud Service Mesh:

1. הפצה של בסיס האמון של רשות האישורים של Cloud Service Mesh.

   1. מתקינים מהדורה חדשה של רמת הבקרה שמשתמשת ב-Istio CA עם אפשרות שתפיץ את שורש האמון של רשות האישורים של Cloud Service Mesh.

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

2. מעבר ל-Certificate Authority של Cloud Service Mesh. עכשיו, כשכל שרתי ה-proxy של קובצי העזר מוגדרים עם שורש האמון הישן ועם שורש האמון של רשות אישורי Cloud Service Mesh, אפשר לבצע מיגרציה לרשות אישורי Cloud Service Mesh בלי השבתה. שוב, פועלים לפי תהליך ההעברה שמבוסס על עדכונים:

   1. התקנת מהדורה של מישור הבקרה עם רשות אישורים (CA) של Cloud Service Mesh מופעלת.

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

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

הפצת שורש האמון של רשות האישורים של Cloud Service Mesh

לפני שתוכלו לבצע מיגרציה לרשות אישורים של Cloud Service Mesh, כל אשכולות GKE ב-mesh צריכים להיות בגרסה Cloud Service Mesh 1.10 ואילך, וכל האשכולות צריכים להיות מוגדרים עם אפשרות של מישור בקרה שמפעילה את שורש האמון של רשות האישורים של Cloud Service Mesh, כדי שיופץ לשרתי ה-proxy של כל עומסי העבודה באשכול. בסיום התהליך, כל שרת proxy מוגדר עם שורש האמון הישן וגם עם שורש האמון החדש. בשיטה הזו, כשמבצעים מיגרציה לרשות האישורים של Cloud Service Mesh, עומסי עבודה שמשתמשים ברשות האישורים של Cloud Service Mesh יוכלו לבצע אימות עם עומסי עבודה שמשתמשים ברשות האישורים הישנה.

התקנת גרסה חדשה של מישור הבקרה

להתקין מהדורה של מישור הבקרה עם אפשרות שמפיצה את שורש האמון של רשות האישורים של Cloud Service Mesh.

1. פועלים לפי השלבים במאמר התקנת כלים תלויי-הקשר ואימות האשכול כדי להתכונן לשימוש בכלי שסופק על ידי Google, ‏ asmcli, להתקנת הגרסה החדשה של מישור הבקרה.

2. מוודאים שיש לכם את הגרסה של asmcli שמתקינה את Cloud Service Mesh 1.11 ואילך:

   ./asmcli --version
   

3. מריצים את asmcli install. בפקודה הבאה, מחליפים את ה-placeholders בערכים שלכם.

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --enable_all \
      --ca citadel \
      --ca_cert CA_CERT_FILE_PATH \
      --ca_key CA_KEY_FILE_PATH \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH \
      --option ca-migration-citadel \
      --revision_name REVISION_1 \
      --output_dir DIR_PATH
   

• ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
• ‫--kubeconfig הנתיב אל קובץ kubeconfig. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
• --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לתיקייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
• --enable_all מאפשר לכלי:
  • נותנים את הרשאות ה-IAM הנדרשות.
  • מפעילים את ממשקי Google API הנדרשים.
  • מגדירים תווית באשכול שמזהה את הרשת.
  • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
• -ca citadel כדי למנוע השבתה, מציינים את Istio CA (האפשרות `citadel` מתאימה ל-Istio CA). בשלב הזה, אל תעברו לרשות האישורים של Cloud Service Mesh.
• ‫--ca_cert אישור הביניים.
• --ca_key המפתח של אישור הביניים
• ‫--root_cert אישור הבסיס.
• --cert_chain שרשרת האישורים.
• --option ca-migration-citadel כשפורסים מחדש את עומסי העבודה, האפשרות הזו מפעילה את הפצת שורש האמון החדש לפרוקסי מסוג sidecar של עומסי העבודה.
• ‫REVISION_1: מומלץ. תווית של עדכון היא צמד מפתח/ערך שמוגדר במישור הבקרה. המפתח של תווית התיקון הוא תמיד istio.io/rev. כברירת מחדל, הכלי מגדיר את הערך של תווית התיקון בהתאם לגרסה של Cloud Service Mesh, לדוגמה: asm-11910-9. מומלץ לכלול את האפשרות הזו ולהחליף את REVISION_1 בשם שמתאר את ההתקנה, כמו asm-11910-9-distribute-root. השם צריך להיות תווית DNS-1035, והוא צריך לכלול אותיות קטנות, מספרים או -, להתחיל באות ולהסתיים באות או במספר (למשל my-name או abc-123).

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

כדי לסיים את ההפצה של שורש האמון החדש, צריך להוסיף תווית ל-namespaces עם תווית התיקון istio.io/rev=<var>REVISION_1</var>-distribute-root ולהפעיל מחדש את עומסי העבודה. כשבודקים את עומסי העבודה אחרי שמפעילים אותם מחדש, מריצים כלי כדי לוודא שפרוקסי ה-sidecar מוגדר עם שורש האמון הישן והחדש עבור רשות אישורים של Cloud Service Mesh.

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

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --region=CLUSTER_LOCATION
   

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

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
   

3. מגדירים את הביט של קובץ ההפעלה בכלי:

   chmod +x migrate_ca
   

4. הכלי migrate_ca קורא ל-istioctl, והפעולה תלויה בגרסה. הכלי asmcli מוסיף קישור סמלי ל-istioctl בספרייה שציינתם עבור --output_dir. מוודאים שהספרייה נמצאת בתחילת הנתיב. בפקודה הבאה, מחליפים את ISTIOCTL_PATH בספרייה שמכילה את istioctl שהכלי הוריד.

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

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

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

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

   NAME                                                             READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
   istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
   istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
   istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
   istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
   istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

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

   2. אחרי שמסיימים להעביר את עומסי העבודה לגרסה החדשה, צריך למחוק את הגרסה הקודמת של istiod. שימו לב לערך בתווית של הגרסה הקודמת istiod. פלט לדוגמה שמציג העברה מ-Istio, שמשתמש בגרסה default.

6. מוסיפים את תווית התיקון למרחב שמות ומסירים את התווית istio-injection (אם היא קיימת). בפקודה הבאה, מחליפים את NAMESPACE במרחב השמות שרוצים לתייג.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite

   אם מופיע "istio-injection not found" בפלט, אפשר להתעלם ממנו. כלומר, במרחב השמות לא הייתה קודם התווית istio-injection. ההתנהגות של הזרקה אוטומטית לא מוגדרת כשמרחב שמות כולל גם את istio-injection וגם את תווית הגרסה. לכן, כל הפקודות kubectl label במסמכי Cloud Service Mesh מוודאות במפורש שרק אחת מהן מוגדרת.

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

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

10. מוודאים שפרוקסי מסוג sidecar לכל עומסי העבודה באשכול מוגדרים עם אישורי הבסיס הישנים והחדשים:

    ./migrate_ca check-root-cert
    

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

    Namespace: foo
    httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
    sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]

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

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

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

    השלמת המעבר

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

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

    2. מגדירים את ה-webhook לאימות לשימוש במישור הבקרה החדש.

       kubectl apply -f asm/istio/istiod-service.yaml
       

    3. מוחקים את 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
       

    4. מחיקת הגרסה הקודמת של 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
       

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

       kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
       

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

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

    רולבק

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

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

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

    3. מוודאים שתווית השינוי במרחב השמות זהה לתווית השינוי בגרסה הקודמת של istiod:

       kubectl get ns NAMESPACE --show-labels
       

    4. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההחדרה, כך שלפרוקסי תהיה הגרסה הקודמת:

       kubectl rollout restart deployment -n NAMESPACE
       

    5. מסירים את הפריסה החדשה istio-ingressgateway.

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
       

    6. הסרת הגרסה החדשה של istiod.

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

    7. מסירים את ההגדרה החדשה של IstioOperator.

       kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system
       

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

       istiooperator.install.istio.io "installed-state-asm-11910-9-distribute-root" deleted

מעבר לרשות אישורים של Cloud Service Mesh

עכשיו, כשפרוקסי ה-sidecar לכל עומסי העבודה מוגדרים עם ה-Root of Trust הישן וגם עם ה-Root of Trust החדש של רשות האישורים של Cloud Service Mesh, השלבים להעברה אל רשות האישורים של Cloud Service Mesh דומים לאלה שביצעתם כדי להפיץ את ה-Root of Trust של רשות האישורים של Cloud Service Mesh:

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

משתמשים ב-asmcli install כדי להתקין גרסה חדשה של מישור הבקרה שמופעל בה Mesh CA.

1. אם התאמתם אישית את ההתקנה הקודמת, תצטרכו לציין את אותם קובצי שכבת-העל כשמריצים את הפקודה asmcli install.

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

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --output_dir DIR_PATH \
      --enable_all \
      --ca mesh_ca \
      --option ca-migration-meshca \
     --revision_name REVISION_2 \
     OVERLAYS
   

   • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של Fleet.
   • ‫--kubeconfig הנתיב אל קובץ kubeconfig אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
   • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את anthos-service-mesh החבילה ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת asmcli, הקבצים יורדים לתיקייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
   • --enable_all מאפשר לכלי:
     • נותנים את הרשאות ה-IAM הנדרשות.
     • מפעילים את ממשקי Google API הנדרשים.
     • מגדירים תווית באשכול שמזהה את הרשת.
     • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
   • --ca mesh_ca עכשיו אפשר לעבור לרשות האישורים של Cloud Service Mesh, כי שורש האמון של רשות האישורים של Cloud Service Mesh הופץ.
   • REVISION_2 מומלץ. מחליפים את REVISION_2 בשם שמתאר את ההתקנה, כמו asm-11910-9-meshca-ca-migration. השם צריך להיות תווית DNS-1035, והוא צריך לכלול אותיות קטנות, מספרים או -, להתחיל באות ולהסתיים באות או במספר (למשל my-name או abc-123).
   • --option ca-migration-migration כש[פורסים מחדש את עומסי העבודה](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads), האפשרות הזו מגדירה את ה-proxies כך שישתמשו בבסיס האמון של רשות האישורים של Cloud Service Mesh.

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

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

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

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

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

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

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

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

2. מוסיפים את תווית הגרסה החדשה למרחב שמות. בפקודה הבאה, מחליפים את NAMESPACE במרחב השמות שרוצים לתייג.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
   

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

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

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

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

   השלמת המעבר

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

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

   2. מגדירים את ה-webhook לאימות לשימוש במישור הבקרה החדש.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. מוחקים את istio-ingressgatewayהפריסה הישנה. בפקודה הבאה, מחליפים את OLD_REVISION בתווית של הגרסה הקודמת של istio-ingressgateway.

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

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

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

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

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

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

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

   רולבק

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

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

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

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
      

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

      namespace/NAMESPACE labeled

   3. מוודאים שתווית השינוי במרחב השמות זהה לתווית השינוי בגרסה הקודמת של istiod:

      kubectl get ns NAMESPACE --show-labels
      

   4. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההחדרה, כך שלפרוקסי תהיה הגרסה הקודמת:

      kubectl rollout restart deployment -n NAMESPACE
      

   5. מסירים את הפריסה החדשה istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
      

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

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

   7. מסירים את הגרסה החדשה של ההגדרה IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
      

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

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

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

1. שומרים את הסודות למקרה שתצטרכו אותם:

   kubectl get secret/cacerts -n istio-system -o yaml > save_file_1
   

2. מסירים את הסודות של רשות האישורים במקבץ שמשויך לרשות האישורים הישנה:

   kubectl delete secret cacerts -n istio-system --ignore-not-found
   

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

   kubectl rollout restart deployment -n istio-system