פנייה לתמיכה

המטרה העיקרית של התמיכה של 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 מסתמך על שלושה סוגי מידע:

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

הגדרת הסביבה

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

• עבור כל סוגי האשכולות, מריצים את הפקודה bmctl check cluster --snapshot כדי לתעד מידע על Kubernetes ועל הצמתים. מצרפים את קובץ ה-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 יבקש גישת קריאה בלבד מרחוק לאשכולות שלכם, כדי לאבחן ולפתור בעיות בצורה יעילה יותר. כדי שלצוות Cloud Customer Care תהיה גישה מספקת לפתרון בעיות באשכול מרחוק, צריך לוודא שהתקנתם את הגרסה האחרונה של Google Cloud CLI ועדכנתם אותה. כדי לתת ל-Cloud Customer Care את ההרשאות הנדרשות, צריך להשתמש ב-Google Cloud CLI בגרסה 401.0.0 ומעלה. מומלץ לעדכן את Google Cloud CLI באופן קבוע כדי לקבל את ההרשאות החדשות ושיפורים אחרים.

כדי להתקין את הרכיבים העדכניים של gcloud CLI, משתמשים בפקודה 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 וזמן הריצה של הקונטיינר	בחירת מאזן עומסים על ידי הלקוח (איזון עומסים ידני)
חיבור וחיבור לנציג	קוד לקוח (ראו תמיכה למפתחים)
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.35	2026-04-29	‫2027-04-29 או תאריך ההשקה של גרסה 1.38
1.34	2025-12-11	‫2026-12-11 או תאריך ההשקה של גרסה 1.37
‫1.33	2025-09-02	‫2026-09-02 או תאריך ההשקה של גרסה 1.36
‫1.32	2025-05-06	‫2026-05-06 או תאריך ההשקה של גרסה 1.35

‫* תאריך ה-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.33‏ ← 1.34‏ ← 1.35, אבל לא 1.33‏ ← 1.35). כשמשדרגים מאגרי צמתים, במקרים מסוימים אפשר לדלג על גרסה משנית. למידע נוסף על לוגיקת השדרוג, אפשר לעיין בכללי הגרסה.

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

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

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

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

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

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

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