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

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

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

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

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

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

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

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

  • משתמשים במסוף Google Cloud .
  • משתמשים ב-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 בService details, אפשר לראות את רשימת ה-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 בשם של ההגדרה של התגובה לפעולה מאתר אחר:

    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

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

מבוי סתום בנוגע לקבלה

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

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

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

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

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

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

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

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

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