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

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

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

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

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

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

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

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

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

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

docker exec -it bmctl-control-plane bash

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

כדי לבדוק את היומנים של 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.

למה הצומת נמצא במצב draining במשך זמן רב

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

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

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

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

ההגדרות הבאות של 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 ומחפשים את ה-Pods של Kubernetes או etcd שקורסים. אם יש פודים שנכשלו, צריך לבדוק את היומנים של הפודים כדי להבין למה הם קורסים.

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

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

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

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

אם אתם צריכים עזרה נוספת, אתם יכולים לפנות אל