תמונות מצב של אשכולות מאפשרות לארוז קובצי תצורה של אשכולות וצמתים בקובץ tar אחד, כדי לפתור בעיות. כשאתם חוקרים בעיות באשכול, Cloud Customer Care משתמש בתמונות המצב האלה כדי לאבחן את שורש הבעיה.
אתם יכולים ליצור תמונות מצב כברירת מחדל או להתאים אישית את הגדרות הצילום כדי לאסוף נתוני אבחון רלוונטיים כשיש שגיאות ספציפיות באשכול.
תמונות מצב שמוגדרות כברירת מחדל
בקטעים הבאים מוסבר מה כולל קובץ snapshot רגיל ואיך יוצרים אותו. מידע נוסף על קובצי snapshot בהתאמה אישית מופיע בקטע קובצי snapshot בהתאמה אישית.
איזה מידע מכילה תמונת מצב שמוגדרת כברירת מחדל?
תמונת המצב של אשכול היא קובץ tar של קובצי תצורה ויומנים שקשורים לאשכול. באופן ספציפי, הגדרת ברירת המחדל של הפקודה מתעדת את המידע הבא על האשכול:
גרסת Kubernetes.
סטטוס המשאבים של Kubernetes במרחבי השמות kube-system ו-gke-system: אשכול, מכונה, צמתים, שירותים, נקודות קצה, ConfigMaps, ReplicaSets, CronJobs, Pods והבעלים של אותם Pods, כולל Deployments, DaemonSets ו-StatefulSets.
פרטים על ההגדרות של כל צומת, כולל כתובות IP, כללי iptables, נקודות טעינה, מערכת קבצים, חיבורים לרשת ותהליכים שפועלים.
מידע על VM Runtime on GDC ועל כל המכונות הווירטואליות והמשאבים שקשורים למכונות וירטואליות שפועלים באשכול. למידע נוסף על הנתונים שנאספים כברירת מחדל ועל יצירת קובצי snapshot ספציפיים למכונות וירטואליות, ראו מידע על מכונות וירטואליות בקובצי snapshot במסמך הזה.
יומנים מהפקודה
bmctl check cluster --snapshot.
פרטי הכניסה של האשכול לא נכללים בתמונת המצב שמוגדרת כברירת מחדל. אם צוות Cloud Customer Care מבקש את המידע הזה, תוכלו לקרוא את המאמר אחזור מידע על אשכולות.
רשימה מקיפה של המידע שנאסף כשמריצים את הפקודה snapshot מופיעה בקטע הבא, קובץ התצורה בפירוט. בקובץ התצורה הזה אפשר לראות אילו פקודות מופעלות כשיוצרים תמונת מצב כברירת מחדל.
יצירת תמונת מצב שמוגדרת כברירת מחדל
הפקודה bmctl check cluster יוצרת קובץ snapshot של אשכול. אפשר להשתמש בפקודה הזו כדי לבצע את אחת מהפעולות הבאות:
- יצירת קובץ snapshot והעלאה אוטומטית שלו לקטגוריה של Cloud Storage.
- יוצרים קובץ snapshot של אשכול ושומרים את קובץ ה-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 של קובץ snapshot לקטגוריה ב-Cloud Storage. הפקודה מחפשת בפרויקט קטגוריית אחסון שהשם שלה מתחיל ב-"
anthos-snapshot-". אם קיימת קטגוריה כזו, הפקודה מעלה את קובץ ה-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: איסוף תמונת מצב של רכיבי המערכת, כולל היומנים שלהם.
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, הפקודה לא יוצרת קובץ snapshot.
במקום זאת, היא מציגה את הפעולות שפקודת ה-snapshot תבצע, ומוציאה קובץ תצורה של תמונת מצב. במאמר איך יוצרים קובץ snapshot בהתאמה אישית מוסבר על קובץ ההגדרות של קובץ ה-snapshot.
כדי לבצע הרצת בדיקה של תמונת מצב באשכול האדמין, מזינים את הפקודה הבאה:
bmctl check cluster --snapshot --snapshot-dry-run \
--cluster=ADMIN_CLUSTER_NAME \
--kubeconfig=ADMIN_KUBECONFIG_PATH
כדי לבצע snapshot של הרצת בדיקה באשכול משתמש, מזינים את הפקודה הבאה:
bmctl check cluster --snapshot --snapshot-dry-run \
--cluster=USER_CLUSTER_NAME \
--kubeconfig=USER_KUBECONFIG_PATH
קבלת יומנים מתקופה מסוימת
אפשר להשתמש בדגל --since כדי לאחזר יומנים מתקופת זמן שמעניינת אתכם במיוחד. כך אפשר ליצור תמונות מצב קטנות וממוקדות יותר של רישום ביומן שהתרחש בשניות, בדקות או בשעות האחרונות.
לדוגמה, הפקודה הבאה ב-bmctl יוצרת קובץ snapshot של רישום ביומן שהתרחש בשלוש השעות האחרונות:
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 כדי למנוע את ההצגה של הודעות ביומן במסוף במהלך הרצת קובץ snapshot. במקום זאת, היומנים של מסוף ה-CLI נשמרים בקובץ 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 תהליכונים במקביל. אם יצירת קובצי ה-Snapshot נמשכת יותר מדי זמן, צריך להגדיל את הערך הזה.
בדוגמה הבאה, הפקודה מגדירה את מספר השרשורים המקבילים ל-30.
bmctl check cluster --snapshot --cluster=cluster1 \
--admin-kubeconfig=bmctl-workspace/admin-cluster/admin-cluster-kubeconfig \
--num-of-parallel-threads=30
היכולת הזו דומה לשדה numOfParallelThreads בקובץ התצורה של תמונת המצב, כשיוצרים תמונות מצב בהתאמה אישית.
תמונות מצב בהתאמה אישית
יכול להיות שתרצו ליצור תמונת מצב בהתאמה אישית של אשכול מהסיבות הבאות:
- כדי לכלול מידע נוסף על האשכול, מעבר למה שמופיע בתמונת המצב שמוגדרת כברירת מחדל.
- כדי להחריג מידע מסוים שמופיע בתמונת המצב שמוגדרת כברירת מחדל.
יצירת תמונת מצב בהתאמה אישית
כדי ליצור קובץ snapshot בהתאמה אישית, צריך להשתמש בקובץ תצורה של קובץ snapshot. בשלבים הבאים מוסבר איך ליצור את קובץ התצורה, לשנות אותו ולהשתמש בו כדי ליצור קובץ snapshot בהתאמה אישית של אשכול:
מריצים את הפקודה הבאה באשכול וכותבים את הפלט לקובץ, כדי ליצור קובץ תצורה של קובץ snapshot:
bmctl check cluster \ --snapshot --snapshot-dry-run --cluster CLUSTER_NAME \ --kubeconfig KUBECONFIG_PATHמגדירים איזה מידע רוצים שיופיע בתמונת המצב המותאמת אישית. כדי לעשות את זה, משנים את קובץ התצורה של הסנאפשוט שיצרתם בשלב 1. לדוגמה, אם רוצים שהתמונה תכיל מידע נוסף, כמו משך הזמן שבו צומת מסוים פועל, מוסיפים את הפקודה
uptimeשל Linux לקטע הרלוונטי בקובץ התצורה.בקטע הבא של קובץ תצורה אפשר לראות איך לגרום לפקודת ה-snapshot לספק מידע מסוג
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להשתמש בתוכן של קובץ התצורה של קובץ ה-snapshot כדי להגדיר איזה מידע יופיע בקובץ ה-snapshot.
קובץ התצורה בפירוט
בקובץ התצורה לדוגמה של תמונת המצב שמוצג בהמשך, מופיעות הפקודות והקבצים הרגילים שמשמשים ליצירת תמונת מצב. עם זאת, אתם יכולים להוסיף עוד פקודות וקבצים כשאתם צריכים מידע נוסף לצורך אבחון:
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, כמו שמוצג בקובץ התצורה לדוגמה שלמעלה. אם יצירת קובצי ה-snapshot נמשכת יותר מדי זמן, צריך להגדיל את הערך הזה.
excludeWords: קובץ ה-snapshot מכיל כמות גדולה של נתונים לצומתי האשכול. כדי לצמצם את סיכוני האבטחה כשמשתפים את תמונת המצב, כדאי להשתמש ב-excludeWords. לדוגמה, אפשר להחריג אתpasswordכדי שלא יהיה אפשר לזהות מחרוזות סיסמה תואמות.
nodeCommands: בקטע הזה מופיעים הפרטים הבאים:
nodes: רשימה של כתובות IP של צומתי האשכול שמהם רוצים לאסוף מידע. כדי ליצור קובץ snapshot כשאין גישה לאשכול האדמין, צריך לציין לפחות כתובת IP אחת של צומת.
commands: רשימה של פקודות (וארגומנטים) להרצה בכל צומת. הפלט של כל פקודה נכלל בתמונת המצב.
nodeFiles: בקטע הזה מופיעים הפרטים הבאים:
nodes: רשימה של כתובות IP של צומתי אשכול שמהם רוצים לאסוף קבצים. כדי ליצור קובץ snapshot כשאין גישה לאשכול האדמין, צריך לציין לפחות כתובת IP אחת של צומת.
files: רשימת הקבצים שצריך לאחזר מכל צומת. כשהקבצים שצוינו נמצאים בצומת, הם נכללים בתמונת המצב.
nodeSSHKey: הנתיב לקובץ של מפתח ה-SSH. אם אין גישה לאשכול האדמין, צריך למלא את השדה הזה.
יצירת תמונות מצב כשנתקלים בשגיאות מסוימות
יכול להיות שיהיה צורך בשלבים נוספים או בפרמטרים של פקודות כדי ליצור תמונת מצב כשמתרחשים אירועים מסוימים, כמו שדרוג שנתקע.
יצירת תמונת מצב כברירת מחדל במהלך התקנות או שדרוגים שנתקעו
כשמתקינים או משדרגים אשכולות אדמין, אשכולות היברידיים או אשכולות עצמאיים, לפעמים bmctl יכול להיתקע בנקודות שבהן אפשר לראות את הפלטים הבאים:
- בהמתנה עד ש-kubeconfig של האשכול יהיה מוכן.
- בהמתנה עד שהאשכול יהיה מוכן.
- בהמתנה למאגרי הצמתים שיהיו מוכנים.
- בהמתנה להשלמת השדרוג.
אם ההתקנה או השדרוג נתקעים, אתם יכולים ליצור קובץ snapshot של אשכול באמצעות אשכול ה-bootstrap, כמו בדוגמה הבאה:
bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
--kubeconfig=WORKSPACE_DIR/.kindkubeconfig
יצירת תמונת מצב בהתאמה אישית במהלך התקנות או שדרוגים שנתקעו
כך יוצרים תמונת מצב בהתאמה אישית של אשכול כשההתקנה או השדרוג נתקעים:
מאחזרים מהארכיון קובץ תצורה של תמונת מצב של האשכול.
משנים את קובץ התצורה של תמונת המצב כך שתמונת המצב תכיל את המידע הרצוי.
כדי ליצור את קובץ ה-snapshot המותאם אישית, מריצים את הפקודה הבאה:
bmctl check cluster --snapshot --snapshot-config=SNAPSHOT_CONFIG_FILE \ --cluster=CLUSTER_NAME --kubeconfig=WORKSPACE_DIR/.kindkubeconfig
יצירת קובץ snapshot בהתאמה אישית כשאין גישה לאשכול האדמין
אם אין גישה לאשכול האדמין, אפשר ליצור קובץ snapshot בהתאמה אישית של האשכול באמצעות הפקודה הבאה:
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
...
מידע על המכונה הווירטואלית בתמונות המצב
אם אתם משתמשים בסביבת זמן הריצה של VM ב-GDC כדי ליצור ולנהל מכונות וירטואליות (VM) ב-Google Distributed Cloud, אתם יכולים לאסוף מידע רלוונטי לאבחון בתמונות מצב. תמונות מצב הן משאב קריטי לאבחון ולפתרון בעיות במכונות הווירטואליות.
אילו נתונים נאספים כברירת מחדל
כשיוצרים קובץ snapshot כברירת מחדל, הוא מכיל את המידע על VM Runtime on GDC ועל המשאבים הקשורים.
סביבת זמן הריצה של VM ב-GDC כלולה ב-Google Distributed Cloud, והמשאב המותאם אישית VMRuntime זמין באשכולות שמריצים עומסי עבודה.
גם אם לא הפעלתם את VM Runtime on GDC, קובץ ה-snapshot עדיין מכיל את תיאור ה-YAML של המשאב בהתאמה אישית VMRuntime.
אם הפעלתם את VM Runtime on GDC, קובצי ה-snapshot מכילים מידע על הסטטוס וההגדרות של המשאבים שקשורים למכונות הווירטואליות (כשהאובייקטים קיימים) באשכול. משאבים שקשורים למכונות וירטואליות כוללים אובייקטים של Kubernetes, כמו Pods, Deployments, DaemonSets ו-ConfigMaps.
אובייקטים במרחב השמות vm-system
פרטי הסטטוס וההגדרות של האובייקטים הבאים נמצאים ב-kubectlCommands/vm-system בתמונת המצב שנוצרה:
KubeVirtVirtualMachineTypeVMHighAvailabilityPolicy
אובייקטים במרחבי שמות אחרים
כשיוצרים מכונה וירטואלית (VirtualMachine), אפשר לציין את מרחב השמות. אם לא מציינים מרחב שמות, ה-VM מקבל את מרחב השמות default. שאר האובייקטים בקטע הזה, כמו VirtualMachineInstance, קשורים למרחב השמות של המכונה הווירטואלית המתאימה.
פרטי הסטטוס וההגדרות של האובייקטים הבאים נמצאים ב-kubectlCommands/VM_NAMESPACE בתמונת המצב שנוצרה. אם לא הגדרתם מרחב שמות ספציפי למכונה הווירטואלית, המידע נמצא ב-kubectlCommands/default:
VirtualMachineVirtualMachineInstanceVirtualMachineDiskGuestEnvironmentDataVirtualMachineAccessRequestVirtualMachinePasswordResetRequest
אובייקטים שלא מוגדרים במרחב שמות
האובייקטים הבאים לא נמצאים במרחב שמות, ולכן המידע התואם שלהם נמצא ישירות ב-kubectlCommands בתמונת המצב שנוצרה:
VMRuntimeDataVolumeCDIGPUAllocation
שימוש בקובץ תצורה של תמונת מצב כדי לתעד רק את פרטי המכונה הווירטואלית
אם אתם מאבחנים בעיות ספציפיות במכונות וירטואליות, אתם יכולים להשתמש בקובץ תצורה של קובץ snapshot כדי להגביל את המידע שנאסף לפרטים שקשורים למכונות וירטואליות בלבד, ולהתאים אישית את המידע שנאסף על המכונות הווירטואליות.
קובץ התצורה הבא של קובץ snapshot ממחיש איך אפשר ליצור קובץ snapshot ספציפי ל-VM. אפשר לכלול פקודות נוספות כדי לאסוף עוד מידע לתמונת המצב.
---
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
מידע נוסף על שימוש בקובצי תצורה של קובצי snapshot מופיע בקטע קובצי snapshot בהתאמה אישית במאמר הזה.
המאמרים הבאים
אם אתם צריכים עזרה נוספת, תוכלו לפנות אל Cloud Customer Care. במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על מקורות המידע לתמיכה, כולל:
- הדרישות לפתיחת בקשת תמיכה.
- כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, יומנים ומדדים.
- רכיבים נתמכים.