התקנת Cloud Service Mesh לעומסי עבודה ב-Kubernetes Google Cloud

בדף הזה מוסבר איך להתקין את Cloud Service Mesh לא מנוהל בתוך אשכול עבור עומסי עבודה של Kubernetes ב- Google Cloud:

• מריצים את הפקודה asmcli כדי להתקין מחדש את Cloud Service Mesh 1.22.8-asm.5.
• אפשר גם לפרוס שער כניסה.
• פורסים או פורסים מחדש את עומסי העבודה כדי להחדיר פרוקסי מסוג sidecar.

אם אתם צריכים להתקין Cloud Service Mesh לא מנוהל בתוך האשכול עם istiodמישור בקרה ב-GKE, תוכלו לעיין במאמר התקנה של Cloud Service Mesh בתוך האשכול ב- Google Cloud. הערה: לעומסי עבודה (workload) של Kubernetes ב-Google Cloud, מומלץ להקצות רמת בקרה מנוהלת

הוראות להכנת התקנה אופליין של Cloud Service Mesh מפורטות במאמר הכנת התקנה אופליין של Cloud Service Mesh. כשמריצים את הפקודה asmcli install, צריך לציין את האפשרויות --offline ו---output_dir.

מגבלות

חשוב לשים לב למגבלות הבאות:

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

• לכלי asmcli צריכה להיות גישה לנקודת הקצה של Google Kubernetes Engine‏ (GKE). אפשר להגדיר גישה דרך שרת מעבר, כמו מכונה וירטואלית של Compute Engine בענן הווירטואלי הפרטי (VPC), כדי לתת גישה ספציפית.

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

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

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

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

בטבלה הבאה מפורטים התפקידים שנדרשים להתקנה של Cloud Service Mesh בתוך האשכול.

שם התפקיד	מזהה תפקיד	Grant location	תיאור
אדמין GKE Hub	roles/gkehub.admin	פרויקט צי	גישה מלאה ל-GKE Hub ולמשאבים קשורים.
Kubernetes Engine Admin	roles/container.admin	פרויקט של אשכול. שימו לב: צריך להעניק את התפקיד הזה גם ב-Fleet וגם בפרויקט האשכול כדי ליצור קשרים בין פרויקטים.	התפקיד הזה מספק גישה לניהול מלא של אשכולות קונטיינרים ואובייקטים שלהם ב-Kubernetes API.
Mesh Config Admin	roles/meshconfig.admin	פרויקט Fleet ופרויקט אשכול	ההרשאות הנדרשות לאתחול רכיבים מנוהלים של Cloud Service Mesh, כמו רמת בקרה מנוהלת והרשאת קצה עורפי שמאפשרת לעומסי עבודה לתקשר עם Stackdriver בלי שכל אחד מהם יקבל הרשאה בנפרד (גם לרמות בקרה מנוהלות וגם לרמות בקרה בתוך האשכול).
אדמין IAM של פרויקט	roles/resourcemanager.projectIamAdmin	פרויקט אשכול	הרשאות לניהול מדיניות IAM בפרויקטים.
אדמין בחשבון שירות	roles/iam.serviceAccountAdmin	פרויקט צי	אימות כחשבון שירות.
אדמין בתפקיד ניהול שירותים	roles/servicemanagement.admin	פרויקט צי	שליטה מלאה במשאבים של ניהול שירותי Google.
אדמין של שימוש בשירות	roles/serviceusage.serviceUsageAdmin	פרויקט צי	אפשרות להפעיל, להשבית ולבדוק את מצבי השירות, לבדוק פעולות ולצרוך מכסה וחיוב בפרויקט צרכן.(הערה 1)
אדמין של שירות CA‏ בטא	roles/privateca.admin	פרויקט צי	גישה מלאה לכל המשאבים של שירות CA. (הערה 2)

הערות:

1. אדמין של Service Usage – התפקיד הזה נדרש כתנאי מוקדם להפעלת mesh.googleapis.com API כשמבצעים הקצאת משאבים ראשונית של Cloud Service Mesh מנוהל.
2. אדמין של שירות CA – התפקיד הזה נדרש רק אם אתם משלבים עם שירות CA.

התקנה של Cloud Service Mesh

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

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

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

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

4. אם אתם מתקינים את Cloud Service Mesh ביותר מאשכול אחד, מריצים את הפקודה asmcli install בכל אשכול. כשמריצים את הפקודה asmcli install, חשוב להשתמש באותו FLEET_PROJECT_ID לכל אשכול. אחרי שמתקינים את Cloud Service Mesh, אפשר לעיין בהוראות להגדרת רשת מרובת אשכולות ב Google Cloud.

5. אם האשכולות שלכם נמצאים ברשתות שונות (כמו במצב איים), צריך להעביר שם רשת ייחודי ל-asmcli באמצעות הדגל --network_id.

התקנה של תכונות ברירת מחדל ו-Mesh CA

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

התקנה של תכונות ברירת המחדל ושירות רשות האישורים (CA)

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

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

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

העלות של רשות האישורים של Cloud Service Mesh כלולה בתמחור של Cloud Service Mesh. שירות ה-CA לא נכלל במחיר הבסיסי של Cloud Service Mesh, והוא מחויב בנפרד. בנוסף, שירות CA מגיע עם SLA מפורש, אבל רשות האישורים של Cloud Service Mesh לא מגיעה עם SLA.

הגדרת שירות רשות האישורים

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

3. אם רוצים שהמאגר ישמש רק להנפקת אישורים לעומסי עבודה של Cloud Service Mesh, צריך להגדיר את מדיניות ההנפקה הבאה למאגר CA:

   policy.yaml

   baselineValues:
     keyUsage:
       baseKeyUsage:
         digitalSignature: true
         keyEncipherment: true
       extendedKeyUsage:
         serverAuth: true
         clientAuth: true
     caOptions:
       isCa: false
   identityConstraints:
     allowSubjectPassthrough: false
     allowSubjectAltNamesPassthrough: true
     celExpression:
       expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
   

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

   gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
   

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

5. אם אתם משתמשים בתבנית אישור, צריך להגדיר אותה עכשיו. מידע נוסף זמין במדריך CA Service בנושא אישורים לזיהוי עומסי עבודה. מוודאים שתבנית האישור נוצרה באותו אזור שבו נוצר מאגר רשויות האישורים. אם יש כמה אזורים למאגרי רשויות אישורים, צריך ליצור תבנית אישור לכל אזור.

הגדרת Cloud Service Mesh לשימוש בשירות CA

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

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/CA_POOL_PROJECT_ID/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 לשימוש בזהות עומס עבודה של Fleet
   • ‫--ca_pool המזהה המלא של מאגר רשויות האישורים בשירות Certificate Authority Service. אם אתם משתמשים בתבנית אישור, צריך להוסיף את מזהה התבנית אחרי :. לדוגמה:

       --ca_pool projects/CA_POOL_PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/CA_POOL_PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID
       

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

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

בקטע הזה נסביר איך:

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

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

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

קובץ ה-Makefile ליצירת האישורים נמצא בספריית המשנה istio-1.22.8-asm.5 בספרייה --output_dir שציינתם בפקודה asmcli validate. אם לא הפעלתם את asmcli validate, או אם אין לכם את הספרייה שהורדתם באופן מקומי, תוכלו להוריד את קובץ ההתקנה של Cloud Service Mesh ולחלץ את התוכן כדי לקבל את קובץ ה-Makefile.

1. עוברים לספרייה istio-1.22.8-asm.5.

2. יוצרים ספרייה עבור האישורים והמפתחות:

   mkdir -p certs && \
   pushd certs

3. יוצרים אישור בסיס ומפתח:

   make -f ../tools/certs/Makefile.selfsigned.mk root-ca
   

   המערכת יוצרת את הקבצים הבאים:

   • ‫root-cert.pem: אישור הבסיס
   • ‫root-key.pem: מפתח הבסיס
   • ‫root-ca.conf: ההגדרה של openssl ליצירת אישור הבסיס
   • ‫root-cert.csr: בקשת ה-CSR לאישור הבסיס

4. יוצרים אישור ומפתח ביניים:

   make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

   הפעולה הזו יוצרת את הקבצים האלה בספרייה בשם cluster1:

   • ‫ca-cert.pem: אישורי הביניים
   • ‫ca-key.pem: המפתח של רשות האישורים ברמת הביניים
   • ‫cert-chain.pem: שרשרת האישורים שבה נעשה שימוש ב-istiod
   • ‫root-cert.pem: אישור הבסיס

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

5. חזרה לספרייה הקודמת:

   popd

6. מריצים את הפקודה asmcli כדי להתקין רשת באמצעות Istio CA:

   מקומי

   מריצים את הפקודות הבאות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware או ב-Google Distributed Cloud (תוכנה בלבד) ל-bare metal כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ו-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 CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain 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 עבור רשת המשנה הציבורית או רשת המשנה הפרטית.

   גלוי לכולם

   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 CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain 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 שרשרת האישורים.

   פרטי

   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 מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--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 שרשרת האישורים.
      • ‫--custom_overlay השם של קובץ השכבות שהתקבל. מידע נוסף על קובצי שכבת-על זמין במאמר בנושא הפעלת תכונות אופציונליות במישור הבקרה בתוך האשכול

   Azure

   מריצים את הפקודות הבאות ב-GKE ב-Azure כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ואת 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 CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain 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 שרשרת האישורים.

   פרטי

   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 מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--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 שרשרת האישורים.
      • ‫--custom_overlay השם של קובץ השכבות שהתקבל. מידע נוסף על קובצי שכבת-על זמין במאמר בנושא הפעלת תכונות אופציונליות במישור הבקרה בתוך האשכול

   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 \
        --option attached-cluster \
        --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 \
        --network_id default
      

      • ‫--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 אם הוא עדיין לא רשום.
      • --option attached-cluster שינוי כלי החתימה שמוגדר כברירת מחדל ל-istiod.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • --ca_cert אישור הביניים
      • --ca_key המפתח של אישור הביניים
      • --root_cert אישור הבסיס
      • --cert_chain שרשרת האישורים
      • --network_id אם מגדירים רשת Mesh מרובת רשתות, צריך להגדיר את --network_id לערך ייחודי לכל אשכול ברשת ה-Mesh.

   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 \
        --option attached-cluster \
        --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 \
        --network_id default
      

      • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer מאפשר רישום ב-GKE Hub.
      • ‫--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 אם הוא עדיין לא רשום.
      • --option attached-cluster שינוי כלי החתימה שמוגדר כברירת מחדל ל-istiod.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • --ca_cert אישור הביניים
      • --ca_key המפתח של אישור הביניים
      • --root_cert אישור הבסיס
      • --cert_chain שרשרת האישורים
      • --network_id אם מגדירים רשת Mesh מרובת רשתות, צריך להגדיר את --network_id לערך ייחודי לכל אשכול ברשת ה-Mesh.

התקנה עם רשות אישורים (CA) של Istio עם Google Cloud Observability מופעל

כדי להשתמש בלוחות הבקרה של Cloud Service Mesh, צריך להפעיל את Stackdriver.

התקנה עם תכונות אופציונליות

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

יש שתי אפשרויות להפעלת תכונות אופציונליות: --option ו- --custom_overlay.

משתמשים ב---option אם לא צריך לשנות את קובץ השכבה. בשיטה הזו, asmcliמאחזר את הקובץ ממאגר GitHub בשבילכם.

משתמשים ב---custom_overlay כשרוצים להתאים אישית את קובץ השכבת-העל.

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

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

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

   kubectl config use-context CLUSTER_NAME
   

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

   ./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 כך שתשתמש בWorkload Identity של fleet
   • --custom_overlay מציינים את השם של קובץ השכבה.

התקנת שערים

בעזרת Cloud Service Mesh, יש לכם אפשרות לפרוס ולנהל שערים כחלק מ-Service mesh. שער מתאר מאזן עומסים שפועל בקצה של רשת ה-mesh ומקבל חיבורי HTTP/TCP נכנסים או יוצאים. שערי מעבר הם שרתי proxy של Envoy שמאפשרים לכם שליטה פרטנית בתנועה שנכנסת לרשת ובזו שיוצאת ממנה.

1. יוצרים מרחב שמות לשער הכניסה (ingress), אם עדיין אין כזה. שערי מעבר הם עומסי עבודה של משתמשים, ולכן מומלץ שלא לפרוס אותם במרחב השמות של מישור הבקרה. מחליפים את GATEWAY_NAMESPACE בשם של מרחב השמות.

   kubectl create namespace GATEWAY_NAMESPACE
   

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

   namespace/GATEWAY_NAMESPACE created
   

2. מפעילים הזרקה אוטומטית בשער. השלבים הנדרשים תלויים בשאלה אם רוצים להשתמש בתוויות ברירת מחדל להוספה (למשל, istio-injection=enabled) או בתווית של עדכון במרחב השמות של השער. תג ברירת המחדל של הגרסה ותווית הגרסה משמשים את ה-webhook של sidecar injector כדי לשייך פרוקסי מוזרקים לגרסה מסוימת של מישור הבקרה.

   ברירת מחדל (מומלץ)

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

      DIR_PATH/istioctl tag list
      

   2. החלת תוויות ברירת המחדל להוספה למרחב השמות.

      kubectl label namespace GATEWAY_NAMESPACE istio-injection=enabled istio.io/rev-
      

   תווית גרסה

   1. משתמשים בפקודה הבאה כדי לאתר את תווית הגרסה ב-istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
        "jsonpath={.items[*].metadata.labels['istio\.io/rev']}{'\n'}"
      

      הפלט של הפקודה כולל את תווית הגרסה שתואמת לגרסה של Cloud Service Mesh, לדוגמה: asm-1228-5

   2. מחילים את תווית הגרסה על מרחב השמות. בפקודה הבאה, REVISION הוא הערך של התווית istiod revision שרשמתם בשלב הקודם.

      kubectl label namespace GATEWAY_NAMESPACE \
        istio.io/rev=REVISION --overwrite
      

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

      namespace/GATEWAY_NAMESPACE labeled
      

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

   אם מרחב השמות של השער לא מסומן, ה-pods‏ istio-ingressgateway ייכשלו עם שגיאת ImagePullBackOff כשהשער ינסה למשוך את התמונה auto. התמונה הזו צריכה להיות מוחלפת על ידי ה-webhook.

3. מורידים את קובץ התצורה לדוגמה של שער הכניסה מסוג .yaml ממאגר anthos-service-mesh-packages.

4. משתמשים בהגדרת ה-YAML של שער הכניסה לדוגמה כמו שהיא, או משנים אותה לפי הצורך.

   kubectl apply -n GATEWAY_NAMESPACE \
     -f CONFIG_PATH/istio-ingressgateway
   

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

   deployment.apps/istio-ingressgateway created
   poddisruptionbudget.policy/istio-ingressgateway created
   horizontalpodautoscaler.autoscaling/istio-ingressgateway created
   role.rbac.authorization.k8s.io/istio-ingressgateway created
   rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
   service/istio-ingressgateway created
   serviceaccount/istio-ingressgateway created
   

מידע נוסף על שיטות מומלצות לשימוש בשערי תשלום

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

‫Cloud Service Mesh משתמש בפרוקסי מסוג sidecar כדי לשפר את אבטחת הרשת, המהימנות והניראות (observability). ב-Cloud Service Mesh, הפונקציות האלה מופשטות מהקונטיינר הראשי של האפליקציה ומיושמות בשרת Proxy משותף מחוץ לתהליך, שמועבר כקונטיינר נפרד באותו Pod.

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

כדי להפעיל הוספה אוטומטית, צריך להוסיף את תוויות ברירת המחדל להוספה למרחבי השמות אם תג ברירת המחדל מוגדר, או תווית של עדכון שהוגדרה ב-istiod כשמתקינים את Cloud Service Mesh. תג ברירת המחדל של הגרסה ותווית הגרסה משמשים את ה-webhook של הזרקת קובץ העזר כדי לשייך קובץ עזר מוזרק לגרסה istiod. אחרי שמוסיפים את התווית, צריך להפעיל מחדש את כל ה-Pods הקיימים במרחב השמות כדי להחדיר את ה-sidecars.

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

1. השלבים שנדרשים להפעלת ההוספה האוטומטית תלויים בתוויות ההוספה שרוצים להשתמש בהן: ברירת המחדל או התווית של הגרסה.

   ברירת מחדל (מומלץ)

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

      DIR_PATH/istioctl tag list
      

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

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

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

   תווית גרסה

   1. משתמשים בפקודה הבאה כדי לאתר את תווית הגרסה ב-istiod:

      kubectl -n istio-system get pods -l app=istiod --show-labels
      

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

      NAME                                READY   STATUS    RESTARTS   AGE   LABELS
      istiod-asm-1228-5-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1228-5,istio=istiod,pod-template-hash=5788d57586
      istiod-asm-1228-5-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1228-5,istio=istiod,pod-template-hash=5788d57586

      בפלט, בעמודה LABELS, שימו לב לערך של istiodתווית הגרסה, שמופיע אחרי התחילית istio.io/rev=. בדוגמה הזו, הערך הוא asm-1228-5.

   2. מחילים את תווית הגרסה ומסירים את התווית istio-injection אם היא קיימת. בפקודה הבאה, NAMESPACE הוא שם מרחב השמות שבו רוצים להפעיל הוספה אוטומטית, ו-REVISION היא תווית הגרסה שרשמתם בשלב הקודם.

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

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

2. אם עומסי עבודה פעלו באשכול לפני שהתקנתם את Cloud Service Mesh, צריך להפעיל מחדש את ה-Pods כדי להפעיל הזרקה מחדש.

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

   אפשר להשתמש ב-kubectl כדי לבצע הפעלה מחדש מדורגת:

   kubectl rollout restart deployment -n NAMESPACE
   

מה השלב הבא?

• אם הרשת שלכם כוללת אשכולות מחוץ ל- Google Cloud, אפשר לעיין במאמר בנושא הגדרת רשת מרובת אשכולות מחוץ ל- Google Cloud.

• הגדרת כתובת IP חיצונית בפריסה מקומית

• פריסת אפליקציית הדוגמה Online Boutique.