Mengumpulkan dan melihat metrik bidang kontrol

Halaman ini menjelaskan cara mengonfigurasi cluster Google Kubernetes Engine (GKE) untuk mengirim metrik yang dikeluarkan oleh server Kubernetes API, Penjadwal, dan Pengelola Pengontrol ke Cloud Monitoring menggunakan Google Cloud Managed Service for Prometheus. Halaman ini juga menjelaskan cara metrik ini diformat saat ditulis ke Monitoring, dan cara membuat kueri metrik.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.

Persyaratan

Mengirim metrik yang dikeluarkan oleh komponen bidang kontrol Kubernetes ke Cloud Monitoring memiliki persyaratan berikut:

Mengonfigurasi pengumpulan metrik bidang kontrol

Anda dapat mengaktifkan metrik bidang kontrol di cluster GKE yang ada menggunakan Konsol Google Cloud, gcloud CLI, atau Terraform.

Konsol

Anda dapat mengaktifkan metrik bidang kontrol untuk cluster dari tab Observability untuk cluster atau dari tab Details untuk cluster. Saat menggunakan tab Kemampuan Observasi, Anda dapat melihat pratinjau diagram dan metrik yang tersedia sebelum mengaktifkan paket metrik.

Untuk mengaktifkan metrik bidang kontrol dari tab Observability untuk cluster, lakukan tindakan berikut:

  1. Di konsol Google Cloud, buka halaman Kubernetes clusters:

    Buka Cluster Kubernetes

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Kubernetes Engine.

  2. Klik nama cluster Anda, lalu pilih tab Observability.

  3. Pilih Control Plane dari daftar fitur.

  4. Klik Aktifkan paket.

    Jika metrik bidang kontrol sudah diaktifkan, Anda akan melihat serangkaian diagram untuk metrik bidang kontrol.

Untuk mengaktifkan metrik bidang kontrol dari tab Detail untuk cluster, lakukan tindakan berikut:

  1. Di konsol Google Cloud, buka halaman Kubernetes clusters:

    Buka Cluster Kubernetes

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Kubernetes Engine.

  2. Klik nama cluster Anda.

  3. Di baris Fitur berlabel Cloud Monitoring, klik ikon Edit.

  4. Pada dialog Edit Cloud Monitoring yang muncul, pastikan Enable Cloud Monitoring dipilih.

  5. Di menu drop-down Components, pilih komponen platform kontrol yang metriknya ingin Anda kumpulkan: API Server, Scheduler, atau Controller Manager.

  6. Klik Oke.

  7. Klik Simpan Perubahan.

gcloud

Update cluster Anda untuk mengumpulkan metrik yang dikeluarkan oleh server Kubernetes API, Scheduler, dan Controller Manager:

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

Ganti kode berikut:

Terraform

Untuk mengonfigurasi pengumpulan metrik bidang kontrol Kubernetes menggunakan Terraform, lihat blok monitoring_config di registry Terraform untuk google_container_cluster. Untuk informasi umum tentang penggunaan Google Cloud dengan Terraform, lihat Terraform dengan Google Cloud.

Kuota

Metrik bidang kontrol menggunakan kuota "Permintaan penyerapan deret waktu per menit" dari Cloud Monitoring API. Sebelum mengaktifkan paket metrik, periksa penggunaan puncak terbaru kuota tersebut. Jika memiliki banyak cluster dalam project yang sama atau sudah mendekati batas kuota tersebut, Anda dapat meminta peningkatan batas kuota sebelum mengaktifkan salah satu paket observabilitas.

Harga

Metrik bidang kontrol GKE menggunakan Google Cloud Managed Service for Prometheus untuk memuat metrik ke Cloud Monitoring. Biaya Cloud Monitoring untuk penyerapan metrik ini didasarkan pada jumlah sampel yang diserap. Namun, metrik ini gratis untuk cluster terdaftar yang termasuk dalam project yang mengaktifkan edisi GKE Enterprise.

Untuk mengetahui informasi selengkapnya, lihat harga Cloud Monitoring.

Format metrik

Semua metrik panel kontrol Kubernetes Kubernetes yang ditulis ke Cloud Monitoring menggunakan jenis resource prometheus_target. Setiap nama metrik diawali dengan prometheus.googleapis.com/ dan memiliki akhiran yang menunjukkan jenis metrik Prometheus, seperti /gauge, /histogram, atau /counter. Jika tidak, setiap nama metrik akan identik dengan nama metrik yang ditampilkan oleh Kubernetes open source.

Mengekspor dari Cloud Monitoring

Metrik bidang kontrol Kubernetes dapat diekspor dari Cloud Monitoring menggunakan Cloud Monitoring API. Karena semua metrik bidang kontrol Kubernetes diserap menggunakan Google Cloud Managed Service for Prometheus, metrik bidang kontrol Kubernetes dapat dikueri menggunakan Prometheus Query Language (PromQL). Metrik ini juga dapat dikueri dengan menggunakan Monitoring Query Language (MQL).

Membuat kueri metrik

Saat Anda membuat kueri metrik bidang kontrol Kubernetes, nama yang Anda gunakan bergantung pada apakah Anda menggunakan PromQL atau fitur berbasis Cloud Monitoring seperti MQL atau antarmuka berbasis menu Metrics Explorer.

Tabel metrik bidang kontrol Kubernetes berikut menunjukkan dua versi setiap nama metrik:

  • Nama metrik PromQL: Saat menggunakan PromQL di halaman Cloud Monitoring di konsol Google Cloud atau di kolom PromQL di Cloud Monitoring API, gunakan nama metrik PromQL.
  • Nama metrik Cloud Monitoring Saat menggunakan fitur Cloud Monitoring lainnya, gunakan nama metrik Cloud Monitoring dalam tabel di bawah. Nama ini harus diawali dengan prometheus.googleapis.com/, yang telah dihilangkan dari entri dalam tabel.

Metrik server API

Bagian ini menyediakan daftar metrik server API dan informasi tambahan tentang cara menafsirkan dan menggunakan metrik.

Daftar metrik server API

Jika metrik server API diaktifkan, semua metrik yang ditampilkan dalam tabel berikut akan diekspor ke Cloud Monitoring dalam project yang sama dengan cluster GKE.

Nama metrik Cloud Monitoring dalam tabel ini harus diawali dengan prometheus.googleapis.com/. Awalan tersebut telah dihilangkan dari entri dalam tabel.

Nama metrik PromQL Tahap peluncuran
Nama metrik Cloud Monitoring
Jenis, Tipe, Unit
Resource yang dimonitor
Versi GKE yang diperlukan		 Deskripsi
Label
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Jumlah maksimum batas permintaan yang sedang digunakan dari API server ini per jenis permintaan dalam detik terakhir.

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ 		Konkurensi (jumlah kursi) yang ditempati oleh permintaan yang sedang dijalankan (tahap awal untuk WATCH, tahap apa pun jika tidak) di subsistem Prioritas dan Keadilan API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
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+ untuk versi minor sebelumnya) 		Jumlah permintaan yang saat ini tertunda dalam antrean subsistem Prioritas dan Keadilan API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BETA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.26.11+, 1.27.8+ untuk versi minor sebelumnya) 		Jumlah nominal slot eksekusi yang dikonfigurasi untuk setiap tingkat prioritas.

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
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+ untuk versi minor sebelumnya) 		Jumlah permintaan yang ditolak oleh subsistem Prioritas dan Keadilan API.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
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+ untuk versi minor sebelumnya) 		Lama waktu yang dihabiskan permintaan untuk menunggu dalam antreannya.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Distribusi latensi respons dalam detik untuk setiap kata kerja, nilai uji coba, grup, versi, resource, subresource, cakupan, dan komponen.

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+ 		Penghitung permintaan apiserver yang dikelompokkan untuk setiap kata kerja, nilai uji coba, grup, versi, resource, cakupan, komponen, dan kode respons 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+ 		Distribusi ukuran respons dalam byte untuk setiap grup, versi, kata kerja, resource, subresource, cakupan, dan komponen.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Jumlah objek yang disimpan pada saat pemeriksaan terakhir yang dibagi menurut jenis.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Histogram latensi pengontrol akses dalam detik, diidentifikasi menurut nama dan dikelompokkan untuk setiap operasi serta resource dan jenis API (memvalidasi atau mengizinkan).

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+ 		Histogram latensi sub-langkah penerimaan dalam detik, yang dikelompokkan untuk setiap operasi, resource API, dan jenis langkah (validasi atau izinkan).

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+ 		Histogram latensi webhook izin dalam detik, diidentifikasi berdasarkan nama dan dikelompokkan untuk setiap operasi serta resource dan jenis API (validasi atau izinkan).

name
operation
rejected
type

Bagian berikut memberikan informasi tambahan tentang metrik server API.

apiserver_request_duration_seconds

Gunakan metrik ini untuk memantau latensi di server API. Durasi permintaan yang dicatat oleh metrik ini mencakup semua fase pemrosesan permintaan, mulai dari waktu permintaan diterima hingga waktu server menyelesaikan responsnya ke klien. Secara khusus, laporan ini mencakup waktu yang dihabiskan untuk hal berikut:

  • Autentikasi dan otorisasi permintaan.
  • Memanggil webhook pihak ketiga dan sistem yang terkait dengan permintaan.
  • Mengambil objek yang diminta dari cache dalam memori (untuk permintaan yang menentukan parameter URL resourceVersion) atau dari etcd (untuk semua permintaan lainnya).
  • Anda dapat menggunakan label group, version, resource, dan subresource untuk secara unik mengidentifikasi permintaan lambat untuk penyelidikan lebih lanjut.
  • Menulis respons kepada klien dan menerima respons klien.

Untuk informasi selengkapnya tentang cara menggunakan metrik ini, lihat Latensi.

Metrik ini memiliki kardinalitas yang sangat tinggi. Saat menggunakan metrik ini, Anda harus menggunakan filter atau pengelompokan untuk menemukan sumber latensi tertentu.

apiserver_admission_controller_admission_duration_seconds

Metrik ini mengukur latensi di webhook penerimaan bawaan, bukan webhook pihak ketiga. Untuk mendiagnosis masalah latensi dengan webhook pihak ketiga, gunakan metrik apiserver_admission_webhook_admission_duration_seconds.

apiserver_admission_webhook_admission_duration_seconds dan
apiserver_admission_step_admission_duration_seconds

Metrik ini mengukur latensi di webhook izin pihak ketiga eksternal. Metrik apiserver_admission_webhook_admission_duration_seconds umumnya merupakan metrik yang lebih berguna. Untuk informasi selengkapnya tentang cara menggunakan metrik ini, lihat Latensi.

apiserver_request_total

Gunakan metrik ini untuk memantau traffic permintaan di server API Anda. Anda juga dapat menggunakannya untuk menentukan tingkat keberhasilan dan kegagalan permintaan. Untuk informasi selengkapnya tentang penggunaan metrik ini, lihat Rasio traffic dan error.

Metrik ini memiliki kardinalitas yang sangat tinggi. Saat menggunakan metrik ini, Anda harus menggunakan filter atau pengelompokan untuk mengidentifikasi sumber error.

apiserver_storage_objects

Gunakan metrik ini untuk mendeteksi kejenuhan sistem dan mengidentifikasi kemungkinan kebocoran resource. Untuk informasi selengkapnya, lihat Saturasi.

apiserver_current_inflight_requests

Metrik ini mencatat jumlah maksimum permintaan yang secara aktif dilayani dalam periode satu detik terakhir. Untuk informasi selengkapnya, lihat Saturasi.

Metrik ini tidak menyertakan permintaan yang berjalan lama seperti "menonton".

Memantau server API

Metrik server API dapat memberi Anda insight tentang sinyal utama untuk kesehatan sistem:

  • Latensi: Berapa lama waktu yang diperlukan untuk melayani permintaan?
  • Traffic: Berapa banyak permintaan yang dialami sistem?
  • Rasio error: Seberapa sering permintaan gagal?
  • Saturasi: Seberapa penuh sistem?

Bagian ini menjelaskan cara menggunakan metrik server API untuk memantau kondisi server API Anda.

Latensi

Jika server API kelebihan beban, latensi permintaan akan meningkat. Untuk mengukur latensi permintaan ke server API, gunakan metrik apiserver_request_duration_seconds. Untuk mengidentifikasi sumber latensi secara lebih spesifik, Anda dapat mengelompokkan metrik menurut label verb atau resource.

Batas atas yang disarankan untuk panggilan resource tunggal seperti GET, POST, atau PATCH adalah 1 detik. Batas atas yang disarankan untuk panggilan LIST cakupan namespace dan cluster adalah 30 detik. Perkiraan batas atas ditetapkan oleh SLO yang ditentukan oleh komunitas Kubernetes open source; untuk informasi selengkapnya, lihat detail SLI/SLOs latensi panggilan API.

Jika nilai metrik apiserver_request_duration_seconds meningkat melebihi durasi yang diharapkan, selidiki kemungkinan penyebab berikut:

  • Panel kontrol Kubernetes mungkin kelebihan beban. Untuk memeriksanya, lihat metrik apiserver_request_total dan apiserver_storage_objects.
    • Gunakan label code untuk menentukan apakah permintaan berhasil diproses. Untuk mengetahui informasi tentang kemungkinan nilai, lihat Kode Status HTTP.
    • Gunakan label group, version, resource, dan subresource untuk mengidentifikasi permintaan secara unik.

  • Webhook izin pihak ketiga lambat atau tidak responsif. Jika nilai metrik apiserver_admission_webhook_admission_duration_seconds meningkat, beberapa webhook izin pihak ketiga atau yang ditentukan pengguna lambat atau tidak responsif. Latensi dalam webhook akses dapat menyebabkan penundaan dalam penjadwalan tugas.

    • Untuk membuat kueri latensi webhook persentil ke-99 per instance platform kontrol Kubernetes, gunakan kueri PromQL berikut:

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

      Sebaiknya lihat juga persentil ke-50, ke-90, ke-95, dan ke-99,9; Anda dapat menyesuaikan kueri ini dengan mengubah nilai 0.99.

    • Webhook eksternal memiliki batas waktu tunggu sekitar 10 detik. Anda dapat menetapkan kebijakan pemberitahuan pada metrik apiserver_admission_webhook_admission_duration_seconds untuk memberi tahu Anda saat mendekati waktu tunggu webhook.

    • Anda juga dapat mengelompokkan metrik apiserver_admission_webhook_admission_duration_seconds pada label name untuk mendiagnosis kemungkinan masalah pada webhook tertentu.

  • Anda mencantumkan banyak objek. Latensi panggilan LIST diharapkan meningkat seiring dengan meningkatnya jumlah objek dari jenis tertentu (ukuran respons).

  • Masalah sisi klien:

    • Klien mungkin tidak memiliki resource yang cukup untuk menerima respons secara tepat waktu. Untuk memeriksanya, lihat metrik penggunaan CPU untuk pod klien.
    • Klien memiliki koneksi jaringan yang lambat. Hal ini mungkin terjadi saat klien berjalan di perangkat seperti ponsel, tetapi kemungkinan tidak terjadi untuk klien yang berjalan di jaringan Compute Engine.
    • Klien keluar secara tiba-tiba, tetapi koneksi TCP memiliki periode waktu tunggu dalam puluhan detik. Sebelum waktu tunggu koneksi habis, resource server akan diblokir, yang dapat meningkatkan latensi.

Untuk informasi selengkapnya, lihat Praktik baik untuk menggunakan Prioritas dan Keadilan API dalam dokumentasi Kubernetes.

Traffic dan tingkat error

Untuk mengukur traffic dan jumlah permintaan yang berhasil dan gagal di server API, gunakan metrik apiserver_request_total. Misalnya, untuk mengukur traffic server API per instance bidang kontrol Kubernetes, gunakan kueri PromQL berikut:

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

  • Untuk membuat kueri permintaan yang tidak berhasil, filter label code untuk nilai 4xx dan 5xx menggunakan kueri PromQL berikut:

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

  • Untuk membuat kueri permintaan yang berhasil, filter label code untuk nilai 2xx menggunakan kueri PromQL berikut:

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

  • Untuk membuat kueri permintaan yang ditolak oleh server API per instance bidang kontrol Kubernetes, filter label code untuk nilai 429 (http.StatusTooManyRequests) menggunakan kueri PromQL berikut:

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

Saturasi

Anda dapat mengukur saturasi di sistem menggunakan metrik apiserver_current_inflight_requests dan apiserver_storage_objects .

Jika nilai metrik apiserver_storage_objects meningkat, Anda mungkin mengalami masalah dengan pengontrol kustom yang membuat objek, tetapi tidak menghapusnya. Anda dapat memfilter atau mengelompokkan metrik menurut label resource untuk mengidentifikasi resource yang mengalami peningkatan.

Evaluasi metrik apiserver_current_inflight_requests sesuai dengan setelan Prioritas dan Keadilan API Anda; setelan ini memengaruhi cara permintaan diprioritaskan, sehingga Anda tidak dapat menarik kesimpulan dari nilai metrik saja. Untuk informasi selengkapnya, lihat Prioritas dan Keadilan API.

Metrik penjadwal

Bagian ini memberikan daftar metrik penjadwal dan informasi tambahan tentang menafsirkan dan menggunakan metrik.

Daftar metrik penjadwal

Jika metrik penjadwal diaktifkan, semua metrik yang ditampilkan dalam tabel berikut akan diekspor ke Cloud Monitoring dalam project yang sama dengan cluster GKE.

Nama metrik Cloud Monitoring dalam tabel ini harus diawali dengan prometheus.googleapis.com/. Awalan tersebut telah dihilangkan dari entri dalam tabel.

Nama metrik PromQL Tahap peluncuran
Nama metrik Cloud Monitoring
Jenis, Tipe, Unit
Resource yang dimonitor
Versi GKE yang diperlukan		 Deskripsi
Label
kube_pod_resource_limit GA
kube_pod_resource_limit/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		Batas resource untuk workload di cluster, yang dikelompokkan menurut pod. Ini menunjukkan penggunaan resource yang diharapkan penjadwal dan kubelet per pod untuk resource, beserta unit resource, jika ada.

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+ 		Resource yang diminta oleh workload di cluster, yang dikelompokkan menurut pod. Ini menunjukkan penggunaan resource yang diharapkan penjadwal dan kubelet per pod untuk resource, beserta unit resource, jika ada.

namespace
node
pod
priority
resource
scheduler
unit
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Jumlah pod yang tertunda, menurut jenis antrean. 'active' berarti jumlah pod di activeQ; 'backoff' berarti jumlah pod di backoffQ; 'unschedulable' berarti jumlah pod di unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds TIDAK DIGUNAKAN LAGI
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.25.1 hingga 1.29 (1.22.17-gke.3100+, 1.23.11+, dan 1.24.5+ untuk versi minor sebelumnya) 		[Tidak digunakan lagi di v. 1.29; dihapus di v. 1.30 dan diganti dengan scheduler_pod_scheduling_sli_duration_seconds.] Latensi E2E untuk pod yang dijadwalkan yang dapat mencakup beberapa upaya penjadwalan.

attempts
scheduler_pod_scheduling_sli_duration_seconds BETA
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.30+ 		Latensi E2E untuk pod yang dijadwalkan, sejak pod memasuki antrean penjadwalan, dan mungkin melibatkan beberapa upaya penjadwalan.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Total upaya preemptif di cluster hingga saat ini
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Jumlah korban preemption yang dipilih
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6+ 		Latensi percobaan penjadwalan dalam detik (algoritma penjadwalan + binding).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Jumlah upaya untuk menjadwalkan pod, berdasarkan hasilnya. 'unschedulable' berarti pod tidak dapat dijadwalkan, sedangkan 'error' berarti masalah penjadwal internal.

profile
result

Bagian berikut memberikan informasi tambahan tentang metrik server API.

scheduler_pending_pods

Anda dapat menggunakan metrik scheduler_pending_pods untuk memantau beban pada penjadwal. Nilai yang meningkat dalam metrik ini dapat menunjukkan masalah sumber daya. Penjadwal memiliki tiga antrean, dan metrik ini melaporkan jumlah permintaan yang tertunda menurut antrean. Antrean berikut didukung:

  • Antrean active
    • Kumpulan pod yang dicoba dijadwalkan oleh penjadwal; pod dengan prioritas tertinggi berada di awal antrean.
  • Antrean backoff
    • Kumpulan pod tidak dapat dijadwalkan saat terakhir kali penjadwal mencoba, tetapi mungkin dapat dijadwalkan pada lain waktu.
    • Pod di antrean ini harus menunggu periode backoff (maksimum 10 detik), setelah itu pod akan dipindahkan kembali ke antrean active untuk percobaan penjadwalan lainnya. Untuk mengetahui informasi selengkapnya tentang pengelolaan antrean backoff, lihat permintaan penerapan, masalah Kubernetes 75417.

  • unschedulable ditetapkan

    • Kumpulan pod yang dicoba dijadwalkan oleh penjadwal, tetapi telah ditentukan tidak dapat dijadwalkan. Penempatan di antrean ini mungkin menunjukkan masalah kesiapan atau kompatibilitas dengan node atau konfigurasi pemilih node Anda.

      Jika batasan resource mencegah penjadwalan pod, pod tersebut tidak akan dikenai penanganan back-off. Sebagai gantinya, saat cluster penuh, pod baru gagal dijadwalkan dan dimasukkan ke antrean unscheduled.

    • Kehadiran pod yang tidak dijadwalkan mungkin menunjukkan bahwa Anda tidak memiliki resource yang memadai atau memiliki masalah konfigurasi node. Pod dipindahkan ke antrean backoff atau active setelah peristiwa yang mengubah status cluster. Pod di antrean ini menunjukkan bahwa tidak ada perubahan di cluster yang akan membuat pod dapat dijadwalkan.

    • Afinitas menentukan aturan untuk cara pod ditetapkan ke node. Penggunaan aturan afinitas atau anti-afinitas dapat menjadi alasan peningkatan pod yang tidak terjadwal.

    • Beberapa peristiwa, misalnya, PVC/Service ADD/UPDATE, penghentian pod, atau pendaftaran node baru, memindahkan beberapa atau semua pod yang tidak terjadwal ke antrean backoff atau active. Untuk mengetahui informasi selengkapnya, lihat masalah Kubernetes 81214.

Untuk mengetahui informasi selengkapnya, lihat Latensi penjadwal dan Masalah resource.

scheduler_scheduling_attempt_duration_seconds

Metrik ini mengukur durasi satu upaya penjadwalan dalam penjadwal itu sendiri dan dikelompokkan berdasarkan hasilnya: terjadwal, tidak dapat dijadwalkan, atau error. Durasi berjalan dari saat penjadwal mengambil pod hingga saat penjadwal menemukan node dan menempatkan pod di node, menentukan bahwa pod tidak dapat dijadwalkan, atau mengalami error. Durasi penjadwalan mencakup waktu dalam proses penjadwalan serta waktu binding. Binding adalah proses saat penjadwal menyampaikan penetapan node-nya ke server API. Untuk informasi selengkapnya, lihat Latensi penjadwal.

Metrik ini tidak mencatat waktu yang dihabiskan pod dalam kontrol atau validasi penerimaan.

Untuk mengetahui informasi selengkapnya tentang penjadwalan, lihat Menjadwalkan Pod.

scheduler_schedule_attempts_total

Metrik ini mengukur jumlah upaya penjadwalan; setiap upaya untuk menjadwalkan pod akan meningkatkan nilai. Anda dapat menggunakan metrik ini untuk menentukan apakah penjadwal tersedia: jika nilainya meningkat, berarti penjadwal beroperasi. Anda dapat menggunakan label result untuk menentukan keberhasilan; pod adalah scheduled atau unschedulable.

Metrik ini sangat berkorelasi dengan metrik scheduler_pending_pods: jika ada banyak pod yang tertunda, Anda akan melihat banyak upaya untuk menjadwalkan pod. Untuk mengetahui informasi selengkapnya, lihat Masalah resource.

Metrik ini tidak meningkat jika penjadwal tidak memiliki pod untuk dijadwalkan, yang dapat terjadi jika Anda memiliki penjadwal sekunder kustom.

scheduler_preemption_attempts_total dan scheduler_preemptions_victims

Anda dapat menggunakan metrik pengalihan untuk membantu menentukan apakah Anda perlu menambahkan resource.

Anda mungkin memiliki pod dengan prioritas lebih tinggi yang tidak dapat dijadwalkan karena tidak ada ruang untuk pod tersebut. Dalam hal ini, penjadwal mengosongkan resource dengan mengambil alih satu atau beberapa pod yang berjalan di node. Metrik scheduler_preemption_attempts_total melacak frekuensi scheduler mencoba mengambil alih pod.

Metrik scheduler_preemptions_victims menghitung pod yang dipilih untuk preemptif.

Jumlah upaya preemptif sangat berkorelasi dengan nilai metrik scheduler_schedule_attempts_total saat nilai label result adalah unschedulable. Kedua nilai tersebut tidak setara: misalnya, jika cluster memiliki 0 node, tidak ada upaya preemptif, tetapi mungkin ada upaya penjadwalan yang gagal.

Untuk mengetahui informasi selengkapnya, lihat Masalah resource.

Memantau penjadwal

Metrik penjadwal dapat memberi Anda insight tentang performa penjadwal:

  • Latensi penjadwal: Apakah penjadwal berjalan? Berapa lama waktu yang diperlukan untuk menjadwalkan pod?
  • Masalah resource: Apakah upaya untuk menjadwalkan pod mengalami kendala resource?

Bagian ini menjelaskan cara menggunakan metrik penjadwal untuk memantau penjadwal Anda.

Latensi penjadwal

Tugas penjadwal adalah memastikan pod Anda berjalan, sehingga Anda ingin mengetahui saat penjadwal macet atau berjalan lambat.

  • Untuk memverifikasi bahwa penjadwal sedang berjalan dan menjadwalkan pod, gunakan metrik scheduler_schedule_attempts_total.

  • Jika penjadwal berjalan lambat, selidiki kemungkinan penyebab berikut:

    • Jumlah pod yang tertunda meningkat. Gunakan metrik scheduler_pending_pods untuk memantau jumlah pod yang tertunda. Kueri PromQL berikut menampilkan jumlah pod yang tertunda per antrean dalam cluster:

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

    • Setiap upaya untuk menjadwalkan pod lambat. Gunakan metrik scheduler_scheduling_attempt_duration_seconds untuk memantau latensi upaya penjadwalan.

      Sebaiknya amati metrik ini setidaknya pada persentil ke-50 dan ke-95. Kueri PromQL berikut mengambil nilai persentil ke-95, tetapi dapat disesuaikan:

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

Masalah resource

Metrik penjadwal juga dapat membantu Anda menilai apakah Anda memiliki resource yang memadai. Jika nilai metrik scheduler_preemption_attempts_total meningkat, periksa nilai scheduler_preemption_victims menggunakan kueri PromQL berikut:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

Jumlah upaya preemptif dan jumlah korban preemptif akan meningkat saat ada pod berprioritas lebih tinggi yang akan dijadwalkan. Metrik preemptif tidak memberi tahu Anda apakah pod prioritas tinggi yang memicu preemptif dijadwalkan, sehingga saat melihat peningkatan nilai metrik preemptif, Anda juga dapat memantau nilai metrik scheduler_pending_pods. Jika jumlah pod yang tertunda juga meningkat, Anda mungkin tidak memiliki resource yang memadai untuk menangani pod dengan prioritas lebih tinggi; Anda mungkin perlu menskalakan resource yang tersedia, membuat pod baru dengan klaim resource yang dikurangi, atau mengubah pemilih node.

  • Jika jumlah korban preemption tidak bertambah, maka tidak ada pod tersisa dengan prioritas rendah yang dapat dihapus. Dalam hal ini, pertimbangkan untuk menambahkan lebih banyak node agar pod baru dapat dialokasikan.

  • Jika jumlah korban preemptif meningkat, berarti ada pod dengan prioritas lebih tinggi yang menunggu untuk dijadwalkan, sehingga penjadwal akan menggantikan beberapa pod yang sedang berjalan. Metrik preemptif tidak memberi tahu Anda apakah pod dengan prioritas lebih tinggi telah berhasil dijadwalkan.

    Untuk menentukan apakah pod dengan prioritas lebih tinggi sedang dijadwalkan, cari nilai metrik scheduler_pending_pods yang menurun. Jika nilai metrik ini meningkat, Anda mungkin perlu menambahkan lebih banyak node.

Anda dapat melihat lonjakan sementara pada nilai untuk metrik scheduler_pending_pods saat beban kerja akan dijadwalkan di cluster, misalnya, selama peristiwa seperti update atau penskalaan. Jika Anda memiliki resource yang memadai di cluster, lonjakan ini bersifat sementara. Jika jumlah pod yang tertunda tidak berkurang, lakukan hal berikut:

  • Pastikan node tidak diisolasi; node yang diisolasi tidak menerima pod baru.
  • Periksa perintah penjadwalan berikut, yang dapat salah dikonfigurasi dan mungkin membuat pod tidak dapat dijadwalkan:
    • Afinitas dan pemilih node.
    • Taint dan toleransi.
    • Batasan penyebaran topologi pod.

Jika pod tidak dapat dijadwalkan karena resource tidak memadai, sebaiknya pertimbangkan untuk mengosongkan beberapa node yang ada atau meningkatkan jumlah node.

Metrik Pengelola Pengontrol

Jika metrik pengelola pengontrol diaktifkan, semua metrik yang ditampilkan dalam tabel berikut akan diekspor ke Cloud Monitoring dalam project yang sama dengan cluster GKE.

Nama metrik Cloud Monitoring dalam tabel ini harus diawali dengan prometheus.googleapis.com/. Awalan tersebut telah dihilangkan dari entri dalam tabel.

Nama metrik PromQL Tahap peluncuran
Nama metrik Cloud Monitoring
Jenis, Tipe, Unit
Resource yang dimonitor
Versi GKE yang diperlukan		 Deskripsi
Label
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24+ 		Jumlah penghapusan Node yang terjadi sejak instance NodeController saat ini dimulai.

zone