אם נתקלתם בבעיה באחד מהאשכולות, תוכלו לקבל עזרה מ-Cloud Customer Care. יכול להיות שב-Customer Care יבקשו מכם לצלם תמונת מצב של האשכול, כדי שיוכלו לאבחן את הבעיה. תמונת מצב מתעדת את קובצי ההגדרות של האשכול והצומת, ואורזת את המידע הזה בקובץ tar יחיד.
במאמר הזה נסביר איך ליצור תמונות מצב שמוגדרות כברירת מחדל או תמונות מצב מותאמות אישית של אשכול. בנוסף, מוסבר איך ליצור תמונות מצב כשמתרחשות שגיאות מסוימות באשכול.
לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל:
- דרישות לפתיחת בקשת תמיכה.
- כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, היומנים והמדדים.
- רכיבים נתמכים.
תמונות ברירת מחדל
בקטעים הבאים מוסבר מה כלול בתמונת מצב רגילה ואיך יוצרים אותה. מידע על תמונות מצב בהתאמה אישית מופיע בקטע בנושא תמונות מצב בהתאמה אישית.
איזה מידע כלול בתמונת מצב שנוצרת כברירת מחדל?
תמונת המצב של אשכול היא קובץ tar של קובצי תצורה ויומנים לגבי האשכול. באופן ספציפי, הגדרת ברירת המחדל של הפקודה מתעדת את המידע הבא על האשכול:
גרסת Kubernetes.
הסטטוס של משאבי Kubernetes במרחבי השמות kube-system ו-gke-system: cluster, machine, nodes, Services, Endpoints, ConfigMaps, ReplicaSets, CronJobs, Pods, והבעלים של ה-Pods האלה, כולל Deployments, DaemonSets ו-StatefulSets.
פרטים על כל הגדרת צומת, כולל כתובות IP, כללי iptables, נקודות הרכבה, מערכת קבצים, חיבורים לרשת ותהליכים שפועלים.
מידע על זמן הריצה של מכונות וירטואליות ב-GDC ועל מכונות וירטואליות ומשאבים שקשורים למכונות וירטואליות שפועלים באשכול. מידע נוסף על הנתונים שנאספים כברירת מחדל ועל יצירת snapshots ספציפיים למכונות וירטואליות זמין במאמר מידע על מכונות וירטואליות ב-snapshots.
יומנים מהפקודה
bmctl check cluster --snapshot.
פרטי הכניסה של אשכול לא נכללים בתמונת המצב שמוגדרת כברירת מחדל. אם צוות Cloud Customer Care מבקש את המידע הזה, אפשר לעיין במאמר בנושא אחזור מידע על אשכול.
רשימה מקיפה של המידע שנאסף כשמריצים את פקודת הצילום מופיעה בקטע קובץ ההגדרות בפירוט. קובץ התצורה הזה מראה אילו פקודות מופעלות כשמצלמים תמונת מצב של ברירת מחדל.
יצירת תמונת מצב שמוגדרת כברירת מחדל
הפקודה bmctl check cluster מצלמת תמונה של אשכול. אפשר להשתמש בפקודה הזו כדי לבצע אחת מהפעולות הבאות:
- ליצור snapshot ולהעלות אותו באופן אוטומטי לקטגוריה של Cloud Storage.
- יוצרים קובץ snapshot של אשכול ושומרים אותו במחשב המקומי שבו מריצים את הפקודה.
שיטה 1: יצירת תמונת מצב שמוגדרת כברירת מחדל והעלאה אוטומטית לקטגוריה של Cloud Storage
כדי ליצור תמונת מצב ולהעלות אותה לקטגוריה של Cloud Storage, מבצעים את הפעולות הבאות:
מגדירים API וחשבון שירות כמו שמתואר במאמר הגדרת חשבון שירות עם גישה לקטגוריה של Cloud Storage.
זהו שלב חד-פעמי.
מריצים את הפקודה
bmctlהבאה כדי ליצור תמונת מצב ולהעלות אותה באופן אוטומטי לקטגוריה של Cloud Storage:bmctl check cluster --snapshot --cluster=CLUSTER_NAME \ --admin-kubeconfig=ADMIN_KUBECONFIG \ --service-account-key-file SA_KEY_FILEמחליפים את הערכים הבאים בפרטים שספציפיים לסביבת האשכול:
-
CLUSTER_NAME: שם האשכול שרוצים ליצור לו snapshot. -
ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין. -
SA_KEY_FILE: הנתיב לקובץ מפתח JSON שהורד עבור חשבון השירות שנוצר בשלב הקודם. אם לא משתמשים בדגל--service-account-key-file, הפקודה משתמשת בפרטי הכניסה שמשויכים למשתנה הסביבהGOOGLE_APPLICATION_CREDENTIALS. הגדרה מפורשת של פרטי הכניסה של חשבון השירות באמצעות הדגל מקבלת עדיפות.
הפקודה הזו יוצרת קובץ tar של תמונת מצב ושומרת אותו באופן מקומי. כשחשבון השירות מוגדר בצורה נכונה, הפקודה מעלה גם את קובץ ה-tar של התמונה ל-bucket ב-Cloud Storage. הפקודה מחפשת בפרויקט קטגוריית אחסון שהשם שלה מתחיל ב-
anthos-snapshot-. אם קטגוריה כזו קיימת, הפקודה מעלה את התמונה שלה לקטגוריה. אם הפקודה לא מוצאת קטגוריה עם שם תואם, היא יוצרת קטגוריה חדשה בשםanthos-snapshot-UUID, כאשרUUIDהוא מזהה ייחודי אוניברסלי בן 32 ספרות.-
משתפים גישה עם Cloud Customer Care כמו שמתואר במאמר איך מאפשרים ל-Cloud Customer Care לצפות בתמונת המצב של האשכול שהועלתה.
שיטה 2: יצירת snapshot שמוגדר כברירת מחדל במחשב המקומי בלבד
כדי לוודא שתמונת המצב של האשכול נשמרת רק באופן מקומי, משתמשים בדגל --local. אפשר לצלם את מצב האשכולות שנוצרו באמצעות הפקודה הבאה:
bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
--admin-kubeconfig=ADMIN_KUBECONFIG --local
מחליפים את מה שכתוב בשדות הבאים:
CLUSTER_NAME: השם של אשכול היעד.
ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
הפקודה הזו יוצרת קובץ tar במחשב המקומי. השם של קובץ ה-tar הזה הוא בפורמט snapshot-CLUSTER_NAME-TIMESTAMP.tar.gz, כאשר TIMESTAMP מציין את התאריך והשעה שבהם הקובץ נוצר. קובץ ה-tar הזה כולל מידע רלוונטי לניפוי באגים לגבי רכיבי המערכת והמכונות של אשכול.
כשמריצים את הפקודה הזו, המערכת אוספת מידע על ה-Pods ממרחבי השמות הבאים: gke-system, gke-connect, capi-system, capi-webhook-system, cert-manager ו-capi-kubeadm-bootstrap-system.
עם זאת, אפשר להרחיב את היקף נתוני האבחון שנאספים באמצעות הדגל --snapshot-scenario all. הדגל הזה מרחיב את היקף תמונת המצב של האבחון כך שיכלול את כל ה-Pods באשכול:
bmctl check cluster --snapshot --snapshot-scenario all \
--cluster=CLUSTER_NAME \
--kubeconfig=KUBECONFIG_PATH \
--local
תרחישים של תמונות מצב
הפקודה bmctl check cluster --snapshot תומכת בשני תרחישים. כדי לציין תרחיש, משתמשים בדגל --scenario. ברשימה הבאה מוצגים הערכים האפשריים:
system: איסוף קובץ snapshot של רכיבי המערכת, כולל היומנים שלהם.
all: איסוף תמונת מצב של כל הפודים, כולל היומנים שלהם.
אפשר להשתמש בכל אחד משני התרחישים עם אשכול אדמין או עם אשכול משתמש. בדוגמה הבאה נוצרת תמונת מצב של אשכול הניהול באמצעות התרחיש system:
bmctl check cluster --snapshot --snapshot-scenario system \
--cluster=ADMIN_CLUSTER_NAME \
--kubeconfig=ADMIN_KUBECONFIG_PATH
בדוגמה הבאה נוצרת תמונת מצב של אשכול משתמשים באמצעות התרחיש all:
bmctl check cluster --snapshot --snapshot-scenario all \
--cluster=USER_CLUSTER_NAME \
--kubeconfig=USER_KUBECONFIG_PATH
הרצת בדיקה של snapshot
כשמשתמשים בדגל --snapshot-dry-run, הפקודה לא יוצרת תמונת מצב.
במקום זאת, הוא מציג את הפעולות שהפקודה ליצירת צילום מהמצלמה תבצע, ומפיק קובץ תצורה של צילום מהמצלמה. מידע על קובץ ההגדרות של תמונת המצב זמין במאמר איך יוצרים תמונת מצב בהתאמה אישית.
כדי לבצע צילום מצב של הרצה יבשה באשכול הניהול, מזינים את הפקודה הבאה:
bmctl check cluster --snapshot --snapshot-dry-run \
--cluster=ADMIN_CLUSTER_NAME \
--kubeconfig=ADMIN_KUBECONFIG_PATH
כדי לבצע צילום מצב של הרצה יבשה באשכול משתמשים, מזינים את הפקודה הבאה:
bmctl check cluster --snapshot --snapshot-dry-run \
--cluster=USER_CLUSTER_NAME \
--kubeconfig=USER_KUBECONFIG_PATH
קבלת יומנים מתקופה מסוימת
אפשר להשתמש בדגל --since כדי לאחזר יומנים מתקופה שמעניינת אתכם במיוחד. כך תוכלו ליצור תמונות מצב קטנות וממוקדות יותר של רישום ביומן שבוצע בשניות, בדקות או בשעות האחרונות.
לדוגמה, הפקודה הבאה bmctl יוצרת תמונת מצב של רישום ביומן שבוצע בשלוש השעות האחרונות:
bmctl check cluster --snapshot --since=3h \
--cluster=CLUSTER_NAME \
--kubeconfig=ADMIN_KUBECONFIG_PATH
הגדרה של ספרייה שבה יישמר הצילום מהמצלמה באופן זמני
אפשר להשתמש בדגל --snapshot-temp-output-dir כדי לציין ספרייה שבה התמונה תישמר באופן זמני:
bmctl check cluster --snapshot --snapshot-temp-output-dir=TEMP_OUTPUT_DIR \
--cluster=CLUSTER_NAME \
--kubeconfig=ADMIN_KUBECONFIG_PATH
אם לא מציינים ספרייה, תמונת המצב נשמרת באופן זמני בספרייה /tmp. מומלץ להשתמש באפשרות --snapshot-temp-output-dir כשאין מספיק מקום בספרייה /tmp שמוגדרת כברירת מחדל, למשל.
השבתת רישום ביומן המסוף
אפשר להשתמש בדגל --quiet כדי למנוע מהודעות יומן להופיע במסוף במהלך הפעלת תמונת מצב. במקום זאת, יומני המסוף נשמרים בקובץ bmctl_diagnose_snapshot.log כחלק מהתמונה.
מריצים את הפקודה הבאה כדי למנוע מהודעות ביומן להופיע במסוף:
bmctl check cluster --snapshot --quiet \
--cluster=CLUSTER_NAME \
--kubeconfig=ADMIN_KUBECONFIG_PATH
שינוי של השרשור המקביל בשורת הפקודה
בדרך כלל, שגרת הצילום של התמונה מייצרת פקודות רבות. ריבוי שרשורים מקביליים מאפשר להריץ פקודות בו-זמנית, וכך התרחיש מבוצע מהר יותר.
בגרסה 1.31 ואילך, הפקודה bmctl check cluster תומכת בדגל --num-of-parallel-threads. משתמשים בדגל הזה כדי להגדיר את מספר השרשורים המקבילים שמשמשים ליצירת תמונות מצב.
כברירת מחדל, שגרת הצילום של התמונה משתמשת ב-10 תהליכונים. אם לוקח יותר מדי זמן ליצור את התמונות, צריך להגדיל את הערך הזה.
בדוגמה הבאה, הפקודה מגדירה את מספר השרשורים המקבילים ל-30.
bmctl check cluster --snapshot --cluster=cluster1 \
--admin-kubeconfig=bmctl-workspace/admin-cluster/admin-cluster-kubeconfig \
--num-of-parallel-threads=30
היכולת הזו דומה לשדה numOfParallelThreads בקובץ התצורה של תמונת המצב, כשיוצרים תמונות מצב בהתאמה אישית.
תמונות מצב בהתאמה אישית
יכול להיות שתרצו ליצור תמונת מצב מותאמת אישית של אשכול מהסיבות הבאות:
- כדי לכלול מידע נוסף על האשכול מעבר למה שמופיע בתמונת המצב שמוגדרת כברירת מחדל.
- כדי להחריג מידע מסוים שמופיע בתמונת המצב שמוגדרת כברירת מחדל.
יצירת תמונת מצב בהתאמה אישית
כדי ליצור snapshot בהתאמה אישית, צריך להשתמש בקובץ הגדרות של snapshot. בשלבים הבאים מוסבר איך ליצור את קובץ התצורה, לשנות אותו ולהשתמש בו כדי ליצור תמונת מצב מותאמת אישית של אשכול:
כדי ליצור קובץ תצורה של תמונת מצב, מריצים את הפקודה הבאה באשכול וכותבים את הפלט לקובץ:
bmctl check cluster \ --snapshot --snapshot-dry-run --cluster CLUSTER_NAME \ --kubeconfig KUBECONFIG_PATHמגדירים איזה מידע רוצים שיופיע בתמונת המצב המותאמת אישית. כדי לעשות זאת, משנים את קובץ התצורה של התמונה שנוצר בשלב 1. לדוגמה, אם רוצים שהתמונה תכיל מידע נוסף, כמו משך הפעולה של צומת מסוים, מוסיפים את פקודת Linux
uptimeלקטע הרלוונטי בקובץ ההגדרה.בקטע הקוד הבא של קובץ תצורה אפשר לראות איך גורמים לפקודת הצילום לספק מידע על
uptimeלגבי הצומת10.200.0.3. המידע הזה לא מופיע בתמונת מצב רגילה.... nodeCommands: - nodes: - 10.200.0.3 commands: - uptime ...אחרי שמשנים את קובץ התצורה כדי להגדיר את סוג התמונה שרוצים ליצור, מריצים את הפקודה הבאה כדי ליצור את התמונה המותאמת אישית:
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE \ --cluster CLUSTER_NAME--kubeconfig KUBECONFIG_PATHהדגל
--snapshot-configמכוון את הפקודהbmctlלהשתמש בתוכן של קובץ התצורה של תמונת המצב כדי להגדיר איזה מידע יופיע בתמונת המצב.
פרטים על קובץ התצורה
בקובץ התצורה לדוגמה של צילום מצב מוצגות הפקודות והקבצים הסטנדרטיים שמשמשים ליצירת צילום מצב, אבל אפשר להוסיף עוד פקודות וקבצים כשצריך מידע אבחוני נוסף:
numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
- 10.200.0.3
- 10.200.0.4
commands:
- uptime
- df --all --inodes
- ip addr
- ip neigh
- iptables-save --counters
- mount
- ip route list table all
- top -bn1 || true
- docker info || true
- docker ps -a || true
- crictl ps -a || true
- docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
sudo docker logs || true
- docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
xargs sudo docker logs || true
- crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
sudo crictl logs || true
- crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
xargs sudo crictl logs || true
- ps -edF
- ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
- conntrack --count
- dmesg
- systemctl status -l docker || true
- journalctl --utc -u docker
- journalctl --utc -u docker-monitor.service
- systemctl status -l kubelet
- journalctl --utc -u kubelet
- journalctl --utc -u kubelet-monitor.service
- journalctl --utc --boot --dmesg
- journalctl --utc -u node-problem-detector
- systemctl status -l containerd || true
- journalctl --utc -u containerd
- systemctl status -l docker.haproxy || true
- journalctl --utc -u docker.haproxy
- systemctl status -l docker.keepalived || true
- journalctl --utc -u docker.keepalived
- systemctl status -l container.haproxy || true
- journalctl --utc -u container.haproxy
- systemctl status -l container.keepalived || true
- journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
- 10.200.0.3
- 10.200.0.4
files:
- /proc/sys/fs/file-nr
- /proc/sys/net/netfilter/nf_conntrack_max
- /proc/sys/net/ipv4/conf/all/rp_filter
- /lib/systemd/system/kubelet.service
- /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
- /lib/systemd/system/docker.service || true
- /etc/systemd/system/containerd.service || true
- /etc/docker/daemon.json || true
- /etc/containerd/config.toml || true
- /etc/systemd/system/container.keepalived.service || true
- /etc/systemd/system/container.haproxy.service || true
- /etc/systemd/system/docker.keepalived.service || true
- /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file
הערכים הבאים בקובץ התצורה כנראה שונים מהערכים שמופיעים בקובץ התצורה לדוגמה הקודם:
- כתובות ה-IP של הצמתים בקטעים
nodeCommandsו-nodeFiles - הנתיב אל
nodeSSHKeyשל האשכול
שדות בקובץ התצורה
קובץ תצורת תמונת מצב הוא בפורמט YAML. קובץ התצורה כולל את השדות הבאים:
numOfParallelThreads: בדרך כלל, שגרת ה-snapshot מריצה מספר רב של פקודות. ריבוי שרשורים מקבילים עוזרים לשגרה להתבצע מהר יותר. מומלץ להגדיר אתnumOfParallelThreadsל-10כפי שמוצג בקובץ התצורה לדוגמה שלמעלה. אם יצירת התמונות לוקחת יותר מדי זמן, צריך להגדיל את הערך הזה.
excludeWords: קובץ ה-snapshot מכיל כמות גדולה של נתונים עבור צמתי האשכול. כדאי להשתמש ב-excludeWordsכדי לצמצם את סיכוני האבטחה כשמשתפים את התמונה. לדוגמה, אפשר להחריג אתpasswordכדי שלא יהיה אפשר לזהות מחרוזות סיסמה תואמות.
nodeCommands: בקטע הזה מצוינים הפרטים הבאים:
nodes: רשימה של כתובות IP של צמתי האשכול שמהם רוצים לאסוף מידע. כדי ליצור תמונת מצב כשאי אפשר להגיע אל אשכול האדמין, צריך לציין כתובת IP של צומת אחת לפחות.
commands: רשימה של פקודות (וארגומנטים) להרצה בכל צומת. הפלט של כל פקודה נכלל בתמונת המצב.
nodeFiles: בקטע הזה מצוינים הפרטים הבאים:
nodes: רשימה של כתובות IP של צמתי אשכולות שמהם רוצים לאסוף קבצים. כדי ליצור תמונת מצב כשאי אפשר להגיע אל אשכול האדמין, צריך לציין לפחות כתובת IP אחת של צומת.
files: רשימה של קבצים לאחזור מכל צומת. כשמערכת מוצאת צמתים עם הקבצים שצוינו, היא כוללת אותם בתמונת המצב.
nodeSSHKey: הנתיב לקובץ של מפתח ה-SSH. השדה הזה הוא חובה כשאי אפשר להגיע אל אשכול האדמין.
יצירת תמונות מצב כשנתקלים בשגיאות מסוימות
יכול להיות שיהיה צורך בשלבים נוספים או בפרמטרים של פקודות כדי ליצור תמונת מצב בהצלחה כשמתרחשים אירועים מסוימים, כמו שדרוג תקוע.
יצירת תמונת מצב של ברירת המחדל במהלך התקנות או שדרוגים תקועים
במהלך התקנה או שדרוג של אשכולות אדמין, אשכולות היברידיים או אשכולות עצמאיים, יכול להיות שהתהליך של bmctl ייעצר בשלב שבו מוצגות הפלטות הבאות:
- בהמתנה שקובץ ה-kubeconfig של האשכול יהיה מוכן.
- בהמתנה שהאשכול יהיה מוכן.
- בהמתנה שמאגרי הצמתים יהיו מוכנים.
- בהמתנה לסיום השדרוג.
אם ההתקנה או השדרוג נתקעים, אפשר לצלם תמונת מצב של אשכול באמצעות אשכול האתחול, כמו בדוגמה הבאה:
bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
--kubeconfig=WORKSPACE_DIR/.kindkubeconfig
יצירת תמונת מצב בהתאמה אישית במהלך התקנות או שדרוגים תקועים
השלבים הבאים מראים איך ליצור תמונת מצב מותאמת אישית של אשכול כשהתקנה או שדרוג נתקעים:
מאחזרים קובץ תצורה של תמונת מצב של האשכול מהארכיונים.
משנים את קובץ התצורה של תמונת המצב כך שתמונת המצב תכיל את המידע הרצוי.
כדי ליצור את התמונה המותאמת אישית, מריצים את הפקודה הבאה:
bmctl check cluster --snapshot --snapshot-config=SNAPSHOT_CONFIG_FILE \ --cluster=CLUSTER_NAME --kubeconfig=WORKSPACE_DIR/.kindkubeconfig
יצירת תמונת מצב בהתאמה אישית כשהאשכול הניהולי לא נגיש
כשאי אפשר להגיע לאשכול הניהול, אפשר ליצור תמונת מצב מותאמת אישית של האשכול על ידי הפעלת הפקודה הבאה:
bmctl check cluster --snapshot --cluster CLUSTER_NAME
--node-ssh-key SSH_KEY_FILE
--nodes NODE_1_IP_ADDRESS, NODE_2_IP_ADDRESS, ...
בפקודה, מחליפים את הערכים הבאים בפרטים שספציפיים לסביבת האשכול:
-
CLUSTER_NAME: שם האשכול שרוצים ליצור לו snapshot. -
SSH_KEY_FILE: הנתיב לקובץ של מפתח ה-SSH של הצומת. -
NODE_x_IP_ADDRESS: כתובת ה-IP של צומת באשכול שרוצים לקבל מידע לגביו.
אפשר גם לרשום את כתובות ה-IP של הצמתים בשורות נפרדות:
bmctl check cluster
--snapshot --cluster CLUSTER_NAME \
--node-ssh-key SSH_KEY_FILE \
--nodes NODE_1_IP_ADDRESS \
--nodes NODE_2_IP_ADDRESS
...
פרטי מכונה וירטואלית ב-snapshots
אם אתם משתמשים ב-VM Runtime ב-GDC כדי ליצור ולנהל מכונות וירטואליות (VM) ב-Google Distributed Cloud, אתם יכולים לאסוף מידע רלוונטי לצורך אבחון בתמונות מצב. תמונות מצב הן משאב חשוב לאבחון ולפתרון בעיות במכונות וירטואליות.
אילו נתונים נאספים כברירת מחדל
כשיוצרים snapshot שמוגדר כברירת מחדל, הוא מכיל את המידע על VM Runtime ב-GDC ועל משאבים קשורים.
VM Runtime on GDC כלול ב-Google Distributed Cloud, והמשאב המותאם אישית VMRuntime זמין באשכולות שמריצים עומסי עבודה.
גם אם לא הפעלתם את VM Runtime ב-GDC, התמונה עדיין מכילה את תיאור ה-YAML של המשאב המותאם אישית VMRuntime.
אם הפעלתם את VM Runtime ב-GDC, התמונות מכילות מידע על הסטטוס וההגדרה של המשאבים שקשורים למכונה הווירטואלית (כשהאובייקטים קיימים) באשכול. משאבים שקשורים למכונות וירטואליות כוללים אובייקטים של Kubernetes, כמו Pods, Deployments, DaemonSets ו-ConfigMaps.
אובייקטים במרחב השמות vm-system
סטטוס ופרטי ההגדרה של האובייקטים הבאים נמצאים ב-kubectlCommands/vm-system בתמונת המצב שנוצרה:
KubeVirtVirtualMachineTypeVMHighAvailabilityPolicy
אובייקטים במרחבי שמות אחרים
כשיוצרים מכונה וירטואלית (VirtualMachine), אפשר לציין את מרחב השמות. אם לא מציינים מרחב שמות, המכונה הווירטואלית מקבלת את מרחב השמות default. האובייקטים האחרים בקטע הזה, כמו VirtualMachineInstance, כולם קשורים למרחב השמות של המכונה הווירטואלית המתאימה.
מידע על הסטטוס וההגדרה של האובייקטים הבאים נמצא בkubectlCommands/VM_NAMESPACE בתמונת המצב שנוצרה. אם לא הגדרתם מרחב שמות ספציפי למכונה הווירטואלית, המידע נמצא ב-kubectlCommands/default:
VirtualMachineVirtualMachineInstanceVirtualMachineDiskGuestEnvironmentDataVirtualMachineAccessRequestVirtualMachinePasswordResetRequest
אובייקטים שלא נמצאים במרחב שמות
האובייקטים הבאים לא נמצאים במרחב שמות, ולכן המידע שמתאים להם נמצא ישירות ב-kubectlCommands בתמונת המצב שנוצרה:
VMRuntimeDataVolumeCDIGPUAllocation
שימוש בקובץ תצורה של snapshot כדי לתעד רק את פרטי ה-VM
אם אתם מאבחנים בעיות שקשורות ספציפית למכונות וירטואליות, אתם יכולים להשתמש בקובץ תצורה של snapshot כדי להגביל את המידע שנאסף לפרטים שקשורים רק למכונות וירטואליות, וגם כדי להתאים אישית את המידע שנאסף על המכונות הווירטואליות.
קובץ התצורה הבא של תמונת מצב ממחיש איך אפשר ליצור תמונת מצב ספציפית למכונה וירטואלית. אפשר לכלול פקודות נוספות כדי לאסוף מידע נוסף לתמונת המצב.
---
kubectlCommands:
- commands:
- kubectl get vm -o wide
- kubectl get vmi -o wide
- kubectl get gvm -o wide
- kubectl get vm -o yaml
- kubectl get vmi -o yaml
- kubectl get gvm -o yaml
- kubectl describe vm
- kubectl describe vmi
- kubectl describe gvm
namespaces:
- .*
- commands:
- kubectl get virtualmachinetype -o wide
- kubectl get virtualmachinedisk -o wide
- kubectl get virtualmachinetype -o yaml
- kubectl get virtualmachinedisk -o yaml
- kubectl describe virtualmachinetype
- kubectl describe virtualmachinedisk
namespaces:
- vm-system
מידע נוסף על שימוש בקובצי תצורה של תמונת מצב זמין במאמר הזה בקטע תמונות מצב בהתאמה אישית.
המאמרים הבאים
לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל:
- דרישות לפתיחת בקשת תמיכה.
- כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, היומנים והמדדים.
- רכיבים נתמכים.