דרישות מוקדמות ל-Cloud Service Mesh בתוך האשכול

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

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

פתיחת פרויקט ב-Cloud

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

• בוחרים או יוצרים Google Cloud פרויקט.

• מוודאים שהחיוב מופעל בפרויקט.

דרישות כלליות

• כדי שיציאות של שירות ייכללו ב-Service mesh, צריך לתת להן שם, והשם צריך לכלול את הפרוטוקול של היציאה בתחביר הבא: name: protocol[-suffix] הסוגריים המרובעים מציינים סיומת אופציונלית שחייבת להתחיל במקף. מידע נוסף זמין במאמר בנושא מתן שמות ליציאות של שירותים.

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

• אם רוצים לשנות את מגבלות ברירת המחדל על משאבים של קובץ ה-sidecar ‏istio-proxy, הערכים החדשים צריכים להיות גדולים יותר מערכי ברירת המחדל כדי למנוע אירועים של חוסר זיכרון (OOM).

• לכל פרויקט ב- Google Cloud יכולה להיות משויכת רק רשת אחת.

הדרישות לגבי אשכולות

• מוודאים שלאשכול המשתמשים שבו מתקינים את Cloud Service Mesh יש לפחות 4 מעבדי vCPU,‏ 15GB של זיכרון ו-4 צמתים.

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

• מוודאים שלמחשב הלקוח שממנו מתקינים את Cloud Service Mesh יש קישוריות לרשת לשרת ה-API.

• אם אתם פורסים קבצי sidecar בתרמילי אפליקציות שבהם אין קישוריות ישירה לשירותי CA (כמו meshca.googleapis.com ו-privateca.googleapis.com), אתם צריכים להגדיר שרת proxy מבוסס-CONNECT ל-HTTPS.

• אם מוגדרים כללי חומת אש לתעבורת נתונים יוצאת (egress) באשכולות ציבוריים שחוסמים כללים משתמעים, צריך לוודא שהגדרתם כללי HTTP/HTTPS ו-DNS כדי להגיע ל-Google APIs ציבוריים.

דרישות לציוד

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

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

• ‫GKE clusters outside Google Cloud: ‫(applies to in-cluster Cloud Service Mesh) ‫Google Distributed Cloud (software only) for VMware, ‫Google Distributed Cloud (software only) for bare metal, ‫GKE on AWS (deprecated), and ‫GKE on Azure (deprecated) are automatically registered to your project fleet at cluster creation time. החל מ-GKE Enterprise 1.8, בכל סוגי האשכולות האלה מופעלת באופן אוטומטי Workload Identity של צי כלי הרכב כשנרשמים. אשכולות רשומים קיימים מתעדכנים לשימוש ב-Workload Identity של Fleet כשהם משודרגים ל-GKE Enterprise 1.8.
• קלאסטרים של Amazon EKS (הוצא משימוש): (רלוונטי ל-Cloud Service Mesh בתוך הקלאסטר) לקלאסטר צריך להיות ספק זהויות ציבורי של IAM OIDC. פועלים לפי ההוראות במאמר יצירת ספק IAM OIDC לאשכול כדי לבדוק אם קיים ספק, וליצור ספק אם צריך.

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

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

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

מה השלב הבא?

• תכנון התקנה חדשה
• תכנון שדרוג