תוכנת Google Distributed Cloud בלבד מבוססת על Kubernetes, ואפשר לפרוס אותה בשרתים מקומיים ב-VMware או בשרתים פיזיים. למרות ש-Distributed Cloud פועל בפריסה מקומית, אנחנו מתכננים אותו כך שתהיה לו חיבור קבוע ל- Google Cloud מכמה סיבות, כולל ניהול ומעקב. עם זאת, יכול להיות שתצטרכו לדעת מה קורה אם מסיבה כלשהי החיבור ל- Google Cloud מתנתק(לדוגמה, בגלל בעיה טכנית). במסמך הזה מתוארת ההשפעה של אובדן קישוריות על אשכולות בפריסה של תוכנה בלבד ב-Distributed Cloud (ב-bare metal או ב-VMware), ופתרונות שאפשר להשתמש בהם במקרה כזה.
המידע הזה שימושי לארכיטקטים שצריכים להתכונן לניתוק לא מתוכנן או לניתוק בכפייה מ- Google Cloud ולהבין את ההשלכות שלו. עם זאת, לא מומלץ לתכנן שימוש בפריסת Distributed Cloud שמבוססת על תוכנה בלבד ומנותקת מ-Google Cloud כמצב עבודה רגיל. חשוב לזכור שתכננו את Distributed Cloud כך שינצל את היתרונות של המדרגיות והזמינות של Google Cloud השירותים. המסמך הזה מתבסס על העיצוב והארכיטקטורה של הרכיבים השונים של Google Cloud Distributed Cloud שפועלים בצורה תואמת במהלך הפרעה זמנית. אנחנו לא יכולים להבטיח שהמסמך הזה מקיף את כל הנושאים.
המסמך הזה מתבסס על ההנחה שאתם מכירים את GKE. אם זה לא המקרה, מומלץ לקרוא קודם את סקירת GKE.
אימות רישיון ומדידת שימוש
אם הפעלתם את Anthos API (anthos.googleapis.com) בפרויקט Google Cloud , בקר המדידה שפועל באשכול יוצר ומעדכן את זכאות הרישיון באופן תקופתי. הסבילות לניתוק היא 12 שעות. בנוסף, המערכת דורשת את החיבור כדי לנהל את המדידה והחיוב.
בטבלה הבאה מפורטת ההתנהגות של תכונות שקשורות לרישוי ולמדידה במקרה של ניתוק זמני מ- Google Cloud:
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| אימות רישיון | בקר המדידה יוצר ומעדכן את המשאב המותאם אישית של זכאות לרישיון באופן תקופתי, כל עוד anthos.googleapis.com מופעל בפרויקט Google Cloud . |
הרכיבים שצורכים את משאב ההרשאות המותאם אישית תומכים בתקופת חסד: הם ממשיכים לפעול כל עוד משאב ההרשאות המותאם אישית מתרענן במהלך תקופת החסד. | ללא הגבלה. אחרי שתקופת החסד מסתיימת, הרכיבים מתחילים לרשום שגיאות ביומן. אי אפשר יותר לשדרג את האשכול. | ללא |
| מדידה וחיוב | בקר המדידה מדווח על קיבולת ה-vCPU של האשכול ל- Google Cloud Service Control API לצורכי חיוב. | סוכן בתוך האשכול שומר את רשומות החיוב באשכול במהלך הניתוק, ומאחזר את הרשומות כשהאשכול מתחבר מחדש אל Google Cloud. | ללא הגבלה. עם זאת, נדרש מידע על מדידה לצורך עמידה בדרישות, כפי שמצוין בתנאים הספציפיים לשירות עבור 'תוכנה פרימיום'. | ללא |
מחזור החיים של אשכול
בקטע הזה מוסבר על תרחישים כמו יצירה, עדכון, מחיקה ושינוי גודל של אשכולות, וגם על מעקב אחרי הסטטוס של הפעילויות האלה.
ברוב התרחישים, אפשר להשתמש בכלים של CLI כמו bmctl, gkectl ו-kubectl כדי לבצע פעולות במהלך ניתוק זמני. אפשר גם לעקוב אחרי הסטטוס של הפעולות האלה באמצעות הכלים האלה. אחרי החיבור מחדש, המסוףGoogle Cloud מתעדכן ומציג את תוצאות הפעולות שבוצעו במהלך התקופה שבה החיבור היה מנותק.
| פעולה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| יצירת אשכול | משתמשים בכלי ה-CLI bmctl או gkectl כדי ליצור אשכולות. כדי לבצע את הפעולה הזו, צריך להתחבר אל Google Cloud. |
אי אפשר ליצור אשכולות. | אפס | ללא |
| שדרוג אשכול | משתמשים בכלי ה-CLI bmctl או gkectl כדי לשדרג אשכולות. כדי לבצע את הפעולה הזו, צריך להתחבר אל Google Cloud. |
אי אפשר לשדרג אשכולות. | אפס | ללא |
| מחיקת אשכול | משתמשים בכלי ה-CLI bmctl או gkectl כדי למחוק אשכולות. כדי לבצע את הפעולה הזו לא צריך להתחבר אל Google Cloud. |
אפשר למחוק אשכולות. | ללא הגבלה | - |
| הצגת סטטוס האשכול | אפשר לראות מידע על האשכולות במסוף, ברשימת האשכולות של Google Kubernetes Engine. | פרטי האשכול לא מוצגים במסוף. | ללא הגבלה | אפשר להשתמש ב-kubectl כדי לשלוח שאילתות ישירות לאשכולות ולקבל את המידע שאתם צריכים. |
| הסרת צמתים מאשכול | לא צריך חיבור ל- Google Cloud כדי להסיר צמתים מאשכול. | אפשר להסיר צמתים מאשכול. | ללא הגבלה | - |
| הוספת צמתים לאשכול | הצומת החדש מושך תמונות של קונטיינרים מ-Container Registry כדי לפעול בצורה תקינה. מתבצעת בדיקה מקדימה כדי לוודא שיש קישוריות אל Google Cloud. | בדיקות קדם-הפעלה שמופעלות כשמוסיפים צומת חדש מאמתות שיש קישוריות אל Google Cloud. לכן, אי אפשר להוסיף צומת חדש לאשכול כשהוא מנותק. | אפס | ללא |
מחזור החיים של האפליקציה
ניתוק זמני מ- Google Cloud בדרך כלל לא משפיע על ניהול האפליקציות שפועלות באשכול מקומי. הן משפיעות רק על שער החיבור. אם אתם משתמשים ב-Container Registry, ב- Artifact Registry, ב-Cloud Build או ב- Cloud Deploy כדי לנהל את קובצי האימג' בקונטיינר או את צינורות ה-CI/CD ב-Google Cloud, הם לא יהיו זמינים במקרה של ניתוק. המסמך הזה לא כולל אסטרטגיות לטיפול בניתוק של המוצרים האלה.
| פעולה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| פריסת אפליקציות | אפשר לפרוס אפליקציות באופן מקומי באמצעות kubectl, באמצעות כלים של CI/CD או באמצעות שער Connect. |
השער לחיבור לא זמין. כל השיטות האחרות לפריסה עדיין פועלות כל עוד הן מתחברות ישירות ל-Kubernetes API. | ללא הגבלה | אם אתם משתמשים בשער החיבור, עברו לשימוש ב-kubectl באופן מקומי. |
| הסרת אפליקציה | אפשר להסיר אפליקציות באופן מקומי באמצעות kubectl, באמצעות כלי CI/CD או באמצעות שער החיבור. |
השער לחיבור לא זמין. כל השיטות האחרות לפריסה עדיין פועלות כל עוד הן מתחברות ישירות ל-Kubernetes API. | ללא הגבלה | אם אתם משתמשים בשער החיבור, עברו לשימוש ב-kubectl באופן מקומי. |
| הרחבת היקף השימוש באפליקציה | אפשר להרחיב את האפליקציות באופן מקומי באמצעות kubectl, באמצעות כלים של CI/CD או באמצעות שער ה-Connect. |
השער לחיבור לא זמין. כל השיטות האחרות לפריסה עדיין פועלות כל עוד הן מתחברות ישירות ל-Kubernetes API. | ללא הגבלה | אם אתם משתמשים בשער החיבור, עברו לשימוש ב-kubectl באופן מקומי. |
רישום ביומן ומעקב
היכולת לבצע ביקורת עוזרת לארגון לעמוד בדרישות הרגולטוריות ובמדיניות התאימות שלו. Distributed Cloud עוזר בביקורת באמצעות רישום ביומן של אפליקציות, רישום ביומן של Kubernetes ורישום ביומן של ביקורת. לקוחות רבים בוחרים להשתמש ב-Cloud Logging וב- Cloud Monitoring של Google כדי להימנע מניהול של תשתית רישום ביומן ומעקב מקומית. לקוחות אחרים מעדיפים לרכז את היומנים שלהם במערכת מקומית לצורך צבירה. כדי לתמוך בלקוחות האלה, Distributed Cloud תומך בשילוב ישיר עם שירותים כמו Prometheus. במצב הזה, במהלך ניתוק זמני מ- Google Cloud, אין השפעה על הפונקציונליות של רישום ביומן או מעקב.
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| רישום ביומן של אפליקציות באמצעות Cloud Logging | המערכת כותבת יומנים ב-Cloud Logging. | היומנים נשמרים בזיכרון הזמני של הדיסק המקומי. | מאגר מקומי של 4.5 שעות או 4GB לכל צומת. כשהמאגר מתמלא או כשהניתוק נמשך 4.5 שעות, המערכת מסירה את הרשומות הכי ישנות. | משתמשים בפתרון רישום ביומן מקומי. |
| רישום ביומן של מערכת/Kubernetes באמצעות Cloud Logging | המערכת כותבת יומנים ב-Cloud Logging. | היומנים נשמרים בזיכרון הזמני של הדיסק המקומי. | מאגר מקומי של 4.5 שעות או 4GB לכל צומת. כשהמאגר מתמלא או כשהניתוק נמשך 4.5 שעות, המערכת מסירה את הרשומות הכי ישנות. | משתמשים בפתרון רישום ביומן מקומי. |
| רישום ביומן ביקורת באמצעות Cloud Audit Logs | המערכת כותבת יומנים ב-Cloud Logging. | היומנים נשמרים בזיכרון הזמני של הדיסק המקומי. | 10GiB של מאגר מקומי לכל צומת של מישור הבקרה. כשהמאגר מתמלא, המערכת משמיטה את הרשומות הכי ישנות. | מגדירים העברה של יומנים לפתרון רישום מקומי ביומן. |
| רישום ביומן של אפליקציות באמצעות ספק אחר | אפשר להשתמש בספקים שונים של צד שלישי כמו Elastic, Splunk, Datadog או Loki. | אין השפעה | ללא הגבלה | - |
| רישום ביומן המערכת או ביומן Kubernetes באמצעות ספק אחר | אתם יכולים להשתמש בספקים שונים של צד שלישי, כמו Elastic, Splunk או Datadog. | אין השפעה | ללא הגבלה | - |
| מדדי אפליקציות ו-Kubernetes שנכתבים ל-Cloud Monitoring | המערכת כותבת מדדים ל-Cloud Monitoring. | המערכת שומרת את המדדים בזיכרון הזמני בדיסק המקומי. | מאגר מקומי של 6GiB לכל צומת למדדי מערכת, או מאגר מקומי של 1GiB לכל צומת למדדי אפליקציה. כשהמאגר מתמלא או כשמשך הניתוק הוא 24 שעות, המערכת מסירה את הרשומות הכי ישנות | שימוש בפתרון מקומי למעקב. |
| גישה לנתוני ניטור וקריאה שלהם מ-Kubernetes ומעומסי עבודה של אפליקציות | כל המדדים זמינים במסוף וב-Cloud Monitoring API. | המערכת לא מעדכנת את המדדים ב-Cloud Monitoring במהלך הניתוק. | מאגר מקומי של 6GiB לכל צומת למדדי מערכת, או מאגר מקומי של 1GiB לכל צומת למדדי אפליקציה. כשהמאגר מתמלא או כשמשך הניתוק הוא 24 שעות, המערכת מסירה את הרשומות הכי ישנות | שימוש בפתרון מקומי למעקב. |
| כללי התראות וזימון תורים למדדים | Cloud Monitoring תומך בהתראות. אפשר ליצור התראות לכל מדד. המערכת יכולה לשלוח התראות בערוצים שונים. | המערכת לא מפעילה התראות כשהיא מנותקת. המערכת מפעילה התראות רק מנתוני מדדים שכבר נשלחו אל Cloud Monitoring. | שימוש בפתרון מקומי למעקב ולהתראות. |
ניהול הגדרות ומדיניות
סנכרון תצורות ו- Policy Controller מאפשרים לכם לנהל הגדרות וכללי מדיניות בהיקף נרחב, בכל האשכולות שלכם. אתם מאחסנים את ההגדרות ואת כללי המדיניות במאגר Git, והמערכת מסנכרנת אותם באופן אוטומטי עם האשכולות.
סנכרון תצורות
סנכרון תצורות משתמש בסוכנים בתוך האשכול כדי להתחבר ישירות למאגר Git.
אפשר לנהל שינויים בכתובת ה-URL של המאגר או בפרמטרים של הסנכרון באמצעות Google Cloud CLI או באמצעות כלים של kubectl.
במהלך ניתוק זמני, הסנכרון לא מושפע אם הסוכנים בתוך האשכול עדיין יכולים להגיע למאגר Git. עם זאת, אם משנים את פרמטרי הסנכרון באמצעות ה-CLI של gcloud או המסוף, האשכול לא מחיל אותם במהלך הניתוק.
אפשר להחליף אותם באופן זמני באופן מקומי באמצעות kubectl. חיבור מחדש
יגרום להחלפת כל השינויים המקומיים.
Policy Controller
Policy Controller מאפשר לאכוף מדיניות שניתנת לתכנות מלא באשכולות שלכם. המדיניות הזו פועלת כ'מגבלות' ומונעת שינויים שמפירים את אמצעי הבקרה שקבעתם בנושאי אבטחה, תפעול או תאימות.
| פעולה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| סנכרון ההגדרות ממאגר Git | סוכנים בתוך האשכול מתחברים ישירות למאגר Git. אפשר לשנות את כתובת ה-URL של המאגר או את פרמטרי הסנכרון באמצעות Google Cloud API. | הסנכרון של ההגדרות לא מושפע. אם משנים את פרמטרי הסנכרון באמצעות ה-CLI של gcloud או במסוף, האשכול לא מחיל אותם במהלך הניתוק. אפשר להחליף אותם באופן זמני באופן מקומי באמצעות kubectl. התחברות מחדש מחליפה את כל השינויים המקומיים. |
ללא הגבלה | אסור להשתמש ב-Fleet API אף פעם בשביל סנכרון תצורות, ואפשר להגדיר אותו רק באמצעות Kubernetes API. |
| אכיפת מדיניות על בקשות ל-Kubernetes API | הסוכן בתוך האשכול אוכף את האילוצים בזכות השילוב שלו עם Kubernetes API. מנהלים את המדיניות באמצעות Kubernetes API המקומי. אתם מנהלים את הגדרות המערכת של Policy Controller באמצעות Google CloudAPI. | האכיפה של המדיניות לא מושפעת. עדיין אפשר לנהל את המדיניות באמצעות Kubernetes API המקומי. המערכת לא מעבירה שינויים בהגדרת המערכת של Policy Controller באמצעות Google Cloud ה-API לאשכול, אבל אפשר להחליף אותם באופן מקומי באופן זמני. התחברות מחדש מחליפה את כל השינויים המקומיים. | ללא הגבלה | אל תשתמשו אף פעם ב-Fleet API עבור Policy Controller, ואל תגדירו אותו אלא באמצעות Kubernetes API. |
| התקנה, הגדרה או שדרוג של סנכרון תצורות באמצעות Google Cloud API | משתמשים ב- Google Cloud API כדי לנהל את ההתקנה והשדרוג של סוכנים בתוך האשכול. משתמשים ב-API הזה (או ב-CLI של gcloud או במסוף) גם כדי לנהל את ההגדרות של הסוכנים האלה. | סוכנים בתוך האשכול ממשיכים לפעול כרגיל. אי אפשר להתקין, לשדרג או להגדיר סוכנים בתוך האשכול באמצעות Google Cloud API. כל ההתקנות, השדרוגים או ההגדרות שממתינים לביצוע באמצעות ה-API ימשיכו לפעול אחרי החיבור מחדש. | אפס | אסור להשתמש ב-Fleet API בשביל Policy Controller, ואפשר להגדיר אותו רק באמצעות Kubernetes API. |
| צפייה בסטטוס המערכת או הסנכרון במסוף | אפשר לראות את תקינות הסוכנים בתוך האשכול ואת סטטוס הסנכרון באמצעות Google Cloud API או המסוף. | מידע על הסטטוס ב- Google Cloud API או במסוף לא מתעדכן. ה-API מציג שגיאת חיבור. כל המידע נשאר זמין ברמת כל אשכול באמצעות Kubernetes API המקומי. | אפס | משתמשים ב-nomos CLI או ב-Kubernetes API המקומי. |
אבטחה
בקטע הזה מוסבר איך תכונות האבטחה, כולל זהות, אימות, הרשאה וניהול סודות, מושפעות מניתוק זמני מ- Google Cloud.
זהות, אימות והרשאה
Distributed Cloud יכול להתחבר ישירות ל-Cloud Identity כדי לנהל עומסי עבודה באמצעות Connect, או כדי לבצע אימות של נקודות קצה באמצעות OIDC. ניתוק מ- Google Cloud מנתק את החיבור ל-Cloud Identity, ולכן התכונות האלה לא זמינות. עבור עומסי עבודה שנדרשת להם חוסן נוסף באמצעות ניתוק זמני, אפשר להשתמש ב- GKE Identity Service כדי לבצע אינטגרציה עם ספק LDAP או OIDC (כולל ADFS) ולהגדיר אימות משתמשי קצה.
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| Cloud Identity כספק זהויות, באמצעות Connect gateway | אתם יכולים לגשת למשאבים של Distributed Cloud באמצעות Cloud Identity כספק הזהויות, ולהתחבר דרך Connect Gateway. | כדי להתחבר לשער, צריך חיבור ל- Google Cloud. לא תוכלו להתחבר לאשכולות במהלך הניתוק. | אפס | שימוש ב-GKE Identity Service כדי לבצע איחוד עם ספק זהויות אחר. |
| זהות ואימות באמצעות ספק זהויות של צד שלישי | תמיכה ב-OIDC וב-LDAP. קודם מתחברים באמצעות ה-CLI של gcloud.
בספקי OIDC, אפשר להשתמש במסוף כדי להיכנס. אחרי זה אפשר לבצע אימות כרגיל מול Cluster API (לדוגמה, באמצעות kubectl). |
כל עוד ספק הזהויות נשאר נגיש גם לכם וגם לאשכול, תוכלו להמשיך לבצע אימות מול ה-API של האשכול. אי אפשר להיכנס דרך המסוף. אפשר לעדכן את הגדרות ה-OIDC או ה-LDAP של האשכולות רק באופן מקומי, ולא באמצעות המסוף. | ללא הגבלה | - |
| הרשאה | Distributed Cloud תומך בבקרת גישה מבוססת תפקידים (RBAC). אפשר לשייך תפקידים למשתמשים, לקבוצות או לחשבונות שירות. המערכת מאחזרת את הזהויות והקבוצות של המשתמשים מספק הזהויות. | מערכת RBAC היא מקומית לאשכול Kubernetes, וניתוק מ- Google Cloud לא משפיע עליה. עם זאת, אם הוא מסתמך על זהויות שמגיעות מ-Cloud Identity, הן לא זמינות במקרה של ניתוק. | ללא הגבלה | - |
ניהול סודות ומפתחות
ניהול סודות ומפתחות הוא חלק חשוב ממצב האבטחה שלכם. ההתנהגות של Distributed Cloud במקרה של ניתוק מ-Google Cloud תלויה בשירות שבו אתם משתמשים לתכונות האלה.
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| ניהול סודות ומפתחות באמצעות Cloud Key Management Service ו-Secret Manager | אתם משתמשים ישירות ב-Cloud Key Management Service למפתחות ההצפנה וב-Secret Manager לסודות. | גם Cloud Key Management Service וגם Secret Manager לא זמינים. | אפס | במקום זאת, אפשר להשתמש במערכות מקומיות. |
| ניהול סודות ומפתחות באמצעות Hashicorp Vault ו Google Cloud services | אתם מגדירים את Hashicorp Vault כך שישתמש ב-Cloud Storage או ב-Spanner כדי לאחסן סודות, וב-Cloud Key Management Service כדי לנהל מפתחות. | אם Hashicorp Vault פועל באשכול המקומי שלכם והניתוק משפיע גם עליו, אז אחסון הסודות וניהול המפתחות לא זמינים במהלך הניתוק. | אפס | במקום זאת, אפשר להשתמש במערכות מקומיות. |
| ניהול סודות ומפתחות באמצעות Hashicorp Vault ושירותים מקומיים | מגדירים את Hashicorp Vault לשימוש בקצה עורפי של אחסון מקומי לסודות, ובמערכת מקומית לניהול מפתחות (כמו מודול אבטחה לחומרה). | אין השפעה לניתוק מ- Google Cloud . | ללא הגבלה | - |
רשתות ושירותי רשת
בקטע הזה מוסבר על שירותי הרשת של אשכולות מקומיים, כולל איך הם מושפעים מניתוק זמני מ-Google Cloud. הוא מספק מידע על איזון עומסים, Cloud Service Mesh ושירותי רשת אחרים.
איזון עומסים
כדי לחשוף שירותי Kubernetes שמתארחים באשכול מקומי למשתמשים, יש לכם את האפשרויות הבאות:
Bare metal:
להשתמש במאזן עומסים מסוג MetalLB או Bundled with BGP.
הגדרה ידנית של האשכולות לשימוש במאזן עומסים משלכם, שהוא חיצוני ל-Distributed Cloud.
VMware:
משתמשים במאזן העומסים המצורף, MetalLB.
הגדרה ידנית של האשכולות לשימוש במאזן עומסים משלכם, שהוא חיצוני ל-Distributed Cloud.
אפשרויות איזון העומסים האלה ממשיכות לפעול גם אם הן מנותקות מ-Google Cloud.
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| מאזן עומסים משולב L4 | השירות מספק איזון עומסים ברמה 4 באופן מקומי לחלוטין, ללא תלות בממשקי API או ברשת.Google Cloud | ללא שינוי | ללא הגבלה | - |
| מאזן עומסים ידני או משולב | יש תמיכה ב-F5 BIG-IP ובפתרונות אחרים שמתארחים גם הם בפריסה מקומית. | ללא שינוי | ללא הגבלה | - |
Cloud Service Mesh
אתם יכולים להשתמש ב-Cloud Service Mesh כדי לנהל, לצפות ולאבטח את התקשורת בין השירותים שפועלים באשכול מקומי. לא כל התכונות של Cloud Service Mesh נתמכות ב-Distributed Cloud. ברשימת התכונות הנתמכות יש מידע נוסף.
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| פריסה או עדכון של מדיניות (ניתוב, הרשאה, אבטחה, ביקורת וכו') | אפשר להשתמש במסוף, ב-kubectl, ב-asmcli או ב-istioctl כדי לנהל את המדיניות של Cloud Service Mesh. |
אפשר להשתמש רק ב-kubectl או ב-istioctl כדי לנהל את המדיניות של Cloud Service Mesh. |
ללא הגבלה | שימוש ב-kubectl או ב-istioctl |
| רשות אישורים (CA) | אתם יכולים להשתמש ברשות האישורים בתוך האשכול או ברשות האישורים של Cloud Service Mesh כדי לנהל את האישורים שבהם נעשה שימוש ב-Cloud Service Mesh. | אם אתם משתמשים ב-CA בתוך האשכול, לא תהיה לכך השפעה. אם אתם משתמשים ברשות האישורים של Cloud Service Mesh, תוקף האישורים יפוג אחרי 24 שעות. לא ניתן לאחזר אישורים ממופעי שירות חדשים. |
ללא הגבלה עבור CA בתוך האשכול. השירות יפעל בצורה מוגבלת למשך 24 שעות, ולאחר מכן לא יפעל בכלל עבור רשות אישורים של Cloud Service Mesh. |
שימוש ב-CA בתוך האשכול. |
| Cloud Monitoring ל-Cloud Service Mesh | אפשר להשתמש ב-Cloud Monitoring כדי לאחסן מדדים שקשורים ל-HTTP שמגיעים מ-Cloud Service Mesh, ולעיין בהם. | המדדים לא נשמרים. | אפס | להשתמש בפתרון תואם לניטור מקומי, כמו Prometheus. |
| רישום ביומני הביקורת של Cloud Service Mesh | Cloud Service Mesh מסתמך על מתקני הרישום המקומיים של Kubernetes. ההתנהגות תלויה באופן שבו הגדרתם את הרישום ביומן עבור האשכול המקומי. | תלוי באופן שבו הגדרתם את הרישום ביומן עבור האשכול המקומי. | - | - |
| שער תעבורת נתונים נכנסת (Ingress) | אפשר להגדיר כתובות IP חיצוניות באמצעות Istio Ingress Gateway. | אין השפעה | ללא הגבלה | - |
| Istio Container Network Interface (CNI) | אתם יכולים להגדיר את Cloud Service Mesh כך שישתמש ב-Istio CNI במקום ב-iptables כדי לנהל את תעבורת הנתונים. | אין השפעה | ללא הגבלה | - |
| אימות משתמשי קצה ב-Cloud Service Mesh לאפליקציות אינטרנט | אתם יכולים להשתמש בשער הכניסה של Cloud Service Mesh כדי לבצע אינטגרציה עם ספק הזהויות שלכם (באמצעות OIDC) כדי לאמת ולאשר למשתמשי קצה גישה לאפליקציות אינטרנט שמהוות חלק מהרשת. | אין השפעה | ללא הגבלה | - |
שירותי רשת אחרים
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| DNS | שרת ה-DNS של Kubernetes פועל בתוך האשכול. | שירות ה-DNS של Kubernetes פועל כרגיל כי הוא פועל בתוך האשכול עצמו. | ללא הגבלה | - |
| שרת proxy לתעבורת נתונים יוצאת (egress) | אתם יכולים להגדיר את האשכולות המקומיים כך שישתמשו ב-proxy לחיבורים יוצאים. | אם ה-proxy פועל בשרת מקומי, האשכול עדיין יכול להשתמש בו במהלך ניתוק זמני. עם זאת, אם ה-proxy מאבד את החיבור ל- Google Cloud, כל התרחישים שמתוארים במסמך הזה עדיין רלוונטיים. | ללא הגבלה | - |
Google Cloud Marketplace
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| פריסה וניהול של אפליקציות ושירותים מ-Cloud Marketplace | Cloud Marketplace זמין במסוף, ואפשר להשתמש בו כדי לגלות, לרכוש ולפרוס פתרונות. | אי אפשר להשתמש ב-Cloud Marketplace. יכול להיות שלפתרונות מסוימים מ-Cloud Marketplace יש דרישות קישוריות משלהם שלא מתועדות כאן. | אפס | ללא |
תמיכה
בקטע הזה מתוארים תרחישים שבהם יכול להיות שתצטרכו לפנות אל Google Cloud התמיכה או אל השותף התפעולי שלכם בנוגע לבעיה שקשורה לאשכולות GKE on GDC.
| תכונה | התנהגות מחוברת | התנהגות ניתוק זמני | טולרנטיות מקסימלית לניתוק | פתרון עקיף לבעיה של אובדן קישוריות |
|---|---|---|---|---|
| שיתוף תמונת מצב של אשכול עם צוות התמיכה | אפשר ליצור תמונת מצב של אשכול באופן מקומי באמצעות הפקודות bmctl check
cluster או gkectl diagnose snapshot. משתפים את תמונת המצב הזו בתהליך התמיכה הרגיל. |
עדיין אפשר ליצור את התמונה, כי זהו תהליך מקומי. אם איבדתם את הגישה ל- Google Cloud ולממשקי האינטרנט של התמיכה, תוכלו להתקשר לצוות התמיכה אם נרשמתם לתוכניות התמיכה המתקדמת או פרימיום. | ללא הגבלה | - |
| שיתוף נתוני יומן רלוונטיים עם צוות התמיכה | אתם יכולים לאסוף יומנים באופן מקומי מהאשכול ולשתף אותם באמצעות תהליך התמיכה הרגיל. | עדיין אפשר לאסוף יומנים מהאשכול. אם איבדתם את הגישה ל- Google Cloud ולממשקי האינטרנט של התמיכה, תוכלו להתקשר לצוות התמיכה אם נרשמתם לתוכניות התמיכה המתקדמת או פרימיום. | ללא הגבלה | - |