מעקב אחרי מדדי זמן האחזור של ההפעלה

בדף הזה מתוארים המדדים ולוחות הבקרה שזמינים למעקב אחרי זמן האחזור של הפעלת עומסי עבודה (workload) ב-Google Kubernetes Engine ‏(GKE) וצמתי האשכול הבסיסיים. אפשר להשתמש במדדים כדי לעקוב אחרי זמן האחזור של ההפעלה, לפתור בעיות ולצמצם אותו.

הדף הזה מיועד לאדמינים ולמפעילים של פלטפורמות שצריכים לעקוב אחרי זמן האחזור של ההפעלה של עומסי העבודה שלהם ולבצע אופטימיזציה שלו. מידע נוסף על תפקידים נפוצים שאנחנו מתייחסים אליהם בתוכן של Cloud de Confiance by S3NS זמין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE.

סקירה כללית

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

לאופטימיזציה של זמן האחזור של הפעלת עומס העבודה יש את היתרונות הבאים:

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

לפני שמתחילים

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

• מפעילים את Cloud Logging API ואת Cloud Monitoring API.

  תפקידים שנדרשים להפעלת ממשקי API

  כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של שימוש בשירות' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

  הפעלת ממשקי ה-API

דרישות

כדי להציג מדדים ולוחות בקרה לגבי זמן האחזור של הפעלת עומסי עבודה, אשכול GKE צריך לעמוד בדרישות הבאות:

• צריכה להיות לכם GKE בגרסה ‎1.31.1-gke.1678000 ואילך.
• צריך להגדיר איסוף של מדדי מערכת.
• צריך להגדיר איסוף של יומני מערכת.
• כדי לראות את המדדים של ה-Pod והקונטיינר, מפעילים את kube state metrics באמצעות הרכיב POD באשכולות.

תפקידים והרשאות נדרשים

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

• צפייה באשכולות, בצמתים ובעומסי עבודה של GKE: Kubernetes Engine Viewer (roles/container.viewer) בפרויקט
• גישה למדדי זמן האחזור של ההפעלה והצגת מרכזי הבקרה: Monitoring Viewer (roles/monitoring.viewer) בפרויקט
• יומני גישה עם מידע על זמן האחזור, כמו אירועי משיכת תמונות של Kubelet, וצפייה בהם בכלי Logs Explorer וב-Observability Analytics: Logs Viewer (roles/logging.viewer) בפרויקט

להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.

מדדים של זמן הטעינה של הפעלה מההתחלה

מדדי זמן האחזור של ההפעלה כלולים במדדי המערכת של GKE ומיוצאים ל-Cloud Monitoring באותו פרויקט כמו אשכול GKE.

לשמות המדדים ב-Cloud Monitoring שמופיעים בטבלה הזו צריך להוסיף את הקידומת kubernetes.io/. התחילית הזו הושמטה מהערכים בטבלה.

הצגת מרכז הבקרה של זמן האחזור בהפעלה של עומסי עבודה

לוח הבקרה Startup Latency לעומסי עבודה זמין רק לפריסות. כדי לראות את מדדי זמן האחזור של הפעלת פריסות, מבצעים את השלבים הבאים במסוף Cloud de Confiance :

1. עוברים לדף Workloads.

   כניסה לדף Workloads

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

3. לוחצים על הכרטיסייה Observability (יכולת תצפית).

4. בתפריט שמימין, בוחרים באפשרות זמן האחזור של ההפעלה.

הצגת ההתפלגות של זמן הטעינה אחרי הפעלה של Pods

זמן האחזור של הפעלת ה-Pods מתייחס לזמן האחזור הכולל של ההפעלה, כולל משיכת תמונות, והוא נמדד מהסטטוס Created של ה-Pod עד לסטטוס Ready. כדי להעריך את זמן האחזור של הפעלת ה-Pods, אפשר להשתמש בשני התרשימים הבאים:

• תרשים Pod Startup Latency Distribution: בתרשים הזה מוצגים אחוזוני חביון ההפעלה של ה-Pods (האחוזון ה-50, ה-95 וה-99) שמחושבים על סמך התצפיות של אירועי הפעלת ה-Pod במרווחי זמן קבועים של 3 שעות, למשל, 00:00 עד 03:00 ו-03:00 עד 06:00. אפשר להשתמש בתרשים הזה למטרות הבאות:

  • הסבר על זמן האחזור הבסיסי של הפעלת ה-Pod.
  • לזהות שינויים בחביון של הפעלת Pod לאורך זמן.
  • אפשר לקשר בין שינויים בחביון של הפעלת Pod לבין אירועים מהזמן האחרון, כמו פריסות של עומסי עבודה או אירועים של Cluster Autoscaler. אפשר לבחור את האירועים ברשימה הערות בחלק העליון של לוח הבקרה.

• תרשים Pod Startup Count: בתרשים הזה מוצג מספר ה-Pods שהופעלו במרווחי הזמן שנבחרו. אפשר להשתמש בתרשים הזה למטרות הבאות:

  • הסבר על גדלי הדגימות של ה-Pod שמשמשים לחישוב האחוזונים של התפלגות זמן האחזור של הפעלת ה-Pod במרווח זמן נתון.
  • הסבר על הסיבות להפעלת קבוצות Pod, כמו פריסות של עומסי עבודה או אירועים של Horizontal Pod Autoscaler. אפשר לבחור את האירועים ברשימה הערות בחלק העליון של לוח הבקרה.

הצגת זמן ההמתנה לתגובה של הפעלת Pods ספציפיים

אפשר לראות את זמן האחזור של הפעלת כל אחד מה-Pods בתרשים ציר הזמן Pod First Ready Latency וברשימה שמשויכת אליו.

• אפשר להשתמש בתרשים ציר הזמן Pod First Ready Latency כדי ליצור קורלציה בין הפעלות של Pod ספציפי לבין אירועים מהזמן האחרון, כמו אירועים של Horizontal Pod Autoscaler או Cluster Autoscaler. אפשר לבחור את האירועים האלה ברשימה הערות בחלק העליון של לוח הבקרה. התרשים הזה עוזר לכם לקבוע את הגורמים האפשריים לשינויים בחביון ההפעלה בהשוואה ל-Pods אחרים.
• אפשר להשתמש ברשימה Pod First Ready Latency כדי לזהות Pods ספציפיים שההפעלה שלהם ארכה הכי הרבה זמן או הכי מעט זמן. אפשר למיין את הרשימה לפי העמודה זמן האחזור. כשמזהים Pods עם זמן האחזור הכי גבוה של ההפעלה, אפשר לפתור בעיות שקשורות לירידה בביצועים של זמן האחזור על ידי שילוב של אירועי ההפעלה של ה-Pod עם אירועים עדכניים אחרים.

כדי לגלות מתי נוצר פוד מסוים, אפשר לבדוק את הערך בשדה timestamp באירוע יצירת הפוד המתאים. כדי לראות את השדה timestamp, מריצים את השאילתה הבאה ב-Logs Explorer:

   log_id("cloudaudit.googleapis.com/activity") AND
   protoPayload.methodName="io.k8s.core.v1.pods.create" AND
   resource.labels.project_id=PROJECT_ID AND
   resource.labels.cluster_name=CLUSTER_NAME AND
   resource.labels.location=CLUSTER_LOCATION AND
   protoPayload.response.metadata.namespace=NAMESPACE AND
   protoPayload.response.metadata.name=POD_NAME

כדי להציג ברשימה את כל אירועי יצירת ה-Pod עבור עומס העבודה, משתמשים במסנן הבא בשאילתה הקודמת: protoPayload.response.metadata.name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"

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

קביעת זמן האחזור של תזמון ה-Pod

החביון של תזמון הפוד הוא משך הזמן שחלף בין יצירת הפוד לבין התזמון שלו בצומת. השהיית התזמון של ה-Pod משפיעה על משך הזמן הכולל של הפעלת ה-Pod, והיא מחושבת על ידי חיסור חותמות הזמן של אירוע תזמון של ה-Pod ובקשה ליצירת ה-Pod.

אפשר למצוא חותמת זמן של אירוע ספציפי לתזמון פוד בשדה jsonPayload.eventTime של אירוע תואם לתזמון פוד. כדי לראות את השדה jsonPayload.eventTime, מריצים את השאילתה הבאה ב-Logs Explorer:

  log_id("events")
  jsonPayload.reason="Scheduled"
  resource.type="k8s_pod"
  resource.labels.project_id=PROJECT_ID
  resource.labels.location=CLUSTER_LOCATION
  resource.labels.cluster_name=CLUSTER_NAME
  resource.labels.namespace_name=NAMESPACE
  resource.labels.pod_name=POD_NAME

כדי להציג את כל האירועים של תזמון ה-Pod עבור עומס העבודה, משתמשים במסנן הבא בשאילתה הקודמת: resource.labels.pod_name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"

צפייה בזמן האחזור של שליפת תמונה

השהיית המשיכה של קובץ האימג' של הקונטיינר תורמת להשהיית ההפעלה של ה-Pod בתרחישים שבהם קובץ האימג' עדיין לא זמין בצומת או שצריך לרענן את קובץ האימג'. כשמבצעים אופטימיזציה של זמן האחזור של שליפת תמונות, מקטינים את זמן האחזור של הפעלת עומס העבודה במהלך אירועים של הרחבת קנה מידה של אשכול.

אפשר לעיין בטבלה Kubelet Image Pull Events כדי לראות מתי נמשכו תמונות הקונטיינר של עומס העבודה וכמה זמן נמשך התהליך.

זמן האחזור של משיכת התמונה זמין בשדה jsonPayload.message, שמכיל הודעה כמו זו שמופיעה בהמשך:

  "Successfully pulled image "gcr.io/example-project/image-name" in 17.093s (33.051s including waiting). Image size: 206980012 bytes."

צפייה בהתפלגות זמן האחזור של המלצות לשינוי גודל של HPA

החביון של המלצות לשינוי גודל של Horizontal Pod Autoscaler‏ (HPA) עבור יעד ה-HPA הוא משך הזמן שחלף בין יצירת המדדים לבין היישום של ההמלצה המתאימה לשינוי גודל בשרת ה-API. כשמבצעים אופטימיזציה של זמן האחזור של המלצות על שינוי גודל של HPA, מקטינים את זמן האחזור של הפעלת עומס העבודה במהלך אירועי הרחבה.

אפשר לראות את שינוי הגודל של HPA בשני התרשימים הבאים:

• תרשים HPA Scaling Recommendation Latency Distribution: התרשים הזה מציג את האחוזונים של חביון ההמלצות לשינוי גודל של HPA (האחוזון ה-50, האחוזון ה-95 והאחוזון ה-99) שמחושבים על סמך התצפיות של ההמלצות לשינוי גודל של HPA במרווחי זמן של 3 שעות. אפשר להשתמש בתרשים הזה למטרות הבאות:

  • להבין את זמן האחזור של ההמלצה לגבי שינוי גודל של HPA.
  • לזהות שינויים בחביון של המלצות לגבי שינוי גודל של HPA לאורך זמן.
  • מבצעים קורלציה בין השינויים בחביון של המלצות לגבי שינוי גודל של HPA לבין אירועים מהזמן האחרון. אפשר לבחור את האירועים ברשימה הערות בחלק העליון של מרכז הבקרה.

• תרשים HPA Scaling Recommendation Count: בתרשים הזה מוצג מספר ההמלצות לשינוי גודל של HPA שנצפו במהלך מרווח הזמן שנבחר. אפשר להשתמש בתרשים כדי לבצע את המשימות הבאות:

  • הסבר על גודלי המדגם של ההמלצות לשינוי גודל של HPA. הדגימות משמשות לחישוב האחוזונים בהתפלגות של זמן האחזור בהמלצות לשינוי גודל של HPA במרווח זמן נתון.
  • אפשר לקשר בין המלצות לשינוי גודל של HPA לבין אירועים חדשים של הפעלת Pod ואירועים של Horizontal Pod Autoscaler. אפשר לבחור את האירועים ברשימה הערות בחלק העליון של לוח הבקרה.

הצגת בעיות בתזמון של Pods

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

אלה שני התרשימים שזמינים למעקב אחרי בעיות כאלה:

• בתרשים Unschedulable/Pending/Failed Pods מוצגים המספרים של Pods שלא ניתן לתזמן, Pods בהמתנה ו-Pods שנכשלו לאורך זמן.
• בתרשים Backoff/Waiting/Readiness Failed Containers מוצגים המספרים של מאגרי התגים במצבים האלה לאורך זמן.

הצגת לוח הבקרה של זמן ההמתנה לתגובה של אתחול הצמתים

כדי לראות את מדדי זמן האחזור של הפעלת הצמתים, מבצעים את השלבים הבאים במסוףCloud de Confiance :

1. עוברים לדף Kubernetes Clusters.

   מעבר אל Kubernetes Clusters

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

3. לוחצים על הכרטיסייה Observability (יכולת תצפית).

4. בתפריט הימני, בוחרים באפשרות זמן האחזור של ההפעלה.

הצגת ההתפלגות של זמן הטעינה אחרי הפעלה של הצמתים

זמן האחזור של הפעלת צומת מתייחס לזמן האחזור הכולל של ההפעלה, שמודד את הזמן מ-CreationTimestamp של הצומת עד לסטטוס Kubernetes node ready. אפשר לראות את זמן האחזור של הפעלת הצומת בשני התרשימים הבאים:

• תרשים Node Startup Latency Distribution: בתרשים הזה מוצגים האחוזונים של זמן האחזור של הפעלת הצומת (האחוזון ה-50, האחוזון ה-95 והאחוזון ה-99) שמחושבים על סמך התצפיות של אירועי הפעלת הצומת במרווחי זמן קבועים של 3 שעות, לדוגמה, 00:00 עד 03:00 ו-03:00 עד 06:00. אפשר להשתמש בתרשים הזה למטרות הבאות:

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

• תרשים Node Startup Count: בתרשים הזה מוצג מספר הצמתים שהופעלו במרווחי הזמן שנבחרו. אפשר להשתמש בתרשים למטרות הבאות:

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

הצגת זמן ההמתנה לתגובה של כל צומת בנפרד

כשמשווים בין זמני האחזור של צמתים נפרדים, אפשר לבדוק את ההשפעה של הגדרות שונות של צמתים על זמן האחזור של הפעלת הצומת, ולזהות הגדרה אופטימלית על סמך הדרישות שלכם. אפשר לראות את זמן האחזור של הפעלת הצמתים של צמתים ספציפיים בתרשים ציר הזמן Node Startup Latency וברשימה שמשויכת אליו.

• אפשר להשתמש בתרשים ציר הזמן Node Startup Latency כדי ליצור קורלציה בין הפעלות של צמתים בודדים לבין אירועים מהזמן האחרון, כמו Cluster Updates או Node Pool Updates. אפשר לקבוע את הסיבות האפשריות לשינויים בזמן האחזור של ההפעלה בהשוואה לצמתים אחרים. אפשר לבחור את האירועים ברשימה הערות בחלק העליון של מרכז הבקרה.

• משתמשים ברשימה Node Startup Latency כדי לזהות צמתים נפרדים שההפעלה שלהם ארכה הכי הרבה זמן או הכי מעט זמן. אפשר למיין את הרשימה לפי העמודה זמן האחזור. כשמזהים צמתים עם זמן האחזור הכי גבוה של תהליך ההפעלה, אפשר לפתור בעיות שקשורות לירידה בביצועים של זמן האחזור על ידי שיוך של אירועי הפעלה של צמתים לאירועים אחרים מהזמן האחרון.

כדי לדעת מתי נוצר צומת מסוים, אפשר לבדוק את הערך של השדה protoPayload.metadata.creationTimestamp באירוע המתאים של יצירת צומת. כדי לראות את השדה protoPayload.metadata.creationTimestamp, מריצים את השאילתה הבאה ב-Logs Explorer:

   log_id("cloudaudit.googleapis.com/activity") AND
   protoPayload.methodName="io.k8s.core.v1.nodes.create" AND
   resource.labels.project_id=PROJECT_ID AND
   resource.labels.cluster_name=CLUSTER_NAME AND
   resource.labels.location=CLUSTER_LOCATION AND
   protoPayload.response.metadata.name=NODE_NAME

הצגת זמן האחזור של ההפעלה במאגר צמתים

אם יש לכם מאגרי צמתים עם הגדרות שונות, למשל כדי להריץ עומסי עבודה שונים, יכול להיות שתצטרכו לעקוב אחרי זמן האחזור של הפעלת הצמתים בנפרד לפי מאגרי הצמתים. כשמשווים את זמני האחזור של הפעלת הצמתים במאגרי הצמתים, אפשר לקבל תובנות לגבי ההשפעה של הגדרת הצמתים על זמני האחזור של הפעלת הצמתים, וכתוצאה מכך לייעל את זמני האחזור.

כברירת מחדל, בלוח הבקרה Node Startup Latency מוצגת ההתפלגות המצטברת של זמן הטעינה אחרי הפעלה וזמני הטעינה אחרי הפעלה של כל צומת בנפרד בכל מאגרי הצמתים באשכול. כדי לראות את זמן האחזור של הפעלת צומת עבור מאגר צמתים ספציפי, בוחרים את השם של מאגר הצמתים באמצעות המסנן $node_pool_name_var שנמצא בחלק העליון של לוח הבקרה.

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

• איך מאיצים את הפעלת האפליקציה באמצעות הגברת מהירות ההפעלה של המעבד
• איך מבצעים אופטימיזציה של שינוי גודל אוטומטי של Pod על סמך מדדים
• מידע נוסף על דרכים לצמצום זמן האחזור של הפעלה במצב התחלתי ב-GKE
• כאן מוסבר איך להקטין את זמן האחזור של שליפת תמונות באמצעות סטרימינג של תמונות.
• מידע נוסף על הכלכלה המפתיעה של כוונון של שינוי גודל אוטומטי של Pods באופן אופקי
• אפשר לעקוב אחרי עומסי העבודה באמצעות מעקב אוטומטי אחרי אפליקציות.