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

בדיקות קדם הפעלה

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

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

‫`PreflightCheck` משאבים בהתאמה אישית

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

כדי לאחזר משאבים בהתאמה אישית של PreflightCheck:

כדי לקבל רשימה של בדיקות מקדימות שבוצעו באשכול מסוים:
```
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
- ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.
התשובה מפרטת את המשאבים לפי מרחב שמות. כדי לקבל רשימה מקיפה, אפשר להריץ את kubectl get preflightchecks בכל מרחבי השמות. בתשובה מוצג הגיל של כל משאב, ומצוין אם הבדיקות המקדימות עברו בהצלחה. בתגובה לדוגמה הבאה מוצגים משאבי PreflightCheck למרחב השמות cluster-test-admin001.
```
NAMESPACE              NAME                                PASS    AGE
cluster-test-admin001   test-admin001                      true    52d
cluster-test-admin001   test-admin001jkm4q                 true    52d
cluster-test-admin001   test-admin001k79t7                 true    6d20h
cluster-test-admin001   upgrade-cluster-20231106-222746    true    6d20h
```

אחזור הפרטים של משאב PreflightCheck ספציפי בהתאמה אישית:

kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

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

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

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

Name:         create-cluster-20230922-175006
Namespace:    cluster-test-user001
Labels:       <none>
Annotations:  <none>
API Version:  baremetal.cluster.gke.io/v1
Kind:         PreflightCheck
Metadata:
  Creation Timestamp:  2023-09-22T17:50:11Z
  Generation:          1
  Resource Version:    6502800
  UID:                 917daf64-963d-44b4-a1f9-c54972a39191
Spec:
  Check Image Version:  latest
  Config YAML:          ---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-test-user
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: test-user001
  namespace: cluster-test-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.0
  gkeConnect:
    projectID: clusters-project
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 192.0.2.53
  ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-test-user001
spec:
  clusterName: test-user001
  nodes:
  - address: 192.0.2.54
  ...
Status:
  Checks:
    192.0.2.53:
      Job UID:  d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c
      Message:  
      Pass:     true
    192.0.2.53-gcp:
      Job UID:  b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8
      Message:  
      Pass:     true
    192.0.2.54:
      Job UID:  b67cf195-3951-46ad-b91c-0d79025cfc0a
      Message:  
      Pass:     true
    192.0.2.54-gcp:
      Job UID:  aed509e2-4bf7-44c4-bfa0-8147ef8ea74e
      Message:  
      Pass:     true
    Gcp:
      Job UID:  ac479ac4-e1c4-4681-9f2b-5773069bf6ae
      Message:  
      Pass:     true
    Node - Network:
      Job UID:  8a57c4ee-ad17-4560-8809-b117c871ad5d
      Message:  
      Pass:     true
    Pod - Cidr:
      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
  ...
  Completion Time:                 2023-09-22T17:51:22Z
  Conditions:
    Last Transition Time:  2023-10-02T23:59:06Z
    Observed Generation:   1
    Reason:                Reconciling
    Status:                True
    Type:                  Reconciling
  Node Pool Specs:
    node-pool-1:
      Cluster Name:  test-user001
      Nodes:
        Address:         192.0.2.54
    ...
  Pass:                  true
  Start Time:            2023-09-22T17:50:32Z
Events:                  <none>

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

בקטע Checks מפורטות בדיקות מקדימות ספציפיות שהופעלו, והתוצאה שלהן (עברו או נכשלו). בדוגמה הזו, הבדיקות הבאות בוצעו:
- ‫192.0.2.53 ו-192.0.2.54: בדיקות צומת (הגדרות של מערכת ההפעלה, המשאבים והתוכנה) למכונות עם כתובות ה-IP‏ 192.0.2.53 ו-192.0.2.54.
- ‫192.0.2.53-gpc ו-192.0.2.54-gcp: Google Cloud בדיקות קישוריות (גישה ל-Artifact Registry ול-Google API) למכונות עם כתובות ה-IP‏ 192.0.2.53 ו-192.0.2.54.
- ‫Gcp: Google Cloud בדיקות קישוריות לאשכול.
- ‫Node - Network: בדיקות רשת (קישוריות, פעולת etcd, גישת VIP וקישור יציאות) לאשכול.
- ‫Pod - Cidr: בדיקות של כתובות IP של Pods לאיתור כתובות חופפות באשכול.
בקטע Cluster Spec מוצגת הגדרת האשכול.
בשדה Pass מוצג הערך true, שמציין שהבדיקות המקדימות עברו בהצלחה.

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

כשמריצים בדיקות מקדימות כתוצאה מפקודת bmctl, כמו bmctl check preflight, Google Distributed Cloud יוצר קובצי יומן. מה נוצר ואיפה:

יומני הבדיקה לפני הטיסה נוצרים בספרייה עם תבנית השמות הבאה: preflight-TIMESTAMP.
הספרייה הזו נוצרת בספרייה log של האשכול בסביבת העבודה bmctl. כברירת מחדל, הנתיב לספרייה log הוא bmctl-workspace/CLUSTER_NAME/log.
יומני הבדיקה המקדימה מורכבים מהקבצים הבאים:
- קובצי יומן לבדיקות של מכונות הצומת, אחד לכל צומת באשכול. השמות של קובצי היומן האלה מבוססים על כתובת ה-IP של הצומת. לדוגמה, שם קובץ יכול להיות 192.0.2.53.
- קובצי יומן לבדיקות גישה של Google Cloud , אחד לכל צומת באשכול. השמות של קובצי היומן האלה כוללים את כתובת ה-IP של הצומת. לדוגמה, שם הקובץ יכול להיות 192.0.2.53-gcp.
- קובץ יומן לבדיקות גישה לאשכול Google Cloud , שנקרא gcp.
- קובץ יומן לבדיקות של רשתות צמתים, שנקרא node-network.

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

בדיקות קדם הפעלה ליצירת אשכולות

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

מה נבדק?

בדיקות קדם ההפעלה להתקנה בודקות את הדברים הבאים:

בדיקות של מכונות צומת:
- המכונות באשכול משתמשות במערכת הפעלה (OS) נתמכת.
- גרסת מערכת ההפעלה נתמכת.
- במערכת ההפעלה מותקנת גרסת ליבה נתמכת.
- מכונות הצומת מוגדרות לשימוש ב-cgroupsv2. הבדיקה נכשלת אם מזוהה
  cgroupsv1.
- ב-Ubuntu, חומת האש Uncomplicated Firewall‏ (UFW) מושבתת.
- ב-Ubuntu, מנהל החבילות apt פועל והחבילות הנדרשות זמינות.
- ב-Red Hat Enterprise Linux, מנהל החבילות dnf פועל והחבילות הנדרשות זמינות.
- ב-Red Hat Enterprise Linux, ‏Podman לא מותקן.
- מכונות הצומת עומדות בדרישות המינימליות של המעבד.
- המכונות של הצמתים עומדות בדרישות המינימליות של הזיכרון.
- מכונות הצומת עומדות בדרישות המינימליות של נפח האחסון בדיסק.
- סנכרון הזמן מוגדר במכונות של הצמתים.
- ‫kubelet פעיל ופועל במכונות של הצמתים.
- ‫containerd פעיל ופועל במכונות של הצמתים.
- בצמתים יש נתיב ברירת מחדל לניתוב חבילות לשער ברירת המחדל.
- מערכת שמות הדומיינים (DNS) פועלת כמו שצריך. אם האשכול מוגדר לפעול מאחורי שרת proxy, הבדיקה הזו לא מתבצעת.
- טווח ה-CIDR של ה-Pod לא חופף לכתובות ה-IP של מכונות הצומת.
- אם האשכול מוגדר להשתמש ב-registry mirror, אפשר להגיע ל-registry mirror.
בדיקותGoogle Cloud לכל צומת ולאשכול:
- ‫Artifact Registry, gcr.io, נבדקת יכולת ההגעה (reachability). אם האשכול מוגדר להשתמש ב-registry mirror, המערכת מדלגת על הבדיקה הזו.
- יש גישה לממשקי ה-API של Google.
בדיקות של רשתות צמתים (משתנות בהתאם להגדרת איזון העומסים):
- כתובת ה-VIP של שרת ה-API של Kubernetes נגישה.
- יש גישה לכתובות ה-VIP של מאזן העומסים.
- הצמתים יכולים לתקשר ביציאות הנדרשות.
- מופע האירועים של etcd מוקצה והדרישות לגבי היציאות מתקיימות.

אחרי שכל הבדיקות עוברות, Google Distributed Cloud יוצר את האשכול. למידע נוסף על הדרישות ליצירת אשכולות, קראו את סקירה כללית על דרישות מוקדמות להתקנה.

הרצת בדיקות קדם הפעלה לפי דרישה ליצירת אשכולות

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

אשכולות בניהול עצמי

הפקודה הבאה מאמתת את קובץ התצורה של האשכול שצוין, אבל לא מנסה ליצור את האשכול עצמו:
```
bmctl check config --cluster CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם של האשכול שמשויך לקובץ התצורה שבודקים.
הפקודה הזו בודקת אם המכונות והרשת מוכנות ליצירת אשכול:
```
bmctl check preflight --cluster CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם האשכול שבודקים.

אשכולות של משתמשים

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

ב-bmctl אפשר להשתמש ב---kubeconfig ככינוי לדגל --admin-kubeconfig.

בדיקות קדם הפעלה לשדרוגי אשכולות

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

מה נבדק?

בדיקות קדם הפעלה לשדרוגי אשכולות בודקות את הדברים הבאים:

בדיקות של מכונות צומת:
- המכונות באשכול משתמשות במערכת הפעלה (OS) נתמכת.
- גרסת מערכת ההפעלה נתמכת.
- במערכת ההפעלה מותקנת גרסת ליבה נתמכת.
- מכונות הצומת מוגדרות לשימוש ב-cgroupsv2. הבדיקה נכשלת אם מזוהה cgroupsv1.
- ב-Ubuntu, חומת האש Uncomplicated Firewall‏ (UFW) מושבתת.
- מכונות הצומת עומדות בדרישות המינימליות של המעבד.
- במכונות של הצמתים יש יותר מ-20% משאבי מעבד (CPU) זמינים.
- המכונות של הצמתים עומדות בדרישות המינימליות של הזיכרון.
- מכונות הצומת עומדות בדרישות המינימליות של נפח האחסון בדיסק.
- סנכרון הזמן מוגדר במכונות של הצמתים.
- בצמתים יש נתיב ברירת מחדל לניתוב חבילות לשער ברירת המחדל.
- מערכת שמות הדומיינים (DNS) פועלת כמו שצריך. אם האשכול מוגדר לפעול מאחורי שרת proxy, הבדיקה הזו לא מתבצעת.
- אם האשכול מוגדר להשתמש ב-registry mirror, אפשר להגיע ל-registry mirror.
- אין צמתים של מישור הבקרה או צמתים של מאזן עומסים שנמצאים במצב תחזוקה.
בדיקותGoogle Cloud לכל צומת ולאשכול:
- ‫Artifact Registry, gcr.io, נבדקת יכולת ההגעה (reachability). אם האשכול מוגדר להשתמש ב-registry mirror, המערכת מדלגת על הבדיקה הזו.
- יש גישה לממשקי ה-API של Google.
בדיקות מכונה:
- ‫kubelet פעיל ופועל במכונות של צמתים.
- ‫containerd פעיל ופועל במכונות של הצמתים.
- סטטוס נקודת הקצה של תקינות ממשק הרשת של הקונטיינר (CNI) תקין.
- טווח ה-CIDR של ה-Pod לא חופף לכתובות ה-IP של מכונות הצומת.
- kubeadm אישורים עדיין בתוקף.
בדיקות של רשתות צמתים (משתנות בהתאם להגדרת איזון העומסים):
- כתובת ה-VIP של שרת ה-API של Kubernetes נגישה.
- יש גישה לכתובות ה-VIP של מאזן העומסים.
- הצמתים יכולים לתקשר ביציאות הנדרשות.
- מופע האירועים של etcd מוקצה והדרישות לגבי היציאות מתקיימות.

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

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

הפקודה bmctl check preflight מאפשרת להריץ בדיקה מקדימה לפני שמשדרגים את האשכול. כדי לבדוק אם האשכולות מוכנים לשדרוג, אפשר להריץ את פקודת הבדיקה המקדימה הבאה לפני שמתחילים את השדרוג:

מעדכנים את גרסת האשכול (anthosBareMetalVersion) בקובץ התצורה של האשכול.
כדי לבדוק אם האשכולות מוכנים לשדרוג ולהריץ בדיקה מקדימה, משתמשים בפקודה הבאה:
```
bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שרוצים לשדרג.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
כשיוצרים את הבדיקה המקדימה באמצעות הפקודה הזו כדי לבדוק שדרוג של אשכול, נוצר משאב בהתאמה אישית של PreflightCheck באשכול האדמין.

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

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

מעקף של בדיקות מקדימות כשמחילים משאבים ב-Kubernetes

כדי להתעלם מהבדיקות המקדימות הפנימיות כשמחילים משאבים על אשכולות קיימים, צריך להגדיר את השדה BypassPreflightCheck לערך true בקובץ התצורה של האשכול.

הנה חלק מקובץ תצורה של אשכול, שבו השדה bypassPreflightCheck מוגדר ל-true:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.36.200-gke.118
...

הרצת הבדיקות האחרונות לפני הטיסה

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

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

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

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

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

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

אם אתם מריצים בדיקות מקדימות לפי דרישה לפני שאתם יוצרים או משדרגים אשכולות, אתם יכולים לעקוף את הבדיקות המקדימות האוטומטיות. כדי לעקוף את הבדיקות האוטומטיות לפני ההעלאה, משתמשים בדגל האופציונלי --force כשמריצים את bmctl create cluster או את bmctl upgrade cluster.

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

‫PreflightCheck משאבים בהתאמה אישית

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

בדיקות קדם הפעלה ליצירת אשכולות

מה נבדק?

הרצת בדיקות קדם הפעלה לפי דרישה ליצירת אשכולות

אשכולות בניהול עצמי

אשכולות של משתמשים

בדיקות קדם הפעלה לשדרוגי אשכולות

מה נבדק?

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

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

מעקף של בדיקות מקדימות כשמחילים משאבים ב-Kubernetes

הרצת הבדיקות האחרונות לפני הטיסה

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

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

בדיקות קדם הפעלה

‫`PreflightCheck` משאבים בהתאמה אישית