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

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

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

סקירה כללית

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

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

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

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

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

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

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

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

  כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

  הפעלת ממשקי ה-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 לעומסי עבודה זמין רק ל-Deployments. כדי לראות את מדדי זמן האחזור של הפעלת פריסות, מבצעים את השלבים הבאים במסוף Cloud de Confiance :

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

   כניסה לדף Workloads

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

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

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

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

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

• תרשים Pod Startup Latency Distribution: בתרשים הזה מוצגים אחוזוני חביון ההפעלה של Pods (האחוזון ה-50, ה-95 וה-99) שמחושבים על סמך התצפיות של אירועי הפעלת Pods במרווחי זמן קבועים של 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 ספציפיים שההפעלה שלהם ארכה הכי הרבה זמן או הכי מעט זמן. אפשר למיין את הרשימה לפי העמודה זמן האחזור. כשמזהים אובייקטים מסוג Pod עם זמן האחזור הכי גבוה של תהליך ההפעלה, אפשר לפתור בעיות שקשורות לירידה בביצועים של זמן האחזור על ידי שיוך של אירועי ההפעלה של ה-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, והיא מחושבת על ידי חיסור חותמות הזמן של אירוע תזמון של ה-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 (אחוזון חמישים, אחוזון תשעים וחמישה ואחוזון תשעים ותשעה) שמחושבים על סמך התצפיות של המלצות לשינוי גודל של 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 שנמצא בחלק העליון של לוח הבקרה.

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

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