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

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

לכלי gkectl יש שתי פקודות לפתרון בעיות באשכולות: gkectl diagnose snapshot ו-gkectl diagnose cluster. הפקודות פועלות גם באשכולות של אדמינים וגם באשכולות של משתמשים.

למידע נוסף על השימוש בפקודה gkectl diagnose cluster כדי לאבחן בעיות באשכול, ראו אבחון בעיות באשכול.

gkectl diagnose snapshot

הפקודה הזו דוחסת את הסטטוס, ההגדרות והיומנים של האשכול לקובץ tar. כשמריצים את gkectl diagnose snapshot, הפקודה מריצה באופן אוטומטי את gkectl diagnose cluster כחלק מהתהליך, וקובצי הפלט ממוקמים בתיקייה חדשה בתמונת המצב שנקראת /diagnose-report.

תמונת מצב שמוגדרת כברירת מחדל

ההגדרה שמוגדרת כברירת מחדל לפקודה gkectl diagnose snapshot מתעדת את המידע הבא על האשכול:

  • גרסת Kubernetes.

  • סטטוס המשאבים ב-Kubernetes במרחבי השמות kube-system ו-gke-system: אשכול, מכונה, צמתים, שירותים, נקודות קצה, ConfigMaps,‏ ReplicaSets,‏ CronJobs,‏ Pods והבעלים של ה-Pods האלה, כולל Deployments (פריסות),‏ DaemonSets ו-StatefulSets.

  • הסטטוס של מישור הבקרה.

  • פרטים על ההגדרות של כל צומת, כולל כתובות IP, כללי iptables, נקודות טעינה, מערכת קבצים, חיבורים לרשת ותהליכים שפועלים.

  • יומני קונטיינרים מצומת מישור הבקרה של אשכול האדמין, כששרת ה-API של Kubernetes לא זמין.

  • מידע על vSphere, כולל אובייקטים של VM והאירועים שלהם על סמך מאגר משאבים. בנוסף, נאסף מידע על האובייקטים Datacenter, ‏ Cluster, ‏ Network ו-Datastore שמשויכים למכונות הווירטואליות.

  • מידע על מאזן העומסים F5 BIG-IP, כולל שרת וירטואלי, כתובת וירטואלית, מאגר, צומת ומסך.

  • יומנים מהפקודה gkectl diagnose snapshot.

  • יומנים של משימות בדיקה מקדימה.

  • יומנים של קונטיינרים במרחבי שמות שמבוססים על התרחישים.

  • מידע על פקיעת התוקף של אישור Kubernetes של אשכול האדמין בקובץ תמונת המצב /nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration.

  • קובץ אינדקס HTML לכל הקבצים בתמונת המצב.

  • אופציונלי: קובץ התצורה של אשכול האדמין שמשמש להתקנה ולשדרוג של האשכול עם הדגל --config.

פרטי הכניסה, כולל אלה של vSphere ו-F5, מוסרים לפני שנוצר קובץ ה-tar.

תמונת מצב קלת משקל

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

  • סטטוס המשאבים של Kubernetes במרחבי השמות kube-system ו-gke-system: אשכול, מכונה, צמתים, שירותים, נקודות קצה, ConfigMaps,‏ ReplicaSets,‏ CronJobs,‏ Pods והבעלים של ה-Pods האלה, כולל Deployments,‏ DaemonSets ו-StatefulSets

  • יומנים מהפקודה gkectl diagnose snapshot

תיעוד מצב האשכול

אם הפקודה gkectl diagnose cluster מוצאת שגיאות, צריך לתעד את מצב האשכול ולספק את המידע ל-Cloud Customer Care. אפשר לתעד את המידע הזה באמצעות הפקודה gkectl diagnose snapshot.

ל-gkectl diagnose snapshot יש דגל אופציונלי עבור --config. בנוסף לאיסוף מידע על האשכול, הדגל הזה אוסף את קובץ התצורה ששימש ליצירה או לשדרוג של האשכול.

תיעוד המצב של אשכול האדמין

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

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config

הפרמטר --config הוא אופציונלי:

אם יש בעיה בכתובת IP וירטואלית (VIP) באשכול היעד, השתמשו בדגל --config כדי לספק את קובץ התצורה של אשכול האדמין, כדי לספק מידע נוסף על תוצאות ניפוי הבאגים.

בגרסה 1.29 ואילך, אפשר לכלול את --scenario=lite אם לא צריך את כל המידע בתמונת המצב שמוגדרת כברירת מחדל.

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

Taking snapshot of admin cluster "[ADMIN_CLUSTER_NAME]"...
   Using default snapshot configuration...
   Setting up "[ADMIN_CLUSTER_NAME]" ssh key file...DONE
   Taking snapshots...
       commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       ...
       nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet
       nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log
       ...
   Snapshot succeeded. Output saved in [TAR_FILE_NAME].tar.gz.

כדי לחלץ את קובץ ה-tar לספרייה, מריצים את הפקודה הבאה:

tar -zxf TAR_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME

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

  • ‫TAR_FILE_NAME: השם של קובץ ה-tar.

  • ‫EXTRACTION_DIRECTORY_NAME: הספרייה שאליה רוצים לחלץ את קובץ ה-tar.

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

cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY
ls kubectlCommands
ls nodes/NODE_NAME/commands
ls nodes/NODE_NAME/files

מחליפים את NODE_NAME בשם הצומת שאת הקבצים שלו רוצים לראות.

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

ציון מפתח ה-SSH לאשכול האדמין

כשיוצרים קובץ snapshot של אשכול האדמין, הכלי gkectl מוצא באופן אוטומטי את מפתח ה-SSH הפרטי של אשכול האדמין. אפשר גם לציין את המפתח באופן מפורש באמצעות הפרמטר --admin-ssh-key-path.

כדי להוריד את מפתחות ה-SSH, פועלים לפי ההוראות במאמר שימוש ב-SSH כדי להתחבר לצומת באשכול.

בפקודה gkectl diagnose snapshot, מגדירים את --admin-ssh-key-path לנתיב המפתח המפוענח:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --admin-ssh-key-path=PATH_TO_DECODED_KEY

תיעוד מצב האשכול של המשתמש

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

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

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

Taking snapshot of user cluster "[USER_CLUSTER_NAME]"...
Using default snapshot configuration...
Setting up "[USER_CLUSTER_NAME]" ssh key file...DONE
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    ...
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    ...
    nodes/[USER_CLUSTER_NODE]/commands/journalctl_-u_kubelet
    nodes/[USER_CLUSTER_NODE]/files/var/log/startup.log
    ...
Snapshot succeeded. Output saved in [FILENAME].tar.gz.

תרחישים של תמונות מצב

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

  • ‫system (ברירת המחדל): איסוף תמונת מצב עם יומנים במרחבי שמות נתמכים של המערכת.

  • ‫all: איסוף קובץ snapshot עם יומנים בכל מרחבי השמות, כולל מרחבי שמות שהוגדרו על ידי המשתמש.

  • ‫lite (גרסה 1.29 ואילך): איסוף קובץ snapshot עם משאבים ב-Kubernetes ויומני gkectl בלבד. כל שאר היומנים, כמו יומני קונטיינרים ויומני ליבה של צמתים, לא נכללים.

התרחישים הזמינים של קובצי snapshot משתנים בהתאם לגרסה של Google Distributed Cloud.

  • גרסאות קודמות ל-1.13: system,‏ system-with-logs,‏ all ו-all-with-logs.

  • גרסאות 1.13 עד 1.28: system ו-all. התרחיש system זהה לתרחיש הישן system-with-logs. התרחיש all זהה לתרחיש all-with-logs הישן.

  • גרסאות 1.29 ואילך: system,‏ all ו-lite.

כדי ליצור קובץ snapshot של אשכול האדמין, לא צריך לציין תרחיש:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

כדי ליצור קובץ snapshot של אשכול משתמש באמצעות התרחיש system:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system

כדי ליצור קובץ snapshot של אשכול משתמש באמצעות התרחיש all:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=all

כדי ליצור קובץ snapshot של אשכול משתמש באמצעות התרחיש lite:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=lite

שימוש ב---log-since כדי להגביל תמונת מצב

אפשר להשתמש בדגל --log-since כדי להגביל את איסוף היומנים לתקופה האחרונה. לדוגמה, אפשר לאסוף רק את היומנים מהיומיים האחרונים או משלוש השעות האחרונות. כברירת מחדל, diagnose snapshot אוסף את כל היומנים.

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=CLUSTER_NAME \
    --scenario=system \
    --log-since=DURATION

מחליפים את <var>DURATION</var> בערך זמן כמו 120m או 48h.

צריך להתחשב בשיקולים הבאים:

  • הדגל --log-since נתמך רק ביומני kubectl ו-journalctl.
  • אי אפשר להשתמש בדגלי פקודות כמו --log-since בהגדרות של קובץ snapshot בהתאמה אישית.

הרצת בדיקה של קובץ snapshot

אפשר להשתמש בדגל --dry-run כדי להציג את הפעולות שצריך לבצע ואת הגדרת קובץ ה-snapshot.

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

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=ADMIN_CLUSTER_NAME \
    --dry-run

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

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --dry-run

שימוש בהגדרת תמונת מצב

אם שני התרחישים האלה (--scenario system או all) לא מתאימים לצרכים שלכם, אתם יכולים ליצור קובץ snapshot בהתאמה אישית על ידי העברת קובץ תצורה של קובץ snapshot באמצעות הדגל --snapshot-config:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --snapshot-config=SNAPSHOT_CONFIG_FILE

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

כדי ליצור הגדרת תמונת מצב לתרחיש מסוים, צריך להעביר את הדגלים --scenario ו---dry-run. לדוגמה, כדי לראות את הגדרת תמונת המצב של תרחיש ברירת המחדל (system) של אשכול משתמש, מזינים את הפקודה הבאה:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system
    --dry-run

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

numOfParallelThreads: 10
excludeWords:
- password
kubectlCommands:
- commands:
  - kubectl get clusters -o wide
  - kubectl get machines -o wide
  - kubectl get clusters -o yaml
  - kubectl get machines -o yaml
  - kubectl describe clusters
  - kubectl describe machines
  namespaces:
  - default
- commands:
  - kubectl version
  - kubectl cluster-info
  - kubectl get nodes -o wide
  - kubectl get nodes -o yaml
  - kubectl describe nodes
  namespaces: []
- commands:
  - kubectl get pods -o wide
  - kubectl get deployments -o wide
  - kubectl get daemonsets -o wide
  - kubectl get statefulsets -o wide
  - kubectl get replicasets -o wide
  - kubectl get services -o wide
  - kubectl get jobs -o wide
  - kubectl get cronjobs -o wide
  - kubectl get endpoints -o wide
  - kubectl get configmaps -o wide
  - kubectl get pods -o yaml
  - kubectl get deployments -o yaml
  - kubectl get daemonsets -o yaml
  - kubectl get statefulsets -o yaml
  - kubectl get replicasets -o yaml
  - kubectl get services -o yaml
  - kubectl get jobs -o yaml
  - kubectl get cronjobs -o yaml
  - kubectl get endpoints -o yaml
  - kubectl get configmaps -o yaml
  - kubectl describe pods
  - kubectl describe deployments
  - kubectl describe daemonsets
  - kubectl describe statefulsets
  - kubectl describe replicasets
  - kubectl describe services
  - kubectl describe jobs
  - kubectl describe cronjobs
  - kubectl describe endpoints
  - kubectl describe configmaps
  namespaces:
  - kube-system
  - gke-system
  - gke-connect.*
prometheusRequests: []
nodeCommands:
- nodes: []
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - sudo iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1
  - sudo docker ps -a
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - sudo conntrack --count
nodeFiles:
- nodes: []
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/nf_conntrack_max
seesawCommands: []
seesawFiles: []
nodeCollectors:
- nodes: []
f5:
  enabled: true
vCenter:
  enabled: true

המידע הבא מוצג בפלט:

  • ‫numOfParallelThreads: מספר השרשורים המקבילים שמשמשים ליצירת קובצי snapshot.

  • ‫excludeWords: רשימת מילים שיוחרגו מתמונת המצב (לא תלוי-רישיות). שורות שמכילות את המילים האלה יוסרו מתוצאות תמונת המצב. הערך "password" תמיד מוחרג, גם אם לא ציינתם אותו.

  • ‫kubectlCommands: רשימה של פקודות kubectl להרצה. התוצאות נשמרות. הפקודות פועלות מול מרחבי השמות המתאימים. בפקודות kubectl logs, כל ה-Pods והקונטיינרים במרחבי השמות התואמים נוספים באופן אוטומטי. אפשר להשתמש בביטויים רגולריים כדי לציין מרחבי שמות. אם לא מציינים מרחב שמות, המערכת מניחה שמרחב השמות הוא default.

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

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

  • ‫seesawCommands: רשימת פקודות להרצה כדי לאסוף מידע על מאזן העומסים של Seesaw. התוצאות נשמרות אם באשכול נעשה שימוש במאזן העומסים Seesaw.

  • ‫seesawFiles: רשימת הקבצים שייאספו למאזן העומסים Seesaw.

  • ‫nodeCollectors: אוסף שפועל בצומתי Cilium כדי לאסוף מידע על eBPF.

  • ‫f5: דגל להפעלת איסוף מידע שקשור למאזן העומסים F5 BIG-IP.

  • ‫vCenter: דגל להפעלת איסוף המידע שקשור ל-vCenter.

  • ‫prometheusRequests: רשימה של בקשות Prometheus. התוצאות נשמרות.

העלאת קובצי Snapshot לקטגוריה של Cloud Storage

כדי שיהיה קל יותר לנהל את הרישומים, לנתח את הנתונים ולאחסן אותם, אתם יכולים להעלות את כל קובצי ה-snapshot של אשכול מסוים לקטגוריה של Cloud Storage. המידע הזה שימושי במיוחד אם אתם צריכים עזרה מ-Cloud Customer Care.

לפני שמעלים קובצי snapshot לקטגוריה של Cloud Storage, צריך לבדוק ולהשלים את הדרישות הראשוניות הבאות:

  • מפעילים את storage.googleapis.com בפרויקט המארח של ה-fleet. אפשר להשתמש בפרויקט אחר, אבל מומלץ להשתמש בפרויקט המארח של ה-fleet.

    gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com

  • מקצים את התפקיד roles/storage.admin לחשבון השירות בפרויקט ההורה שלו, ומעבירים את קובץ המפתח בפורמט JSON של חשבון השירות באמצעות הפרמטר --service-account-key-file. אפשר להשתמש בכל חשבון שירות, אבל מומלץ להשתמש בחשבון השירות לרישום ב-Connect. מידע נוסף זמין במאמר חשבונות שירות.

    gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
  --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \
  --role "roles/storage.admin"

    מחליפים את CONNECT_REGISTER_SERVICE_ACCOUNT בחשבון השירות של Connect Register.

אחרי שמוודאים שהדרישות האלה מתקיימות, אפשר להעלות את קובץ ה-snapshot לקטגוריה של Cloud Storage:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name CLUSTER_NAME \
    --upload \
    --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT

הדגל --share-with יכול לקבל רשימה של שמות של חשבונות שירות. מחליפים את GOOGLE_SUPPORT_SERVICE_ACCOUNT בחשבון השירות של Cloud Customer Care שסופק על ידי Cloud Customer Care, יחד עם כל חשבון שירות אחר שסופק על ידי Cloud Customer Care.

כשמשתמשים בדגל --upload, הפקודה מחפשת בפרויקט קטגוריית אחסון שהשם שלה מתחיל ב-"anthos-snapshot-". אם קיימת קטגוריה כזו, הפקודה מעלה את קובץ ה-snapshot לקטגוריה הזו. אם הפקודה לא מוצאת קטגוריה עם שם תואם, היא יוצרת קטגוריה חדשה בשם anthos-snapshot-UUID, כאשר UUID הוא מזהה ייחודי אוניברסלי בן 32 ספרות.

כשמשתמשים בדגל --share-with, לא צריך לשתף באופן ידני את הגישה לקטגוריה עם Cloud Customer Care.

הפלט הבא מוצג כשמעלים קובץ snapshot לקטגוריה של Cloud Storage:

Using "system" snapshot configuration...
Taking snapshot of user cluster <var>CLUSTER_NAME</var>...
Setting up <var>CLUSTER_NAME</var> ssh key...DONE
Using the gke-connect register service account key...
Setting up Google Cloud Storage bucket for uploading the snapshot...DONE
Taking snapshots in 10 thread(s)...
   ...
Snapshot succeeded.
Snapshots saved in "<var>SNAPSHOT_FILE_PATH</var>".
Uploading snapshot to Google Cloud Storage......  DONE
Uploaded the snapshot successfully to gs://anthos-snapshot-a4b17874-7979-4b6a-a76d-e49446290282/<var>xSNAPSHOT_FILE_NAME</var>.
Shared successfully with service accounts:
<var>GOOGLE_SUPPORT_SERVICE_ACCOUNT</var>

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

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

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