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

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

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

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

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

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

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

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

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

  1. כדי לקבל רשימה של בדיקות מקדימות שהופעלו באשכול מסוים:

    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

  2. אחזור הפרטים של 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) נתמכת.

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

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

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

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

  • Google Cloud בודק כל צומת ואת האשכול:

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

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

  • בדיקות של רשתות צמתים (משתנות בהתאם להגדרת איזון העומסים):

    • אפשר לגשת ל-VIP של שרת Kubernetes API.

    • כתובות ה-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) נתמכת.

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

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

    • מכונות הצומת מוגדרות לשימוש ב-cgroupsv2. הבדיקה נכשלת אם מזוהה cgroupsv1.

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

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

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

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

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

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

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

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

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

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

  • Google Cloud בודק כל צומת ואת האשכול:

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

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

  • בדיקות מחשב:

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

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

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

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

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

  • בדיקות של רשתות צמתים (משתנות בהתאם להגדרת איזון העומסים):

    • אפשר לגשת ל-VIP של שרת Kubernetes API.

    • כתובות ה-VIP של מאזן העומסים נגישות.

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

    • הוקצה מופע של etcd events ועומדים בדרישות לגבי יציאות.

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

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

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

  1. מעדכנים את גרסת האשכול (anthosBareMetalVersion) בקובץ התצורה של האשכול.

  2. כדי לבדוק אם האשכולות מוכנים לשדרוג ולהריץ בדיקה לפני ההפעלה, משתמשים בפקודה הבאה:

    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.35.100
...

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

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

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

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

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

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

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

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

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