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

בדף הזה מוסבר איך להגדיר אשכול של Google Kubernetes Engine (GKE) כדי לשלוח מדדים שנוצרו על ידי שרת ה-API,‏ Scheduler ו-Controller Manager של Kubernetes ל-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 אי אפשר להריץ את הפקודות שבמסמך הזה.

דרישות

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

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

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

המסוף

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

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

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

    נכנסים לדף Kubernetes clusters.

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

  2. לוחצים על שם האשכול ובוחרים בכרטיסייה Observability.

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

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

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

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

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

    נכנסים לדף 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 metric name: כשמשתמשים ב-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
סוג, סוג, יחידה
משאבים במעקב
גרסת GKE נדרשת		 תיאור
תוויות
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+‎ 		המספר המקסימלי של בקשות שנמצאות כרגע בטיפול ב-apiserver הזה, לפי סוג הבקשה בשנייה האחרונה.

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) 		מספר הבקשות שממתינות כרגע בתורים של תת-המערכת 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_priority_level_seat_utilization בטא
apiserver_flowcontrol_priority_level_seat_utilization/histogram
Cumulative, Distribution, 1
prometheus_target
1.37.0-gke.3503000+‎ 		תצפיות, בסוף כל ננו-שנייה, על ניצול המושבים בכל שלב של הביצוע (אבל רק בשלב הראשוני של WATCHes).

phase (תווית קבועה עם הערך executing)
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_longrunning_requests GA
apiserver_longrunning_requests/gauge
Gauge, Double, 1
prometheus_target
1.37.0-gke.3503000+‎ 		מדידה של כל הבקשות הפעילות ל-apiserver שפועלות לאורך זמן, בחלוקה לפי verb,‏ group,‏ version,‏ resource,‏ scope ו-component. לא כל הבקשות נשלחות בדרך הזו.

component
group
resource
scope
subresource
verb
version
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_resource_size_estimate_bytes בטא
apiserver_resource_size_estimate_bytes/gauge
Gauge, Double, 1
prometheus_target
1.37.1-gke.2079000+‎ 		הגודל המשוער של האובייקטים שמאוחסנים במסד הנתונים. האומדן מבוסס על סכום הגדלים האחרונים שנצפו של אובייקטים שעברו סריאליזציה.

group
resource
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_events_sizes בטא
apiserver_watch_events_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.37.0-gke.3503000+‎ 		התפלגות גודל אירועי הצפייה בבייטים.

group
resource
version
apiserver_watch_events_total בטא
apiserver_watch_events_total/counter
Cumulative, Double, 1
prometheus_target
1.37.0-gke.3503000+‎ 		מספר האירועים שנשלחו בלקוחות צפייה.

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

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

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

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

מדדי תזמון

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

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

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

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

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

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+‎ 		מספר הניסיונות לתזמן Pods, לפי התוצאה. ‫'unschedulable' פירושו שלא ניתן היה לתזמן pod, ו-'error' פירושו בעיה פנימית בתזמון.

profile
result

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

scheduler_pending_pods

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

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

  • הוגדרה מגבלת זמן אחת (unschedulable)

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

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

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

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

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

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

scheduler_scheduling_attempt_duration_seconds

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

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

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

scheduler_schedule_attempts_total

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

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

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

scheduler_preemption_attempts_total וגם scheduler_preemptions_victims

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

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

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

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

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

מעקב אחרי המתזמן

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

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

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

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

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

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

    • מספר ה-Pod-ים בהמתנה גדל. כדי לעקוב אחרי מספר הפודים בהמתנה, משתמשים במדד 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"}

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

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

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

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

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

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

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

מדדים של Controller Manager

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

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

שם המדד ב-PromQL שלב ההשקה
שם המדד ב-Cloud Monitoring
סוג, סוג, יחידה
משאבים במעקב
גרסת GKE נדרשת		 תיאור
תוויות
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24+‎ 		מספר פינויי הצמתים שהתרחשו מאז שהמופע הנוכחי של NodeController התחיל.

zone

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