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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

המידע הזה חשוב לכל מי שמשתמש בפקודות kubectl כדי לנהל אפליקציות או משאבי אשכול ב-GKE. המאמר הזה חשוב במיוחד למפתחי אפליקציות ולאדמינים ולמפעילים של פלטפורמות שמסתמכים על פקודות kubectl במשימות היומיומיות שלהם. מידע נוסף על התפקידים הנפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בתוכן של Cloud de Confiance by S3NSזמין במאמר תפקידי משתמשים נפוצים ומשימות ב-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 בגרסה 1.26 ואילך:client-go

no Auth Provider found for name "gcp"

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

מתקינים את gke-gcloud-auth-plugin כמו שמתואר במאמר התקנת פלאגינים נדרשים.
מעדכנים לגרסה העדכנית של ה-CLI של gcloud:
```
gcloud components update
```
מעדכנים את הקובץ kubeconfig:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

שגיאה: פלאגין האימות של GCP הוצא משימוש. צריך להשתמש ב-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:

פותחים את סקריפט הכניסה לשורת הפקודה בכלי לעריכת טקסט:
Bash
vi ~/.bashrc
Zsh
vi ~/.zshrc
אם אתם משתמשים ב-PowerShell, דלגו על השלב הזה.

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

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')

מחילים את המשתנה בסביבה שלכם:
Bash
source ~/.bashrc
Zsh
source ~/.zshrc
PowerShell
יוצאים מהטרמינל ופותחים סשן טרמינל חדש.
מעדכנים את ה-CLI של gcloud:
```
gcloud components update
```
אימות לאשכול:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

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

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

מתקינים את הקובץ הבינארי kubectl:
```
gcloud components update kubectl
```
כאשר תוכנית ההתקנה מבקשת לשנות את משתנה הסביבה $PATH, מזינים y כדי להמשיך. שינוי המשתנה הזה מאפשר להשתמש בפקודות kubectl בלי להקליד את הנתיב המלא שלהן.

אפשרות אחרת היא להוסיף את השורה הבאה למיקום שבו המעטפת מאחסנת את משתני הסביבה, כמו ~/.bashrc (או ~/.bash_profile ב-macOS):
```
export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/
```
מריצים את הפקודה הבאה כדי לטעון את הקובץ המעודכן. בדוגמה הבאה נעשה שימוש ב-.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 לא מצליח לתקשר עם מישור הבקרה של האשכול.

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

עוברים אל $HOME/.kube/config או מריצים את הפקודה kubectl config view כדי לוודא שקובץ ההגדרות מכיל את הקשר של האשכול ואת כתובת ה-IP החיצונית של מישור הבקרה.
מגדירים את פרטי הכניסה של האשכול:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
- ‫PROJECT_ID: מזהה הפרויקט שבו נוצר האשכול.
אם הפעלתם רשתות מורשות באשכול, צריך לוודא שרשימת הרשתות המורשות הקיימות כוללת את כתובת ה-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 שלכם.
אם כללי חומת האש לא מאפשרים תנועה מהסוג הזה, צריך לשנות את הכללים.

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

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

חסימת תעבורת Ingress ממרחב השמות kube-system למרחב השמות workload
חסימת תעבורת יציאה למישור הבקרה של האשכול ביציאה 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 של מישור הבקרה של האשכול.

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

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

kubectl get networkpolicy --namespace AFFECTED_NAMESPACE

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

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

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

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

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

שינוי של סוכן ה-IP masquerade

מישור הבקרה של האשכול מקבל את התנועה מסוכני 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.

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

בודקים את התקינות של ה-Pods‏ konnectivity-agent:
1. בודקים אם konnectivity-agent Pods פועלים:
```
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 שהוגדר בצורה שגויה וחוסם את בדיקות הטוקנים. השגיאות 'החיבור נדחה' או 'זמן קצוב לתפוגה' בדרך כלל מצביעות על כך שכלל חומת אש או מדיניות רשת חוסמים תעבורה למישור הבקרה ביציאת TCP‏ 8132, או חוסמים תעבורה בין סוכן Konnectivity לבין צמתים אחרים. שגיאות באישור מצביעות על כך שחומת אש או שרת proxy בודקים את תעבורת ה-TLS המוצפנת ומתערבים בה.
3. בדיקה למה ה-Pods לא פועלים אם הסטטוס של ה-Pods הוא Pending או סטטוס אחר שאינו 'פועל', צריך לבדוק מה הסיבה לכך. ה-konnectivity-agent פועל כפריסה ולא כ-DaemonSet. מכיוון שהסוכן פועל כפריסת תוכנה, פודי הסוכן צריכים לפעול רק על קבוצת משנה של צמתים. עם זאת, אם קבוצת המשנה הספציפית הזו של הצמתים לא זמינה, יכול להיות שהשירות כולו ייכשל.
  
  אלה כמה מהסיבות הנפוצות לכך ש-Pod לא פועל:
  - הכתמות מותאמות אישית של צמתים שמונעות תזמון של Pod.
  - אין מספיק משאבים בצומת (CPU או זיכרון).
  - מדיניות מגבילה של Binary Authorization שחוסמת תמונות מערכת של GKE.
  כדי לקבל פרטים נוספים על הסיבה לכך ש-Pod מסוים לא פועל, משתמשים בפקודה kubectl describe:
```
kubectl describe pod POD_NAME -n kube-system
```
  מחליפים את POD_NAME בשם של ה-Pod שלא פועל.
כדאי לבדוק את ה-webhooks של ההרשאות כדי לוודא שאף אחד מהם לא חוסם בקשות ל-API של TokenReview. ה-konnectivity-agent מסתמך על טוקנים של חשבונות שירות, ולכן הפרעה לבדיקות של טוקנים יכולה למנוע מסוכנים להתחבר. אם הבעיה היא ב-webhook, ‏ Konnectivity לא יכול לשחזר את הנתונים עד שה-webhook הפגום יוסר או יתוקן.
מוודאים שכללי חומת האש מאפשרים תעבורת נתונים יוצאת (egress) ב-TCP מהצמתים של GKE לכתובת ה-IP של מישור הבקרה ביציאה 8132. החיבור הזה נדרש כדי שאפליקציית konnectivity-agent תוכל להגיע לשירות Konnectivity. מידע נוסף זמין במאמר בנושא מתן גישה לחומת האש הנדרשת.
מוודאים שאין כללים של מדיניות רשת שמגבילים תעבורה חיונית של 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 כדי לקבל תמיכה נוספת מהקהילה.
- פתיחת דיווחים על בעיות או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.

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

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

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

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

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

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

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

Bash

Zsh

Bash

Zsh

PowerShell

Bash

Zsh

PowerShell

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

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

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

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

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

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

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

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

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

שינוי של סוכן ה-IP masquerade

שגיאה: הפקודות kubectl נכשלות עם השגיאה 'אין סוכן זמין'

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

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

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

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

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

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

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

שגיאה: הפקודות `kubectl` נכשלות עם השגיאה 'אין סוכן זמין'

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