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

טייס אוטומטי רגילה

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

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

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

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

• למידע נוסף על בעיות שלא ספציפיות ל-GKE, אפשר לעיין במאמר פתרון בעיות ב-kubectl במאמרי העזרה של Kubernetes.
• למידע נוסף על שימוש בפקודות kubectl כדי לאבחן בעיות באשכולות ובעומסי העבודה, אפשר לעיין במאמר בדיקת מצב האשכול באמצעות kubectl.

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

אם נתקלתם בשגיאות שקשורות לאימות ולהרשאה כשאתם משתמשים בפקודות של הכלי 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 מחזירות שגיאה מסוג 'החיבור נדחה', צריך להגדיר את הקשר של האשכול באמצעות הפקודה הבאה:

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 היוצאת של המכונה לא נכללת ברשימת הרשתות המורשות מהפלט של הפקודה הקודמת, צריך לבצע אחד מהשלבים הבאים:

   • אם אתם משתמשים במסוף, פועלים לפי ההוראות במאמר Can't reach control plane of a cluster with no external endpoint (לא ניתן להגיע למישור הבקרה של אשכול ללא נקודת קצה חיצונית).
   • אם מתחברים מ-Cloud Shell, פועלים לפי ההוראות במאמר שימוש ב-Cloud Shell כדי לגשת לאשכול עם נקודת קצה חיצונית מושבתת.

שגיאה: פקודות kubectl מחזירות את השגיאה failed to negotiate an api version

אם פקודות 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 proxy כדי לאפשר תקשורת מאובטחת. בקטעים הבאים מפורטים שלבי פתרון הבעיות שספציפיים לכל שירות:

• SSH
• Konnectivity proxy

פתרון בעיות ב-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 של כל מכונה מהמטא-נתונים של המכונה.

פתרון בעיות ב-Konnectivity Proxy

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

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

אם באשכול שלכם נעשה שימוש ב-Konnectivity proxy, הפלט יהיה דומה לזה:

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

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

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

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

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

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

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

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

שינוי מדיניות הרשת

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

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

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

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

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

כשמדיניות הרשת חוסמת יציאה, היומנים 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 של מישור הבקרה של האשכול.

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

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

kubectl get networkpolicy --namespace AFFECTED_NAMESPACE

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

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

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

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

אם מדיניות הרשת שלכם משתמשת בשילוב של כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress), כדאי לשקול להתאים את שניהם.

שינוי סוכן הסתרת ה-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 אל Pod – לדוגמה, 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 במישור הבקרה לא יכול להתחבר לאף תרמיל 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 במסוףGoogle Cloud :

      1. במסוף Google Cloud , עוברים אל 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 שהוגדר בצורה שגויה וחוסם בדיקות של טוקנים. שגיאות כמו 'החיבור נדחה' או 'זמן קצוב לתפוגה' בדרך כלל מצביעות על כך שכלל חומת אש או מדיניות רשת חוסמים תעבורה למישור הבקרה ביציאת TCP‏ 8132, או חוסמים תעבורה בין סוכן Konnectivity לבין צמתים אחרים. שגיאות באישור מצביעות על כך שחומת אש או שרת proxy בודקים את תעבורת ה-TLS המוצפנת ומתערבים בה.

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

      אלה כמה מהסיבות הנפוצות לכך ש-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 תוכל להגיע לשירות הקישוריות. מידע נוסף זמין במאמר בנושא מתן גישה לחומת האש הנדרשת.

4. מוודאים שאין כללים של מדיניות רשת שמגבילים תעבורה חיונית של Konnectivity. כללי מדיניות הרשת צריכים לאפשר תנועה בתוך האשכול (מ-Pod ל-Pod) במרחב השמות 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. הבעיה הזו אמורה להיפתר מעצמה.

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

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

  • פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
  • קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
  • פתיחת באגים או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.