דרישות מוקדמות לשימוש באשכולות מחוץ ל-Google Cloud

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

• בודקים ומבינים את הרשאות הגישה של רכיבים ב-Knative serving.

• צריך לוודא שיש לכם הרשאות מתאימות ב Google Cloud פרויקט כדי לעמוד בדרישות ההתקנה של האשכול, הצי ו-Cloud Service Mesh:

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

  • שימו לב שדרישות ההרשאות של Cloud Service Mesh עומדות גם בכל דרישות ההרשאות להתקנה ולהגדרה של Knative serving.

  • שימוש בתפקידים אחרים ובדרישות המינימום:

    בהתאם לארגון, אפשר גם לעמוד בדרישות ההרשאה באמצעות שילוב של התפקידים המוגדרים מראש הבאים:

    • Google Cloud הרשאות בפרויקט: תפקיד עריכה בסיסי

    • הרשאות ב-Fleet: GKE Hub Admin או תפקיד שכולל את ההרשאות הבאות:

      • gkehub.features.create
      • gkehub.features.update

    • הרשאות באשכול: תפקיד אדמין ב-Kubernetes Engine:

      • Kubernetes Engine Admin
      • Kubernetes Engine Cluster Admin

• נדרש אשכול עם ההגדרה הבאה:

  • אשכול נתמך של Google Distributed Cloud. אם התקנתם בעבר אשכולות של Google Distributed Cloud, אתם צריכים להעביר את Knative serving ב-VMware לצי.

    ‫Preview: סביבות אחרות של אשכולות GKE מחוץ ל- Google Cloud זמינות כרגע כ-Preview. מידע נוסף

  • רשום ב-Fleet:

    מעבר לאשכולות GKE

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

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

  • Cloud Service Mesh מותקן באשכול. בנוסף, חשוב לשים לב לדרישות המוקדמות הבאות:

    • ‫Knative serving לא תומך כרגע באופן מלא במישור הבקרה של Cloud Service Mesh שמנוהל על ידי Google. במקום זאת, צריך להשתמש במישור הבקרה בתוך האשכול.
    • כדי להשתמש ב-Cloud Service Mesh, צריך להשתמש באשכול בסוג מכונה עם לפחות 4 ליבות וירטואליות (vCPU), כמו e2-standard-4. פרטים נוספים על הדרישות זמינים במדריך ההתקנה של Cloud Service Mesh. אם אתם צריכים לשנות את סוג המכונה של האשכול הקיים, אפשר לעיין במאמר העברת עומסי עבודה לסוגי מכונות שונים.
    • כדי ליהנות מהקצאת משאבים אוטומטית של דומיינים לבדיקה – Cloud Service Mesh משתמש בשער כניסה ובשירות בשם istio-ingress במרחב השמות istio-system. כדי להפעיל את יצירת השער במהלך התקנת התכונה, משתמשים ב---option legacy-default-ingressgateway של סקריפט ההתקנה asmcli.

• צריך להגדיר את סביבת שורת הפקודה.

• צריך להפעיל את ממשקי ה-API הבאים בפרויקט ב- Google Cloud :

  • ‫Kubernetes Engine API: יצירה וניהול של אפליקציות מבוססות-קונטיינרים.
  • Cloud Build API: יצירה וניהול של תהליכי build.
  • ‫Container Registry API: העברה בדחיפה ומשיכה של תמונות ב-Container Registry.

  הפעלת ממשקי ה-API ב Google Cloud מסוף