פתרון בעיות בכלי שורת הפקודה kubectl

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

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

המידע הזה חשוב לכל מי שמשתמש בפקודות kubectl כדי לנהל אפליקציות או משאבי אשכולות ב-GKE. הוא חשוב במיוחד למפתחי אפליקציות, לאדמינים ולמפעילי פלטפורמות שמסתמכים על פקודות kubectl במשימות היומיומיות העיקריות שלהם. למידע נוסף על התפקידים הנפוצים ודוגמאות למשימות שאנחנו מתייחסים אליהן בתוכן של Cloud de Confiance by S3NS, קראו את המאמר תפקידים ומשימות נפוצים של משתמשי GKE.

מידע נוסף זמין במקורות הבאים:

שגיאות אימות והרשאה

אם נתקלתם בשגיאות שקשורות לאימות ולהרשאה כשאתם משתמשים בפקודות של כלי שורת הפקודה kubectl, קראו את הסעיפים הבאים כדי לקבל עצות.

שגיאה: 401 (אין הרשאה)

כשמתחברים לאשכולות GKE, יכול להיות שתקבלו שגיאת אימות והרשאה עם קוד סטטוס של HTTP‏ 401 (Unauthorized). הבעיה הזו יכולה לקרות כשמנסים להריץ פקודת kubectl באשכול GKE מסביבה מקומית. למידע נוסף, קראו את המאמר בעיה: שגיאות אימות והרשאה.

שגיאה: אין מספיק היקפי הרשאות לאימות

כשמריצים את gcloud container clusters get-credentials, יכול להיות שתופיע השגיאה הבאה:

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Request had insufficient authentication scopes.

השגיאה הזו מתרחשת כי אתם מנסים לגשת ל-GKE API ממכונה וירטואלית של Compute Engine שאין לה את ההיקף cloud-platform.

כדי לפתור את השגיאה, צריך להעניק את ההיקף החסר של cloud-platform. במאמר יצירה והפעלה של חשבונות שירות למכונות שבמסמכי התיעוד של Compute Engine מוסבר איך משנים את היקפי ההרשאות במכונה הווירטואלית של Compute Engine.

שגיאה: לא נמצא קובץ ההפעלה gke-gcloud-auth-plugin

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

Unable to connect to the server: getting credentials: exec: executable gke-gcloud-auth-plugin not found

It looks like you are trying to use a client-go credential plugin that is not installed.

To learn more about this feature, consult the documentation available at:
      https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins

Visit cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin to install gke-gcloud-auth-plugin.

Unable to connect to the server: getting credentials: exec: fork/exec /usr/lib/google-cloud-sdk/bin/gke-gcloud-auth-plugin: no such file or directory

כדי לפתור את הבעיה, מתקינים את gke-gcloud-auth-plugin כמו שמתואר בקטע התקנת הפלאגינים הנדרשים.

שגיאה: לא נמצא ספק אימות

השגיאה הבאה מתרחשת אם kubectl או לקוחות Kubernetes בהתאמה אישית נוצרו באמצעות Kubernetes client-go בגרסה 1.26 ואילך:

no Auth Provider found for name "gcp"

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

  1. מתקינים את gke-gcloud-auth-plugin כמו שמתואר בקטע התקנת הפלאגינים הנדרשים.

  2. מעדכנים לגרסה העדכנית של ה-CLI של gcloud:

    gcloud components update

  3. מעדכנים את הקובץ kubeconfig:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. מציינים אזור לאשכולות אזוריים, או תחום לאשכולות של תחומים.

שגיאה: הפלאגין gcp auth הוצא משימוש, צריך להשתמש ב-gcloud במקום זאת

יכול להיות שתופיע הודעת האזהרה הבאה אחרי התקנת gke-gcloud-auth-plugin והרצת פקודת kubectl באשכול GKE:

WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.

ההודעה הזו מופיעה אם גרסת הלקוח שלכם ישנה יותר מ-1.26.

כדי לפתור את הבעיה, צריך להנחות את הלקוח להשתמש בפלאגין האימות gke-gcloud-auth-plugin:

  1. פותחים את סקריפט ההתחברות למעטפת בכלי לעריכת טקסט:

    Bash

    vi ~/.bashrc

    Zsh

    vi ~/.zshrc

    אם אתם משתמשים ב-PowerShell, דלגו על השלב הזה.

  2. מגדירים את משתנה הסביבה הבא:

    Bash

    export USE_GKE_GCLOUD_AUTH_PLUGIN=True

    Zsh

    export USE_GKE_GCLOUD_AUTH_PLUGIN=True

    PowerShell

    [Environment]::SetEnvironmentVariable('USE_GKE_GCLOUD_AUTH_PLUGIN', True, 'Machine')

  3. מחילים את המשתנה בסביבה:

    Bash

    source ~/.bashrc

    Zsh

    source ~/.zshrc

    PowerShell

    יוצאים מהטרמינל ופותחים סשן חדש.

  4. מעדכנים את ה-CLI של gcloud:

    gcloud components update

  5. מאמתים את האשכול:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. מציינים אזור לאשכולות אזוריים, או תחום לאשכולות של תחומים.

הבעיה: הפקודה kubectl לא נמצאה

אם קיבלתם הודעה שהפקודה kubectl לא נמצאה, התקינו מחדש את הקובץ הבינארי kubectl והגדירו את משתנה הסביבה $PATH:

  1. מתקינים את הקובץ הבינארי של kubectl:

    gcloud components update kubectl

  2. כשההתקנה מבקשת לשנות את משתנה הסביבה $PATH, מזינים y כדי להמשיך. שינוי המשתנה הזה מאפשר להשתמש בפקודות kubectl בלי להקליד את הנתיב המלא שלהן.

    לחלופין, מוסיפים את השורה הבאה למקום שבו המעטפת מאחסנת משתני סביבה, כמו ~/.bashrc (או ~/.bash_profile ב-macOS):

    export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/

  3. מריצים את הפקודה הבאה כדי לטעון את הקובץ המעודכן. בדוגמה הבאה נעשה שימוש ב-.bashrc:

    source ~/.bashrc

    אם אתם משתמשים ב-macOS, השתמשו ב-~/.bash_profile במקום ב-.bashrc.

הבעיה: פקודות kubectl מחזירות את השגיאה "החיבור נדחה"

אם הפקודות של kubectl מחזירות את השגיאה "connection refused", צריך להגדיר את ההקשר של האשכול באמצעות הפקודה הבאה:

gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION

מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. מציינים אזור לאשכולות אזוריים, או תחום לאשכולות של תחומים.

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

gcloud container clusters list

שגיאה: הזמן הקצוב לפקודה kubectl פג

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

  • Unable to connect to the server: dial tcp IP_ADDRESS: connect: connection timed out
  • Unable to connect to the server: dial tcp IP_ADDRESS: i/o timeout.

השגיאות האלה מציינות ש-kubectl לא יכול לתקשר עם מישור הבקרה של האשכול.

כדי לפתור את הבעיה, צריך לאמת ולהגדיר את ההקשר שבו האשכול מוגדר, ולוודא שיש קישוריות לאשכול:

  1. עוברים אל $HOME/.kube/config או מריצים את הפקודה kubectl config view כדי לוודא שקובץ התצורה מכיל את ההקשר של האשכול ואת כתובת ה-IP החיצונית של מישור הבקרה.

  2. מגדירים את פרטי הכניסה לאשכול:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. מציינים אזור לאשכולות אזוריים, או תחום לאשכולות של תחומים.
    • ‫PROJECT_ID: מזהה הפרויקט שבו נוצר האשכול.

  3. אם הפעלתם רשתות מורשות באשכול, ודאו שרשימת הרשתות המורשות הקיימות כוללת את כתובת ה-IP היוצאת של המכונה שממנה אתם מנסים להתחבר. אתם יכולים למצוא את הרשתות המורשות הקיימות במסוף או באמצעות הפקודה הבאה:

    gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID \
    --format "flattened(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetwork
sConfig.cidrBlocks[])"

    אם כתובת ה-IP היוצאת של המכונה לא נכללת ברשימת הרשתות המורשות מהפלט של הפקודה הקודמת, צריך לבצע את אחת מהפעולות הבאות:

שגיאה: הפקודות של kubectl מחזירות את השגיאה "failed to negotiate an api version" (המשא ומתן על גרסת API נכשל)

אם הפקודות של kubectl מחזירות שגיאה מסוג failed to negotiate an API version, צריך לוודא של-kubectl יש פרטי כניסה לאימות:

gcloud auth application-default login

הבעיה: הפקודה kubectl logs,‏ attach,‏ exec או port-forward מפסיקה להגיב

אם הפקודות kubectl logs,‏ attach,‏ exec או port-forward מפסיקות להגיב, בדרך כלל שרת ה-API לא מצליח לתקשר עם הצמתים.

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

אם באשכול יש לפחות צומת אחד, צריך לבדוק אם אתם משתמשים במנהרות SSH או פרוקסי של Konnectivity כדי לאפשר תקשורת מאובטחת. בקטעים הבאים מפורטים השלבים לפתרון בעיות שספציפיים לכל שירות:

פתרון בעיות ב-SSH

אם אתם משתמשים ב-SSH, ‏ GKE שומר קובץ מפתח ציבורי SSH במטא-נתונים של הפרויקט ב-Compute Engine. כל המכונות הווירטואליות ב-Compute Engine שמשתמשות בתמונות שסופקו על ידי Google בודקות באופן קבוע את המטא-נתונים הנפוצים של הפרויקט ואת המטא-נתונים של המכונה שלהן, כדי למצוא מפתחות SSH ולהוסיף אותם לרשימת המשתמשים המורשים של המכונה הווירטואלית. בנוסף, GKE מוסיף כלל של חומת אש לרשת של Compute Engine כדי לאפשר גישת SSH מכתובת ה-IP של מישור הבקרה לכל צומת באשכול.

ההגדרות הבאות יכולות לגרום לבעיות בתקשורת SSH:

  • כללי חומת האש של הרשת לא מאפשרים גישת SSH ממישור הבקרה.

    כל הרשתות של Compute Engine נוצרות עם כלל של חומת אש שנקרא default-allow-ssh, שמאפשר גישה ל-SSH מכל כתובות ה-IP (נדרש מפתח פרטי תקין). בנוסף, GKE מוסיף כלל SSH לכל אשכול ציבורי בפורמט gke-CLUSTER_NAME-RANDOM_CHARACTERS-ssh, שמאפשר גישת SSH ספציפית ממישור הבקרה של האשכול לצמתים של האשכול.

    אם אף אחד מהכללים האלה לא קיים, מישור הבקרה לא יכול לפתוח מנהרות SSH.

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

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

  • רשומת המטא-נתונים הנפוצה של הפרויקט ל-ssh-keys מלאה.

    אם ערך המטא-נתונים של הפרויקט שנקרא ssh-keys קרוב למגבלת הגודל המקסימלי, GKE לא יכול להוסיף מפתח SSH משלו כדי לפתוח מנהרות SSH.

    כדי לוודא שזו הבעיה, בודקים את אורך הרשימה של ssh-keys. כדי לראות את המטא-נתונים של הפרויקט, מריצים את הפקודה הבאה, ואפשר לכלול את הדגל --project:

    gcloud compute project-info describe [--project=PROJECT_ID]

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

  • הגדרתם שדה מטא-נתונים עם המפתח ssh-keys במכונות הווירטואליות באשכול.

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

    כדי לוודא שזו הבעיה, מריצים את gcloud compute instances describe VM_NAME ומחפשים שדה ssh-keys במטא-נתונים.

    כדי לפתור את הבעיה, מוחקים את מפתחות ה-SSH לכל מכונה מהמטא-נתונים של המכונה.

פתרון בעיות בשרת ה-proxy של Konnectivity

כדי לבדוק אם האשכול משתמש בשרת ה-proxy של Konnectivity, בודקים את פריסת המערכת הבאה:

kubectl get deployments konnectivity-agent --namespace kube-system

אם האשכול משתמש בשרת proxy של Konnectivity, הפלט דומה לזה:

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
konnectivity-agent   3/3     3            3           18d

אחרי שמוודאים שמשתמשים בשרת ה-proxy של Konnectivity, צריך לוודא שלסוכני Konnectivity יש את הגישה הנדרשת לחומת האש, ושהגדרתם נכון את מדיניות הרשת ב-Kubernetes.

מתן גישה נדרשת לחומת האש

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

  • יציאת מישור הבקרה: כשיוצרים אשכול, סוכני Konnectivity יוצרים חיבורים למישור הבקרה ביציאה 8132. כשמריצים פקודת kubectl, שרת ה-API משתמש בחיבור הזה כדי לתקשר עם האשכול. חשוב לוודא שאתם מאפשרים תעבורת נתונים יוצאת למישור הבקרה של האשכול ביציאה 8132 (לשם השוואה, שרת ה-API משתמש ביציאה 443). אם יש לכם כללים שמונעים גישה לתעבורת נתונים יוצאת, יכול להיות שתצטרכו לשנות את הכללים או ליצור חריגים.

  • יציאת kubelet: סוכני Konnectivity הם פודים של המערכת שנפרסים בצומתי האשכול, לכן צריך לוודא שכללי חומת האש מאפשרים את סוגי התנועה הבאים:

    • תנועה נכנסת לעומסי העבודה ביציאה 10250 מטווח ה-Pod.
    • תנועה יוצאת מהטווחים של ה-Pod.

    אם כללי חומת האש לא מאפשרים תנועה מהסוג הזה, צריך לשנות את הכללים.

שינוי מדיניות הרשת ב-Kubernetes

יכול להיות שיהיו בעיות בשרת ה-proxy של Konnectivity אם מדיניות הרשת ב-Kubernetes של האשכול:

  • חסימת תעבורת נתונים נכנסת ממרחב השמות kube-system למרחב השמות workload
  • חסימת תעבורת נתונים יוצאת למישור הבקרה של האשכול ביציאה 8132

כשמדיניות הרשת ב-Kubernetes של Pods של עומסי עבודה חוסמת את תעבורת הנתונים הנכנסת, היומנים של konnectivity-agent כוללים הודעת שגיאה שדומה לזו:

"error dialing backend" error="dial tcp POD_IP_ADDRESS:PORT: i/o timeout"

בהודעת השגיאה, POD_IP_ADDRESS היא כתובת ה-IP של ה-Pod של עומס העבודה.

כשתעבורת הנתונים היוצאת חסומה על ידי מדיניות רשת ב-Kubernetes, היומנים של konnectivity-agent כוללים הודעת שגיאה שדומה לזו:

"cannot connect once" err="rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp CP_IP_ADDRESS:8132: i/o timeout

בהודעת השגיאה, CP_IP_ADDRESS היא כתובת ה-IP של מישור הבקרה של האשכול.

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

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

kubectl get networkpolicy --namespace AFFECTED_NAMESPACE

כדי לפתור את הבעיה במדיניות התעבורה הנכנסת, מוסיפים את הערך הבא לשדה spec.ingress של מדיניות הרשת ב-Kubernetes:

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
    podSelector:
      matchLabels:
        k8s-app: konnectivity-agent

כדי לפתור את הבעיה במדיניות התעבורה היוצאת, מוסיפים את הערך הבא לשדה spec.egress של מדיניות הרשת ב-Kubernetes:

egress:
- to:
  - ipBlock:
      cidr: CP_IP_ADDRESS/32
  ports:
  - protocol: TCP
    port: 8132

אם מדיניות הרשת ב-Kubernetes משתמשת בשילוב של כללי תעבורת נתונים נכנסת ויוצאת, יכול להיות שתצטרכו לשנות את שניהם.

התאמת הסוכן להסתרת כתובות IP

מישור הבקרה של האשכול מקבל את התנועה מסוכני Konnectivity אם כתובת ה-IP של המקור נמצאת בטווחים של כתובות ה-IP של Pod. אם משנים את ההגדרות של ip-masq-agent כדי להסוות את כתובת ה-IP של המקור לתנועה למישור הבקרה של האשכול, יכול להיות שיהיו שגיאות קישוריות בסוכני Konnectivity.

כדי לפתור את הבעיה ולוודא שהתנועה מסוכני Konnectivity למישור הבקרה של האשכול לא מוסווית לכתובת ה-IP של הצומת, מוסיפים את כתובת ה-IP של מישור הבקרה לרשימה nonMasqueradeCIDRs ב-ConfigMap של ip-masq-agent:

nonMasqueradeCIDRs:
- CONTROL_PLANE_IP_ADDRESS/32

למידע נוסף על ההגדרה הזו, ראו סוכן הסתרת IP.

שגיאה: הפקודות של kubectl נכשלות ומוצגת השגיאה "אין סוכן זמין"

כשמריצים פקודות kubectl שצריכות להתחבר ממישור הבקרה של GKE לפוד (למשל kubectl exec,‏ kubectl logs או kubectl port-forward), יכול להיות שהפקודה תיכשל ותופיע הודעת שגיאה דומה לזו:

Error from server: error dialing backend: No agent available

failed to call webhook: Post "https://WEBHOOK_SERVICE.WEBHOOK_NAMESPACE.svc:PORT/PATH?timeout=10s": No agent available

v1beta1.metrics.k8s.io failed with: failing or missing response from https://NODE_IP:10250/apis/metrics.k8s.io/v1beta1: Get "https://NODE_IP:10250/apis/metrics.k8s.io/v1beta1": No agent available

השגיאות האלה מצביעות על בעיה ב-Konnectivity, מנהרת התקשורת המאובטחת בין מישור הבקרה של GKE לבין הצמתים של האשכול. באופן ספציפי, המשמעות היא ש-konnectivity-server במישור הבקרה לא יכול להתחבר לאף Pod תקין של konnectivity-agent במרחב השמות kube-system.

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

  1. בודקים את התקינות של Pods מסוג konnectivity-agent:

    1. בודקים אם הפודים של konnectivity-agent פועלים:

      kubectl get pods -n kube-system -l k8s-app=konnectivity-agent

      הפלט אמור להיראות כך:

      NAME                                   READY   STATUS    RESTARTS  AGE
konnectivity-agent-abc123def4-xsy1a    2/2     Running   0         31d
konnectivity-agent-abc123def4-yza2b    2/2     Running   0         31d
konnectivity-agent-abc123def4-zxb3c    2/2     Running   0         31d

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

    2. בודקים ביומנים אם יש בעיות בחיבור. אם הסטטוס של ה-Pods הוא Running, צריך לבדוק ביומנים אם יש בעיות בחיבור. הפקודה kubectl logs תלויה ב-Konnectivity, לכן צריך להשתמש ב-Logs Explorer במסוףCloud de Confiance :

      1. במסוף Cloud de Confiance , נכנסים לדף Logs Explorer.

        כניסה לדף Logs Explorer

      2. בחלונית השאילתה, מזינים את השאילתה הבאה.

        resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="kube-system"
labels."k8s-pod/k8s-app"="konnectivity-agent"
resource.labels.container_name="konnectivity-agent"

        מחליפים את CLUSTER_NAME בשם האשכול.

      3. לוחצים על Run query.

      4. בדקו את התוצאה. כשבודקים את היומנים של konnectivity-agent, צריך לחפש שגיאות שמציינות למה הסוכן לא מצליח להתחבר. שגיאות אימות או הרשאה בדרך כלל מצביעות על הגדרה שגויה של webhook שחוסם בדיקות של טוקנים. השגיאות "Connection refused" או "timeout" בדרך כלל מצביעות על כך שכלל חומת אש או מדיניות רשת ב-Kubernetes חוסמים את התנועה למישור הבקרה ביציאת TCP‏ 8132, או חוסמים את התנועה בין סוכן Konnectivity לצמתים אחרים. שגיאות שקשורות לאישורים מצביעות על כך שחומת אש או שרת proxy בודקים את תנועת ה-TLS המוצפנת ומפריעים לה.

    3. בדיקה למה ה-Pods לא פועלים. אם הסטטוס של Pods הוא Pending או מצב אחר שאינו פועל, צריך לבדוק את הסיבה לכך. ‫konnectivity-agent פועל כ-Deployment ולא כ-DaemonSet. מכיוון שהוא פועל כ-Deployment, הפודים של הסוכן צריכים לפעול רק בקבוצת משנה של צמתים. עם זאת, אם קבוצת המשנה הספציפית הזו של הצמתים לא זמינה, השירות כולו עלול להיכשל.

      הנה כמה סיבות נפוצות לכך ש-Pod לא פועל:

      • כתמי צומת בהתאמה אישית שמונעים תזמון של Pod.
      • אין מספיק משאבים בצומת (מעבד או זיכרון).
      • כללי מדיניות מגבילים של Binary Authorization שחוסמים תמונות מערכת של GKE.

      כדי לקבל פרטים נוספים על הסיבה לכך ש-Pod ספציפי לא פועל, משתמשים בפקודה kubectl describe:

      kubectl describe pod POD_NAME -n kube-system

      מחליפים את POD_NAME בשם של ה-Pod שלא פועל.

  2. בודקים את ה-webhooks של בקרת הגישה כדי לוודא שאף אחד מהם לא חוסם בקשות API של TokenReview. ‫konnectivity-agent מסתמך על אסימונים של חשבונות שירות, ולכן הפרעה לבדיקות של האסימונים יכולה למנוע מהסוכנים להתחבר. אם הבעיה נגרמת בגלל webhook, אי אפשר לשחזר את Konnectivity עד שמסירים או מתקנים את ה-webhook הפגום.

  3. מוודאים שכללי חומת האש מאפשרים תעבורת נתונים יוצאת (egress) ב-TCP מצומתי GKE לכתובת ה-IP של מישור הבקרה ביציאה 8132. החיבור הזה נדרש כדי ש-konnectivity-agent יגיע לשירות Konnectivity. מידע נוסף זמין במאמר מתן גישה נדרשת לחומת האש.

  4. חשוב לוודא שאין כללים של מדיניות רשת ב-Kubernetes שמגבילים את התעבורה החיונית של Konnectivity. כללי מדיניות רשת ב-Kubernetes צריכים לאפשר גם תעבורת נתונים בתוך האשכול (בין Pods) במרחב השמות kube-system וגם תעבורת נתונים יוצאת (egress) מה-Pods של konnectivity-agent למישור הבקרה של GKE.

פתרון בעיות בוויסות הנתונים של kubectl בצד הלקוח

התסמין:

יכול להיות שתחוו ויסות נתונים בצד הלקוח כשתשתמשו ב-kubectl, עם הודעות שגיאה שמכילות את הטקסט הבא: ...Throttling request took 1.002582473s, request: GET:... או Waited for 1.183040416s due to client-side throttling, not priority and fairness, request: GET: ....

הסיבה:

כשמריצים פקודת kubectl, היא קודם שומרת במטמון רשימה של משאבים משרת ה-API. הרשימה הזו תואמת להגדרות המשאבים בהתאמה אישית (CRD) שזמינות משרת ה-API.

כשאשכול GKE כולל מספר גדול של CRD, למשל 300 או יותר, kubectl שולח מספר גדול של בקשות לשרת ה-API כדי ליצור או לרענן את המטמון שלו. כדי למנוע עומס יתר על שרת ה-API, ‏kubectl מווסת את עצמו.

פתרון:

הודעות השגיאה האלה הן התנהגות צפויה, והן נגרמות בגלל ויסות נתונים בצד הלקוח, בצד של kubectl. הבעיה אמורה להיפתר מעצמה.

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