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

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

בעיות בהתקנה

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

הודעות שגיאה חולפות

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

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

  Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
  https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Internal error occurred: failed calling webhook "vcluster.kb.io": Post
  https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Failed to register cluster with GKE Hub; gcloud output: error running command
  'gcloud container fleet memberships register CLUSTER_NAME  --verbosity=error --quiet':
  error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
  Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF

  Get
  https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
  cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"

  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""

אם תוקף המפתח של חשבון השירות שלכם פג, תוצגנה הודעות השגיאה הבאות מ-bmctl: Google Cloud 

Error validating cluster config: 3 errors occurred:
        * GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

צריך ליצור מפתח חדש לחשבון השירות.

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

כש-Google Distributed Cloud יוצרת אשכולות בניהול עצמי (אדמין, היברידי או עצמאי), היא פורסת אשכול Kubernetes in Docker (kind) כדי לארח באופן זמני את בקרי Kubernetes שנדרשים ליצירת אשכולות. האשכול הזמני הזה נקרא אשכול אתחול. אשכולות משתמשים נוצרים ומשודרגים על ידי האדמין המנהל או אשכול היברידי, בלי להשתמש באשכול bootstrap.

אם קיים כבר אשכול מסוג kind בפריסה כשמנסים להתקין, Google Distributed Cloud מוחק את האשכול הקיים מסוג kind. המחיקה מתבצעת רק אחרי שההתקנה או השדרוג מסתיימים בהצלחה. כדי לשמור את אשכול ה-Kind הקיים גם אחרי שהפעולה תצליח, משתמשים בדגל --keep-bootstrap-cluster של bmctl.

‫Google Distributed Cloud יוצר קובץ תצורה עבור אשכול האתחול בנתיב WORKSPACE_DIR/.kindkubeconfig. אפשר להתחבר לאשכול bootstrap רק במהלך יצירה ושדרוג של אשכול.

לשם כך, קלאסטר האתחול צריך גישה למאגר Docker כדי לשלוף תמונות. ברירת המחדל של המרשם היא Artifact Registry, אלא אם אתם משתמשים במרשם פרטי. במהלך יצירת האשכול,bmctl יוצר את הקבצים הבאים:

  • ‫bmctl-workspace/config.json: מכיל Google Cloud פרטי כניסה של חשבון שירות לגישה למאגר. פרטי הכניסה מתקבלים מהשדה gcrKeyPath בקובץ התצורה של האשכול.

  • ‫bmctl-workspace/config.toml: מכיל את ההגדרה של containerd באשכול kind.

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

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

  • מתחברים לאשכול bootstrap במהלך יצירה ושדרוג של אשכול.
  • מקבלים את היומנים של אשכול האתחול.

אפשר למצוא את היומנים במחשב שבו מריצים את bmctl בתיקיות הבאות:

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

מחליפים את CLUSTER_NAME ואת TIMESTAMP בשם האשכול ובשעה המקבילה במערכת.

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

docker exec -it bmctl-control-plane bash

הפקודה פותחת טרמינל בתוך קונטיינר של מישור הבקרה של bmctl שפועל באשכול bootstrap.

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

journalctl -u kubelet
journalctl -u containerd

הפעלת רישום נתונים של ניפוי באגים ב-containerd

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

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

  1. מפעילים את הרישום ביומן של נתוני ניפוי באגים:

    1. פותחים את קובץ התצורה של containerd ‏ (/etc/containerd/config.toml) באמצעות כלי לעריכת טקסט.

    2. בקטע [debug] בקובץ, משנים את הערך של level מ-"" ל-"debug".

    3. שומרים את הקובץ ויוצאים מהכלי לעריכת טקסט.

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

      cat /etc/containerd/config.toml | grep debug

      הפלט צריך להיות:

      [debug]
  level = "debug"
    shim_debug = false

    5. כדי להחיל את השינוי ברמת הרישום ביומן, מפעילים מחדש את containerd:

      sudo systemctl restart containerd

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

    # This command fails because the image doesn't exist
crictl pull us-west1-docker.pkg.dev/gdc-project/samples/non-existent-image:latest

    הפעולה הזו גורמת ל-containerd לבצע פעולה וליצור יומנים מפורטים.

  3. מחכים שהתמונה תימשך או שהפעולה תיכשל, ואז אוספים את היומנים של containerd בקובץ בשם containerd_log.txt:

    journalctl -u containerd --no-pager --since TIME_PERIOD > containerd_log.txt

    מחליפים את TIME_PERIOD בערך שמציין את שעת ההתחלה של היומנים. צריך לתחום במירכאות כפולות כל ערך שמכיל רווחים. לדוגמה, "2 hours ago".

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

    1. פותחים את הקובץ /etc/containerd/config.toml ומשנים את הערך של level בחזרה ל-"", רמת הרישום ביומן שמוגדרת כברירת מחדל.

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

      cat /etc/containerd/config.toml | grep level

      הפלט צריך להיות:

      level = ""

    3. כדי להחיל את השינוי, מפעילים מחדש את containerd:

      sudo systemctl restart containerd

      המערכת תחזור להגדרות ברירת המחדל של הרישום ביומן.

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

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

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

מעקב אחרי התקדמות השדרוג

כדי לראות את הסטטוס של אשכול במהלך תהליך השדרוג, משתמשים בפקודה kubectl describe cluster:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

מחליפים את הערכים הבאים:

  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.
  • ‫ADMIN_KUBECONFIG: קובץ ה-kubeconfig של האדמין.
    • כברירת מחדל, אשכולות של מנהלים, אשכולות היברידיים ואשכולות עצמאיים משתמשים בשדרוג במקום. אם משתמשים בדגל --use-bootstrap=true עם הפקודה bmctl upgrade, פעולת השדרוג משתמשת באשכול bootstrap. כדי לעקוב אחרי התקדמות השדרוג כשמשתמשים באשכול אתחול, צריך לציין את הנתיב לקובץ kubeconfig של אשכול האתחול, .kindkubeconfig. הקובץ הזה נמצא בספרייה של סביבת העבודה.

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

בדיקה אם הצמתים מוכנים

משתמשים בפקודה kubectl get nodes כדי לראות את הסטטוס של הצמתים באשכול במהלך תהליך השדרוג:

kubectl get nodes --kubeconfig KUBECONFIG

כדי לבדוק אם הצומת השלים את תהליך השדרוג, בודקים את העמודות VERSION ו-AGE בתגובה לפקודה. ‫VERSION היא גרסת Kubernetes של האשכול. כדי לראות את גרסת Kubernetes עבור גרסה מסוימת של Google Distributed Cloud, אפשר לעיין במאמר בנושא ניהול גרסאות.

אם הצומת מציג NOT READY, נסו לחבר את הצומת ולבדוק את הסטטוס של kubelet:

systemctl status kubelet

אפשר גם לבדוק את יומני kubelet:

journalctl -u kubelet

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

בדיקה של הצומת שעובר שדרוג

כדי לבדוק איזה צומת באשכול נמצא בתהליך שדרוג, משתמשים בפקודה kubectl get baremetalmachines:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

מחליפים את הערכים הבאים:

  • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.
  • ‫ADMIN_KUBECONFIG: קובץ ה-kubeconfig של האדמין.
    • אם משתמשים באשכול bootstrap לשדרוג של אדמין, היברידי או עצמאי, צריך לציין את קובץ ה-kubeconfig של אשכול ה-bootstrap ‏(bmctl-workspace/.kindkubeconfig).

בדוגמה הבאה של הפלט אפשר לראות שלצומת שמשדרגים יש ABM VERSION ששונה מ-DESIRED ABM VERSION:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

בדיקה אילו צמתים נמצאים בתהליך של ניקוז

במהלך תהליך השדרוג, המערכת מרוקנת את הצמתים מ-Pods, והתזמון מושבת עד שהשדרוג של הצומת מסתיים בהצלחה. כדי לראות אילו צמתים מתרוקנים, משתמשים בפקודה kubectl get nodes:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

מחליפים את USER_CLUSTER_KUBECONFIG בנתיב לקובץ kubeconfig של אשכול המשתמשים.

העמודה STATUS מסוננת באמצעות grep כדי להציג רק צמתים שמדווחים על SchedulingDisabled. הסטטוס הזה מציין שהמערכת מרוקנת את הצמתים.

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

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

מחליפים את הערכים הבאים:

  • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.
  • ‫ADMIN_KUBECONFIG: קובץ ה-kubeconfig של האדמין.
    • אם משתמשים באשכול bootstrap לשדרוג של אדמין, היברידי או עצמאי, צריך לציין את קובץ ה-kubeconfig של אשכול ה-bootstrap ‏(bmctl-workspace/.kindkubeconfig).

הסטטוס של הצומת שמתבצע בו ניקוז מופיע בעמודה MAINTENANCE.

בדיקה למה צומת נמצא בסטטוס של ניקוז במשך זמן רב

משתמשים באחת מהשיטות שבקטע הקודם כדי לזהות את הצומת שמתבצע בו ניקוז באמצעות הפקודה kubectl get nodes. משתמשים בפקודה kubectl get pods ומסננים לפי שם הצומת הזה כדי לראות פרטים נוספים:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

מחליפים את NODE_NAME בשם הצומת שרוצים לנקז. הפלט מחזיר רשימה של Pods שנתקעו או שמתרוקנים לאט. השדרוג ממשיך, גם אם יש פודים תקועים, כשתהליך הניקוי של צומת נמשך יותר מ-20 דקות.

החל מגרסה 1.29, תהליך ניקוי הצמתים משתמש ב-Eviction API, שמכבד את PodDisruptionBudgets (PDB).

הגדרות ה-PDB הבאות עלולות לגרום לבעיות בניקוז הצמתים:

  • ‫Pods שמנוהלים על ידי כמה PDB

  • הגדרות סטטיות של PDB כמו אלה:

    • maxUnavailable == 0
    • ‫minUnavailable >= סה"כ העותקים

    קשה לקבוע את מספר הרפליקות הכולל מתוך משאב ה-PDB, כי הוא מוגדר במשאב ברמה גבוהה יותר, כמו Deployment,‏ ReplicaSet או StatefulSet. התאמה של PDB ל-pods מבוססת רק על הסלקטור בהגדרה שלהם. דרך טובה לאבחן אם הגדרת PDB סטטית גורמת לבעיה היא לבדוק אם pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy קודם, ואם אחת מההגדרות הסטטיות שצוינו מאפשרת את זה.

הפרות בזמן ריצה, כמו ערך DisruptionsAllowed שחושב עבור משאב PDB שהוא 0, יכולות גם לחסום את ניקוי הצמתים. אם יש לכם אובייקטים של PodDisruptionBudget שהוגדרו שלא מאפשרים שיבושים נוספים, יכול להיות ששדרוגי הצמתים ייכשלו בשדרוג לגרסת מישור הבקרה אחרי ניסיונות חוזרים. כדי למנוע את הכשל הזה, מומלץ להגדיל את Deployment או את HorizontalPodAutoscaler כדי לאפשר ניקוז של הצומת תוך שמירה על ההגדרה של PodDisruptionBudget.

כדי לראות את כל האובייקטים של PodDisruptionBudget שלא מאפשרים שיבושים, משתמשים בפקודה הבאה:

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

למה ה-Pods לא תקינים

השדרוגים עלולים להיכשל אם ה-Pod מכיל כתובות IP של מישור הבקרה upgrade-first-node או upgrade-node. ההתנהגות הזו נובעת בדרך כלל מכך ש-Pods סטטיים לא תקינים.

  1. בודקים את ה-Pods הסטטיים באמצעות הפקודה crictl ps -a ומחפשים Kubernetes או etcd Pods שקורסים. אם יש לכם Pods שנכשלו, כדאי לעיין ביומני הרישום של ה-Pods כדי להבין למה הם קורסים.

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

    • ההרשאות או הבעלים של קבצים שמוצמדים ל-Pods סטטיים לא נכונים.
    • הקישוריות לכתובת ה-IP הווירטואלית לא פועלת.
    • בעיות ב-etcd.

  2. אם הפקודה crictl ps לא פועלת או לא מחזירה כלום, צריך לבדוק את הסטטוס של kubelet ושל containerd. משתמשים בפקודות systemctl status SERVICE ו-journalctl -u SERVICE כדי לעיין ביומנים.

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

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

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