תוכנת Google Distributed Cloud בלבד מבוססת על Kubernetes, ואפשר לפרוס אותה באופן מקומי ב-VMware או בשרתי Bare Metal. למרות ש-Distributed Cloud פועל באופן מקומי, אנחנו מתכננים אותו כך שיהיה לו חיבור קבוע ל- Google Cloud מכמה סיבות, כולל מעקב וניהול. עם זאת, יכול להיות שתרצו לדעת מה קורה אם מסיבה כלשהי החיבור ל- Google Cloud מתנתק(לדוגמה, בגלל בעיה טכנית). במאמר הזה נסביר מה קורה כשהקישוריות של אשכולות בפריסה של Distributed Cloud לתוכנה בלבד (בשרת פיזי או ב-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 של האשכול ל-Service Control API של Google Cloud למטרות חיוב. | סוכן בתוך האשכול שומר את רשומות החיוב באשכול בזמן הניתוק, ומאחזר את הרשומות כשהאשכול מתחבר מחדש ל- 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 או באמצעות שער החיבור. |
שער הקישור לא זמין. כל השיטות האחרות לפריסה עדיין פועלות, כל עוד הן מתחברות ישירות ל-Kubernetes API. | ללא הגבלה | אם אתם משתמשים בשער הקישור, עברו לשימוש ב-kubectl באופן מקומי. |
| הסרת אפליקציות | אתם מסירים אפליקציות באופן מקומי באמצעות kubectl, דרך כלי CI/CD או באמצעות שער הקישור. |
שער הקישור לא זמין. כל השיטות האחרות לפריסה עדיין פועלות, כל עוד הן מתחברות ישירות ל-Kubernetes API. | ללא הגבלה | אם אתם משתמשים בשער הקישור, עברו לשימוש ב-kubectl באופן מקומי. |
| הרחבה אופקית של אפליקציות בהתאם לעומס (scale out) | אתם יכולים להרחיב אופקית בהתאם לעומס (scale out) של אפליקציות באופן מקומי באמצעות kubectl, דרך כלי CI/CD או באמצעות שער הקישור. |
שער הקישור לא זמין. כל השיטות האחרות לפריסה עדיין פועלות, כל עוד הן מתחברות ישירות ל-Kubernetes API. | ללא הגבלה | אם אתם משתמשים בשער הקישור, עברו לשימוש ב-kubectl באופן מקומי. |
רישום ביומן ומעקב
יכולת הביקורת עוזרת לארגון לעמוד בדרישות הרגולטוריות ובמדיניות התאימות. ב-Distributed Cloud יש אפשרות לרישום ביומן של אפליקציות, של Kubernetes ושל ביקורת, כדי לעזור לכם לבצע ביקורת. לקוחות רבים בוחרים להשתמש ב-Cloud Logging וב- Cloud Monitoring של Google כדי להימנע מניהול של תשתית רישום ביומן ומעקב מקומית. לקוחות אחרים מעדיפים לרכז את היומנים במערכת מקומית לצורך צבירה. כדי לתמוך בלקוחות האלה, Distributed Cloud תומך בשילוב ישיר עם שירותים כמו Prometheus. במצב הזה, אם יש ניתוק זמני מ- Google Cloud, אין השפעה על פונקציונליות הרישום ביומן או המעקב.
| תכונה | התנהגות מקושרת | התנהגות במקרה של ניתוק זמני | הזמן המקסימלי המותר לניתוק | פתרון עקיף לאובדן הקישוריות |
|---|---|---|---|---|
| רישום ביומן של אפליקציות באמצעות Cloud Logging | המערכת כותבת יומנים ב-Cloud Logging. | המערכת שומרת את היומנים במאגר נתונים זמני בדיסק המקומי. | מאגר נתונים מקומי של 4.5 שעות או 4GiB לכל צומת. כשהמאגר מתמלא או כשהניתוק נמשך 4.5 שעות, המערכת מוחקת את הרשומות הישנות ביותר. | להשתמש בפתרון רישום מקומי. |
| רישום ביומן של המערכת או של Kubernetes באמצעות Cloud Logging | המערכת כותבת יומנים ב-Cloud Logging. | המערכת שומרת את היומנים במאגר נתונים זמני בדיסק המקומי. | מאגר נתונים מקומי של 4.5 שעות או 4GiB לכל צומת. כשהמאגר מתמלא או כשהניתוק נמשך 4.5 שעות, המערכת מוחקת את הרשומות הישנות ביותר. | להשתמש בפתרון מקומי לרישום ביומן. |
| רישום ביומני ביקורת באמצעות Cloud Audit Logs | המערכת כותבת יומנים ב-Cloud Logging. | המערכת שומרת את היומנים במאגר נתונים זמני בדיסק המקומי. | מאגר נתונים מקומי של 10GiB לכל צומת במישור הבקרה. כשהמאגר מתמלא, המערכת מוחקת את הרשומות הישנות ביותר. | להגדיר העברת יומנים לפתרון מקומי לרישום ביומן. |
| רישום ביומן של אפליקציות באמצעות ספק אחר | אתם יכולים להשתמש בספקי צד שלישי שונים כמו Elastic, Splunk, Datadog או Loki. | אין השפעה | ללא הגבלה | - |
| רישום ביומן של המערכת או של Kubernetes באמצעות ספק אחר | אתם יכולים להשתמש בספקי צד שלישי שונים כמו Elastic, Splunk או Datadog. | אין השפעה | ללא הגבלה | - |
| מדדי אפליקציות ו-Kubernetes שנכתבו ב-Cloud Monitoring | המערכת כותבת מדדים ב-Cloud Monitoring. | המערכת שומרת את המדדים במאגר נתונים זמני בדיסק המקומי. | מאגר נתונים מקומי של 24 שעות או 6GiB לכל צומת למדדי מערכת, ומאגר נתונים מקומי של 1GiB לכל צומת למדדי אפליקציות. כשהמאגר מתמלא או כשהניתוק נמשך 24 שעות, המערכת מוחקת את הרשומות הישנות ביותר. | להשתמש בפתרון מעקב מקומי. |
| גישה לנתוני המעקב וקריאה שלהם מעומסי העבודה של Kubernetes ושל האפליקציה | כל המדדים זמינים במסוף ובאמצעות Cloud Monitoring API. | בזמן הניתוק, המערכת לא מעדכנת את המדדים ב-Cloud Monitoring. | מאגר נתונים מקומי של 24 שעות או 6GiB לכל צומת למדדי מערכת, ומאגר נתונים מקומי של 1GiB לכל צומת למדדי אפליקציות. כשהמאגר מתמלא או כשהניתוק נמשך 24 שעות, המערכת מוחקת את הרשומות הישנות ביותר. | להשתמש בפתרון מעקב מקומי. |
| כללי התראות ודפדוף במדדים | אפשר להגדיר התראות ב-Cloud Monitoring. אפשר ליצור התראות לכל מדד. המערכת יכולה לשלוח התראות בערוצים שונים. | המערכת לא מפעילה התראות כשהיא מנותקת. המערכת מפעילה התראות רק מנתוני מדדים שכבר נשלחו אל Cloud Monitoring. | להשתמש בפתרון מקומי למעקב ולהתראות. |
ניהול הגדרות ומדיניות
בעזרת סנכרון תצורות ו Policy Controller, אתם יכולים לנהל את ההגדרות וכללי המדיניות בכל האשכולות שלכם. אתם מאחסנים הגדרות ומדיניות במאגר Git, והמערכת מסנכרנת אותם באופן אוטומטי עם האשכולות שלכם.
סנכרון תצורות
סנכרון ההגדרות משתמש בסוכנים בתוך האשכול כדי להתחבר ישירות למאגר Git.
אתם יכולים לנהל את השינויים בכתובת ה-URL של המאגר או בפרמטרים של הסנכרון באמצעות Google Cloud CLI או הכלים של kubectl.
במהלך ניתוק זמני, הסנכרון לא מושפע אם הסוכנים באשכול עדיין יכולים להגיע למאגר Git. עם זאת, אם משנים את הפרמטרים של הסנכרון באמצעות ה-CLI של gcloud או מסוף Google Cloud, האשכול לא מחיל אותם במהלך הניתוק.
אפשר לשנות אותן באופן זמני באופן מקומי באמצעות kubectl. החיבור מחדש מבטל את כל השינויים המקומיים.
Policy Controller
Policy Controller מאפשר לאכוף מדיניות שניתנת לתכנות מלא באשכולות שלכם. המדיניות הזו פועלת כ "מעקה בטיחות" ומונעת שינויים שמפרים את אמצעי הבקרה שהגדרתם לאבטחה, לתפעול או לתאימות.
| פעולה | התנהגות מקושרת | התנהגות במקרה של ניתוק זמני | הזמן המקסימלי המותר לניתוק | פתרון עקיף לאובדן הקישוריות |
|---|---|---|---|---|
| סנכרון הגדרות ממאגר Git | סוכנים בתוך האשכול מתחברים ישירות למאגר Git. אפשר לשנות את כתובת ה-URL של המאגר או את הפרמטרים של הסנכרון באמצעות API של Google Cloud . | סנכרון ההגדרות לא מושפע. אם משנים את פרמטרי הסנכרון באמצעות ה-CLI של gcloud או במסוף, האשכול לא מחיל אותם במהלך הניתוק. אפשר לשנות אותם באופן זמני באופן מקומי באמצעות kubectl. החיבור מחדש מחליף את כל השינויים המקומיים. |
ללא הגבלה | אל תשתמשו ב-Fleet API בשביל סנכרון ההגדרות, אלא רק באמצעות Kubernetes API. |
| אכיפת כללי מדיניות על בקשות ל-Kubernetes API | הסוכן באשכול אוכף את האילוצים בזכות השילוב שלו עם Kubernetes API. אתם מנהלים את כללי המדיניות באמצעות Kubernetes API המקומי. אתם יכולים לנהל את הגדרות המערכת של Policy Controller באמצעות ממשק API של Google Cloud. | אכיפת המדיניות לא מושפעת. אתם עדיין מנהלים את כללי המדיניות באמצעות Kubernetes API המקומי. המערכת לא מפיצה את השינויים בהגדרות המערכת של Policy Controller באמצעות ה-API של Google Cloud לאשכול, אבל אפשר להחליף אותם באופן זמני באופן מקומי. החיבור מחדש מחליף את כל השינויים המקומיים. | ללא הגבלה | אל תשתמשו ב-Fleet API בשביל Policy Controller, והגדירו אותו רק באמצעות Kubernetes API. |
| התקנה, הגדרה או שדרוג של סנכרון ההגדרות באמצעות ה-API של Google Cloud | אתם משתמשים ב-API של Google Cloud כדי לנהל את ההתקנה והשדרוג של סוכנים באשכול. אתם יכולים להשתמש ב-API הזה (או ב-CLI של gcloud או במסוף) גם כדי לנהל את ההגדרות של הסוכנים האלה. | סוכנים בתוך האשכול ממשיכים לפעול כרגיל. אי אפשר להתקין, לשדרג או להגדיר סוכנים באשכול באמצעות Google Cloud API. כל ההתקנות, השדרוגים או ההגדרות האישיות שבוצעו באמצעות ה-API והיו בהמתנה, ימשיכו לפעול אחרי החיבור מחדש. | אפס | אל תשתמשו ב-Fleet API בשביל Policy Controller, והגדירו אותו רק באמצעות Kubernetes API. |
| צפייה בסטטוס המערכת או הסנכרון במסוף | אתם יכולים לראות את הסטטוס של הסוכנים באשכול ואת סטטוס הסנכרון באמצעות ה-API של Google Cloud או באמצעות המסוף. | פרטי הסטטוס ב-API או במסוף Google Cloud לא מעודכנים. מוצגת שגיאת חיבור ב-API. כל המידע נשאר זמין לכל אשכול בנפרד באמצעות ה-API המקומי של Kubernetes. | אפס | משתמשים ב-CLI של nomos או ב-Kubernetes API המקומי. |
אבטחה
בקטע הזה מוסבר איך ניתוק זמני מ- Google Cloudמשפיע על אמצעי האבטחה, כולל זהות, אימות, הרשאה וניהול סודות.
זהות, אימות והרשאה
אפשר לחבר את Distributed Cloud ישירות ל-Cloud Identity כדי להגדיר תפקידים של אפליקציות ומשתמשים, לנהל עומסי עבודה באמצעות Connect או לאמת נקודות קצה באמצעות OIDC. ניתוק מ- Google Cloud ינתק את החיבור ל-Cloud Identity, והתכונות האלה לא יהיו זמינות. לעומסי עבודה שדורשים עמידות נוספת באמצעות ניתוק זמני, אתם יכולים להשתמש ב- GKE Identity Service כדי לשלב עם ספק LDAP או OIDC (כולל ADFS) כדי להגדיר אימות של משתמשי קצה.
| תכונה | התנהגות מקושרת | התנהגות במקרה של ניתוק זמני | הזמן המקסימלי המותר לניתוק | פתרון עקיף לאובדן הקישוריות |
|---|---|---|---|---|
| Cloud Identity כספק זהויות, באמצעות שער Connect | אתם יכולים לגשת למשאבים של Distributed Cloud באמצעות Cloud Identity כספק הזהויות, ולהתחבר דרך שער הקישוריות. | שער Connect דורש חיבור אל Google Cloud. בזמן הניתוק לא תוכלו להתחבר לאשכולות. | אפס | שימוש ב-GKE Identity Service כדי לאחד עם ספק זהויות אחר. |
| זהות ואימות באמצעות ספק זהויות של צד שלישי | תמיכה ב-OIDC וב-LDAP. קודם אתם משתמשים ב-CLI של gcloud כדי להתחבר.
בספקי OIDC, אתם יכולים להשתמש במסוף כדי להתחבר. אחרי כן אפשר לבצע אימות רגיל מול ה-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 | אתם מגדירים את Hashicorp Vault כך שישתמש ב-Cloud Storage או ב-Spanner כדי לאחסן סודות, וב-Cloud Key Management Service כדי לנהל מפתחות. | אם Hashicorp Vault פועל באשכול המקומי והניתוק משפיע גם עליו, אחסון הסודות וניהול המפתחות לא יהיו זמינים במהלך הניתוק. | אפס | במקום זאת, צריך להשתמש במערכות מקומיות. |
| ניהול סודות ומפתחות באמצעות Hashicorp Vault ושירותים מקומיים | אתם מגדירים את Hashicorp Vault כך שישתמש ב-backend של אחסון מקומי לסודות, ובמערכת מקומית לניהול מפתחות (כמו מודול אבטחת חומרה). | הניתוק מ- Google Cloud לא משפיע על שום דבר. | ללא הגבלה | - |
רשתות ושירותי רשת
בקטע הזה נסביר על הרשתות ושירותי הרשת של אשכולות מקומיים, ואיך הם מושפעים מניתוק זמני מ-Google Cloud. הוא מספק מידע על איזון עומסים, Cloud Service Mesh ושירותי רשת אחרים.
איזון עומסים
כדי לחשוף למשתמשים שירותי Kubernetes שמתארחים באשכול מקומי, אתם יכולים:
Bare Metal:
משתמשים במאזן עומסים שכלול בחבילה, MetalLB או Bundled with BGP.
להגדיר ידנית את האשכולות כך שישתמשו במאזן עומסים משלכם, מחוץ ל-Distributed Cloud.
VMware:
להשתמש במאזן העומסים המצורף, MetalLB.
להגדיר ידנית את האשכולות כך שישתמשו במאזן עומסים משלכם, מחוץ ל-Distributed Cloud.
האפשרויות האלה לאיזון עומסים ממשיכות לפעול גם אם הן מנותקות מ-Google Cloud.
| תכונה | התנהגות מקושרת | התנהגות במקרה של ניתוק זמני | הזמן המקסימלי המותר לניתוק | פתרון עקיף לאובדן הקישוריות |
|---|---|---|---|---|
| מאזן עומסים מקובץ בשכבה 4 | מספק איזון עומסים בשכבה 4 באופן מקומי לחלוטין, ללא תלות בממשקי API או ברשת שלGoogle Cloud . | ללא שינוי | ללא הגבלה | - |
| מאזן עומסים ידני או משולב | תמיכה ב-F5 BIG-IP ובאחרים שמתארחים גם באופן מקומי. | ללא שינוי | ללא הגבלה | - |
Cloud Service Mesh
אתם יכולים להשתמש ב-Cloud Service Mesh כדי לנהל, לנטר ולאבטח את התקשורת בין השירותים שפועלים באשכול מקומי. ב-Distributed Cloud אין תמיכה בכל התכונות של Cloud Service Mesh: למידע נוסף, עיינו ברשימת התכונות הנתמכות.
| תכונה | התנהגות מקושרת | התנהגות במקרה של ניתוק זמני | הזמן המקסימלי המותר לניתוק | פתרון עקיף לאובדן הקישוריות |
|---|---|---|---|---|
| פריסה או עדכון של כללי מדיניות (ניתוב, הרשאה, אבטחה, ביקורת וכו') | כדי לנהל את כללי המדיניות של Cloud Service Mesh, אתם יכולים להשתמש במסוף, ב-kubectl, ב-asmcli או ב-istioctl. |
אפשר להשתמש רק ב-kubectl או ב-istioctl כדי לנהל את כללי המדיניות של Cloud Service Mesh. |
ללא הגבלה | אפשר להשתמש ב-kubectl או ב-istioctl. |
| רשות אישורים (CA) | כדי לנהל את האישורים שמשמשים את Cloud Service Mesh, אתם יכולים להשתמש ברשות האישורים באשכול או ברשות האישורים של Cloud Service Mesh. | אם אתם משתמשים ברשות לאישורים באשכול, אין לכך השפעה. אם אתם משתמשים ברשות לאישורים של Cloud Service Mesh, תוקף האישורים יפוג אחרי 24 שעות. אי אפשר לאחזר אישורים במכונות חדשות של שירותים. |
ללא הגבלה ל-CA באשכול. שירות מוגבל למשך 24 שעות, וללא שירות אחרי 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. | אין השפעה | ללא הגבלה | - |
| ממשק רשת קונטיינרים (CNI) של Istio | אתם יכולים להגדיר את 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. אתם משתפים את תמונת המצב הזו בתהליך התמיכה הרגיל. |
עדיין אפשר ליצור את קובץ ה-snapshot כי זו פעולה מקומית. אם איבדתם את הגישה ל- Google Cloud ולממשקי האינטרנט של התמיכה, אתם יכולים להתקשר לצוות התמיכה, בתנאי שנרשמתם לחבילת תמיכה מתקדמת או לחבילת תמיכת Premium. | ללא הגבלה | - |
| שיתוף נתוני יומן רלוונטיים עם צוות התמיכה | אתם יכולים לאסוף יומנים באופן מקומי מהאשכול שלכם ולשתף אותם באמצעות תהליך התמיכה הרגיל. | עדיין אפשר לאסוף יומנים מהאשכול. אם איבדתם את הגישה ל- Google Cloud ולממשקי האינטרנט של התמיכה, אתם יכולים להתקשר לצוות התמיכה אם נרשמתם לחבילת תמיכה מתקדמת או לחבילת תמיכת Premium. | ללא הגבלה | - |