‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

מה נבדק?

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

בדיקות של מכונות צומת
בדיקות ברמת האשכול

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

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

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

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

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

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

המכונות באשכול משתמשות במערכת הפעלה (OS) נתמכת.
גרסת מערכת ההפעלה נתמכת.
מערכת ההפעלה משתמשת בגרסת ליבה נתמכת.
האפשרות BPF Just In Time (JIT) compiler מופעלת בליבה (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 של מכונות הצומת.

התוקף של האישורים של kubeadm לא פג.

מידע נוסף על הדרישות לגבי מכונות צמתים זמין במאמר Cluster node machine prerequisites.

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

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

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

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

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

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

DaemonSet
- ההגדרות תקינות
- קבוצות הדימון (Daemon) תקינות
פריסה
- ההגדרות תקינות
- הפריסות תקינות
צומת (כל התנאים הבאים הם תנאי צומת)
- סטטוס מוכנות הצומת
- kubelet disk pressure
- kubelet memory pressure
- לחץ על מזהה התהליך (PID) של kubelet
- תדירות ההפעלה מחדש של kubelet
- ה-kubelet תקין
- זמינות הרשת
- הפונקציה containerd
- תדירות ההפעלה מחדש של containerd
- הפונקציה Docker Overlay2
- תדירות ההפעלה מחדש של Docker
- תדירות האירועים של ביטול הרישום של מכשיר ברשת
- מבוי סתום בליבה
- ‫KubeProxy תקין
- מערכת קבצים לקריאה בלבד
Pod
- ההגדרות תקינות
- ה-Pods תקינים
- הקונטיינרים תקינים
PodDisruptionBudget ‏ (PDB)
- ההגדרות תקינות
- פונקציית זמן ריצה של PDB
- קובצי PDB תואמים ל-pods
- תאי Pod שלא מנוהלים על ידי כמה PDB
בקשות למשאבים
- הבקשות של המעבד (CPU) והזיכרון מוגדרות ל-Pods בצמתי היעד
- הבקשה הממוצעת למשאבים לכל צומת נמצאת בתוך המגבלה המעקב
שירות
- ההגדרות תקינות
- השירותים תקינים
StatefulSet
- ההגדרות תקינות
- StatefulSet

בדיקות רשת

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

אם האשכול משתמש באיזון עומסים בחבילה, לצמתים במאגר הצמתים של איזון העומסים צריכה להיות קישוריות של פרוטוקול לפתרון כתובות (ARP) בשכבה 2. פרוטוקול ARP נדרש לגילוי של כתובות IP וירטואליות.
בצמתים של מישור הבקרה, היציאות 8443 ו-8444 פתוחות לשימוש על ידי GKE Identity Service.
בצמתים של מישור הבקרה, היציאות 2382 ו-2383 פתוחות לשימוש על ידי מופע etcd-events.

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

‏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*resources שפועלים באשכול הניהול במרחב השמות של האשכול. מידע נוסף על משאבי בדיקת תקינות זמין במאמר בנושא HealthCheckמשאבים בהתאמה אישית.

רכיבי Cloud Logging Stackdriver ו-Connect Agent פועלים:
- stackdriver-log-aggregator
- stackdriver-log-forwarder
- stackdriver-metadata-agent
- stackdriver-prometheus-k8
- gke-connect-agent
במשאבים שמנוהלים על ידי Google Distributed Cloud לא מוצגים שינויים ידניים (סחף הגדרות):
- ערכי השדות לא עודכנו
- לא נוספו או הוסרו שדות אופציונליים
- המשאבים לא נמחקו

אם בדיקת תקינות מזהה סחף תצורה, הערך של המשאב המותאם אישית 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‏ (API Version: baremetal.cluster.gke.io/v1): המשאבים האלה מספקים פרטים על בדיקות תקינות תקופתיות. המשאבים האלה נמצאים באשכול האדמין במרחבי השמות של האשכול. משאבי Bare Metal‏ (HealthCheck) אחראים ליצירת משימות וג'ובים של בדיקות תקינות ב-cron. המשאבים האלה מתעדכנים באופן עקבי עם התוצאות העדכניות ביותר.HealthCheck
משאבים מותאמים אישית של Anthos‏ (HealthCheck‏API Version: anthos.gke.io/v1): המשאבים האלה משמשים לדיווח על מדדים של בדיקות תקינות. המשאבים האלה נמצאים במרחב השמות kube-system של כל אשכול. העדכונים של המשאבים האלה מתבצעים בשיטת best effort. אם עדכון נכשל בגלל בעיה, כמו שגיאת רשת זמנית, המערכת מתעלמת מהכשל.

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

בדיקות תקינות של Bare Metal Anthos HealthChecks חוּמרה

בדיקות תקינות של 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`	קריטית
סוג: add-ons שם: `bm-system-add-ons`	סוג: add-ons שם: `bm-system-add-ons-add-ons` שם: `bm-system-add-ons-configdrift`	אופציונלי

סוג: ברירת מחדל

שם: 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

קריטית

סוג: add-ons

שם: bm-system-add-ons

סוג: add-ons

שם: bm-system-add-ons-add-ons

שם: bm-system-add-ons-configdrift

אופציונלי

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

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

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

כדי לקרוא פרטים על בדיקת תקינות ספציפית, משתמשים ב-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
  ...

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

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:

כדי לקבל רשימה של משימות 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). אי אפשר לערוך את מרווחי הזמן של בדיקות התקינות התקופתיות, אבל כדאי לדעת מתי הן אמורות לפעול כדי לפתור בעיות.

אחזור פרטים של 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

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

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

bmctl
check kubernetes

עבור אשכול בשם test-cluster, אפשר למצוא את היומנים בספרייה כמו bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

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

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

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

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

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

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 ביומני המסוף.

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

כניסה לדף Logs Explorer

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

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

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

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

ברירת מחדל

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 והתוספים הן בדיקות ברמת האשכול, ולכן יש משאב אחד לכל בדיקה. בדיקת המכונה מופעלת לכל צומת באשכול היעד, ולכן יש משאב לכל צומת.

כדי להציג רשימה של משאבי 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 משאבים בהתאמה אישית ויומני בדיקות תקינות.

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

בדיקות תקינות תקופתיות מופעלות כברירת מחדל בכל האשכולות. כדי להשבית בדיקות תקינות תקופתיות באשכול, צריך להגדיר את השדה periodicHealthCheck.enable לערך false במשאב Cluster.

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

עורכים את קובץ ההגדרות של האשכול ומוסיפים את השדה periodicHealthCheck.enable למפרט האשכול. מגדירים את הערך שלו ל-false:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: false
  ...

מריצים את הפקודה הבאה כדי לעדכן את האשכול:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול שרוצים לעדכן.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
כדי לוודא שהשבתתם את בדיקות התקינות התקופתיות, מריצים את הפקודה הבאה כדי לוודא שמשאבי healthchecks.baremetal.cluster.gke.io המתאימים נמחקו:
```
kubectl get healthchecks.baremetal.cluster.gke.io \
    --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
- ‫CLUSTER_NAMESPACE: מרחב השמות של אשכול היעד של בדיקת תקינות.

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

בדיקות תקינות תקופתיות מופעלות כברירת מחדל בכל האשכולות. אם השבתתם את בדיקות התקינות התקופתיות, אתם יכולים להפעיל אותן מחדש על ידי הגדרת השדה periodicHealthCheck.enable לערך true במשאב Cluster.

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

עורכים את קובץ ההגדרות של האשכול ומוסיפים את השדה periodicHealthCheck.enable למפרט האשכול. מגדירים את הערך שלו ל-true:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: true
  ...

מריצים את הפקודה הבאה כדי לעדכן את האשכול:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול שרוצים לעדכן.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
כדי לוודא שהפעלתם בדיקות תקינות תקופתיות, מריצים את הפקודה הבאה כדי לוודא שמשאבי healthchecks.baremetal.cluster.gke.io המתאימים קיימים:
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
- ‫CLUSTER_NAMESPACE: מרחב השמות של אשכול היעד של בדיקת תקינות.
יכול להיות שיחלפו כמה דקות עד שהמשאבים יופיעו.

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

בקטעים הבאים מפורטות בדיקות התקינות שאפשר להריץ לפי דרישה באמצעות bmctl check. כשמשתמשים ב-bmctl check כדי להריץ בדיקות תקינות, הכללים הבאים חלים:

כשבודקים אשכול משתמשים באמצעות הפקודה bmctl check, צריך לציין את הנתיב של קובץ ה-kubeconfig של אשכול האדמין באמצעות הדגל --kubeconfig.
היומנים נוצרים בספריית חותמות זמן בתיקיית היומנים של האשכול בתחנת העבודה של האדמין (כברירת מחדל, bmctl-workspace/CLUSTER_NAME/log).
יומנים של בדיקות תקינות נשלחים גם אל Cloud Logging. מידע נוסף על היומנים זמין במאמר יומנים של בדיקות תקינות.

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

תוספים

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

כדי לבדוק תוספים לאשכול:
```
bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שבודקים.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

רשימה של מה שנבדק מופיעה בקטע תוספים במסמך הזה.

הבדיקה הזו יוצרת קובצי יומן בספרייה check-addons-TIMESTAMP בתיקיית היומן של האשכול בתחנת העבודה של האדמין. היומנים נשלחים גם אל Cloud Logging. מידע נוסף על היומנים זמין במאמר בנושא יומנים של בדיקות תקינות.

אשכול

הכלי בודק את כל הצמתים באשכול, את הרשת של הצמתים, את Kubernetes ואת התוספים של האשכול שצוין. אתם מספקים את שם האשכול, וכברירת מחדל, הכלי bmctl מחפש את קובץ ההגדרות של האשכול בנתיב bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

כדי לבדוק את תקינות האשכול:
```
bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שבודקים.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

רשימה של מה שנבדק מופיעה בסעיפים הבאים של המסמך הזה, בקטע'מה נבדק':

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

הבדיקה הזו יוצרת קובצי יומן בספרייה check-cluster-TIMESTAMP בתיקיית היומן של האשכול בתחנת העבודה של האדמין. היומנים נשלחים גם אל Cloud Logging. מידע נוסף על היומנים זמין במאמר בנושא יומנים של בדיקות תקינות.

הגדרה

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

כדי לבדוק קובץ תצורה של אשכול:
```
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שבודקים.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

הפקודה הזו בודקת את תחביר ה-YAML של קובץ הגדרות האשכול, אתGoogle Cloud הגישה וההרשאות של חשבון השירות שצוין בקובץ הגדרות האשכול.

הבדיקה הזו יוצרת קובצי יומן בספרייה check-config-TIMESTAMP בתיקיית היומן של האשכול בתחנת העבודה של האדמין. היומנים נשלחים גם אל Cloud Logging. מידע נוסף על היומנים זמין במאמר בנושא יומנים של בדיקות תקינות.

קישוריות אל Google Cloud

מוודאים שלכל המכונות של צומתי האשכול יש גישה ל-Artifact Registry ‏ (gcr.io) ולנקודת הקצה של Google APIs ‏ (googleapis.com).

כדי לבדוק את הגישה של האשכול למשאבים הנדרשים Google Cloud :
```
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שבודקים.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

הבדיקה הזו יוצרת קובצי יומן בספרייה check-gcp-TIMESTAMP בתיקיית היומן של האשכול בתחנת העבודה של האדמין. היומנים נשלחים גם אל Cloud Logging. מידע נוסף על היומנים זמין במאמר בנושא יומנים של בדיקות תקינות.

‏Kubernetes

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

כדי לבדוק את התקינות של רכיבי Kubernetes באשכול:
```
bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שמכיל את הצמתים שבודקים.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

רשימה של מה שנבדק מופיעה בקטע Kubernetes במסמך הזה.

הבדיקה הזו יוצרת קובצי יומן בספרייה check-kubernetes-TIMESTAMP בתיקיית היומן של האשכול בתחנת העבודה של האדמין. היומנים נשלחים גם אל Cloud Logging. מידע נוסף על היומנים זמין במאמר בנושא יומנים של בדיקות תקינות.

צמתים

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

כדי לבדוק את תקינות המכונות של הצמתים באשכול:
```
bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שמכיל את הצמתים שבודקים.
- ‫NODE_IP_ADDRESSES: רשימה מופרדת בפסיקים של כתובות IP של מכונות צמתים.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

רשימה של מה שנבדק מופיעה בקטע בדיקות של מכונות צומת במסמך הזה.

בבדיקה הזו נוצרים קובצי יומן לכל מכונת צומת באשכול, בתיקייה check-nodes-TIMESTAMP בתיקיית היומן של האשכול בתחנת העבודה של האדמין. היומנים נשלחים גם ל-Cloud Logging. מידע נוסף על היומנים זמין במאמר יומנים של בדיקות תקינות.

קדם-הפעלה

מידע על שימוש ב-bmctl כדי להריץ בדיקות קדם-הפעלה זמין במאמרים הרצת בדיקות קדם-הפעלה לפי דרישה ליצירת אשכול והרצת בדיקות קדם-הפעלה לפי דרישה לשדרוג אשכול.

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

בדיקת קדם-הפעלה של VM Runtime ב-GDC מאמתת קבוצה של תנאים מוקדמים של מכונת צומת לפני השימוש ב-VM Runtime ב-GDC ובמכונות וירטואליות. אם בדיקת הטרום-הפעלה של VM Runtime ב-GDC נכשלת, יצירת ה-VM נחסמת. כשהערך של spec.enabled מוגדר ל-true במשאב המותאם אישית VMRuntime, בדיקת קדם-ההפעלה של VM Runtime ב-GDC מופעלת באופן אוטומטי.

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

מידע נוסף זמין במאמר בנושא בדיקת תאימות של VM Runtime ב-GDC.

הפעלת בדיקות התקינות העדכניות

בדיקות תקינות (ובדיקות קדם-הפעלה) מתעדכנות ככל שמזוהות בעיות ידועות. כדי להנחות את bmctl להריץ את הבדיקות מתמונת התיקון האחרונה של הגרסה המשנית המותקנת, משתמשים בדגל האפשרות --check-image-version latest:

bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest

מחליפים את CLUSTER_NAME בשם האשכול שרוצים לבדוק.

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

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

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

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

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

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

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

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

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

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

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

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

באופן כללי, מומלץ לא לבצע שינויים במשאבים שמנוהלים על ידי Google Distributed Cloud, ולא להתעלם משינויים שמתבצעים בהם. עם זאת, אנחנו יודעים שלפעמים צריך לשנות את המשאבים כדי לענות על דרישות ייחודיות או כדי לפתור בעיות. לכן, אנחנו מספקים ignore-config-drift ConfigMap לכל אשכול ב-Fleet. משתמשים ב-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

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

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

השדה הזה מקבל מערך של מחרוזות JSON, כאשר כל מחרוזת מציינת משאב, ואופציונלית, שדות ספציפיים במשאב.
מציינים את המשאב ואת השדות הספציפיים להתעלמות כאובייקט 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, אפשר לציין כמה תבניות להחרגה. אם אתם פותרים בעיות או מנסים דברים חדשים באשכולות שלכם ולא רוצים להפעיל שגיאות של שינוי בהגדרות, יכול להיות שימושי להחריג מהזיהוי של שינויים בהגדרות גם משאבים ספציפיים מאוד וגם שדות של משאבים או קטגוריות רחבות יותר של משאבים.

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

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

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

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

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

מה נבדק?

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

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

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

בדיקות רשת

‏Kubernetes

תוספים

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

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

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

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

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

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

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

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

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

תוספים

אשכול

הגדרה

קישוריות אל Google Cloud

‏Kubernetes

צמתים

קדם-הפעלה

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

הפעלת בדיקות התקינות העדכניות

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

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

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

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

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

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

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