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

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

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

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

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

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

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

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

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

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

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

  • התחברות לאשכול ה-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 בשם האשכול ובשעה של המערכת המתאימה.

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

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

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

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

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

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

  • פודים שמנוהלים על ידי כמה תקציבי PDB

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

    • maxUnavailable == 0
    • ‫minUnavailable >= סה"כ רפליקות

    קשה לקבוע את המספר הכולל של הרפליקות ממשאב ה-PDB, כי הוא מוגדר במשאב ברמה גבוהה יותר, כמו Deployment,‏ ReplicaSet או StatefulSet. התאמת ה-PDB ל-Pod מתבצעת רק על סמך הבורר בהגדרות האישיות שלהם. כדי לבדוק אם הגדרת 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. ההתנהגות הזו מתרחשת בדרך כלל כי הפודים הסטטיים לא תקינים.

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

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

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

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

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

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

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