איך מוודאים את היציבות של מישור הבקרה כשמשתמשים ב-webhook

Autopilot Standard

‫Webhooks לאישור, או webhooks ב-Kubernetes, הם סוג של בקר אישור שאפשר להשתמש בו באשכולות של Kubernetes כדי לאמת או לשנות בקשות למישור הבקרה לפני שהבקשה נשמרת. בדרך כלל, אפליקציות של צד שלישי משתמשות ב-webhooks שפועלים במשאבים ובמרחבי שמות שחיוניים למערכת. תצורות שגויות של תגובות לפעולה מאתר אחר (webhook) יכולות להשפיע על הביצועים והאמינות של מישור הבקרה. לדוגמה, אם אפליקציית צד שלישי יוצרת webhook שלא מוגדר נכון, יכול להיות ש-GKE לא יוכל ליצור ולשנות משאבים במרחב השמות המנוהל kube-system, מה שעלול לפגוע בפונקציונליות של האשכול.

‫Google Kubernetes Engine ‏ (GKE) עוקב אחרי האשכולות שלכם ומשתמש בשירות ההמלצות כדי לספק הנחיות לשיפור השימוש בפלטפורמה. כדי לוודא שהאשכול יישאר יציב ובעל ביצועים טובים, כדאי לעיין בהמלצות של GKE לתרחישים הבאים:

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

ההנחיות האלה מסבירות איך לבדוק אם יש תצורות שגויות ב-webhooks ולעדכן אותן במקרה הצורך.

במאמר אופטימיזציה של השימוש ב-GKE באמצעות תובנות ו המלצות מוסבר איך לנהל את התובנות וההמלצות מ שירות ההמלצות.

זיהוי תצורות שגויות של תגובות לפעילות אינטראקטיבית (webhook) שעלולות להשפיע על האשכול

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

• משתמשים במסוף Google Cloud .
• משתמשים ב-Google Cloud CLI או ב-Recommender API, ומסננים לפי סוגי המשנה K8S_ADMISSION_WEBHOOK_UNSAFE ו-K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

אחרי שמזהים את ה-webhooks באמצעות התובנות, פועלים לפי ההוראות לפתרון בעיות ב-webhooks שזוהו.

כש-GKE מזהה תגובות לפעולה מאתר אחר (webhooks) שהוגדרו באופן שגוי

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

• K8S_ADMISSION_WEBHOOK_UNAVAILABLE: באשכול GKE יש webhooks אחד או יותר שמדווחים שאין נקודות קצה זמינות. כך בודקים אם יש תגובות לפעולה מאתר אחר (webhook) שמדווחות שאין נקודות קצה זמינות.

• K8S_ADMISSION_WEBHOOK_UNSAFE: באשכול GKE יש webhooks אחד או יותר שנחשבים לא בטוחים בהתבסס על המשאבים שהם מיירטים. פועלים לפי ההוראות כדי לבדוק את ה-webhooks שנחשבים לא בטוחים. התגובות לפעולה מאתר אחר (webhook) הבאות נחשבות לא בטוחות:

  • ‫Webhooks שמיירטים משאבים, כולל Pods וLeases, במרחב השמות kube-system.
  • תפיסת Leases על ידי Webhooks במרחב השמות kube-node-lease.
  • תגובות לפעולה מאתר אחר (webhooks) שמיירטות משאבי מערכת ברמת האשכול, כולל Nodes,‏ TokenReviews,‏ SubjectAccessReviews ו-CertificateSigningRequests.

פתרון בעיות ב-webhooks שזוהו

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

אחרי שתבצעו את ההוראות ותגדירו את ה-webhooks כמו שצריך, ההמלצה תטופל תוך 24 שעות ולא תופיע יותר במסוף.

אם אתם לא רוצים ליישם את ההמלצה, אתם יכולים לסגור אותה.

ה-webhooks מדווחים שאין נקודות קצה (endpoints) זמינות

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

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

2. מאתרים את ה-Pods שמשרתים את השירות שמשויך ל-webhook:

   המסוף

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

   kubectl

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

   kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
   

   מחליפים את SERVICE_NAME ואת SERVICE_NAMESPACE בשם ובמרחב השמות של השירות, בהתאמה.

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

3. בודקים את ה-Pods שמציגים את השירות הזה:

   המסוף

   בקטע Serving Pods שב-Service details, מוצגת רשימת הפודים שמגבים את השירות הזה.

   kubectl

   כדי לזהות אילו Pods לא פועלים, מציגים את הפריסה או את ה-Pods:

   kubectl get deployment -n SERVICE_NAMESPACE
   

   או להריץ את הפקודה הבאה:

   kubectl get pods -n SERVICE_NAMESPACE -o wide
   

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

תגובות Webhook שנחשבות לא בטוחות

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

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

2. בודקים את הגדרות ה-webhook:

   המסוף

   מעיינים בטבלה שבחלונית הצדדית של התובנה. בכל שורה מופיע השם של הגדרת ה-webhook והסיבה שההגדרה הזו סומנה.

   כדי לבדוק כל הגדרה, לוחצים על השם שלה כדי לעבור אליה בחלונית האובייקטים Object Browser ב-GKE.

   kubectl

   מריצים את הפקודה הבאה של kubectl כדי לקבל את הגדרת ה-webhook, ומחליפים את CONFIGURATION_NAME בשם של הגדרת ה-webhook:

   kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
   

   אם הפקודה לא מחזירה שום דבר, מריצים אותה שוב ומחליפים את validatingwebhookconfigurations ב-mutatingwebhookconfigurations.

   בקטע webhooks, מופיעים webhook אחד או יותר.

3. עורכים את ההגדרות בהתאם לסיבה שה-webhook סומן:

   החרגה של מרחבי השמות kube-system ו-kube-node-lease

   Webhook מסומן אם הערך של scope הוא *. לחלופין, תסומן התראה על תגובת webhook אם ההיקף הוא Namespaced ואחד מהתנאים הבאים מתקיים:

   • התנאי operator הוא NotIn, והתנאי values משמיט את kube-system ואת kube-node-lease, כמו בדוגמה הבאה:

     webhooks:
     - admissionReviewVersions:
       ...
       namespaceSelector:
         matchExpressions:
         - key: kubernetes.io/metadata.name
           operator: NotIn
           values:
           - blue-system
       objectSelector: {}
       rules:
       - apiGroups:
         ...
         scope: '*'
       sideEffects: None
       timeoutSeconds: 3
     

     חשוב לוודא שהגדרתם את scope ל-Namespaced ולא ל-*, כדי שה-webhook יפעל רק במרחבי שמות ספציפיים. חשוב גם לוודא שאם הערך של operator הוא NotIn, אתם כוללים את kube-system ו-kube-node-lease ב-values (בדוגמה הזו, עם blue-system).

   • התנאי operator הוא In, ו-values כולל את kube-system ו-kube-node-lease, כמו בדוגמה הבאה:

     namespaceSelector:
         matchExpressions:
         - key: kubernetes.io/metadata.name
           operator: In
           values:
           - blue-system
           - kube-system
           - kube-node-lease
     

     חשוב לוודא שהגדרתם את scope ל-Namespaced ולא ל-*, כדי שה-webhook יפעל רק במרחבי שמות ספציפיים. אם הערך של operator הוא In, צריך לוודא שהמאפיינים kube-system ו-kube-node-lease לא נכללים במאפיין values. בדוגמה הזו, רק blue-system צריך להיות ב-values כי operator הוא In.

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

   Webhook מסומן גם אם nodes,‏ tokenreviews,‏ subjectaccessreviews או certificatesigningrequests מופיעים ברשימה של המשאבים, כמו בדוגמה הבאה:

   - admissionReviewVersions:
   ...
     resources:
     - 'pods'
     - 'nodes'
     - 'tokenreviews'
     - 'subjectaccessreviews'
     - 'certificatesigningrequests'
     scope: '*'
   sideEffects: None
   timeoutSeconds: 3
   

   מסירים את nodes,‏ tokenreviews,‏ subjectaccessreviews ו-certificatesigningrequests מהקטע של המשאבים. אפשר להמשיך להשתמש ב-pods ב-resources.

תגובות לפעולה מאתר אחר (webhook) שחוסמות רכיבים קריטיים במערכת

תגובות לפעולות לפיתוח API (webhook) שמיירטות בקשות ליצירה או לעדכון של ClusterRoles ו-ClusterRoleBindings יכולות להפריע ליכולת של מישור הבקרה להתאים את משאבי המערכת הקריטיים האלה. לדוגמה, במהלך שדרוג של אשכול, יכול להיות שיהיה צורך לעדכן את תפקידי המערכת של kube-apiserver. אם webhook שלא זמין או שהוגדר באופן שגוי חוסם את העדכון הזה, ה-kube-apiserver לא יהיה תקין, והשדרוג של האשכול ייחסם.

‫GKE לא מזהה אם ה-webhooks מיירטים את ClusterRoles ו-ClusterRoleBindings, ולכן לא נוצרת תובנה בתרחיש הזה.

בדוגמה הבאה מוצגת הגדרה בעייתית של webhook שמיירט את ClusterRoles:

-   admissionReviewVersions:
  ...
  resources:
  -   'clusterroles'
  -   'clusterrolebindings'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

כדי למנוע את המצב הזה, ודאו שה-webhooks לא מיירטים בקשות של ClusterRoles ו-ClusterRoleBindings עם ההגדרה system: prefix.

מבוי סתום בקבלה

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

‫GKE לא מזהה תרחישים של מבוי סתום בקבלה, ולכן לא נוצרת תובנה לגבי התרחיש הזה. עם זאת, יכול להיות מצב של מבוי סתום (deadlock) אם Pods של webhook מושבתים. במקרה כזה, GKE מזהה של-webhook אין נקודות קצה זמינות ויוצר תובנה מסוג K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

כדי לפתור את הבעיה, אפשר למחוק את ValidatingWebhookConfiguration כדי לשבור את התלות המעגלית ולאפשר לאשכול להתאושש.

הזמינות של מישור הבקרה של האשכול

כש-webhook מוגדר לסגירה במקרה שגיאה, הזמינות של מישור הבקרה של Kubernetes תלויה בזמינות של ה-webhook. כדי לשפר את הזמינות של מישור הבקרה, כדאי:

‫GKE לא מזהה בעיות בזמינות של מישור הבקרה של האשכול שנגרמות על ידי תגובות לפעולה מאתר אחר (webhook), ולכן לא נוצרת תובנה לתרחיש הזה.

• הגבלת ההיקף של ה-webhook: אתם יכולים להחריג משאבים קריטיים מאימות על ידי ה-webhook, כדי למנוע ממנו להפריע לתהליכים רגישים. אתם יכולים להחריג מרחבי שמות או סוגים ספציפיים של משאבים. עם זאת, חשוב לשים לב ליחסי תלות לא ברורים. לדוגמה, ConfigMap יכול להיות משאב קריטי לבחירת מנהיג ב-Kubernetes.

• הקשחת הפריסה של ה-webhook: הפעלת ה-webhook בכמה Pods יכולה לשפר את העמידות ואת זמן הפעולה התקינה שלו. אתם יכולים להשתמש בבוררי צמתים כדי להפיץ את ה-Pods בין דומייני כשל שונים.

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

• אופטימיזציה של השימוש ב-GKE באמצעות תובנות והמלצות
• פתרון בעיות נפוצות
• אימות ל-APIs של Google Cloud מעומסי עבודה ב-GKE
• מידע ולמידה על תכונות וממשקי API שהוצאו משימוש