קבלת תמיכה

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

‫Cloud Customer Care מציע חבילות תמיכה שונות שמתאימות לצרכים שלכם. כל חבילות Cloud Customer Care כוללות תמיכה ב-GKE וב-Google Distributed Cloud. אם יש לכם חבילת תמיכה קיימת של Cloud Customer Care, אתם כבר מקבלים תמיכה ב-GKE וב-Google Distributed Cloud.

מידע נוסף זמין במאמר בנושא Cloud Customer Care hub.

דרישות לתמיכה ב-Google Distributed Cloud

כדי לפתור ביעילות אירועים קריטיים לעסק, צריך:

• צריך לוודא שהסביבה שלכם עדכנית ושהיא נמצאת בתוך מסגרות הזמן שפורסמו לסיום התמיכה. מידע נוסף זמין בקטע מדיניות התמיכה בגרסאות.
• מפעילים את Cloud Logging ואת Cloud Monitoring לרכיבי המערכת. מידע נוסף זמין בקטע כלי תמיכה.

כלי תמיכה

כדי לפתור בעיה ב-Google Distributed Cloud, צוות Cloud Customer Care מסתמך על שלושה סוגי מידע:

• הגדרת הסביבה
• יומנים מהאשכולות
• מדדים מהאשכולות

הגדרת הסביבה

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

• כדי לאסוף מידע על Kubernetes ועל הצמתים שלכם, מריצים את הפקודה bmctl check cluster --snapshot לכל סוגי האשכולות. מצרפים את קובץ ה-tar שנוצר לבקשת התמיכה.

• במקרה של אדמין, היברידי וקלאסטרים עצמאיים, מריצים את הפקודה bmctl check cluster כדי לבדוק את סטטוס התקינות של הקלאסטר והצמתים. מצרפים את היומנים שנוצרו לבקשת התמיכה. היומנים אמורים להיות בספרייה bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

• כדי ליצור אשכולות משתמשים, קודם יוצרים קובץ YAML של בדיקת תקינות עם שם האשכול ומרחב השמות, ואז מחילים את הקובץ באשכול האדמין המתאים:

  1. יוצרים קובץ YAML עם המאפיינים הבאים של healthcheck. התוכן הבא הוא דוגמה לתוכן של אשכול בשם user1 במרחב השמות cluster-user1:

     apiVersion: baremetal.cluster.gke.io/v1
     kind: HealthCheck
     metadata:
       generateName: healthcheck-
       namespace: cluster-user1
     spec:
       clusterName: user1
     

  2. אחרי שיוצרים את קובץ ה-YAML, מפעילים את המשאב בהתאמה אישית באשכול האדמין שמנהל את אשכול המשתמשים באמצעות הפקודה kubectl. הנה דוגמה לפקודה שמשתמשת בקובץ ה-YAML שנוצר בשלב הקודם. בדוגמה, המשתנה ADMIN_KUBECONFIG מציין את הנתיב לקובץ kubeconfig של אשכול האדמין:

     kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
     

     הפקודה מחזירה את התגובה הבאה:

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
     

  3. ממתינים עד לסיום של משימת בדיקת התקינות. כדי לעשות זאת, בודקים אם משימת בדיקת התקינות סיימה את ההתאמה. בדוגמה הקודמת, שם המשימה של בדיקת תקינות הוא healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. בדוגמה הבאה מוצגת בדיקה לדוגמה שמשתמשת בפקודה kubectl וממתינה 30 דקות עד להשלמת העבודה של בדיקת תקינות:

     kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
         -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
     

     כשפעולת בדיקת התקינות מסתיימת, הפקודה kubectl שלמעלה מחזירה:

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met
     

     כדי לראות את התוצאות של בדיקת התקינות, מריצים את הפקודה הבאה:

     kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \
         -n cluster-user1
     

     הפקודה מחזירה את התוצאה הבאה:

     NAME                PASS   AGE
     healthcheck-7c4qf   true   17m
     

  4. אוספים את כל היומנים של ה-Pod של משימת בדיקת התקינות לקובץ מקומי באמצעות הפקודה kubectl. בדוגמה הבאה נעשה שימוש במשימת בדיקת תקינות לדוגמה שמופיעה למעלה:

     kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \
         -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \
         healthcheck-7c4qf.log
     

יומני אשכולות

כשיוצרים אשכול חדש של Google Distributed Cloud, סוכני Cloud Logging מופעלים כברירת מחדל ומוגבלים לרכיבים ברמת המערכת בלבד. הפעולה הזו משכפלת יומנים ברמת המערכת לפרויקט Google Cloud שמשויך לאשכול. יומנים ברמת המערכת הם מ-Pods של Kubernetes במרחבי השמות הבאים:

• kube-system
• gke-system
• gke-connect
• istio-system
• config-management-system
• gatekeeper-system
• cnrm-system
• knative-serving

אפשר לשלוח שאילתות ליומנים מתוך Logs Explorer.

הערה: אם Cloud Logging מושבת, התמיכה ניתנת רק על בסיס מאמץ מרבי, ועשויה לדרוש מאמץ נוסף משמעותי מצוות ההנדסה באתר שלכם.

פרטים נוספים זמינים במאמר בנושא הגדרת רישום ביומן ומעקב.

Google Cloud CLI וגישה מרחוק לאשכול

אם פותחים בקשת תמיכה, Cloud Customer Care עשוי לבקש הרשאת קריאה בלבד מרחוק לאשכולות שלכם כדי לאבחן ולפתור בעיות בצורה יעילה יותר. כדי שלצוות Cloud Customer Care תהיה גישה מספקת לפתרון בעיות באשכול מרחוק, צריך לוודא שהתקנתם את הגרסה האחרונה של Google Cloud CLI ועדכנתם אליה. כדי לתת ל-Cloud Customer Care את ההרשאות הנדרשות, צריך להשתמש בגרסה 401.0.0 או בגרסה מתקדמת יותר של Google Cloud CLI. מומלץ לעדכן את Google Cloud CLI באופן קבוע כדי לקבל הרשאות נוספות ושיפורים אחרים.

כדי להתקין את הרכיבים האחרונים של ה-CLI של gcloud, משתמשים בפקודה gcloud components update. מידע נוסף על מתן גישת קריאה בלבד מרחוק ל-Cloud Customer Care לאשכולות שלכם זמין במאמר בנושא תמיכה מרחוק באשכול GKE.

מדדים של אשכולות

בנוסף ליומנים, סוכן Cloud Monitoring מתעד גם מדדים. הפעולה הזו משכפלת מדדים ברמת המערכת לפרויקט Google Cloud שמשויך לאשכול. מדדים ברמת המערכת הם מ-Pods של Kubernetes שפועלים באותם מרחבי שמות שמפורטים בקטע Cluster logs.

הערה: אם Cloud Monitoring מושבת, התמיכה ניתנת רק על בסיס המאמץ הטוב ביותר, ועשויה לדרוש מאמץ נוסף משמעותי מצוות ההנדסה באתר.

פרטים נוספים זמינים במאמר בנושא הגדרת רישום ביומן ומעקב.

איך אנחנו פותרים בעיות בסביבה שלכם

דוגמה לאירוע תמיכה טיפוסי:

1. האדמין של האשכול פותח בקשת תמיכה במסוף Google Cloud דרך Cloud Customer Care. לאחר מכן הם בוחרים באפשרות GKE וב-Google Distributed Cloud בתור Category (קטגוריה) ו-Component (רכיב), בהתאמה. הם מזינים את המידע הנדרש ומצרפים את הפלט של פקודות bmctl רלוונטיות לכרטיס התמיכה.

2. בקשת התמיכה מועברת למהנדס תמיכה טכנית שמתמחה ב-Google Distributed Cloud.

3. מהנדס התמיכה בודק את התוכן של התמונה כדי לקבל הקשר לגבי הסביבה.

4. מהנדס התמיכה בודק את היומנים והמדדים ב Google Cloudהפרויקט. הם מזינים את מספר בקשת התמיכה כהצדקה העסקית, שנרשמת באופן פנימי.

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

מה Google תומכת?

בדרך כלל, Cloud Customer Care תומך בכל רכיבי התוכנה שנשלחים כחלק מ-Google Distributed Cloud ו-Cloud Service Mesh,‏ Policy Controller,‏ סנכרון תצורות ו-Config Controller. בטבלה הבאה מופיעה רשימה מפורטת יותר של מה שנתמך ומה שלא נתמך:

Google Cloud נתמכים	לא נתמך
‫Kubernetes וזמן הריצה של הקונטיינר	בחירת מאזן עומסים על ידי הלקוח (איזון עומסים ידני)
Connect ו-Agent של Connect	קוד לקוח (ראו תמיכה למפתחים)
Google Cloud פעולות, Monitoring,‏ Logging וסוכנים	בחירת מערכת הפעלה על ידי הלקוח
מאזן עומסים בחבילה	שרת פיזי או וירטואלי, אחסון ורשת
בקר Ingress	מערכות DNS,‏ DHCP וזהויות חיצוניות
GKE Identity Service
Cloud Service Mesh
Policy Controller
סנכרון תצורות
Config Controller

מדיניות התמיכה בגרסאות

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

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

‫Google תומכת בכל גרסה משנית של Google Distributed Cloud עד לתאריך המאוחר מבין:

• ‫12 חודשים אחרי ההשקה הראשונית של גרסת המשנה.
• הגרסה המשנית השלישית שיוצאת ברצף.

לדוגמה, גרסה משנית 1.33 שפורסמה ב-2 בספטמבר 2025. התמיכה בגרסה המשנית הזו ובכל תיקוני האבטחה שלה תימשך עד 2 בספטמבר 2026 או עד תאריך ההשקה של גרסה משנית 1.36, לפי התאריך המאוחר מביניהם.

מומלץ לשמור על סביבת Google Distributed Cloud עם הגרסה המשנית האחרונה של המוצר וגרסת הטלאי המומלצת.

מדיניות התמיכה הזו כוללת:

• תמיכה בתיקון תקלות מ-Cloud Customer Care.
• נקודות חולשה באבטחה של CVE ב-Kubernetes וברכיבים קשורים.
• תיקונים כלליים ב-Kubernetes וברכיבים קשורים.

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

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

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

תקופת זכאות לתמיכה

בטבלה הבאה מפורטות הגרסאות המשניות הנתמכות של Google Distributed Cloud ותאריכי סוף חיי המוצר (EOL) המוקדמים ביותר:

גרסה של Google Distributed Cloud	תאריך הפצה	תאריך סוף חיי המוצר^*
‫1.33	2025-09-02	‫2026-09-02 או תאריך ההפצה של גרסה 1.36
‫1.32	2025-05-06	‫2026-05-06 או תאריך ההשקה של גרסה 1.35
1.31	2024-12-18	‫2025-12-18 או תאריך ההשקה של גרסה 1.34

‫* תאריך ה-EOL יהיה התאריך המאוחר מבין שני התאריכים האלה.

מידע נוסף על תאימות גרסאות ל-Google Distributed Cloud ולGoogle Cloud מוצרים קשורים זמין במאמר תמיכה בגרסאות ובשדרוגים.

תכנית ניהול גרסאות

ב-Google Distributed Cloud נעשה שימוש בניהול גרסאות סמנטי של Kubernetes כדי להתייחס לגרסאות נתמכות של Kubernetes, אבל מתווספת גרסת תיקון של GKE. התוצאה היא מספר גרסה בפורמט: x.y.z-gke.N.

הגרסה הראשית של Kubernetes‏ (x)

בדרך כלל, המספר של גרסה ראשית עולה אם מוצגים שינויים בממשק ה-API הציבורי שלא תואמים לאחור. גרסה ראשית מגדילה את גרסת Kubernetes מ-x.y ל-x+1.y.

הגרסה המשנית של Kubernetes ‏ (y)

ב-Kubernetes מתפרסמת גרסה משנית חדשה שלוש פעמים בשנה. כל מחזור גרסה נמשך כ-15 שבועות. יכול להיות שממשקי API שהוצאו משימוש יוסרו בגרסה משנית חדשה. בגרסה משנית, מספר הגרסה של Kubernetes עולה מ-1.y ל-1.y+1. לדוגמה, Kubernetes 1. ‫29 היא הגרסה המשנית שאחרי Kubernetes 1.28.

גרסת תיקון (patch) של Google Distributed Cloud‏ (z-gke.N)

גרסת תיקון, כמו 1.28.300-gke.131, מגדילה את גרסת התיקון (z) ב-100 וכוללת סיומת -gke.N שמציינת את ה-build. מהדורות של תיקוני אבטחה כוללות עדכוני אבטחה ותיקוני באגים. גרסת הפצה של תיקון Google Distributed Cloud לא תואמת לגרסת תיקון של Kubernetes.

מודל האחריות המשותפת

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

האחריות של Google

• תחזוקה והפצה של חבילת התוכנה Google Distributed Cloud.

• שליחת הודעה למשתמשים על שדרוגים זמינים ל-Google Distributed Cloud, ויצירת סקריפטים לשדרוג הגרסה הקודמת.

  ב-Google Distributed Cloud יש תמיכה רק בשדרוגים רציפים של אשכולות (לדוגמה: 1.32 ← 1.33 ← 1.34, אבל לא 1.32 ← 1.34). כשמשדרגים מאגרי צמתים, במקרים מסוימים אפשר לדלג על גרסה משנית. מידע נוסף על לוגיקת השדרוג זמין במאמר בנושא כללי גרסה.

• הפעלת השירותים Connect ו-Cloud Operations.

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

האחריות של המשתמשים

• ניהול כללי של המערכת באשכולות מקומיים.
• תחזוקה של עומסי עבודה של אפליקציות שנפרסו באשכול.
• הפעלה, תחזוקה ועדכון של תשתית מרכז הנתונים, כולל רשתות, שרתים, מערכת הפעלה, אחסון וקישוריות אלGoogle Cloud.
• הפעלה, תחזוקה ותיקון של מאזני עומסים ברשת אם בוחרים באפשרות של מאזן עומסים ידני.
• שדרוג גרסאות של Google Distributed Cloud באופן קבוע.
• מעקב אחר האשכול והאפליקציות, ותגובה לכל תקרית.
• הבטחה שסוכני Cloud Operations נפרסים באשכולות.
• לספק ל-Google פרטים על הסביבה לצורך פתרון בעיות.

תמיכה למפתחים

‫Google לא מספקת תמיכה ספציפית לעומסי העבודה של האפליקציה. עם זאת, אנחנו מספקים תמיכה למפתחים בשיטת best-effort כדי לוודא שהמפתחים יוכלו להריץ אפליקציות ב-Google Distributed Cloud. אנחנו מאמינים שמעורבות מוקדמת יותר במהלך הפיתוח יכולה למנוע תקריות קריטיות בהמשך הפריסה.

תמיכת המפתחים הזו, שניתנת בשיטת best-effort, זמינה ללקוחות עם כל חבילת תמיכה בתשלום. הטיפול בבעיה שמונעת השקה מתבצע בעדיפות P3, והטיפול בהתייעצות כללית מתבצע בעדיפות P4. בסיווג הזה, רמת העדיפות 0 היא הגבוהה ביותר.