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

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

בעיות בהתקנה

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

שימוש באשכול ה-bootstrap כדי לנפות באגים

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

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

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

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

    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 של אשכול ה-bootstrap

אם אתם מנסים ליצור או לשדרג אשכול אדמין והפעולה נכשלת, Google Distributed Cloud יוצרת תמונת מצב חיצונית של אשכול ה-bootstrap. תמונת המצב הזו של אשכול ה-bootstrap דומה לתמונת המצב שנוצרת כשמריצים את הפקודה 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 לא מופעל אחרי שמישור הבקרה לאדמין הופעל, אפשר לבדוק את הבעיה באמצעות היומנים מה-Pod של בקרי ה-Cluster API באשכול האדמין:

  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, וגיליתם בעיה בצומתי העובדים המשודרגים. לכן אתם מחליטים להחזיר מאגר צמתים אחד או יותר לגרסה הקודמת שהפעלתם: ‎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 משתמש בפקודה drain של Kubernetes במהלך השדרוג. התהליך של drain יכול להיחסם על ידי פריסה עם רפליקה אחת בלבד, שנוצר עבורה PodDisruptionBudget‏ (PDB) עם minAvailable: 1.

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

  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.

במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על מקורות המידע לתמיכה, כולל: