פתרון בעיות בשרת ה-API של Kubernetes

בדף הזה מוסבר איך לפתור בעיות בשרת ה-API של Kubernetes ‏(kube-apiserver) ב-Google Distributed Cloud.

הדף הזה מיועד לאדמינים ולמפעילים בתחום ה-IT שמנהלים את מחזור החיים של תשתית טכנולוגית בסיסית, ומגיבים להתראות ולדפים כשלא עומדים ביעדי רמת השירות (SLO) או כשהאפליקציות נכשלות. מידע נוסף על תפקידים נפוצים ודוגמאות למשימות שאנחנו מתייחסים אליהן ב Google Cloudתוכן זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.

פסק זמן של webhook וקריאות שנכשלו ל-webhook

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

  • החיבור נדחה: אם kube-apiserver מדווח על שגיאות של זמן קצוב לתפוגה בקריאה ל-webhook, השגיאה הבאה מדווחת ביומנים:

    failed calling webhook "server.system.private.gdc.goog":
failed to call webhook: Post "https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s":
dial tcp 10.202.1.18:443: connect: connection refused

  • Context deadline exceeded: יכול להיות שגם השגיאה הבאה תופיע ביומנים:

    failed calling webhook "namespaces.hnc.x-k8s.io": failed to call webhook: Post
"https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\":
context deadline exceeded"

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

  • בודקים את יומן השרת של ה-API כדי לראות אם יש בעיה ברשת.

    • בודקים ביומן אם יש שגיאות שקשורות לרשת, כמו TLS handshake error.
    • בודקים אם כתובת ה-IP או היציאה תואמות למה ששרת ה-API מוגדר להגיב לו.

  • כדי לעקוב אחרי זמן האחזור של ה-webhook, פועלים לפי השלבים הבאים:

    1. במסוף, עוברים לדף Cloud Monitoring.

      כניסה לדף Cloud Monitoring

    2. בוחרים באפשרות Metrics explorer (כלי לבחירת מדדים).

    3. בוחרים את המדד apiserver_admission_webhook_admission_duration_seconds.

כדי לפתור את הבעיה, אפשר לנסות את הפתרונות הבאים:

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

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

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

כשל בחיוג לשרת API או חביון

השגיאה הזו יכולה להופיע בכמה דרכים:

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

    dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host

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

  • שגיאות ברשת: יכול להיות שהלקוח ידפיס שגיאה כללית ברשת כשמנסים לחייג לשרת ה-API, כמו בדוגמאות הבאות:

    dial tcp 10.96.0.1:443: connect: no route to host
dial tcp 10.96.0.1:443: connect: connection refused
dial tcp 10.96.0.1:443: connect: i/o timeout

  • השהיה גבוהה בהתחברות לשרת API: יכול להיות שההתחברות לשרת API תצליח, אבל פסק הזמן של הבקשות יפוג בצד הלקוח. בתרחיש הזה, בדרך כלל הלקוח מדפיס הודעות שגיאה שמכילות את context deadline exceeded.

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

  1. ממקום ההפעלה של הלקוח הבעייתי, משתמשים ב-kubectl כדי לבצע בקשה עם רמת פירוט גבוהה. לדוגמה, בדרך כלל לא נדרש אימות לבקשת GET אל /healthz:

    kubectl get -v999 --raw /healthz

  2. אם הבקשה נכשלת או אם kubectl לא זמין, אפשר לקבל את כתובת ה-URL מהפלט ולבצע את הבקשה באופן ידני באמצעות curl. לדוגמה, אם מארח השירות שהתקבל מהפלט הקודם היה https://192.0.2.1:36917/, אפשר לשלוח בקשה דומה באופן הבא:

    # Replace "--ca-cert /path/to/ca.pem" to "--insecure" if you are accessing
# a local cluster and you trust the connection cannot be tampered.
# The output is always "ok" and thus contains no sensentive information.

curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz

    הפלט מהפקודה הזו בדרך כלל מצביע על שורש הבעיה שגורמת לחיבור להיכשל.

    אם החיבור מצליח אבל איטי או שפג הזמן הקצוב לתגובה, זה מצביע על שרת API עמוס מדי. כדי לוודא, בודקים במסוף את מדדי זמן האחזור של הבקשות ב-Cloud Kubernetes > Anthos > Cluster > K8s Control Plane.API Server Request Rate

כדי לפתור את בעיות החיבור או את בעיות ההשהיה, כדאי לבדוק את האפשרויות הבאות לתיקון:

  • אם מתרחשת שגיאת רשת באשכול, יכול להיות שיש בעיה בתוסף Container Network Interface‏ (CNI). הבעיה הזו בדרך כלל זמנית ונפתרת מעצמה אחרי יצירה מחדש של ה-Pod או תזמון מחדש שלו.

  • אם השגיאה ברשת היא מחוץ לאשכול, בודקים אם הלקוח מוגדר כראוי לגישה לאשכול, או יוצרים מחדש את הגדרת הלקוח. אם החיבור עובר דרך שרת proxy או שער, בודקים אם חיבור אחר שעובר דרך אותו מנגנון פועל.

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

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

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

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