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

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

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

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

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

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

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

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

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

gcloud

מעדכנים את האשכול כדי לאסוף מדדים שנשלחים על ידי שרת ה-API,‏ Scheduler ו-Controller Manager של 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 ל-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 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) 		מספר הבקשות שממתינות כרגע בתורים של תת-המערכת API Priority and Fairness.

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

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

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

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

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

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

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 מצפים לו לכל pod, יחד עם יחידת המשאב, אם יש כזו.

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) של pod שמתזמנים, שיכול לכלול כמה ניסיונות תזמון.

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

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

  • סט אחד (unschedulable)

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

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

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

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

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

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

scheduler_scheduling_attempt_duration_seconds

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

המדד הזה לא מתעד את הזמן שבו ה-pod נמצא בבקרת הגישה או באימות.

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

scheduler_schedule_attempts_total

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

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

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

scheduler_preemption_attempts_total וגם scheduler_preemptions_victims

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

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

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

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

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

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

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

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

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

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

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

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

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

  • מוודאים שהצמתים לא מבודדים. צמתים מבודדים לא מקבלים 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

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