העברה מבוססת-קנרי ל-Mesh CA

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

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

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

מגבלות

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

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

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

כלים נדרשים

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

  • אישור הבסיס של Istio CA ו-Mesh CA.
  • אישור mTLS של עומס העבודה שהונפק על ידי Istio CA ועל ידי Mesh CA.
  • דומייני האמון שהוגדרו על ידי Istio CA ו-Mesh CA.

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

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

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

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

בקטע הבא מפורט תהליך ההעברה אל Mesh CA:

  1. הפצה של ה-root of trust של Mesh CA.

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

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

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

    1. מתקינים מהדורה של מישור הבקרה עם Mesh CA מופעל.

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

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

הפצה של רשות אישורים (CA) עליונה של רשת Mesh

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

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

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

  1. פועלים לפי השלבים במאמר Install dependent tools and validate cluster (התקנת כלים תלויי-הקשר ואימות האשכול) כדי להתכונן לשימוש בכלי שסופק על ידי 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, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לתיקייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
  • --enable_all מאפשר לכלי:
    • מעניקים את הרשאות ה-IAM הנדרשות.
    • מפעילים את ממשקי Google API הנדרשים.
    • מגדירים תווית באשכול שמזהה את הרשת.
    • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.

  • -ca citadel כדי למנוע השבתה, מציינים את Istio CA (האפשרות citadel מתאימה ל-Istio CA). בשלב הזה, אל תעברו ל-Mesh CA.
  • --ca_cert אישור הביניים.
  • --ca_key המפתח של אישור הביניים
  • --root_cert אישור הבסיס.
  • --cert_chain שרשרת האישורים.
  • --option ca-migration-citadel כשפורסים מחדש את עומסי העבודה, האפשרות הזו מפעילה את הפצת שורש האמון החדש לפרוקסי מסוג sidecar של עומסי העבודה.
  • ‫REVISION_1: מומלץ. תווית של עדכון היא צמד מפתח/ערך שמוגדר במישור הבקרה. מפתח תווית הגרסה הוא תמיד istio.io/rev. כברירת מחדל, הכלי מגדיר את הערך של תווית התיקון על סמך הגרסה של Cloud Service Mesh, לדוגמה: asm-1282-4. מומלץ לכלול את האפשרות הזו ולהחליף את REVISION_1 בשם שמתאר את ההתקנה, כמו asm-1282-4-distribute-root. השם חייב להיות תווית DNS-1035, והוא צריך לכלול תווים אלפאנומריים באותיות קטנות או -, להתחיל בתו אלפביתי ולהסתיים בתו אלפאנומרי (כמו my-name או abc-123).

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

כדי לסיים את הפצת שורש האמון החדש, צריך להוסיף את התווית של המרחבים לשמות עם תווית הגרסה istio.io/rev=<var>REVISION_1</var>-distribute-root ולהפעיל מחדש את עומסי העבודה. כשבודקים את עומסי העבודה אחרי שמפעילים אותם מחדש, מריצים כלי כדי לוודא שפרוקסי ה-sidecar מוגדר עם Root of Trust (קיצור: RoT) הישן והחדש של רשת הרשות שמנפיקה את האישורים (CA).

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

    • משתמשים ב-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-1282-4-distribute-root -n istio-system

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

      istiooperator.install.istio.io "installed-state-asm-1282-4-distribute-root" deleted

מעבר ל-Mesh CA

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

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

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

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

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

     ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --output_dir DIR_PATH \
   --enable_all \
   --ca mesh_ca \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH
   --option ca-migration-meshca \
  --revision_name REVISION_2 \
  --output_dir DIR_PATH \
  OVERLAYS
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב אל הקובץ kubeconfig. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • ‫--output_dir Include this option to specify a directory where asmcli downloads the anthos-service-mesh package and extracts the installation file, which contains istioctl, samples, and manifests. אחרת, הקבצים יורדים לתיקייה asmcli.tmp אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --enable_all מאפשר לכלי:
        • מעניקים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.

      • --ca mesh_ca עכשיו אפשר לעבור ל-Mesh CA כי שורש האמון של Mesh CA הופץ.
      • מומלץ: REVISION_2 מחליפים את REVISION_2 בשם שמתאר את ההתקנה, כמו asm-1282-4-meshca-ca-migration. השם חייב להיות תווית DNS-1035, והוא צריך לכלול תווים אלפאנומריים באותיות קטנות או -, להתחיל בתו אלפביתי ולהסתיים בתו אלפאנומרי (למשל my-name או abc-123).
      • --option ca-migration-migration כשפורסים מחדש את עומסי העבודה, האפשרות הזו מגדירה את שרתי ה-proxy כך שישתמשו בשורש האמון של Mesh CA.

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

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

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

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

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

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

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

    2. שימו לב גם לערך בתווית הגרסה של הגרסה הישנה של istiod. תצטרכו את זה כדי למחוק את הגרסה הישנה של istiod אחרי שתסיימו להעביר את עומסי העבודה לגרסה החדשה. בדוגמה, הערך של תווית הגרסה של הגרסה הקודמת הוא asm-1282-4-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

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

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

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

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

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

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

    kubectl rollout restart deployment -n istio-system