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

ווּבּהוּקים של הרשאות גישה, או ווּבּהוּקים ב-Kubernetes, הם סוג של בקר הרשאות גישה שאפשר להשתמש בהם באשכולות Kubernetes כדי לאמת או לשנות בקשות למישור הבקרה לפני שהבקשה נשמרת. מקובל שאפליקציות של צד שלישי משתמשות ב-webhook שפועלים במשאבים ובמרחבי שמות שחיוניים למערכת. הגדרות שגויות של ווּבּוּקים עלולות להשפיע על הביצועים והמהימנות של מישור הבקרה. לדוגמה, webhook שהוגדר בצורה שגויה ונוצר על ידי אפליקציית צד שלישי עלול למנוע מ-GKE ליצור ולשנות משאבים במרחב השמות המנוהל kube-system, מה שעלול לפגוע בפונקציונליות של האשכול.

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

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

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

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

זיהוי של ווּבּהוּקים (webhook) שההגדרה שלהם שגויה ועלולים להשפיע על האשכול

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

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

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

מתי GKE מזהה ווּבּהוקים שההגדרה שלהם שגויה

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

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

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

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

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

דיווח על Webhooks ללא נקודות קצה זמינות

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

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

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

    המסוף

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

    kubectl

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

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

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

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

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

    המסוף

    בקטע Serving Pods בפרטי השירות, אפשר לראות את רשימת ה-Pods שתומכים בשירות הזה.

    kubectl

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

    kubectl get deployment -n SERVICE_NAMESPACE

    לחלופין, מריצים את הפקודה הבאה:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

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

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

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

  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 מופיע ווּב-הוּק אחד או יותר.

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

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

    הודעת webhook מסומנת אם scope הוא *. לחלופין, ווּבּהוּק מסומן אם ההיקף הוא 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.

‫Webhooks שחוסמים רכיבים קריטיים למערכת

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

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

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

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

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

קיפאון (deadlock) בקבלה

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

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

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

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

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

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

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

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

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