בדיקות תקינות של אשכול

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

מה נבדק?

יש שתי קטגוריות של בדיקות תקינות ב-Google Distributed Cloud:

• בדיקות של מכונות צמתים

• בדיקות בכל האשכול

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

בדיקות של מכונות צמתים

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

הבדיקות האלה תואמות למשאבים מותאמים אישית של Bare Metal HealthCheck בשם bm-system-NODE_IP_ADDRESS-machine (לדוגמה, bm-system-192.0.2.54-machine) שפועלים באשכול הניהול במרחב השמות של האשכול. מידע נוסף על משאבי בדיקת תקינות זמין במאמר HealthCheckמשאבים בהתאמה אישית.

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

• המכונות באשכול משתמשות במערכת הפעלה (OS) נתמכת.

• הגרסה של מערכת ההפעלה נתמכת.

• מערכת ההפעלה משתמשת בגרסת ליבה נתמכת.

• האפשרות BPF Just In Time (JIT) compiler (מהדר JIT של BPF) מופעלת בקרנל (CONFIG_BPF_JIT=y).

• ב-Ubuntu, חומת האש Uncomplicated Firewall ‏ (UFW) מושבתת.

• מכונות הצומת עומדות בדרישות המינימום של המעבד.

• במכונות הצמתים יש יותר מ-20% ממשאבי ה-CPU שזמינים.

• מכונות הצמתים עומדות בדרישות הזיכרון המינימליות.

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

• סנכרון הזמן מוגדר במכונות הצמתים.

• מסלול ברירת המחדל לניתוב מנות לשער ברירת המחדל מופיע בצמתים.

• מערכת DNS פועלת (הבדיקה הזו מדלגת אם האשכול מוגדר לפעול מאחורי שרת proxy).

• אם האשכול מוגדר לשימוש ברפליקציה של מאגר, אפשר להגיע לרפליקציה של המאגר.

הבדיקות של מכונות Google Cloud כוללות את הפעולות הבאות:

• אפשר להגיע אל Artifact Registry‏, gcr.io (הבדיקה הזו מדלגת אם האשכול מוגדר להשתמש בשיקוף של מאגר).

• אפשר להגיע אל Google APIs.

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

• ‫kubelet פעיל ופועל במכונות צמתים.

• ‫containerd פעיל ופועל במכונות צמתים.

• הסטטוס של נקודת הקצה של תקינות ממשק הרשת של הקונטיינר (CNI) הוא תקין.

• ה-CIDR של ה-Pod לא חופף לכתובות ה-IP של מכונות הצמתים.

מידע נוסף על הדרישות של הצומת מופיע במאמר דרישות של CPU,‏ RAM ואחסון.

בדיקות בכל האשכול

בקטע הזה מתואר מה נבדק בבדיקות התקינות של אשכול.

בדיקות ברירת מחדל

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

הבדיקות האלה תואמות למשאבים המותאמים אישית של Bare Metal HealthCheck שנקראים bm-system-default-*resources שפועלים באשכול הניהול במרחב השמות של האשכול. מידע נוסף על משאבי בדיקת תקינות זמין במאמר HealthCheckמשאבים בהתאמה אישית.

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

• DaemonSet

  • ההגדרות תקינות
  • קבוצות הדימונים תקינות

• פריסה

  • ההגדרות תקינות
  • הפריסות תקינות

• צומת (כל התנאים הבאים הם תנאי צומת)

  • סטטוס מוכנות הצומת
  • kubelet disk pressure
  • kubelet memory pressure
  • לחץ על מזהה התהליך (PID) של kubelet
  • תדירות ההפעלה מחדש של kubelet
  • ה-kubelet תקין
  • זמינות הרשת
  • הפונקציה containerd
  • תדירות ההפעלה מחדש של containerd
  • הפונקציה Docker Overlay2
  • תדירות ההפעלה מחדש של Docker
  • תדירות האירועים של ביטול הרישום של מכשיר ברשת
  • קיפאון בליבה
  • ה-KubeProxy תקין
  • מערכת קבצים לקריאה בלבד

• Pod

  • ההגדרות תקינות
  • הפודים תקינים
  • הקונטיינרים תקינים

• PodDisruptionBudget (PDB)

  • ההגדרות תקינות
  • פונקציית זמן ריצה של PDB
  • התאמה של קובצי PDB ל-Pods
  • אין אפשרות לנהל פודים באמצעות כמה PDB

• בקשות למשאבים

  • ל-Pods בצמתי היעד מוגדרות בקשות של מעבד (CPU) וזיכרון
  • הבקשה הממוצעת למשאבים לכל צומת נמצאת בתוך המגבלה המעקב

• שירות

  • ההגדרות תקינות
  • השירותים תקינים

• StatefulSet

  • ההגדרות תקינות
  • StatefulSet

בדיקות רשת

במסגרת בדיקות התקינות התקופתיות, מתבצעות באופן אוטומטי בדיקות הרשת הבאות של צומתי אשכולות בצד הלקוח. אי אפשר להפעיל בדיקות רשת לפי דרישה. הבדיקות האלה תואמות למשאבים המותאמים אישית של Bare Metal HealthCheck שנקראים bm-system-network ופועלים באשכול הניהול במרחב השמות של האשכול. מידע נוסף על משאבי בדיקת תקינות זמין במאמר בנושא HealthCheck משאבים בהתאמה אישית.

• אם באשכול נעשה שימוש באיזון עומסים בחבילה, לצמתים במאגר הצמתים של איזון העומסים צריכה להיות קישוריות של פרוטוקול לפתרון כתובות (ARP) בשכבה 2. נדרש ARP לגילוי של כתובת IP וירטואלית.

• בצמתים של מישור הבקרה, היציאות 8443 ו-8444 פתוחות לשימוש על ידי GKE Identity Service.

• בצמתים של מישור הבקרה, היציאות 2382 ו-2383 פתוחות לשימוש על ידי מופע etcd-events.

מידע על פרוטוקולים ושימוש ביציאות באשכולות זמין במאמר כללי proxy וחומת אש.

‏Kubernetes

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

הבדיקות האלה תואמות למשאבים המותאמים אישית של Bare Metal HealthCheck שנקראים bm-system-kubernetesresources שפועלים באשכול הניהול במרחב השמות של האשכול. מידע נוסף על משאבי בדיקת תקינות זמין במאמר HealthCheckמשאבים בהתאמה אישית.

• שרת ה-API פועל.

• מפעיל השירות anetd מוגדר בצורה נכונה.

• כל הצמתים של מישור הבקרה פועלים.

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

  • anthos-cluster-operator

  • controller-manager

  • cluster-api-provider

  • ais

  • capi-kubeadm-bootstrap-system

  • cert-manager

  • kube-dns

תוספים

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

הבדיקות האלה תואמות למשאבים מותאמים אישית של Bare Metal HealthCheck שנקראים bm-system-add-ons*משאבים שפועלים באשכול הניהול במרחב השמות של האשכול. מידע נוסף על משאבי בדיקת תקינות זמין במאמר HealthCheckמשאבים בהתאמה אישית.

• רכיבי Cloud Logging Stackdriver ו-Connect Agent ניתנים להפעלה:

  • stackdriver-log-aggregator

  • stackdriver-log-forwarder

  • stackdriver-metadata-agent

  • stackdriver-prometheus-k8

  • gke-connect-agent

• במשאבים שמנוהלים על ידי Google Distributed Cloud לא מוצגים שינויים ידניים (config drift):

  • ערכי השדות לא עודכנו

  • לא נוספו או הוסרו שדות אופציונליים

  • המשאבים לא נמחקו

אם בדיקת התקינות מזהה שינוי בהגדרות, הערך של המשאב המותאם אישית bm-system-add-ons Bare Metal HealthCheck Status.Pass מוגדר ל-false. השדה Description בקטע Failures מכיל פרטים על כל המשאבים שהשתנו, כולל המידע הבא:

• ‫Version: גרסת ה-API של המשאב.
• ‫Kind: סכימת האובייקט, למשל Deployment, של המשאב.
• ‫Namespace: מרחב השמות שבו נמצא המשאב.
• ‫Name: שם המשאב.
• ‫Diff: השוואה בפורמט מחרוזת של ההבדלים בין מניפסט המשאב שמתועד לבין המניפסט של המשאב ששוּנה.

HealthCheck משאבים מותאמים אישית

כשמריצים בדיקת תקינות, Google Distributed Cloud יוצר HealthCheck משאב מותאם אישית. HealthCheck משאבים בהתאמה אישית הם קבועים ומספקים תיעוד מובנה של פעילויות ותוצאות של בדיקות תקינות. יש שתי קטגוריות של HeathCheck משאבים בהתאמה אישית:

• משאבים מותאמים אישית של Bare Metal HealthCheck (API Version: baremetal.cluster.gke.io/v1): המשאבים האלה מספקים פרטים על בדיקות תקינות תקופתיות. המשאבים האלה נמצאים באשכול הניהול במרחבי השמות של האשכול. משאבי Bare Metal HealthCheck אחראים ליצירת משימות ומשימות cron לבדיקת תקינות. מקורות המידע האלה מתעדכנים באופן קבוע עם התוצאות העדכניות ביותר.

• משאבים מותאמים אישית של Anthos‏ (HealthCheck): המשאבים האלה משמשים לדיווח על מדדים של בדיקות תקינות.API Version: anthos.gke.io/v1 המשאבים האלה נמצאים במרחב השמות kube-system של כל אשכול. העדכונים של המשאבים האלה הם בשיטת הכי טוב שאפשר. אם עדכון נכשל בגלל בעיה, כמו שגיאה זמנית ברשת, המערכת מתעלמת מהכשל.

בטבלה הבאה מפורטים סוגי המשאבים שנוצרים עבור קטגוריה HealthCheck:

בדיקות תקינות של Bare Metal	Anthos HealthChecks	חוּמרה
סוג: ברירת מחדל שם: bm-system-default-daemonset שם: bm-system-default-deployment שם: bm-system-default-node שם: bm-system-default-pod שם: bm-system-default-poddisruptionbudget שם: bm-system-default-resource שם: bm-system-default-service שם: bm-system-default-statefulset	סוג: ברירת מחדל שם: bm-system-default-daemonset שם: bm-system-default-deployment שם: bm-system-default-node שם: bm-system-default-pod שם: bm-system-default-poddisruptionbudget שם: bm-system-default-resource שם: bm-system-default-service שם: bm-system-default-statefulset	קריטית
Type: machine שם: bm-system-NODE_IP_ADDRESS-machine	Type: machine שם: bm-system-NODE_IP_ADDRESS-machine	קריטית
סוג: רשת שם: bm-system-network	סוג: רשת שם: bm-system-network	קריטית
סוג: kubernetes שם: bm-system-kubernetes	סוג: kubernetes שם: bm-system-kubernetes	קריטית
סוג: תוספים שם: bm-system-add-ons	סוג: תוספים שם: bm-system-add-ons-add-ons שם: bm-system-add-ons-configdrift	אופציונלי

כדי לאחזר את הסטטוס של HealthCheck:

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

   kubectl get healthchecks.baremetal.cluster.gke.io \
       --kubeconfig ADMIN_KUBECONFIG \
       --all-namespaces
   

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

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

   NAMESPACE               NAME                               PASS    AGE
   cluster-test-admin001   bm-system-192.0.2.52-machine       true    11d
   cluster-test-admin001   bm-system-add-ons                  true    11d
   cluster-test-admin001   bm-system-kubernetes               true    11d
   cluster-test-admin001   bm-system-network                  true    11d
   cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
   cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
   cluster-test-user001    bm-system-add-ons                  true    56d
   cluster-test-user001    bm-system-kubernetes               true    56d
   cluster-test-user001    bm-system-network                  true    56d
   

   הערה: לכל המשאבים של בדיקות התקינות התקופתיות יש את התווית baremetal.cluster.gke.io/periodic-health-check=true.

2. כדי לקרוא פרטים על בדיקת תקינות ספציפית, משתמשים ב-kubectl describe:

   kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫HEALTHCHECK_NAME: השם של בדיקת תקינות.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.

   כשבודקים את המשאב, בקטע Status: מופיעים השדות החשובים הבאים:

   • ‫Pass: מציין אם המשימה האחרונה של בדיקת תקינות עברה או לא.
   • ‫Checks: מכיל מידע על משימת בדיקת התקינות האחרונה.
   • ‫Failures: מכיל מידע על המשימה האחרונה שנכשלה.
   • ‫Periodic: מכיל מידע כמו מתי נקבעה לאחרונה משימת בדיקת תקינות ומתי היא בוצעה.

   בדוגמה הבאה של HealthCheck מוצגת בדיקה מוצלחת של מכונה:

   Name:         bm-system-192.0.2.54-machine
   Namespace:    cluster-test-user001
   Labels:       baremetal.cluster.gke.io/periodic-health-check=true
                 machine=192.0.2.54
                 type=machine
   Annotations:  <none>
   API Version:  baremetal.cluster.gke.io/v1
   Kind:         HealthCheck
   Metadata:
     Creation Timestamp:  2023-09-22T18:03:27Z
     ...
   Spec:
     Anthos Bare Metal Version:  1.16.0
     Cluster Name:               nuc-user001
     Interval In Seconds:        3600
     Node Addresses:
       192.168.1.54
     Type:  machine
   Status:
     Check Image Version:  1.16.0-gke.26
     Checks:
       192.168.1.54:
         Job UID:  345b74a6-ce8c-4300-a2ab-30769ea7f855
         Message:
         Pass:     true
     ...
     Cluster Spec:
       Anthos Bare Metal Version:  1.16.0
       Bypass Preflight Check:     false
       Cluster Network:
         Bundled Ingress:  true
         Pods:
           Cidr Blocks:
             10.0.0.0/16
         Services:
           Cidr Blocks:
             10.96.0.0/20
     ...
     Conditions:
       Last Transition Time:  2023-11-22T17:53:18Z
       Observed Generation:   1
       Reason:                LastPeriodicHealthCheckFinished
       Status:                False
       Type:                  Reconciling
     Node Pool Specs:
       node-pool-1:
         Cluster Name:  nuc-user001
       ...
     Pass:                  true
     Periodic:
       Last Schedule Time:                    2023-11-22T17:53:18Z
       Last Successful Instrumentation Time:  2023-11-22T17:53:18Z
     Start Time:                              2023-09-22T18:03:28Z
   Events:
     Type    Reason                  Age                  From                    Message
     ----    ------                  ----                 ----                    -------
     Normal  HealthCheckJobFinished  6m4s (x2 over 6m4s)  healthcheck-controller  health check job bm-system-192.0.2.54-machine-28344593 finished
   

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

   Name:         bm-system-192.0.2.57-machine
   Namespace:    cluster-user-cluster1
   ...
   API Version:  baremetal.cluster.gke.io/v1
   Kind:         HealthCheck
   ...
   Status:
     Checks:
       192.0.2.57:
         Job UID:  492af995-3bd5-4441-a950-f4272cb84c83
         Message:  following checks failed, ['check_kubelet_pass']
         Pass:     false
     Failures:
       Category:     AnsibleJobFailed
       Description:  Job: machine-health-check.
       Details:       Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn].
       Reason:       following checks failed, ['check_kubelet_pass']
     Pass:                  false
     Periodic:
       Last Schedule Time:                    2023-10-24T23:04:21Z
       Last Successful Instrumentation Time:  2023-10-24T23:31:30Z
     ...
   

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

   kubectl get healthchecks.anthos.gke.io \
       --kubeconfig CLUSTER_KUBECONFIG \
       --namespace kube-system
   

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

   בדוגמה הבאה אפשר לראות את פורמט התגובה:

   NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
   kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
   kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
   kube-system   bm-system-default-daemonset                                             Healthy   52m
   kube-system   bm-system-default-deployment                                            Healthy   52m
   kube-system   bm-system-default-node                                                  Healthy   52m
   kube-system   bm-system-default-pod                                                   Healthy   52m
   kube-system   bm-system-default-poddisruptionbudget                                   Healthy   52m
   kube-system   bm-system-default-resource                                              Healthy   52m
   kube-system   bm-system-default-service                                               Healthy   52m
   kube-system   bm-system-default-statefulset                                           Healthy   57m
   kube-system   bm-system-kubernetes                                                    Healthy   57m
   kube-system   bm-system-network                                                       Healthy   32m
   kube-system   component-status-controller-manager                                     Healthy   5s
   kube-system   component-status-etcd-0                                                 Healthy   5s
   kube-system   component-status-etcd-1                                                 Healthy   5s
   kube-system   component-status-scheduler                                              Healthy   5s
   

משימות cron לבדיקת תקינות

לכל משאב מותאם אישית של HealthCheck Bare Metal יש CronJob תואם עם אותו שם, לצורך בדיקות תקינות תקופתיות. ה-CronJob הזה אחראי לתזמון של בדיקת התקינות המתאימה שתופעל במרווחי זמן קבועים. ה-CronJob כולל גם קונטיינר ansible-runner שמריץ את בדיקת התקינות על ידי יצירת חיבור Secure Shell‏ (SSH) לצמתים.

כדי לאחזר מידע על משימות cron:

1. כדי לקבל רשימה של משימות cron שהופעלו באשכול נתון:

   kubectl get cronjobs \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.

   בדוגמה הבאה מוצגת תגובה אופיינית:

   NAMESPACE           NAME                           SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   cluster-test-admin   bm-system-10.200.0.3-machine   17 */1 * * *   False     0        11m             25d
   cluster-test-admin   bm-system-add-ons              25 */1 * * *   False     0        3m16s           25d
   cluster-test-admin   bm-system-kubernetes           16 */1 * * *   False     0        12m             25d
   cluster-test-admin   bm-system-network              41 */1 * * *   False     0        47m             25d
   

   הערכים בעמודה SCHEDULE מציינים את לוח הזמנים של כל הפעלה של משימת בדיקת תקינות בתחביר של לוח זמנים. לדוגמה, המשימה bm-system-kubernetes פועלת כל שעה (*/1) בכל יום (* * *) בדקה ה-17 אחרי כל שעה עגולה (17). אי אפשר לערוך את מרווחי הזמן של בדיקות תקינות תקופתיות, אבל כדאי לדעת מתי הן אמורות לפעול כדי לפתור בעיות.

2. אחזור פרטים של CronJob משאב מותאם אישית ספציפי:

   kubectl describe cronjob CRONJOB_NAME \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.

   בדוגמה הבאה מוצגת תגובה של CronJob שבוצעה בהצלחה:

   Name:                          bm-system-network
   Namespace:                     cluster-test-admin
   Labels:                        AnthosBareMetalVersion=1.16.1
                                  baremetal.cluster.gke.io/check-name=bm-system-network
                                  baremetal.cluster.gke.io/periodic-health-check=true
                                  controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613
                                  type=network
   Annotations:                   target: node-network
   Schedule:                      41 */1 * * *
   Concurrency Policy:            Forbid
   Suspend:                       False
   Successful Job History Limit:  1
   Failed Job History Limit:      1
   Starting Deadline Seconds:     <unset>
   Selector:                      <unset>
   Parallelism:                   <unset>
   Completions:                   1
   Active Deadline Seconds:       3600s
   Pod Template:
     Labels:           baremetal.cluster.gke.io/check-name=bm-system-network
     Annotations:      target: node-network
     Service Account:  ansible-runner
     Containers:
     ansible-runner:
       Image:      gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5
       Port:       <none>
       Host Port:  <none>
       Command:
         cluster
       Args:
         -execute-command=network-health-check
         -login-user=root
         -controlPlaneLBPort=443
       Environment:  <none>
       Mounts:
         /data/configs from inventory-config-volume (ro)
         /etc/ssh-key from ssh-key-volume (ro)
     Volumes:
     inventory-config-volume:
       Type:      ConfigMap (a volume populated by a ConfigMap)
       Name:      bm-system-network-inventory-bm-system-ne724a7cc3584de0635099
       Optional:  false
     ssh-key-volume:
       Type:            Secret (a volume populated by a Secret)
       SecretName:      ssh-key
       Optional:        false
   Last Schedule Time:  Tue, 14 Nov 2023 18:41:00 +0000
   Active Jobs:         <none>
   Events:
     Type    Reason            Age   From                Message
     ----    ------            ----  ----                -------
     Normal  SuccessfulCreate  48m   cronjob-controller  Created job bm-system-network-28333121
     Normal  SawCompletedJob   47m   cronjob-controller  Saw completed job: bm-system-network-28333121, status: Complete
     Normal  SuccessfulDelete  47m   cronjob-controller  Deleted job bm-system-network-28333061
   

יומנים של בדיקת תקינות

כשמריצים בדיקות תקינות, נוצרים יומנים. בין אם אתם מריצים בדיקות תקינות באמצעות gkectl diagnose cluster או שהן מורצות באופן אוטומטי כחלק מבדיקות תקינות תקופתיות, היומנים נשלחים אל Cloud Logging. כשמריצים בדיקות תקינות לפי דרישה, נוצרים קובצי יומן ב-/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log.

צפייה ביומנים באופן מקומי

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

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

   kubectl get pods \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.

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

   NAME                                                              READY   STATUS      RESTARTS   AGE
   bm-system-10.200.0.4-machine-28353626-lzx46                       0/1     Completed   0          12m
   bm-system-10.200.0.5-machine-28353611-8vjw2                       0/1     Completed   0          27m
   bm-system-add-ons-28353614-gxt8f                                  0/1     Completed   0          24m
   bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c   0/1     Completed   0          75m
   bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk   0/1     Completed   0          74m
   bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj   0/1     Completed   0          67m
   bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj   0/1     Completed   0          77m
   bm-system-kubernetes-28353604-4tc54                               0/1     Completed   0          34m
   bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn   0/1     Completed   0          63m
   bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z   0/1     Completed   0          77m
   ...
   bm-system-network-28353597-cbwk7                                  0/1     Completed   0          41m
   bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd   0/1     Completed   0          76m
   bm-system-network-preflight-check-create275a0fdda700cb2b44b264c   0/1     Completed   0          77m
   

2. אחזור יומנים של פוד:

   kubectl logs POD_NAME  \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫POD_NAME: השם של ה-pod לבדיקת תקינות.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.

   בדוגמה הבאה מוצג חלק מיומן של pod לבדיקת תקינות מוצלחת של מכונת צומת:

   ...
   TASK [Summarize health check] **************************************************
   Wednesday 29 November 2023  00:26:22 +0000 (0:00:00.419)       0:00:19.780 ****
   ok: [10.200.0.4] => {
       "results": {
           "check_cgroup_pass": "passed",
           "check_cni_pass": "passed",
           "check_containerd_pass": "passed",
           "check_cpu_pass": "passed",
           "check_default_route": "passed",
           "check_disks_pass": "passed",
           "check_dns_pass": "passed",
           "check_docker_pass": "passed",
           "check_gcr_pass": "passed",
           "check_googleapis_pass": "passed",
           "check_kernel_version_pass": "passed",
           "check_kubelet_pass": "passed",
           "check_memory_pass": "passed",
           "check_pod_cidr_intersect_pass": "passed",
           "check_registry_mirror_reachability_pass": "passed",
           "check_time_sync_pass": "passed",
           "check_ubuntu_1804_kernel_version": "passed",
           "check_ufw_pass": "passed",
           "check_vcpu_pass": "passed"
       }
   }
   ...
   

   בדוגמה הבאה מוצג חלק מיומן של פוד לבדיקת תקינות של מכונת צומת שנכשלה. בדוגמה אפשר לראות שהבדיקה kubelet (check_kubelet_pass) נכשלה, מה שמצביע על כך ש-kubelet לא פועל בצומת הזה.

   ...
   TASK [Reach a final verdict] ***************************************************
   Thursday 02 November 2023  17:30:19 +0000 (0:00:00.172)       0:00:17.218 *****
   fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"}
   ...
   

צפייה ביומנים ב-Cloud Logging

יומני בדיקת התקינות מועברים בסטרימינג אל Cloud Logging, ואפשר לראות אותם ב-Logs Explorer. בדיקות התקינות התקופתיות מסווגות כ-Pods ביומני המסוף.

1. במסוף Google Cloud , נכנסים לדף Logs Explorer בתפריט Logging.

   כניסה לדף Logs Explorer

2. בשדה Query, מזינים את השאילתה הבסיסית הבאה:

   resource.type="k8s_container"
   resource.labels.pod_name=~"bm-system.*-machine.*"
   

3. בחלון Query results מוצגים היומנים של בדיקות התקינות של מכונת הצומת.

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

• ברירת מחדל

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system.default-*"
  

• מכונת צומת

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system.*-machine.*"
  

• רשת

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system-network.*"
  

• ‏Kubernetes

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system-kubernetes.*"
  

• תוספים

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system-add-ons.*"
  

בדיקות תקינות תקופתיות

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

• ברירת מחדל
• מכונה
• רשת
• Kubernetes
• תוספים

כדי לבדוק את תקינות האשכול, אפשר לעיין במשאבים המותאמים אישית של Bare Metal HealthCheck (healthchecks.baremetal.cluster.gke.io) באשכול האדמין. הבדיקות של הרשת, Kubernetes והתוספים הן בדיקות ברמת האשכול, ולכן יש משאב אחד לכל בדיקה. מתבצעת בדיקת מכונה לכל צומת באשכול היעד, כך שיש משאב לכל צומת.

הערה: ב-Google Distributed Cloud for VMware אין תמיכה בהשבתה של בדיקות תקינות תקופתיות.

• כדי להציג רשימה של משאבי HealthCheck Bare Metal עבור אשכול נתון, מריצים את הפקודה הבאה:

  kubectl get healthchecks.baremetal.cluster.gke.io \
      --kubeconfig=ADMIN_KUBECONFIG \
      --namespace=CLUSTER_NAMESPACE
  

  מחליפים את מה שכתוב בשדות הבאים:

  • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

  • ‫CLUSTER_NAMESPACE: מרחב השמות של אשכול היעד של בדיקת תקינות.

  בדוגמה הבאה של תגובה מוצג הפורמט:

  NAMESPACE               NAME                               PASS    AGE
  cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
  cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
  cluster-test-user001    bm-system-add-ons                  true    56d
  cluster-test-user001    bm-system-kubernetes               true    56d
  cluster-test-user001    bm-system-network                  true    56d
  

  בשדה Pass של healthchecks.baremetal.cluster.gke.io מצוין אם בדיקת התקינות האחרונה עברה (true) או נכשלה (false).

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

בדיקות תקינות על פי דרישה

כדי להריץ בדיקות תקינות לפי דרישה, משתמשים בפקודה gkectl diagnose cluster. כשמשתמשים ב-gkectl diagnose cluster כדי להריץ בדיקות תקינות, הכללים הבאים חלים:

• כשבודקים אשכול משתמשים באמצעות פקודה gkectl diagnose cluster, צריך לציין את הנתיב של קובץ ה-kubeconfig של אשכול האדמין באמצעות הדגל --kubeconfig.

• היומנים נוצרים בתיקייה עם חותמת זמן בתיקיית היומנים של האשכול בתחנת העבודה של האדמין (כברירת מחדל, /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log).

• יומני בדיקות התקינות נשלחים גם ל-Cloud Logging. מידע נוסף על היומנים זמין במאמר בנושא יומנים של בדיקות תקינות.

זיהוי שינויים בהגדרות

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

אילו מניפסטים נבדקים

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

ClusterRoles ClusterRoleBindings CustomResourceDefinitions DaemonSets פריסות HorizontalPodAutoscalers מנפיקים

MetricsServers MutatingWebhookConfigurations מרחבי שמות רשתות NetworkLoggings PodDisruptionBudgets ספקים

תפקידים RoleBindings שירותים StorageClasses ValidatingWebhookConfigurations

אילו מניפסטים לא נבדקים

כברירת מחדל, אנחנו לא בודקים חלק מהמניפסטים. מטעמי פרטיות ואבטחה, אנחנו מתעלמים מסוגים מסוימים של משאבים, כמו Certificates,‏ Secrets ו-ServiceAccounts. בנוסף, הבדיקה של התוספים מתעלמת מחלק מהמשאבים ושדות המשאבים, כי אנחנו מצפים שהם ישתנו ולא רוצים שהשינויים יפעילו שגיאות של סטיות בהגדרות. לדוגמה, הבדיקה מתעלמת משדות replicas בפריסות, כי יכול להיות שהמידרוג האוטומטי ישנה את הערך הזה.

איך מחריגים מביקורת מניפסטים נוספים או חלקים ממניפסטים

באופן כללי, מומלץ לא לבצע שינויים במשאבים שמנוהלים על ידי Google Distributed Cloud, או להתעלם משינויים שמתבצעים בהם. עם זאת, אנחנו יודעים שלפעמים צריך לשנות משאבים כדי לענות על דרישות ייחודיות או כדי לפתור בעיות. לכן, אנחנו מספקים ignore-config-drift ConfigMap לכל אשכול בצי. משתמשים ב-ConfigMaps האלה כדי לציין משאבים ושדות משאבים ספציפיים שיוחרגו מההערכה.

‫Google Distributed Cloud יוצרת ignore-config-drift ConfigMap לכל אשכול. קובצי ה-ConfigMap האלה נמצאים באשכול הניהול (אדמין או היברידי) במרחב השמות של האשכול המתאים. לדוגמה, אם יש לכם אשכול אדמין (admin-one) שמנהל שני אשכולות משתמשים (user-one ו-user-two), תוכלו למצוא את ConfigMap של האשכול user-one באשכול admin-one במרחב השמות cluster-user-one.ignore-config-drift

כדי להחריג משאב או שדות משאב מהבדיקה:

1. מוסיפים שדה data.ignore-resources ל-ConfigMap‏ ignore-config-drift.

   השדה הזה מקבל מערך של מחרוזות JSON, כאשר כל מחרוזת מציינת משאב, ואופציונלית, שדות ספציפיים במשאב.

2. מציינים את המשאב ואת השדות הספציפיים להתעלמות כאובייקט JSON במערך המחרוזות:

   אובייקט ה-JSON של משאב ושדות בנוי באופן הבא:

   {
     "Version": "RESOURCE_VERSION",
     "Kind": "RESOURCE_KIND",
     "Namespace": "RESOURCE_NAMESPACE",
     "Name": "RESOURCE_NAME",
     "Fields": [
       "FIELD_1_NAME",
       "FIELD_2_NAME",
       ...
       "FIELD_N_NAME"
     ]
   }
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫RESOURCE_VERSION: (אופציונלי) הערך apiVersion של המשאב.

   • ‫RESOURCE_KIND: (אופציונלי) הערך kind של המשאב.

   • ‫RESOURCE_NAMESPACE: (אופציונלי) ערך metadata.namespace של המשאב.

   • ‫RESOURCE_NAME: (אופציונלי) הערך metadata.name של המשאב.

   • ‫FIELD_NAME: (אופציונלי) מציינים מערך של שדות משאבים שצריך להתעלם מהם. אם לא מציינים שדות, התוספים מתעלמים מכל השינויים במשאב.

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

   לדוגמה, אם רוצים שהבדיקה של התוספים תתעלם משינויים רק בקטע command של הפריסה ais באשכול הניהול, קובץ ה-JSON יכול להיראות כך:

   {
     "Version": "apps/v1",
     "Kind": "Deployment",
     "Namespace": "anthos-identity-service",
     "Name": "ais",
     "Fields": [
       "command"
     ]
   }
   

   מוסיפים את אובייקט ה-JSON הזה ל-ignore-resources ב-config-drift-ignore ConfigMap כמחרוזת במערך, כמו בדוגמה הבאה:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     creationTimestamp: "2024-09-24T00:39:45Z"
     name: config-drift-ignore
     namespace: cluster-example-admin
     ownerReferences:
     - apiVersion: baremetal.cluster.gke.io/v1
       kind: Cluster
       name: example-admin
     ...
   data:
     ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]'
     ...
   

   ההגדרה הזו של ConfigMap מאפשרת להוסיף, להסיר או לערוך שדות בפריסה בלי להפעיל שגיאות של סטיות בהגדרות.commandais עם זאת, עריכות בשדות מחוץ לקטע command בפריסה עדיין מזוהות על ידי הבדיקה של התוספים ומדווחות כשינוי בהגדרות.

   אם רוצים להחריג את כל הפריסות, הערך ignore-resources יכול להיראות כך:

   ...
   data:
     ignore-resources: '[{"Kind":"Deployment"}]'
   ...
   

   מכיוון שהפונקציה ignore-resources מקבלת מערך של מחרוזות JSON, אפשר לציין כמה תבניות להחרגה. אם אתם פותרים בעיות או מנסים דברים חדשים באשכולות שלכם ולא רוצים להפעיל שגיאות של שינוי בהגדרות, יכול להיות שימושי להחריג מהזיהוי של שינויים בהגדרות גם משאבים מאוד ספציפיים וגם שדות של משאבים או קטגוריות רחבות יותר של משאבים.

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

למידע נוסף, קראו את המאמרים הבאים:

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

• הסבר על ההשפעה של כשלים ב-Google Distributed Cloud

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

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

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