פנייה לתמיכה

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

ב-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 שמשויך לאשכול. יומנים ברמת המערכת מגיעים מקבוצות Pod של 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 שמשויך לאשכול. המדדים ברמת המערכת הם מפודים של Kubernetes שפועלים באותם מרחבי שמות שמופיעים בקטע Cluster logs.

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

למידע נוסף, קראו את המאמר הגדרת רישום ביומן ומעקב.

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

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

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

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

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

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

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

במה Google תומכת?

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

Google Cloud נתמך	לא נתמך
‫Kubernetes וזמן הריצה של הקונטיינר	בחירה מותאמת אישית של מאזן עומסים (איזון עומסים ידני)
‫Connect ו-Connect Agent	קוד לקוח (ראו תמיכה למפתחים)
פעולות ב-Google Cloud , מעקב, רישום ביומן וסוכנים	בחירת הלקוח במערכת ההפעלה
מאזן עומסים בחבילה	שרת פיזי או וירטואלי, אחסון ורשת
בקר 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 ולרכיבים קשורים.

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

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

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

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

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

גרסת Google Distributed Cloud	תאריך השקה	תאריך סוף תקופת התמיכה^*
1.35	2026-04-29	‫29 באפריל 2027 או תאריך ההשקה של גרסה 1.38
1.34	2025-12-11	‫11 בדצמבר 2026 או תאריך ההשקה של גרסה 1.37
1.33	2025-09-02	‫2 בספטמבר 2026 או תאריך ההשקה של גרסה 1.36
1.32	2025-05-06	‫6 במאי 2026 או תאריך ההשקה של גרסה 1.35

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

למידע נוסף על תאימות גרסאות של 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.

גרסת תיקון של 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.34 → 1.35 → 1.36, אבל לא ‎1.34 → 1.36). כשמשדרגים מאגרי צמתים, במקרים מסוימים אפשר לדלג על גרסה משנית. מידע נוסף על לוגיקת השדרוג זמין במאמר כללי גרסאות.

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

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

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

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

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

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

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