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

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

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

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

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

דרישות

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

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

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

המסוף

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

כדי להפעיל מדדים של מישור הבקרה מהכרטיסייה 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, לוחצים על סמל Edit.

  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 ב google_container_cluster במאגר Terraform. מידע כללי על שימוש ב- Google Cloud עם Terraform זמין במאמר Terraform עם Google Cloud.

מכסה

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

תמחור

מדדים של מישור הבקרה של GKE משתמשים בשירות המנוהל של Google Cloud ל-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_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
‫1.22.13+ 		המספר המקסימלי של בקשות בטיסה שנעשה בהן שימוש כרגע במגבלת ה-apiserver הזה לכל סוג בקשה בשנייה האחרונה.

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

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_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
‫1.22.13+ 		מספר האובייקטים המאוחסנים בזמן הבדיקה האחרונה, מחולק לפי סוג.

resource
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

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

apiserver_request_duration_seconds

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

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

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

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

apiserver_admission_controller_admission_duration_seconds

המדד הזה מודד את זמן האחזור של ווּבקוקים מובנים של אישור, ולא של ווּבקוקים של צד שלישי. כדי לאבחן בעיות של זמן אחזור ב-Webhook של צד שלישי, משתמשים במדד 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

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

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

מעקב אחרי שרת ה-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 עולה, סימן שחלק מה-webhook של צד שלישי או של משתמשים שמוגדרים על ידיכם פועלים לאט או לא מגיבים. זמן האחזור של ה-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 יתארך ככל שמספר האובייקטים מסוג מסוים (גודל התגובה) יגדל.

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

    • יכול להיות שללקוח אין מספיק משאבים כדי לקבל תשובות בזמן. כדי לבדוק, מסתכלים על מדדי השימוש במעבד של ה-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.] השהיה מקצה לקצה של תרמיל שמתוזמן, שעשויה לכלול ניסיונות תזמון מרובים.

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
    • הקבוצה של הפודים לא הייתה ניתנת לתזמון בפעם האחרונה שהמתזמן ניסה, אבל יכול להיות שהיא תהיה ניתנת לתזמון בפעם הבאה.
    • הפודים בתור הזה צריכים להמתין לתקופת השהיה לפני ניסיון חוזר (backoff) (עד 10 שניות), ואז הם מועברים חזרה לתור activeלניסיון תזמון נוסף. מידע נוסף על ניהול התור backoff זמין בבקשת ההטמעה, Kubernetes issue 75417.

  • unschedulable הגדרה

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

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

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

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

    • חלק מהאירועים, למשל 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 עוקב אחרי מספר הפעמים שמתזמן המשימות ניסה להקצות מראש תאי Pod.

המדד scheduler_preemptions_victims סופר את הפודים שנבחרו להפסקה זמנית.

מספר ניסיונות ההפסקה הזמנית קשור באופן הדוק לערך של מדד 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. אם גם מספר הפודים בהמתנה עולה, יכול להיות שאין לכם מספיק משאבים כדי לטפל בפודים עם העדיפות הגבוהה יותר. במקרה כזה, יכול להיות שתצטרכו להגדיל את המשאבים הזמינים, ליצור פודים חדשים עם דרישות משאבים מופחתות או לשנות את בורר הצמתים.

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

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

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

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

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

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

מדדים של 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