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

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

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

ב-Google Distributed Cloud אפשר להריץ בדיקות לפני ההפעלה במצבים שונים:

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

`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, גישה לכתובת IP וירטואלית וקישור ליציאה) עבור האשכול.
- ‫Pod - Cidr: בדיקות של כתובות ה-IP של ה-Pod כדי לוודא שאין חפיפה בין כתובות באשכול.
בקטע 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) נתמכת.
- הגרסה של מערכת ההפעלה נתמכת.
- מערכת ההפעלה משתמשת בגרסת ליבה נתמכת.
- ב-Ubuntu, חומת האש Uncomplicated Firewall ‏ (UFW) מושבתת.
- ב-Ubuntu, מנהל החבילות apt פועל והחבילות הנדרשות זמינות.
- ב-Red Hat Enterprise Linux, מנהל החבילות dnf פועל והחבילות הנדרשות זמינות.
- ב-Red Hat Enterprise Linux, ‏ Podman לא מותקן.
- מכונות הצומת עומדות בדרישות המינימום של המעבד.
- מכונות הצמתים עומדות בדרישות הזיכרון המינימליות.
- מכונות הצמתים עומדות בדרישות המינימום של נפח האחסון בדיסק.
- סנכרון הזמן מוגדר במכונות הצמתים.
- ‫kubelet פעיל ופועל במכונות צמתים.
- ‫containerd פעיל ופועל במכונות צמתים.
- מסלול ברירת המחדל לניתוב מנות לשער ברירת המחדל מופיע בצמתים.
- מערכת שמות הדומיינים (DNS) פועלת בצורה תקינה. אם האשכול מוגדר לפעול מאחורי שרת proxy, הבדיקה הזו תדלג.
- ה-CIDR של ה-Pod לא חופף לכתובות ה-IP של מכונות הצמתים.
- אם האשכול מוגדר לשימוש בשיקוף של מאגר, אפשר להגיע לשיקוף של המאגר.
Google Cloud בודק כל צומת ואת האשכול:
- ‫Artifact Registry, ‏ gcr.io, נבדקת הנגישות. אם האשכול מוגדר לשימוש במאגר תמונות משוכפל, הבדיקה הזו מדלגת על האשכול.
- אפשר להגיע אל Google APIs.
בדיקות של רשתות צמתים (משתנות בהתאם להגדרת איזון העומסים):
- אפשר לגשת ל-VIP של שרת ה-API של Kubernetes.
- כתובות ה-VIP של מאזן העומסים נגישות.
- הצמתים יכולים לתקשר ביציאות הנדרשות.
- הוקצה מופע של etcd events והדרישות לגבי יציאות מתקיימות.

אם כל הבדיקות מסתיימות בהצלחה, 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) נתמכת.
- הגרסה של מערכת ההפעלה נתמכת.
- מערכת ההפעלה משתמשת בגרסת ליבה נתמכת.
- ב-Ubuntu, חומת האש Uncomplicated Firewall ‏ (UFW) מושבתת.
- מכונות הצומת עומדות בדרישות המינימום של המעבד.
- במכונות הצמתים יש יותר מ-20% ממשאבי ה-CPU שזמינים.
- מכונות הצמתים עומדות בדרישות הזיכרון המינימליות.
- מכונות הצמתים עומדות בדרישות המינימום של נפח האחסון בדיסק.
- סנכרון הזמן מוגדר במכונות הצמתים.
- מסלול ברירת המחדל לניתוב מנות לשער ברירת המחדל מופיע בצמתים.
- מערכת שמות הדומיינים (DNS) פועלת בצורה תקינה. אם האשכול מוגדר לפעול מאחורי שרת proxy, הבדיקה הזו תדלג.
- אם האשכול מוגדר לשימוש בשיקוף של מאגר, אפשר להגיע לשיקוף של המאגר.
- אף צומת של מישור הבקרה או צומת של איזון העומסים לא נמצא במצב תחזוקה.
Google Cloud בודק כל צומת ואת האשכול:
- ‫Artifact Registry, ‏ gcr.io, נבדקת הנגישות. אם האשכול מוגדר לשימוש במאגר תמונות משוכפל, הבדיקה הזו מדלגת על האשכול.
- אפשר להגיע אל Google APIs.
בדיקות מכונה:
- ‫kubelet פעיל ופועל במכונות צמתים.
- ‫containerd פעיל ופועל במכונות צמתים.
- הסטטוס של נקודת הקצה של תקינות ממשק הרשת של הקונטיינר (CNI) הוא תקין.
- ה-CIDR של ה-Pod לא חופף לכתובות ה-IP של מכונות הצמתים.
- האישורים של kubeadm לא פגו.
בדיקות של רשתות צמתים (משתנות בהתאם להגדרת איזון העומסים):
- אפשר לגשת ל-VIP של שרת ה-API של Kubernetes.
- כתובות ה-VIP של מאזן העומסים נגישות.
- הצמתים יכולים לתקשר ביציאות הנדרשות.
- הוקצה מופע של etcd events והדרישות לגבי יציאות מתקיימות.

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

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

‫Google Distributed Cloud מבצעת בדיקות פנימיות לפני ההמראה באופן אוטומטי כשמחילים משאבי Kubernetes על אשכול קיים. אם אחד מהבדיקות נכשל, ‫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.34.100-gke.93
...

הרצת הבדיקות העדכניות לפני ההטמעה

אנחנו מעדכנים את הבדיקות המקדימות (ואת בדיקות התקינות) כשאנחנו מזהים בעיות מוכרות. כדי להנחות את 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` משאבים מותאמים אישית