פתרון בעיות נפוצות

בדף הזה מוסבר איך לפתור בעיות נפוצות ב-GKE ב-Azure.

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

הודעות שגיאה נפוצות

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

לשרת אין משאב

שגיאות כמו error: the server doesn't have a resource type "services" יכולות לקרות אם באשכול אין מאגרי צמתים פעילים, או אם שער Connect לא יכול להתחבר למאגר צמתים. כדי לבדוק את הסטטוס של מאגרי הצמתים, מריצים את הפקודה הבאה:

gcloud container azure node-pools list \
    --cluster-name CLUSTER_NAME \
    --location LOCATION

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

  • ‫CLUSTER_NAME: השם של האשכול
  • ‫LOCATION: המיקום Google Cloud שממנו מתנהל האשכול

הפלט כולל את הסטטוס של מאגרי הצמתים של האשכול. אם אין לכם מאגר צמתים ברשימה, צרו מאגר צמתים.

משתמשים שאין להם הרשאה

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

Error from server (Forbidden): users "administrator@example.com" is forbidden:
User "system:serviceaccount:gke-connect:connect-agent-sa" cannot impersonate
resource "users" in API group "" at the cluster scope

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

אם אתם משתמשים בשער Connect ולא מצליחים להתחבר לאשכול, נסו את השלבים הבאים:

  1. מקבלים את המשתמשים המורשים עבור האשכול.

    gcloud container azure clusters describe CLUSTER_NAME \
    --format 'value(authorization.admin_users)'

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

    הפלט כולל את שמות המשתמשים עם גישת אדמין לאשכול. לדוגמה:

    {'username': 'administrator@example.com'}

  2. מקבלים את שם המשתמש שאומת כרגע באמצעות Google Cloud CLI.

    gcloud config get-value account

    הפלט כולל את החשבון שאומת באמצעות Google Cloud CLI. אם הפלט של gcloud containers azure clusters describe ושל gcloud config get-value account לא זהה, מריצים את gcloud auth login ומבצעים אימות בתור שם המשתמש עם גישת אדמין לאשכול.

בעיות בפקודות kubectl

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

פקודות kubectl מפסיקות להגיב

אם האשכול שלכם מריץ גרסת Kubernetes מוקדמת מ-1.25 והפקודות kubectl לא מגיבות או שפג הזמן הקצוב לתפוגה שלהן, הסיבה הנפוצה ביותר לכך היא שעדיין לא יצרתם מאגר צמתים. כברירת מחדל, GKE ב-Azure יוצר קובצי kubeconfig שמשתמשים בשער Connect כנקודת קצה שאפשר להגיע אליה דרך האינטרנט. כדי שהתכונה הזו תפעל, פריסת gke-connect-agent צריכה לפעול במאגר צמתים באשכול.

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

kubectl cluster-info -v=9

אם אין מאגרי צמתים פעילים, הבקשות אל connectgateway.googleapis.com נכשלות עם השגיאה 404 cannot find active connections for cluster.

באשכולות עם גרסת Kubernetes‏ 1.25 ואילך, הפקודה gke-connect-agent פועלת במישור הבקרה, ולא נדרש מאגר צמתים. אם הפקודה kubectl לא מגיבה, בודקים את היומנים של רכיב מישור הבקרה באמצעות Cloud Logging.

פקודות kubectl exec,‏ attach ו-port-forward נכשלות

יכול להיות שהפקודות kubectl exec,‏ kubectl attach ו-kubectl port-forward ייכשלו עם ההודעה error: unable to upgrade connection כשמשתמשים בשער Connect. זוהי מגבלה כשמשתמשים בשער Connect כנקודת הקצה של שרת ה-API של Kubernetes.

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

פתרון בעיות כללי ב-kubectl

אם משתמשים בשער Connect:

  • מוודאים שהפעלתם את שער Connect ב Google Cloud פרויקט:

    gcloud services enable connectgateway.googleapis.com

  • במקרה של אשכולות עם גרסת Kubernetes מוקדמת יותר מ-1.25, צריך לוודא שיש לפחות מאגר צמתים אחד עם Linux שפועל, ושהכלי gke-connect-agent פועל. פרטים נוספים זמינים במאמר בנושא פתרון בעיות בחיבורים של אשכולים.

  • במקרה של אשכולות עם Kubernetes בגרסה 1.25 ואילך, בודקים את gke-connect-agentהיומנים באמצעות Cloud Logging.

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