פתרון בעיות ביצירה או בשדרוג של אשכולות

בדף הזה מוסבר איך לחקור בעיות שקשורות ליצירה ולשדרוג של אשכולות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware.

בעיות בהתקנה

החלקים הבאים יכולים לעזור לכם לפתור בעיות בהתקנה של Google Distributed Cloud.

שימוש באשכול bootstrap לניפוי באגים בבעיות

במהלך ההתקנה, Google Distributed Cloud יוצר אשכול זמני של bootstrap. אחרי התקנה מוצלחת, Google Distributed Cloud מוחק את אשכול האתחול, ומשאיר את אשכול האדמין ואת אשכול המשתמש. בדרך כלל, אין סיבה ליצור אינטראקציה עם אשכול האתחול. עם זאת, אם נתקלים בבעיות במהלך ההתקנה, אפשר להשתמש ביומני האתחול של האשכול כדי לנפות את הבעיה.

אם מעבירים את --cleanup-external-cluster=false אל gkectl create cluster, אשכול האתחול לא נמחק ואפשר להשתמש בו כדי לנפות באגים בבעיות שקשורות להתקנה.

בדיקת היומנים של אשכול האתחול

  1. כדי למצוא את השמות של ה-Pods שפועלים במרחב השמות kube-system:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

  2. כדי להציג את היומנים של Pod:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

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

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

    docker exec -it gkectl-control-plane bash

    הפקודה הזו פותחת טרמינל בתוך מאגר gkectl-control-plane שפועל באשכול bootstrap.

  4. כדי לבדוק את היומנים kubelet ו-containerd, משתמשים בפקודות הבאות ומחפשים שגיאות או אזהרות בפלט:

    systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd

בדיקת ה-snapshot של אשכול האתחול

אם מנסים ליצור או לשדרג אשכול אדמין והפעולה נכשלת, Google Distributed Cloud יוצר תמונת מצב חיצונית של אשכול האתחול. תמונת המצב הזו של אשכול האתחול דומה לתמונת המצב שנוצרת כשמריצים את הפקודה gkectl diagnose snapshot באשכול הניהול, אבל התהליך מופעל באופן אוטומטי. תמונת המצב של אשכול האתחול מכילה מידע על תוצאות ניפוי הבאגים החשוב לתהליך היצירה והשדרוג של אשכול הניהול.

התמונה החיצונית הזו מועלית אוטומטית לקטגוריות של Cloud Storage עבור Google Cloud הפרויקט שלכם בתיקיות /home/ubuntu. תמונת המצב נוצרת רק אם הפעולה של יצירת האשכול או השדרוג שלו נכשלת. במקרה הצורך, אפשר לשלוח את התמונה הזו ל-Cloud Customer Care. אם פעולת האשכול מצליחה, לא מתבצעת העלאה של תמונת מצב.

תמונת המצב החיצונית כוללת יומני Pod מ-onprem-admin-cluster-controller שאפשר להציג כדי לנפות באגים ביצירת אשכולות או בבעיות שקשורות לשדרוג. היומנים מאוחסנים בקובץ נפרד, למשל:

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_ \
    --container_onprem-admin-cluster-controller_ \
    --kubeconfig_.home.ubuntu..kube.kind-config-gkectl_\
    --namespace_kube-system

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

kubectl describe validations.onprem.cluster.gke.io \
    --kubeconfig /home/ubuntu/.kube/kind-config-gkectl \
    --request-timeout 30s \
    --namespace kube-node-lease

המכונה הווירטואלית לא מופעלת אחרי הפעלת מישור הבקרה של האדמין

אם מכונת VM לא מופעלת אחרי שמישור הבקרה של האדמין מופעל, אפשר לבדוק את הבעיה על ידי עיון ביומנים של רכיבי Cluster API controllers Pod באשכול האדמין:

  1. מאתרים את השם של ה-Pod של בקרי Cluster API:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

  2. צפייה ביומנים מהדומיין vsphere-controller-manager. מתחילים בהגדרת ה-Pod, אבל לא הקונטיינר:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

    הפלט מציין שצריך לציין מאגר תגים, ומציג את השמות של מאגרי התגים ב-Pod. לדוגמה:

    ... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

  3. בוחרים מאגר תגים וצופים ביומנים שלו:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

הוקצה מספר מספיק של כתובות IP, אבל המחשב לא נרשם באשכול

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

כדי לפתור את הבעיה, צריך לעדכן את קובץ בלוק כתובות ה-IP של האשכול כך שכתובות המכונות לא יתנגשו עם הכתובות שצוינו בקובץ ההגדרות של האשכול או בקובץ בלוק כתובות ה-IP של Seesaw.

אשכול Kind לא נמחק

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

אם מופיעה הודעת השגיאה Failed to delete the kind cluster, אפשר לבצע את השלבים הבאים בתחנת העבודה של האדמין כדי למחוק ידנית את אשכול kind:

  1. מוצאים את kind מזהה מאגר התגים:

    docker inspect --format="{{.Id}}" gkectl-control-plane

  2. מקבלים את מזהה התהליך containerd-shim:

    sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'

  3. מבטלים את התהליך:

    sudo kill -9 PROCESS_ID

בעיות בשדרוג אשכולות

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

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

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

אפשר לבטל שינויים במאגרי צמתים נבחרים ב-Ubuntu וב-COS, אבל לא במאגרי צמתים של Windows.

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

הצגת הגרסאות הזמינות של מאגר הצמתים

נניח ששדרגתם לאחרונה את אשכול המשתמשים, את הצמתים של העובדים ואת רמת הבקרה מגרסה 1.13.1-gke.35 לגרסה 1.14.0, וגיליתם בעיה בצמתים של העובדים ששודרגו. לכן אתם מחליטים לבצע Rollback של מאגר צמתים אחד או יותר לגרסה שהייתה בשימוש קודם: 1.13.1-gke.35. לפני שמתחילים את החזרה לגרסה הקודמת, צריך לוודא שהגרסה הקודמת זמינה לחזרה.

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

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

חזרה לגרסה קודמת של מאגר צמתים

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

כדי להחזיר לאחור גרסה של מאגר צמתים:

  1. בקובץ התצורה של אשכול המשתמשים, במאגר צמתים אחד או יותר, מגדירים את הערך של gkeOnPremVersion לגרסה הקודמת. בדוגמה הבאה אפשר לראות איך חוזרים לגרסה 1.13.1-gke.35:

    nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...

  2. מעדכנים את האשכול כדי להחזיר את מאגרי הצמתים לגרסה הקודמת:

    gkectl update cluster --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  3. מוודאים שהחזרה לגרסה הקודמת בוצעה בהצלחה:

    gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    הפלט הבא מראה שבוצעה חזרה לגרסה pool-1 1.13.1-gke.35.

    user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.13.1-gke.35
  - previous version: 1.14.0-gke.x
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

שדרוג לגרסת תיקון חדשה

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

כדי לשדרג לגרסה חדשה, צריך לבצע את השלבים הבאים:

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

    1. מגדירים את הערך של gkeOnPremVersion לגרסת תיקון חדשה. בדוגמה הזו נעשה שימוש בגרסה 1.14.1-gke.x.

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

      השינויים האלה נראים כמו בדוגמה הבאה:

      gkeOnPremVersion: 1.14.1-gke.x

nodePools:
-   name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: ""
-   name: pool-2
  cpus: 8
  memoryMB: 8192
  replicas: 2
  gkeOnPremVersion: ""

  2. מריצים את gkectl prepare ואת gkectl upgrade cluster כמו שמתואר במאמר שדרוג Google Distributed Cloud.

  3. מאמתים את הגרסה החדשה של האשכול, ורואים את הגרסאות שזמינות לחזרה לגרסה קודמת:

    gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

     user cluster version: 1.14.1-gke.y

 node pools:
 - pool-1:
   - version: 1.14.1-gke.y
   - previous version: 1.13.1-gke.35
 - pool-2:
   - version: 1.14.1-gke.y
   - previous version: 1.13.1-gke.35

 available node pool versions:
 - 1.13.1-gke.35
 - 1.14.0-gke.x
 - 1.14.1-gke.y
 ```

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

אם תנסו לשדרג אשכול אדמין או אשכול משתמשים, והפעולה תיכשל, Google Distributed Cloud יריץ אוטומטית את הפקודה gkectl diagnose cluster באשכול.

כדי לדלג על האבחון האוטומטי, מעבירים את הדגל --skip-diagnose-cluster אל gkectl upgrade.

תהליך השדרוג נתקע

מאחורי הקלעים, Google Distributed Cloud משתמש בפקודה Kubernetes drain במהלך שדרוג. יכול להיות שפריסת drain תיחסם אם יש לה רק רפליקה אחת, ונוצר בשבילה PodDisruptionBudget ‏ (PDB) עם minAvailable: 1.

החל מגרסה 1.13 של Google Distributed Cloud, אפשר לבדוק כשלים באמצעות אירועים של Kubernetes Pod.

  1. מאתרים את שמות המכונות:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

  2. בודקים אם יש שגיאות באמצעות הפקודה kubectl describe machine:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

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

    Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

  3. אופציונלי: כדי לקבל ניתוח מפורט יותר של הסטטוס של אובייקטים של מכונות, מריצים את הפקודה gkectl diagnose cluster.

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

    ...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

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

הסרת שינויים שלא נתמכים כדי לבטל את החסימה של השדרוג

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

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

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

failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
   v1alpha1.OnPremUserClusterSpec{
    ... // 20 identical fields
    CloudAuditLogging:     &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
-   AutoRepair:            &v1alpha1.AutoRepairConfig{Enabled: true},
+   AutoRepair:            &v1alpha1.AutoRepairConfig{},
    CARotation:            &{Generated: &{CAVersion: 1}},
    KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
    ... // 8 identical fields
  }

אם אתם צריכים לעקוף את השגיאה הזו, יש כמה דרכים לעשות זאת:

  • מבטלים את השינוי שניסיתם לבצע, ואז מריצים שוב את השדרוג. לדוגמה, בתרחיש הקודם, הייתם מבטלים את השינויים שבוצעו בהגדרות של AutoRepair ואז מריצים מחדש את gkectl upgrade.
  • לחלופין, אפשר להריץ את הפקודה gkectl get-config כדי ליצור קובצי תצורה שתואמים למצב הנוכחי של האשכול, לעדכן את השדות gkeOnPremVersion של האשכול ושל מאגרי הצמתים בקובץ התצורה, ואז להריץ מחדש את הפקודה gkectl upgrade.

בעיה: קובץ האימג' של מערכת ההפעלה לא נמצא אחרי gkectl prepare

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

[FAILURE] User OS images exist: OS images [gke-on-prem-ubuntu-VERSION] don't exist, please run `gkectl prepare` to upload OS images.

השגיאה הזו יכולה לקרות אם אשכול האדמין ואשכול המשתמש מוגדרים לשימוש בתיקיות שונות ב-vSphere. כברירת מחדל, הפקודה gkectl prepare מעלה את תמונת מערכת ההפעלה לתיקייה של אשכול האדמין. כדי להעלות את התמונה לתיקייה של אשכול המשתמשים, משתמשים בדגל --user-cluster-config כמו שמוצג בפקודה הבאה:

  gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-VERSION-full.tgz \
    --user-cluster-config USER_CLUSTER_CONFIG

ניפוי באגים בבעיות ב-F5 BIG-IP באמצעות קובץ kubeconfig פנימי

אחרי ההתקנה, Google Distributed Cloud יוצר קובץ kubeconfig בשם internal-cluster-kubeconfig-debug בספריית הבית של תחנת העבודה של האדמין. קובץ ה-kubeconfig הזה זהה לקובץ ה-kubeconfig של אשכול האדמין, אלא שהוא מפנה ישירות לצומת של מישור הבקרה של אשכול האדמין, שבו פועל שרת ה-API של Kubernetes. אפשר להשתמש בקובץ internal-cluster-kubeconfig-debug כדי לנפות באגים ב-F5 BIG-IP.

ניפוי באגים ב-vSphere

אפשר להשתמש ב-govc כדי לבדוק בעיות ב-vSphere. לדוגמה, אתם יכולים לאשר הרשאות וגישה לחשבונות המשתמשים שלכם ב-vCenter, ולאסוף יומנים של vSphere.

יצירה מחדש של קובץ kubeconfig חסר של אשכול משתמשים

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

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

כדי ליצור קובץ kubeconfig חדש עבור אשכול המשתמשים, מבצעים את השלבים הבאים:

  1. הגדרת משתני סביבה:

    מתחילים בהגדרת משתני הסביבה הבאים עם הערכים המתאימים:

    USER_CONTROLPLANEVIP=USER_CONTROLPLANEVIP
USER_CLUSTER_NAME=USER_CLUSTER_NAME
ADMIN_CLUSTER_KUBECONFIG=PATH_TO_ADMIN_KUBECONFIG
KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets -n $USER_CLUSTER_NAME | grep ^admin | cut -d' ' -f1 | head -n 1)

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

    • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב של קובץ kubeconfig לאשכול האדמין.
    • ‫USER_CONTROLPLANEVIP: controlPlaneVIP של המשתמש באשכול. אפשר לאחזר את הערך הזה מקובץ המניפסט של אשכול המשתמשים.

  2. יוצרים את קובץ ה-Kubeconfig:

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

    kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets $KUBECONFIG_SECRET_NAME \
 -n $USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}'  | base64 -d | \
 sed -r "s/ kube-apiserver.*local\./${USER_CONTROLPLANEVIP}/" \
 > USER_CLUSTER_KUBECONFIG

    מחליפים את :

    • ‫USER_CLUSTER_KUBECONFIG: השם של קובץ kubeconfig החדש של אשכול המשתמשים.

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

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

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