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

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

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

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

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

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

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

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

  1. גישה למסוף Google Cloud ולפרויקט ב- Google Cloud שמחובר ל-Distributed Cloud.
  2. תפקיד ה-IAM צפייה ב-Monitoring, שמאפשר לראות את המדדים של 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. בקטע מדד, מחפשים את הערך current_cluster_version.

    2. בוחרים במדד Machine Uptime. הנתיב המלא שלו הוא edgecontainer.googleapis.com/edge_cluster/current_cluster_version.

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

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

    1. לוחצים על Add Query.

    2. בקטע מדד, מחפשים את הערך 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 connected. אין.
שדרוג
הערך של currentVersion נמוך מ-targetVersion
הערך של `status` הוא UPDATING
 האשכול משודרג לגרסת היעד של תוכנת Distributed Cloud connected. עוקבים אחרי האשכול ב-Metrics Explorer עד שהערכים של גרסת האשכול הנוכחית וגרסת היעד של האשכול תואמים.
תקוע
הערך של currentVersion נמוך מ-targetVersion ללא הגבלת זמן
הערך של status הוא UPDATING ללא הגבלת זמן
 השדרוג לגרסת היעד של התוכנה של Distributed Cloud במודל מחובר נכשל בצומת אחד לפחות באשכול. צריך לבדוק את הקישוריות של המכונה ואת יומני המערכת. אפשר לפנות אל Google לקבלת עזרה.
חזרה לגרסה קודמת
הערך של currentVersion גבוה מ-targetVersion
הערך של `status` הוא UPDATING
 האשכול חוזר לגרסה קודמת של התוכנה של Distributed Cloud במודל מחובר. צרו קשר עם Google כדי לברר את הסיבה לביטול.

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

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

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

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

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

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

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

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

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

  1. גישה למסוף Google Cloud ולפרויקט המחובר ב-Distributed Cloud Google Cloud .
  2. תפקיד ה-IAM צפייה ב-Monitoring, שמאפשר לראות את המדדים של 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. בקטע מדד, מחפשים את הערך uptime.

    2. בוחרים במדד Machine Uptime. הנתיב המלא שלו הוא edgecontainer.googleapis.com/machine/uptime.

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

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

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

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

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

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

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

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

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

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

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

  1. גישה למסוף Google Cloud ולפרויקט המחובר ב-Distributed Cloud Google Cloud .
  2. תפקיד ה-IAM צפייה ב-Monitoring, שמאפשר לראות את המדדים של 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. בקטע מדד, מחפשים את הערך connected.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    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.

תקלות באחסון

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

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) של אישור שנכשלו

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

מבוי סתום במישור הבקרה

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

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

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

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

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

שימוש ב-failurePolicy: Ignore

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

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

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

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

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

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