איסוף והצגה של מדדים של מישור הבקרה

בדף הזה מוסבר איך להגדיר אשכול Google Kubernetes Engine‏ (GKE) כדי לשלוח מדדים שמופקים על ידי שרת ה-API של Kubernetes,‏ Scheduler ו-Controller Manager אל Cloud Monitoring באמצעות השירות המנוהל של Google Cloud ל-Prometheus. בדף הזה מוסבר גם איך המדדים האלה מעוצבים כשהם נכתבים ב-Monitoring, ואיך לשלוח שאילתות לגבי מדדים.

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

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

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

דרישות

כדי לשלוח מדדים שנפלטים מרכיבי מישור הבקרה של Kubernetes אל Cloud Monitoring, צריך לעמוד בדרישות הבאות:

הגדרת איסוף של מדדים ממישור הבקרה

אפשר להפעיל מדדים של מישור הבקרה באשכול GKE קיים באמצעות מסוף Google Cloud , CLI של gcloud או Terraform.

המסוף

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

כדי להפעיל מדדים של מישור הבקרה מהכרטיסייה Observability (יכולת צפייה) עבור האשכול:

  1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .

    כניסה אל Kubernetes clusters

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Kubernetes Engine.

  2. לוחצים על שם האשכול ואז על הכרטיסייה Observability (יכולת תצפית).

  3. בוחרים באפשרות Control Plane מתוך רשימת התכונות.

  4. לוחצים על הפעלת החבילה.

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

כדי להפעיל מדדים של מישור הבקרה מהכרטיסייה פרטים של האשכול: פועלים לפי השלבים הבאים:

  1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .

    כניסה אל Kubernetes clusters

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Kubernetes Engine.

  2. לוחצים על שם האשכול.

  3. בשורה Features (תכונות) עם התווית Cloud Monitoring, לוחצים על סמל העריכה.

  4. בתיבת הדו-שיח Edit Cloud Monitoring שמופיעה, מוודאים שהאפשרות Enable Cloud Monitoring מסומנת.

  5. בתפריט הנפתח Components, בוחרים את רכיבי מישור הבקרה שמהם רוצים לאסוף מדדים: API Server,‏ Scheduler או Controller Manager.

  6. לוחצים על OK.

  7. לוחצים על שמירת השינויים.

gcloud

מעדכנים את האשכול כדי לאסוף מדדים שמופקים משרת ה-API של Kubernetes, מהמתזמן וממנהל הבקרה:

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

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

Terraform

כדי להגדיר את איסוף המדדים של מישור הבקרה של Kubernetes באמצעות Terraform, אפשר לעיין בבלוק monitoring_config ב מאגר Terraform עבור google_container_cluster. מידע כללי על שימוש ב- Google Cloud עם Terraform זמין במאמר Terraform עם Google Cloud.

מכסה

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

תמחור

מדדים של מישור הבקרה של GKE משתמשים ב-Google Cloud Managed Service for Prometheus כדי לטעון מדדים ל-Cloud Monitoring. החיובים על הטמעת המדדים האלה ב-Cloud Monitoring מבוססים על מספר הדגימות שהוטמעו.

מידע נוסף זמין במאמר בנושא תמחור של Cloud Monitoring.

פורמט המדד

כל המדדים של מישור הבקרה של Kubernetes שנכתבים ל-Cloud Monitoring משתמשים בסוג המשאב prometheus_target. לכל שם של מדד יש קידומת prometheus.googleapis.com/ וסיומת שמציינת את סוג המדד של Prometheus, כמו /gauge,‏ /histogram או /counter. אחרת, כל שם של מדד זהה לשם המדד שמוצג על ידי Kubernetes בקוד פתוח.

ייצוא מ-Cloud Monitoring

אפשר לייצא את מדדי רמת הבקרה של Kubernetes מ-Cloud Monitoring באמצעות Cloud Monitoring API. מכיוון שכל המדדים של רמת הבקרה של Kubernetes מוזנים באמצעות השירות המנוהל של Google Cloud ל-Prometheus, אפשר לשלוח שאילתות על המדדים של רמת הבקרה של Kubernetes באמצעות שפת השאילתות של Prometheus‏ (PromQL). אפשר גם לשלוח שאילתות לגביהם באמצעות שפת שאילתת מעקב (MQL).

שאילתות לגבי מדדים

כששולחים שאילתות על מדדים של רמת הבקרה של Kubernetes, השם שבו משתמשים תלוי אם משתמשים ב-PromQL או בתכונות שמבוססות על Cloud Monitoring, כמו MQL או Metrics Explorer ממשק מבוסס-תפריט.

בטבלאות הבאות של מדדי מישור הבקרה של Kubernetes מוצגות שתי גרסאות של כל שם מדד:

  • שם המדד ב-PromQL: כשמשתמשים ב-PromQL בדפי Cloud Monitoring במסוף Google Cloud או בשדות PromQL ב-Cloud Monitoring API, צריך להשתמש בשם המדד ב-PromQL.
  • שם המדד ב-Cloud Monitoring כשמשתמשים בתכונות אחרות של Cloud Monitoring, צריך להשתמש בשם המדד ב-Cloud Monitoring שמופיע בטבלאות שבהמשך. לפני השם הזה צריך להוסיף את הקידומת prometheus.googleapis.com/, שלא מופיעה ברשומות שבטבלה.

מדדים של שרת API

בקטע הזה מופיעה רשימה של מדדי שרת ה-API ומידע נוסף על פירוש המדדים והשימוש בהם.

רשימת מדדים של שרת API

כשמדדי שרת ה-API מופעלים, כל המדדים שמוצגים בטבלה הבאה מיוצאים אל Cloud Monitoring באותו פרויקט כמו אשכול GKE.

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

שם המדד ב-PromQL שלב ההשקה
שם המדד ב-Cloud Monitoring
‫Kind, Type, Unit
Monitored resources
Required GKE version		 תיאור
תוויות
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
‫1.23.6+ 		היסטוגרמה של זמן האחזור של בקר הכניסה בשניות, מזוהה לפי שם ומפורטת לכל פעולה, משאב API וסוג (אימות או אישור).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		היסטוגרמה של זמן האחזור של שלב המשנה של ההרשאה בשניות, עם פירוט לכל פעולה, משאב API וסוג שלב (אימות או הרשאה).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		היסטוגרמה של זמן האחזור של webhook של הרשאה בכניסה בשניות, מזוהה לפי שם ומפורטת לכל פעולה, משאב API וסוג (אימות או הרשאה).

name
operation
rejected
type
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		המספר המקסימלי של בקשות בטיפול שנעשה בהן שימוש כרגע במגבלת הבקשות של שרת ה-API הזה לכל סוג בקשה בשנייה האחרונה.

request_kind
apiserver_flowcontrol_current_executing_seats בטא
apiserver_flowcontrol_current_executing_seats/gauge
‫Gauge, Double, 1
prometheus_target
1.28.3+ 		מקביליות (מספר המושבים) שתפוסים על ידי הבקשות שמופעלות כרגע (השלב הראשוני של בקשת WATCH, כל שלב אחר בכל מקרה אחר) במערכת המשנה של עדיפות והוגנות של ה-API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests בטא
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
‫1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ for prior minor versions) 		מספר הבקשות שממתינות כרגע בתורים של מערכת המשנה Priority and Fairness של ה-API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats בטא
apiserver_flowcontrol_nominal_limit_seats/gauge
‫Gauge, Double, 1
prometheus_target ‫
1.28.3+ (1.26.11+, 1.27.8+ for prior minor versions) 		מספר המושבים הנומינלי להרצה שמוגדר לכל רמת עדיפות.

priority_level
apiserver_flowcontrol_rejected_requests_total בטא
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
‫1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ for prior minor versions) 		מספר הבקשות שנדחו על ידי מערכת המשנה API Priority and Fairness.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds בטא
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
‫1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ for prior minor versions) 		משך הזמן שהבקשה המתינה בתור.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
‫1.23.6+ 		התפלגות זמן האחזור של התגובה בשניות לכל פועל, ערך הרצת ניסיון, קבוצה, גרסה, משאב, משאב משנה, היקף ורכיב.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		מונה של בקשות ל-apiserver, עם פירוט של כל פועל, ערך של הרצה יבשה, קבוצה, גרסה, משאב, היקף, רכיב וקוד תגובת HTTP.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		התפלגות גודל התשובה בבייטים לכל קבוצה, גרסה, פועל, משאב, משאב משני, היקף ורכיב.

component
group
resource
scope
subresource
verb
version
apiserver_storage_events_received_total בטא
apiserver_storage_events_received_total/counter
Cumulative, Int64, 1
prometheus_target
1.36.0-gke.1759000+ 		מספר האירועים של etcd שהתקבלו, מחולק לפי סוג.

group
resource
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		מספר האובייקטים המאוחסנים בזמן הבדיקה האחרונה, מחולק לפי סוג.

resource
apiserver_storage_size_bytes GA
apiserver_storage_size_bytes/gauge
Gauge, Int64, By
prometheus_target
1.36.0-gke.1759000+ 		הגודל של קובץ מסד הנתונים של האחסון שהוקצה פיזית בבייטים.

storage_cluster_id
apiserver_watch_list_duration_seconds בטא
apiserver_watch_list_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.36.0-gke.1759000+ 		התפלגות חביון התגובה בשניות לבקשות של רשימת המעקב, לפי קבוצה, גרסה, משאב והיקף.

group
resource
scope
version

בקטעים הבאים מוסבר בהרחבה על מדדי שרת ה-API.

apiserver_request_duration_seconds

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

  • האימות וההרשאה של הבקשה.
  • מתקשרים אל ה-webhook של הצד השלישי ואל ה-webhook של המערכת שמשויכים לבקשה.
  • שליפת האובייקט המבוקש ממטמון בזיכרון (עבור בקשות שמציינות פרמטר של כתובת URL resourceVersion) או ממסד הנתונים של מצב האשכול מבוסס etcd או Spanner על ידי קריאה ל-API‏ etcd (עבור כל הבקשות האחרות).
  • אתם יכולים להשתמש בתוויות group,‏ version,‏ resource ו-subresource כדי לזהות באופן ייחודי בקשה איטית לצורך בדיקה נוספת.
  • לכתוב את התגובה ללקוח ולקבל את התגובה שלו.

מידע נוסף על השימוש במדד הזה זמין במאמר זמן אחזור.

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

apiserver_admission_controller_admission_duration_seconds

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

‫apiserver_admission_webhook_admission_duration_seconds ו-
apiserver_admission_step_admission_duration_seconds

המדדים האלה מודדים את זמן האחזור ב-webhooks חיצוניים של צד שלישי לצירוף משתמשים. בדרך כלל המדד apiserver_admission_webhook_admission_duration_seconds שימושי יותר. מידע נוסף על השימוש במדד הזה זמין במאמר בנושא זמן אחזור.

apiserver_request_total

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

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

apiserver_storage_objects

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

apiserver_current_inflight_requests

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

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

מעקב אחרי שרת ה-API

מדדי שרת ה-API יכולים לספק לכם תובנות לגבי האותות העיקריים של תקינות המערכת:

בקטע הזה מוסבר איך להשתמש במדדים של שרת ה-API כדי לעקוב אחרי תקינות שרת ה-API.

זמן אחזור

כששרת ה-API עמוס מדי, זמן האחזור של הבקשות מתארך. כדי למדוד את זמן האחזור של בקשות לשרת ה-API, משתמשים במדד apiserver_request_duration_seconds. כדי לזהות את מקור ההשהיה בצורה ספציפית יותר, אפשר לקבץ את המדדים לפי התווית verb או resource.

הגבול העליון המומלץ לקריאה של משאב יחיד, כמו GET,‏ POST או PATCH, הוא שנייה אחת. הגבול העליון המומלץ לקריאות LIST בהיקף של מרחב שמות ובהיקף של אשכול הוא 30 שניות. הציפיות לגבי הגבול העליון מוגדרות על ידי הסכמי רמת שירות (SLO) שהוגדרו על ידי קהילת הקוד הפתוח של Kubernetes. מידע נוסף זמין במאמר פרטים על מדדי רמת השירות (SLI) ויעדי רמת השירות (SLO) של זמן האחזור של קריאות ל-API.

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

  • יכול להיות שיש עומס יתר במישור הבקרה של Kubernetes. כדי לבדוק, מעיינים במדדים apiserver_request_total ו-apiserver_storage_objects.
    • אפשר להשתמש בתווית code כדי לבדוק אם הבקשות מטופלות בהצלחה. מידע על הערכים האפשריים זמין במאמר בנושא קודי סטטוס של HTTP.
    • משתמשים בתוויות group,‏ version,‏ resource ו-subresource כדי לזהות באופן ייחודי בקשה.

  • ה-webhook של צד שלישי לקבלת הרשאות איטי או לא מגיב. אם הערך של מדד apiserver_admission_webhook_admission_duration_seconds עולה, סימן שחלק מה-webhooks של צד שלישי או של משתמשים מוגדרים איטיים או לא מגיבים. זמן האחזור של ה-webhook של הגישה יכול לגרום לעיכובים בתזמון של משימות.

    • כדי לשלוח שאילתה לגבי זמן האחזור של ה-webhook באחוזון ה-99 לכל מופע של רמת הבקרה של Kubernetes, משתמשים בשאילתת PromQL הבאה:

      sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))

      מומלץ גם לבדוק את האחוזונים 50, 90, 95 ו-99.9. כדי לעשות זאת, צריך לשנות את הערך של 0.99 בשאילתה.

    • ל-Webhooks חיצוניים יש הגבלת זמן קצרה של כ-10 שניות. אפשר להגדיר מדיניות התראות במדד apiserver_admission_webhook_admission_duration_seconds כדי לקבל התראה כשמתקרבים לזמן הקצוב לתפוגה של ה-webhook.

    • אפשר גם לקבץ את המדד apiserver_admission_webhook_admission_duration_secondsname לפי התווית כדי לאבחן בעיות אפשריות ב-webhook ספציפי.

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

  • בעיות בצד הלקוח:

    • יכול להיות שללקוח אין מספיק משאבים כדי לקבל תגובות בזמן. כדי לבדוק, מסתכלים על מדדי השימוש במעבד (CPU) של ה-pod של הלקוח.
    • החיבור של הלקוח לרשת איטי. זה יכול לקרות כשהלקוח פועל במכשיר כמו טלפון נייד, אבל זה לא סביר לגבי לקוחות שפועלים ברשת Compute Engine.
    • הלקוח יצא באופן לא צפוי, אבל לחיבור ה-TCP יש תקופת זמן קצובה של עשרות שניות. לפני שהחיבור נכשל בגלל חוסר פעילות, המשאבים של השרת נחסמים, מה שיכול להגדיל את זמן האחזור.

מידע נוסף זמין במאמר שיטות מומלצות לשימוש ב-API Priority and Fairness במסמכי העזרה של Kubernetes.

תנועת גולשים ושיעור שגיאות

כדי למדוד את התנועה ואת מספר הבקשות שבוצעו בהצלחה והבקשות שנכשלו בשרת ה-API, משתמשים במדד apiserver_request_total. לדוגמה, כדי למדוד את התנועה בשרת ה-API לכל מופע של מישור הבקרה של Kubernetes, משתמשים בשאילתת PromQL הבאה:

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

  • כדי לשלוח שאילתה לגבי הבקשות שלא הצליחו, מסננים את התווית code לפי הערכים 4xx ו-5xx באמצעות שאילתת PromQL הבאה:

    sum(rate(apiserver_request_total{code=~"[45].."}[5m]))

  • כדי לשלוח שאילתה לגבי הבקשות שהצליחו, מסננים את התווית code לפי ערכי 2xx באמצעות שאילתת PromQL הבאה:

    sum(rate(apiserver_request_total{code=~"2.."}[5m]))

  • כדי לשלוח שאילתה לגבי בקשות שנדחו על ידי שרת ה-API לכל מופע של מישור הבקרה של Kubernetes, מסננים את התווית code לפי הערך 429 (http.StatusTooManyRequests) באמצעות שאילתת PromQL הבאה:

    sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))

רוויה

אפשר למדוד את רמת הרוויה במערכת באמצעות המדדים apiserver_current_inflight_requests ו-apiserver_storage_objects .

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

כדאי לבדוק את מדד apiserver_current_inflight_requests בהתאם להגדרות העדיפות וההוגנות של ה-API. ההגדרות האלה משפיעות על סדר העדיפויות של הבקשות, ולכן אי אפשר להסיק מסקנות רק מהערכים של המדד. מידע נוסף מופיע במאמר עדיפות והוגנות ב-API.

מדדים של כלי התזמון

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

רשימת מדדים של מתזמן

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

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

שם המדד ב-PromQL שלב ההשקה
שם המדד ב-Cloud Monitoring
‫Kind, Type, Unit
Monitored resources
Required GKE version		 תיאור
תוויות
kube_pod_resource_limit GA
kube_pod_resource_limit/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		מגבלת המשאבים לעומסי עבודה באשכול, עם פירוט לפי פוד. השדות האלה מציגים את השימוש במשאבים שהמתזמן ו-kubelet צופים לכל פוד עבור משאב, יחד עם יחידת המשאב, אם יש כזו.

namespace
node
pod
priority
resource
scheduler
unit
kube_pod_resource_request GA
kube_pod_resource_request/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		משאבים שנדרשים לעומסי עבודה באשכול, עם פירוט לפי Pod. השדות האלה מציגים את השימוש במשאבים שהמתזמן ו-kubelet צופים לכל פוד עבור משאב, יחד עם יחידת המשאב, אם יש כזו.

namespace
node
pod
priority
resource
scheduler
unit
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		מספר הפודים בהמתנה, לפי סוג התור. ‫'active' (פעיל) מציין את מספר הפודים ב-activeQ,‏ 'backoff' (השהיה) מציין את מספר הפודים ב-backoffQ,‏ 'unschedulable' (לא ניתן לתזמון) מציין את מספר הפודים ב-unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds יצא משימוש
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
‫1.25.1 עד 1.29 (‫1.22.17-gke.3100+,‏ 1.23.11+ ו-1.24.5+ לגרסאות משניות קודמות) 		[הוצא משימוש בגרסה 1.29; הוסר בגרסה 1.30 והוחלף ב- scheduler_pod_scheduling_sli_duration_seconds.] השהיית E2E של פוד שמתוזמן, שעשויה לכלול ניסיונות תזמון מרובים.

attempts
scheduler_pod_scheduling_sli_duration_seconds בטא
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.30+ 		השהיה מקצה לקצה של תרמיל שמתבצעת לו הקצאה, מהרגע שבו התרמיל נכנס לתור ההקצאה, ועשויה לכלול כמה ניסיונות הקצאה.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		סך כל הניסיונות להפסקת פעולה מראש באשכול עד עכשיו
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		מספר הקורבנות שנבחרו להקדמת תורים
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
‫1.23.6+ 		השהיית ניסיון התזמון בשניות (אלגוריתם התזמון + קישור).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		מספר הניסיונות לתזמן פודים, לפי התוצאה. ‫'unschedulable' פירושו שלא ניתן לתזמן פוד, ואילו 'error' פירושו בעיה פנימית במתזמן.

profile
result

בקטעים הבאים מוסבר בהרחבה על מדדי שרת ה-API.

scheduler_pending_pods

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

  • active queue
    • קבוצת הפודים שהמתזמן מנסה לתזמן. הפוד עם העדיפות הכי גבוהה נמצא בראש התור.
  • backoff queue
    • קבוצת הפודים לא הייתה ניתנת לתזמון בפעם האחרונה שהמתזמן ניסה, אבל יכול להיות שהיא תהיה ניתנת לתזמון בפעם הבאה.
    • הפודים בתור הזה צריכים להמתין לתקופת השהיה (עד 10 שניות), ואז הם מועברים חזרה לתור activeלניסיון תזמון נוסף. מידע נוסף על ניהול התור backoff זמין בבקשת ההטמעה, Kubernetes issue 75417.

  • סט אחד (unschedulable)

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

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

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

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

    • אירועים מסוימים, למשל PVC/Service ADD/UPDATE, סיום של פוד או רישום של צמתים חדשים, מעבירים חלק מהפודים שלא תוכננו או את כולם לתור backoff או active. למידע נוסף, ראו בעיה מספר 81214 ב-Kubernetes.

מידע נוסף זמין במאמרים זמן האחזור של מתזמן המשימות ובעיות במשאבים.

scheduler_scheduling_attempt_duration_seconds

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

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

מידע נוסף על תזמון זמין במאמר בנושא תזמון של Pod.

scheduler_schedule_attempts_total

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

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

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

scheduler_preemption_attempts_total וגם scheduler_preemptions_victims

אפשר להשתמש במדדי קדימות כדי להבין אם צריך להוסיף משאבים.

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

המדד scheduler_preemptions_victims סופר את ה-Pods שנבחרו להפסקת פעולה.

מספר הניסיונות לשיבוש קשור באופן הדוק לערך של מדד scheduler_schedule_attempts_total כשערך התווית result הוא unschedulable. שני הערכים לא שווים: לדוגמה, אם באשכול יש 0 צמתים, לא יהיו ניסיונות קדימות אבל יכול להיות שיהיו ניסיונות תזמון שנכשלו.

מידע נוסף מופיע במאמר בעיות במשאבים.

מעקב אחרי מתזמן הפגישות

מדדי מתזמן הפגישות יכולים לספק תובנות לגבי הביצועים של מתזמן הפגישות:

  • ‫Scheduler latency (השהיית התזמון): האם המתזמן פועל? כמה זמן לוקח לתזמן פודים?
  • בעיות במשאבים: האם ניסיונות לתזמן פודים נתקלים במגבלות משאבים?

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

זמן האחזור של מתזמן הפעולות

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

  • כדי לוודא שהמתזמן פועל ומתזמן פודים, משתמשים במדד scheduler_schedule_attempts_total.

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

    • מספר הפודים בהמתנה גדל. אפשר להשתמש במדד scheduler_pending_pods כדי לעקוב אחרי מספר הפודים בהמתנה. שאילתת PromQL הבאה מחזירה את מספר הפודים בהמתנה לכל תור באשכול:

      sum by (queue)
(delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))

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

      מומלץ לבדוק את המדד הזה לפחות באחוזון ה-50 ובאחוזון ה-95. שאילתת PromQL הבאה מאחזרת ערכים של האחוזון ה-95, אבל אפשר לשנות אותה:

      sum by (instance) (histogram_quantile(0.95, rate(
scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))

בעיות במשאבים

המדדים של הכלי לתזמון יכולים לעזור לכם להעריך אם יש לכם מספיק משאבים. אם הערך של המדד scheduler_preemption_attempts_total עולה, צריך לבדוק את הערך של scheduler_preemption_victims באמצעות שאילתת PromQL הבאה:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

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

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

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

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

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

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

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

מדדים של Controller Manager

כשמפעילים את המדדים של Controller Manager, כל המדדים שמוצגים בטבלה הבאה מיוצאים אל Cloud Monitoring באותו פרויקט כמו אשכול GKE.

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

שם המדד ב-PromQL שלב ההשקה
שם המדד ב-Cloud Monitoring
‫Kind, Type, Unit
Monitored resources
Required GKE version		 תיאור
תוויות
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24+ 		מספר ההוצאות של צמתים שקרו מאז ההפעלה הנוכחית של NodeController.

zone

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