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

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

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

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

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

לשרת אין משאב

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

gcloud container aws 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 aws 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 aws clusters describe ושל gcloud config get-value account לא זהה, מריצים את gcloud auth login ומבצעים אימות בתור שם המשתמש עם גישת אדמין לאשכול.

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

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

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

אם האשכול שלכם מריץ גרסת Kubernetes מוקדמת מ-1.25 והפקודות kubectl לא מגיבות או שפג הזמן הקצוב לתפוגה שלהן, הסיבה הנפוצה ביותר לכך היא שעדיין לא יצרתם מאגר צמתים. כברירת מחדל, ‫GKE ב-AWS יוצר קובצי 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 logs נכשלת עם שגיאה מרחוק: tls: שגיאה פנימית

הבעיה הזו יכולה לקרות אם חסרה הרשאה בתפקיד של Control Plane API. לדוגמה, זה יכול לקרות אם לתפקיד שלכם ב-AWS חסרה ההרשאה ec2:DescribeDhcpOptions. במקרה כזה, אי אפשר לאשר בקשות לחתימת אישורים מצמתים, ולצומת העובד אין אישור תקף.

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

kubectl get csr

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

פתרון בעיות כללי ב-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.

שירות Kubernetes ‏ (LoadBalancer) או Kubernetes Ingress לא פועלים

אם יצרתם מאזני עומסים גמישים של AWS‏ (ELB/NLB/ALB) אבל הם לא פועלים כמצופה, יכול להיות שהבעיה היא בתיוג של רשתות משנה. מידע נוסף זמין במאמר בנושא רשתות משנה של איזון עומסים.

קריסה של Pods בצמתי Arm

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

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

  1. בודקים את הסטטוס של הפודים:

    kubectl get pods

  2. מקבלים את היומנים של ה-Pod שקורס:

    kubectl logs POD_NAME

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

    הודעת השגיאה ביומני ה-Pod דומה להודעה הבאה:

    exec ./hello-app: exec format error

כדי לפתור את הבעיה, צריך לוודא שקובץ אימג' של קונטיינר תומך בארכיטקטורת Arm. מומלץ ליצור כמה תמונות של הארכיטקטורה.

אי אפשר למחוק את האשכול

אם אתם מקבלים שגיאה דומה לזו שבהמשך כשאתם מנסים למחוק אשכול, יכול להיות שהתפקיד שלכם ב-GKE Multi-Cloud API לא קיים:

ERROR: (gcloud.container.aws.clusters.delete) FAILED_PRECONDITION: Could not
assume role
"arn:aws:iam::ACCOUNT_NUMBER:role/gke123456-anthos-api-role"
through service account
"service-123456789@gcp-sa-gkemulticloud.iam.gserviceaccount.com".
Please make sure the role has a trust policy allowing the GCP service agent to
assume it: WebIdentityErr failed to retrieve credentials

כדי לפתור את הבעיה, פועלים לפי השלבים במאמר בנושא יצירת תפקיד GKE Multi-Cloud API. כשיוצרים מחדש את התפקיד עם אותו שם ואותן הרשאות, אפשר לנסות שוב להריץ את הפקודה.

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