אבחון בעיות באשכול

בכלי gkectl יש שתי פקודות לפתרון בעיות שקשורות לאשכולות: gkectl diagnose cluster ו-gkectl diagnose snapshot. הפקודות פועלות גם עם אשכולות של אדמינים וגם עם אשכולות של משתמשים. במסמך הזה מוסבר איך להשתמש בפקודה gkectl diagnose כדי לאבחן בעיות באשכולות.

שימו לב למגבלה הבאה בנוגע לאשכולות מתקדמים:

  • גרסה 1.31: הפקודות gkectl diagnose לא נתמכות באשכולות מתקדמים.
  • גרסה 1.32 ומעלה: הפקודות gkectl diagnose נתמכות באשכולות מתקדמים.

מידע נוסף על השימוש בפקודה gkectl diagnose snapshot כדי ליצור תמונות מצב שיכולות לעזור לצוות Cloud Customer Care לאבחן בעיות זמין במאמר יצירת תמונות מצב לאבחון אשכולות.

gkectl diagnose cluster

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

  • vCenter
    • פרטי כניסה
    • DRS
    • קבוצות אנטי-אפיניות
    • רשת
    • גרסה
    • מרכז נתונים
    • Datastore
    • ResourcePool
    • תיקייה
    • רשת
  • מאזן עומסים (F5,‏ Seesaw או ידני)
  • מאגרי צמתים ואשכולות משתמשים
  • אובייקטים באשכול
  • המוכנות של אשכול המשתמשים לשרת הקישוריות
  • אובייקטים של מכונות והצמתים המתאימים באשכול
  • ‫Pods במרחבי השמות kube-system ו-gke-system
  • מישור הבקרה
  • נפחי אחסון מתמיד ב-vSphere באשכול
  • אותות של תחרות על משאבים (CPU וירטואלי וזיכרון) באשכולות של משתמשים ואדמינים
  • ‫ESXi של אשכולות משתמשים ואדמינים הגדרות מוכנות מראש של התראות על שימוש במעבד (CPU) ובזיכרון של המארח.
  • השעה ביום (TOD)
  • מדיניות רשת של צומת באשכול עם Dataplane V2 מופעל
  • רמת התקינות הכוללת של סוכן הצומת Dataplane V2

אבחון של אשכול אדמין

כדי לאבחן אשכול אדמין, מציינים את הנתיב לאשכול האדמין:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

מחליפים את ADMIN_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול האדמין.

הפלט הבא מוחזר מהפקודה gkectl diagnose cluster:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS

- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

אם יש בעיה בכתובת IP וירטואלית (VIP) באשכול היעד, אפשר להשתמש בדגל --config כדי לספק את קובץ התצורה של אשכול האדמין ולקבל מידע על תוצאות ניפוי הבאגים.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG

מחליפים את CLUSTER_CONFIG בנתיב של קובץ התצורה של אשכול האדמין או המשתמש.

בדוגמת הפלט הבאה אפשר לראות שהפקודה gkectl diagnose cluster יכולה להתחבר עכשיו לאשכול ולבדוק אם יש בעיות:

Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...

אבחון של אשכול משתמשים

כדי לאבחן אשכול משתמשים, צריך לציין את שם אשכול המשתמשים. אם אתם צריכים לקבל את השם של אשכול משתמשים, מריצים את הפקודה הבאה:

kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG

מחליפים את USER_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול המשתמשים.

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

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

מחליפים את USER_CLUSTER_NAME בשם של אשכול המשתמשים.

הפלט הבא מוחזר מהפקודה gkectl diagnose cluster:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

Diagnose result is saved successfully in <DIAGNOSE_REPORT_JSON_FILE>

- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success

- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checeking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

אבחון הסטטוס של מכונה וירטואלית

אם מתעוררת בעיה ביצירת מכונה וירטואלית, מריצים את הפקודה gkectl diagnose cluster כדי לקבל אבחון של סטטוס המכונה הווירטואלית.

הפלט אמור להיראות כך:


- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
    Reason: 1 machine VMs error(s).
    Unhealthy Resources:
    Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
    Debug Information:
    null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot

פתרון בעיות

בטבלה הבאה מפורטים כמה פתרונות אפשריים לבעיות בהרצת הפקודה gkectl diagnose cluster:

שגיאהסיבות אפשריותרזולוציה
אי אפשר להגיע לשרת ה-API של Kubernetes, לא באשכול האדמין ולא באשכולות המשתמשים. בודקים את הגרפים של זמן האחזור של הזיכרון במכונה הווירטואלית OOB (out-of-box), שבאופן אידיאלי צריך להיות סביב אפס. התחרות על הזיכרון יכולה גם להגביר את התחרות על המעבד, ויכול להיות שיהיה זינוק בגרפים של מוכנות המעבד כי יתבצע החלפת זיכרון. הגדלת הזיכרון הפיזי. אפשרויות נוספות זמינות במאמר הצעות לפתרון בעיות ב-VMware.
הפעולה ליצירת מאגר צמתים נכשלת בגלל חריגה מזמן קצוב לתפוגה. זמן אחזור ארוך של קריאה/כתיבה ב-VMDK. בודקים את תקינות ה-VM מחוץ לרצועת התדרים (OOB) כדי לראות את זמן האחזור של קריאה וכתיבה בדיסק וירטואלי. לפי VMware, זמן אחזור כולל של יותר מ-20ms מצביע על בעיה. אפשר לעיין בפתרונות של VMware לבעיות בביצועים של דיסקים.

שגיאה מסוג BundleUnexpectedDiff

יכול להיות שמשאב ה-API של אשכול Kubernetes שמנוהל על ידי חבילת Google Distributed Cloud ישונה בטעות, וזה עלול לגרום לכשל ברכיבי המערכת או לכשל בשדרוג או בעדכון של האשכול.

ב-Google Distributed Cloud מגרסה 1.13 ואילך, ‏onprem-user-cluster-controller בודק מעת לעת את הסטטוס של האובייקטים ומדווח על כל הבדל לא צפוי מהמצב הרצוי באמצעות יומנים ואירועים. האובייקטים האלה כוללים את מישור הבקרה של אשכול המשתמשים ותוספים כמו Services ו-DaemonSets.

בדוגמה הבאה של פלט מוצג אירוע חריג של שינוי:

 Type     Reason                 Age    From                              Message
 ----     ------                 ----   ----                              -------
 Warning  BundleUnexpectedDiff   13m    onpremusercluster/ci-bundle-diff  Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.

בדוגמה הבאה מוצגים יומנים שנוצרו על ידי onprem-user-cluster-controller:

2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252       1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff:   map[string]string{
2022-08-06T02:54:42.701376406Z -    "mesh": (
2022-08-06T02:54:42.701381190Z -        """
2022-08-06T02:54:42.701385438Z -        defaultConfig:
2022-08-06T02:54:42.701389350Z -          discoveryAddress: istiod.gke-system.svc:15012
...
2022-08-06T02:54:42.701449954Z -        """
2022-08-06T02:54:42.701453099Z -    ),
2022-08-06T02:54:42.701456286Z -    "meshNetworks": "networks: {}",
2022-08-06T02:54:42.701459304Z +    "test-key":     "test-data",
2022-08-06T02:54:42.701462434Z   }

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

המאמרים הבאים

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

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