תכנון שדרוג

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

בדף הזה תמצאו מידע שיעזור לכם לתכנן שדרוג של Cloud Service Mesh. מומלץ גם לעיין בהערות השדרוג של Istio.

מידע על שדרוגי גרסת גישושים

מומלץ לשדרג את Cloud Service Mesh על ידי הפעלת פריסה של גרסה ראשונית (canary) של מישור הבקרה החדש. בשדרוג גרסה ראשונית (canary),‏ asmcli מתקין גרסה חדשה של מישור הבקרה לצד מישור הבקרה הישנה. גם מישור הבקרה הישן וגם מישור הבקרה החדש מסומנים בתווית revision, שמשמשת כמזהה של מישורי הבקרה.

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

1. מגדירים את התווית revision של מישור הבקרה החדש באחד ממרחבי השמות.

2. מבצעים הפעלה מחדש מתגלגלת. ההפעלה מחדש מחדירה מחדש את ה-sidecar proxies ב-Pods כדי שהפרוקסי ישתמש במישור הבקרה החדש.

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

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

שדרוג גרסה ראשונית (canary) בטוח הרבה יותר משדרוג במקום, שבו מישור הבקרה החדש מחליף את מישור הבקרה הישן. שלבים מפורטים מופיעים במאמר בנושא מעבר למישור הבקרה החדש.

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

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

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

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

הספרייה asmcli ב-GitHub מכילה הרבה קבצים של שכבות-על. הקבצים האלה מכילים התאמות אישיות נפוצות להגדרות ברירת המחדל. אפשר להשתמש בקבצים האלה כמו שהם, או לבצע בהם שינויים נוספים לפי הצורך. חלק מהקבצים נדרשים כדי להפעיל תכונות אופציונליות של Cloud Service Mesh. חבילת anthos-service-mesh מורדת כשמריצים את asmcli כדי לאמת את הפרויקט ואת האשכול.

כשמתקינים את Cloud Service Mesh באמצעות asmcli install, אפשר לציין קובץ או כמה קובצי שכבת-על באמצעות --option או --custom_overlay. אם לא צריך לבצע שינויים בקבצים במאגר anthos-service-mesh, אפשר להשתמש באפשרות --option, והסקריפט יאחזר את הקובץ מ-GitHub בשבילכם. אחרת, אפשר לבצע שינויים בקובץ השכבה ואז להשתמש באפשרות --custom_overlay כדי להעביר אותו אל asmcli.

בחירת רשות אישורים

אם בהתקנה הנוכחית של Cloud Service Mesh נעשה שימוש ברשות האישורים (CA) של Cloud Service Mesh להנפקת אישורים של TLS דו-צדדי (mTLS), מומלץ להמשיך להשתמש ברשות האישורים של Cloud Service Mesh מהסיבות הבאות:

• ‫Cloud Service Mesh רשות אישורים הוא שירות אמין וניתן להרחבה שמותאם לעומסי עבודה שניתנים להרחבה באופן דינמי.
• בעזרת רשות האישורים של Cloud Service Mesh, ‏ Google מנהלת את האבטחה והזמינות של הקצה העורפי של רשות האישורים.
• רשות האישורים של Cloud Service Mesh מאפשרת להסתמך על Root of Trust יחיד בכל האשכולות.

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

הערה לגבי הפלטפורמה: שירות CA נתמך רק בפלטפורמות הבאות: אשכולות GKE ב- Google Cloud,‏ Google Distributed Cloud (תוכנה בלבד) ל-VMware ו-Distributed Cloud. אם מריצים את הפקודה asmcli install ומציינים את --ca gcp_cas בפלטפורמות אחרות, ההתקנה תיראה מוצלחת, אבל עומסי העבודה לא יתחילו.

האישורים מרשות האישורים של Cloud Service Mesh כוללים את הנתונים הבאים על השירותים של האפליקציה:

• Google Cloud מזהה הפרויקט
• מרחב השמות של GKE
• השם של חשבון השירות ב-GKE

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

זיהוי ה-CA

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

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

1. כדי לקבל רשימה של Pods מאחד ממרחבי השמות:

   kubectl get pods -n NAMESPACE
   

2. מחליפים את POD_NAME בשם של אחד מה-Pods בפקודה הבאה:

   kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
   

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

   - name: CA_ADDR
     value: meshca.googleapis.com:443
   

הכנת הגדרות השער

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

asmcli לא מתקין את istio-ingressgateway. מומלץ לפרוס ולנהל את רמת הבקרה ואת השערים בנפרד. מידע נוסף זמין במאמר התקנה ושדרוג של שערים.

שדרוג הפלטפורמה (אופציונלי)

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

מה השלב הבא?

• התקנת כלים תלויי-הקשר ואימות אשכולות