פתרון בעיות ב-Distributed Cloud במודל מחובר

‫Google עוקבת מרחוק אחרי החומרה של Google Distributed Cloud במודל מחובר ומבצעת בה תחזוקה. לצורך הזה, למהנדסי Google יש גישה Secure Shell ‏ (SSH) לחומרה של Distributed Cloud במודל מחובר. אם Google מזהה בעיה, מהנדס של Google יפנה אליכם כדי לפתור אותה. אם זיהיתם בעיה בעצמכם, פנו מיד לתמיכה של Google כדי לאבחן אותה ולפתור אותה.

שדרוגי תוכנה מחוברים של Distributed Cloud

בקטע הזה מוסבר איך להשתמש בכלי Metrics Explorer כדי לבדוק אם מתבצעת שדרוג תוכנה באשכול שמחובר ל-Distributed Cloud.

התהליך הזה משתמש במדדים הבאים של Monitoring:

  • ‫Current Cluster Version (/edge_cluster/current_cluster_version): מציין את הגרסה הנוכחית של התוכנה המחוברת של Distributed Cloud שפועלת באשכול.

  • ‫Target Cluster Version (/edge_cluster/target_cluster_version): מציין את גרסת היעד של Distributed Cloud במודל מחובר שאליו האשכול משודרג.

כדי להשלים את השלבים בקטע הזה, אתם צריכים לעמוד בדרישות המוקדמות הבאות:

  1. גישה למסוף Google Cloud ולפרויקט המקושר שלכם ב-Distributed Cloud. Google Cloud
  2. תפקיד ה-IAM‏ Monitoring Viewer, שמאפשר לכם לצפות במדדי Monitoring.
  3. (אופציונלי) ערך machine_id של המכונה המחוברת ל-Distributed Cloud, לסינון התוצאות שמוחזרות.

שימוש ב-Metrics Explorer כדי לבדוק את גרסאות התוכנה הנוכחיות והמיועדות של האשכול

  1. עוברים אל Metrics Explorer:

    1. במסוף Google Cloud , עוברים לקטע Monitoring.

    2. בעץ הניווט שבצד ימין, לוחצים על Metrics Explorer (הכלי לבחירת מדדים).

  2. בוחרים את סוג משאב היעד:

    1. בדף Metrics Explorer, עוברים לדף Configuration.

    2. לוחצים על בחירת מדד.

    3. משתמשים בסרגל החיפוש כדי לחפש את סוג המשאב Cluster. אפשר גם להשתמש במזהה המשאב המלא edgecontainer.googleapis.com/Cluster.

    4. בתוצאות שמוחזרות, לוחצים על סוג המשאב Cluster.

  3. משיגים את גרסת התוכנה הנוכחית של האשכול:

    1. בקטע Metric, מחפשים את הערך current_cluster_version.

    2. בוחרים במדד Machine Uptime (זמן הפעולה של המכונה). הנתיב המלא שלה הוא edgecontainer.googleapis.com/edge_cluster/current_cluster_version.

    3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

  4. משיגים את גרסת התוכנה של היעד של האשכול:

    1. לוחצים על הוספת שאילתה.

    2. בקטע Metric, מחפשים את הערך target_cluster_version.

    3. בוחרים במדד Target Cluster Version (גרסת אשכול היעד). הנתיב המלא שלה הוא edgecontainer.googleapis.com/edge_cluster/target_cluster_version.

    4. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

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

    • אם בשורות Current Cluster Version ו-Target Cluster Version מופיעים ערכים שונים, האשכול עובר שדרוג תוכנה.

    • אם בשורות Current Cluster Version ו-Target Cluster Version מופיע אותו ערך, המשמעות היא שלא מתבצע שדרוג תוכנה באשכול.

  6. כדי לאמת את התוצאה מהשלב הקודם, משתמשים בפקודה הבאה:

    gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION

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

    • ‫CLUSTER_ID: המזהה של אשכול היעד.
    • ‫REGION: האזור Google Cloud שבו נוצר האשכול.

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

    • אם הערך של השדה status הוא UPDATING, המשמעות היא שהאשכול עובר שדרוג תוכנה.
    • אם הערכים בשדות clusterVersion ו-targetVersion שונים, צריך להשוות אותם לערכים שמוחזרים ב-Metrics Explorer.

הסבר על התוצאות

בטבלה הבאה מוסברות התוצאות שמוחזרות על ידי Metrics Explorer והפקודה gcloud.

מצב האשכול אבחון רזולוציה
תקין
הערכים currentVersion ו-targetVersion זהים
הערך של `status` הוא RUNNING
 האשכול מריץ את גרסת היעד של התוכנה המחוברת של Distributed Cloud. אין.
שדרוג
הערך של currentVersion נמוך מהערך של targetVersion
הערך של `status` הוא UPDATING
 האשכול משודרג לגרסת היעד של תוכנת Distributed Cloud במודל מחובר. עוקבים אחרי האשכול בכלי לבחירת מדדים עד שהערכים של הגרסה הנוכחית והגרסה הרצויה של האשכול זהים.
תקוע
הערך של currentVersion נמוך מהערך של targetVersion ללא הגבלת זמן
הערך של `status` הוא UPDATING ללא הגבלת זמן
 השדרוג לגרסת היעד של התוכנה במודל מחובר של Distributed Cloud נכשל לפחות בצומת אחד באשכול. כדאי לבדוק את הקישוריות של המכונה ואת יומני המערכת, ולפנות אל Google לקבלת עזרה.
החזרה לגרסה הקודמת
הערך של currentVersion גבוה מהערך של targetVersion
הערך של `status` הוא UPDATING
 מערכת luster חוזרת לגרסה קודמת של התוכנה Google Distributed Cloud במודל מחובר. כדי לזהות את הסיבה להחזרה לגרסה הקודמת, צריך ליצור קשר עם Google.

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

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

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

הפעלה מחדש של מכונה שמחוברת ל-Distributed Cloud

בקטע הזה מוסבר איך להשתמש ב-Metrics Explorer כדי לבדוק אם מכונה פיזית שמחוברת ל-Distributed Cloud הופעלה מחדש, ולברר את הסיבה להפעלה מחדש. מעקב אחרי הפעלות מחדש עוזר לקבוע אם הן היו חלק מתחזוקה מתוכננת או שהן נבעו מכשל בחומרה או מהפסקת חשמל.

התהליך הזה משתמש במדדים הבאים של Monitoring:

  • זמן פעולה רציפה של המחשב (/machine/uptime): מציין את הזמן בשניות מאז ההפעלה מחדש האחרונה.

  • הפעלות מחדש של המחשב (/machine/restart_count): מציין את המספר הכולל של הפעלות מחדש של מכונת היעד מאז הפריסה שלה.

כדי להשלים את השלבים בקטע הזה, אתם צריכים לעמוד בדרישות המוקדמות הבאות:

  1. גישה למסוף Google Cloud ולפרויקט המקושר שלכם ב-Distributed Cloud. Google Cloud
  2. תפקיד ה-IAM‏ Monitoring Viewer, שמאפשר לכם לצפות במדדי Monitoring.
  3. (אופציונלי) ערך machine_id של המכונה המחוברת ל-Distributed Cloud, לסינון התוצאות שמוחזרות.

שימוש ב-Metrics Explorer כדי לבדוק את זמן הפעולה של המכונה ואת מספר ההפעלה מחדש

  1. עוברים אל Metrics Explorer:

    1. במסוף Google Cloud , עוברים לקטע Monitoring.

    2. בעץ הניווט שבצד ימין, לוחצים על Metrics Explorer (הכלי לבחירת מדדים).

  2. בוחרים את סוג משאב היעד:

    1. בדף Metrics Explorer, עוברים לדף Configuration.

    2. לוחצים על בחירת מדד.

    3. משתמשים בסרגל החיפוש כדי לחפש את סוג המשאב Machine. אפשר גם להשתמש במזהה המשאב המלא edgecontainer.googleapis.com/Machine.

    4. בתוצאות שמוחזרות, לוחצים על סוג המשאב Machine.

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

    1. בקטע Metric, מחפשים את הערך uptime.

    2. בוחרים במדד Machine Uptime (זמן הפעולה של המכונה). הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/uptime.

    3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

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

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

    1. בקטע Metric, מחפשים את הערך restart_count.

    2. בוחרים במדד הפעלות מחדש של המחשב. הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/restart_count.

    3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

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

    5. (אופציונלי) כדי לראות אירועים בודדים במקום תרשים, עוברים לקטע Aggregation בדף, מגדירים את השדה Alignment period לערך 1 minute ואת השדה Per-series aligner לערך Delta.

הסבר על התוצאות

בטבלה הבאה מוסברות התוצאות שמוצגות ב-Metrics Explorer.

מצב המכונה אבחון רזולוציה
יציב
המדד 'זמן פעולה רציף של המחשב' עולה בהתמדה
הדלתא של המדד 'הפעלות מחדש של המחשב' היא 0
 המחשב לא הופעל מחדש. אין.
הפעלה מחדש נקייה
המדד 'זמן הפעלה של המחשב' יורד ל-0
המדד 'הפעלות מחדש של המחשב' עולה ל-1
 המחשב הופעל מחדש והתחבר מחדש אל Google Cloud. בודקים את יומני המערכת כדי לברר את הסיבה להפעלה מחדש.
הפסקת חשמל
בתרשים של המדד Machine Uptime (זמן פעולה של המכונה) יש הפסקה ללא נתונים
המדד Machine Restarts (הפעלות מחדש של המכונה) לא השתנה במהלך ההפסקה בזמן הפעולה של המכונה
 הסוללה של המכונה נגמרה או שהחיבור לרשת נותק לפני שהיא יכלה להפעיל את עצמה מחדש. בודקים את כבלי החשמל והרשת, את ההגדרה של הרשת המקומית ואת הסטטוס של נורית ה-LED.
לסירוגין
הערך של המדד 'המכונה מחוברת' משתנה לסירוגין בין 0 ל-1
הערך של המדד 'קישוריות לרשת' משתנה לסירוגין בין 0 ל-1
 חיבור לא יציב לרשת, אובדן מנות או זמן אחזור מוגזם. בודקים אם יש עומס ברשת המקומית או חומרה פגומה.

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

קישוריות של מכונות ב-Distributed Cloud במודל מחובר

בקטע הזה מוסבר איך לבדוק את החיבור לאינטרנט ואת Google Cloud הקישוריות של המכונות המחוברות ל-Distributed Cloud באמצעות התכונה 'סייר המדדים' ב-Cloud Monitoring.

התהליך הזה משתמש במדדים הבאים של Monitoring:

  • ‫Machine Connected (/machine/connected): מציין אם המכונה מחוברת ל- Google Cloud.

  • קישוריות רשת (/machine/network/connectivity): מציין אם לממשק הרשת הראשי של המחשב יש קישוריות לאינטרנט.

כדי להשלים את השלבים בקטע הזה, אתם צריכים לעמוד בדרישות המוקדמות הבאות:

  1. גישה למסוף Google Cloud ולפרויקט המקושר שלכם ב-Distributed Cloud. Google Cloud
  2. תפקיד ה-IAM‏ Monitoring Viewer, שמאפשר לכם לצפות במדדי Monitoring.
  3. (אופציונלי) ערך machine_id של המכונה המחוברת ל-Distributed Cloud, לסינון התוצאות שמוחזרות.

שימוש ב-Metrics Explorer כדי לבדוק את הקישוריות של המכונה

  1. עוברים אל Metrics Explorer:

    1. במסוף Google Cloud , עוברים לקטע Monitoring.

    2. בעץ הניווט שבצד ימין, לוחצים על Metrics Explorer (הכלי לבחירת מדדים).

  2. בוחרים את סוג משאב היעד:

    1. בדף Metrics Explorer, עוברים לדף Queries.

    2. משתמשים בסרגל החיפוש כדי לחפש את סוג המשאב Machine. אפשר גם להשתמש במזהה המשאב המלא edgecontainer.googleapis.com/Machine.

    3. בתוצאות שמוחזרות, לוחצים על סוג המשאב Machine.

  3. בודקים את החיבור של המכונה אל Google Cloud:

    1. בקטע Metric, מחפשים את הערך connected.

    2. בוחרים במדד Machine Connected (מכונה מחוברת). הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/connected.

    3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

    4. בתרשים הזמן שמופיע, מוודאים שהקו תקין נשאר רציף ב-100%. אם בשלב כלשהו הערך הזה הוא 0% או Unhealthy, המחשב איבד את הקישוריות ל- Google Cloud בזמן שצוין.

  4. בודקים את החיבור לאינטרנט של המכונה:

    1. בקטע Metric, מחפשים את הערך connectivity.

    2. בוחרים במדד קישוריות לרשת. הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/network/connectivity.

    3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

    4. בתרשים הזמן שמופיע, מוודאים שהקו תקין נשאר רציף ב-100%. אם בשלב כלשהו הערך הזה הוא 0% לא תקין, סימן שהמחשב איבד את הקישוריות לאינטרנט בזמן שצוין.

הסבר על התוצאות

בטבלה הבאה מוסברות התוצאות שמוצגות ב-Metrics Explorer.

מצב המכונה אבחון רזולוציה
תקין
הערך של המדד 'המחשב מחובר' הוא 1
הערך של המדד 'קישוריות לרשת' הוא 1
 פעולה רגילה. אין.
מנותק
הערך של המדד 'המחשב מחובר' הוא 0
הערך של המדד 'קישוריות לרשת' הוא 1
 למחשב יש חיבור לאינטרנט, אבל הוא לא יכול להתחבר אל Google Cloud. בודקים את הכללים של חומת האש עבור שירותי Google ונקודות הקצה של ה-API. מוודאים שהסוכנים המחוברים של Distributed Cloud פועלים במכונה.
מבודד
הערך של המדד 'המחשב מחובר' הוא 0
הערך של המדד 'קישוריות לרשת' הוא 0
 למחשב אין קישוריות לאינטרנט. בודקים את כבלי החשמל והרשת, את ההגדרה של הרשת המקומית ואת הסטטוס של נורית ה-LED. מאמתים את ההגדרות של ה-VLAN והניתוב.
לסירוגין
הערך של המדד 'המכונה מחוברת' משתנה לסירוגין בין 0 ל-1
הערך של המדד 'קישוריות לרשת' משתנה לסירוגין בין 0 ל-1
 חיבור לא יציב לרשת, אובדן מנות או זמן אחזור מוגזם. בודקים אם יש עומס ברשת המקומית או חומרה פגומה.

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

מכונות וירטואליות תקועות במצב Pending

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

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

כדי לפתור את הבעיה:

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

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

    kubectl describe virtualmachine VM_NAME -n NAMESPACE

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

    • ‫VM_NAME: השם של המכונה הווירטואלית של היעד.
    • ‫NAMESPACE: מרחב השמות של המכונה הווירטואלית של היעד.

    הפקודה מחזירה פלט שדומה לזה:

    Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

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

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

אין מספיק משאבים

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

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

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

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

צמתים עם כתמים

יכול להיות שתופיע הודעה שמציינת שהצומת של היעד מוכתם. לדוגמה:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

כדי לפתור את הבעיה, צריך לבצע את הפעולות הבאות:

  1. משתמשים בפקודה הבאה כדי לבדוק אם יש taints בצומת:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    הפקודה מחזירה פלט שדומה לזה:

    NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

  2. מבצעים אחת מהפעולות הבאות:

    • אם יש כתמים לא צפויים, צריך להסיר אותם כמו שמתואר במאמר Taints and Tolerations.
    • אם יש taints צפויים, מוסיפים את ה-tolerations המתאימים להגדרות של המכונה הווירטואלית, כמו שמתואר במאמר Taints and Tolerations.

תקלות באחסון

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

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

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

כדי לפתור את הבעיה, צריך לבצע את הפעולות הבאות:

  1. כדי לקבל את הסטטוס של התביעות על נפח אחסון קבוע (PVC) במרחב השמות של המכונה הווירטואלית המושפעת, משתמשים בפקודה הבאה:

    kubectl get pvc -n NAMESPACE

    מחליפים את NAMESPACE בשם של מרחב השמות של היעד.

    הפקודה מחזירה פלט שדומה לזה:

    NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

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

נעילות בתזמון שנגרמות על ידי וווב-הוקים של קבלה שנכשלו

תגובות לפעולות מאתר אחר (webhook) של בקרת כניסה מאפשרות לכם ליירט בקשות לשרת ה-API של Kubernetes לפני שהאובייקט הופך לקבוע. השימוש ב-webhooks שימושי לאכיפת מדיניות אבטחה בהתאמה אישית, אבל אם מגדירים אותם בצורה לא נכונה הם עלולים לגרום להפסקות חשמל בכל האשכול, במיוחד במהלך פעולות קריטיות כמו שדרוגי תוכנה ורענון אישורים. באופן ספציפי, ווּבְהוּק (webhook) של הרשאות גישה שחסום או לא זמין עלול לגרום להשהיה של מישור הבקרה של Kubernetes, ולמנוע תזמון נוסף של עומסי עבודה (workload) באשכול.

קיפאון במישור הבקרה

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

אם מגדירים webhook עם failurePolicy: Fail, כל שגיאת תקשורת או פסק זמן בין שרת ה-API לבין ה-webhook יגרמו לדחיית בקשת ה-API. הבעיות שנובעות מכך:

  • שדרוגי תוכנה נכשלים: אי אפשר לתזמן רכיבי מערכת ומכונות וירטואליות במהלך שדרוג תוכנה של צומת ואחריו.
  • שירותי המערכת לא יכולים להתחיל: פודים של תשתית, כמו Symcloud Storage ו-VM Runtime ב-GDC, לא יכולים להתחיל.
  • צמתים תקועים במצב תחזוקה: אי אפשר לבצע התאמה או לצאת מצמתים במצב תחזוקה כי הבקר חסום על ידי לוגיקת הגישה.

שיטות מומלצות להגדרת Webhook

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

שימוש ב-failurePolicy: Ignore

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

החרגה של מרחבי שמות שמורים

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

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

שחזור אשכול שנמצא במצב של נעילה הדדית בגלל ווּבְּהוּקים שנכשלו

אם האשכול שלכם נתקע בגלל פעולות webhook שנכשלו, והפקודות kubectl ליצירת משאבים נכשלות או מחזירות שגיאות, בדרך כלל זה קורה כי הערך של failurePolicy ב-webhook מוגדר ל-Fail. כדי לשחזר את האשכול ממצב הקיפאון, פועלים לפי השלבים שבקטע הזה. אם ה-webhook שנכשל הוא webhook לשינוי, משתמשים ב-mutatingwebhookconfiguration במקום ב-validatingwebhookconfiguration.

  1. מזהים את ה-webhook שנכשל:

    1. מציגים את רשימת ה-webhook לאימות שנפרסו באשכול:

      kubectl get validatingwebhookconfigurations

    2. מציגים את רשימת ה-webhooks לשינוי שפריסתם באשכול:

      kubectl get mutatingwebhookconfigurations

  2. בודקים אם ה-Pods שתומכים ב-Webhooks האלה פועלים:

    kubectl get pods -A | grep WEBHOOK_SERVICE

    מחליפים את WEBHOOK_SERVICE בשם של שירות היעד של ה-webhook.

  3. מגדירים את failurePolicy של ה-webhook שנכשל ל-Ignore:

    kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

    מחליפים את WEBHOOK_SERVICE בשם של שירות היעד של ה-webhook.

  4. (אופציונלי) אם השלב הקודם נכשל, מבצעים מחיקה מאולצת של ההגדרה של ה-webhook המושפע:

    kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s

    מחליפים את WEBHOOK_CONFIG בשם של הגדרת ה-webhook של היעד.

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