Metrik untuk Komponen Sistem Kubernetes

Metrik dari komponen sistem dapat memberikan gambaran yang lebih baik tentang apa yang sedang terjadi di dalam sistem. Metrik sangat berguna untuk membuat dasbor (dashboard) dan peringatan (alert).

Komponen Kubernetes mengekspos metrik dalam format Prometheus. Format ini berupa teks biasa yang terstruktur, dirancang agar orang dan mesin dapat membacanya.

Metrik-metrik dalam Kubernetes

Dalam kebanyakan kasus, metrik tersedia pada endpoint /metrics dari server HTTP. Untuk komponen yang tidak mengekspos endpoint secara bawaan, endpoint tersebut dapat diaktifkan dengan menggunakan opsi --bind-address.

Contoh-contoh untuk komponen tersebut adalah:

• kube-controller-manager
• kube-proxy
• kube-apiserver
• kube-scheduler
• kubelet

Di dalam lingkungan produksi, kamu mungkin ingin mengonfigurasi Server Prometheus atau pengambil metrik (metrics scraper) lainnya untuk mengumpulkan metrik-metrik ini secara berkala dan membuatnya tersedia dalam semacam pangkalan data deret waktu (time series database).

Perlu dicatat bahwa kubelet juga mengekspos metrik pada endpoint-endpoint seperti /metrics/cadvisor, /metrics/resource dan /metrics/probes. Metrik-metrik tersebut tidak memiliki siklus hidup yang sama.

Jika klastermu menggunakan RBAC, maka membaca metrik memerlukan otorisasi melalui user, group, atau ServiceAccount dengan ClusterRole yang memperbolehkan untuk mengakses /metrics.

Sebagai contoh:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
  - nonResourceURLs:
      - "/metrics"
    verbs:
      - get

Siklus hidup metrik

Metrik alfa (alpha) → Metrik stabil → Metrik usang (deprecated) → Metrik tersembunyi → Metrik terhapus

Metrik alfa tidak memiliki jaminan stabilitas. Metrik ini dapat dimodifikasi atau dihapus kapan saja.

Metrik stabil dijamin tidak akan mengalami perubahan. Hal ini berarti:

• Metrik stabil tanpa penanda usang (deprecated signature) tidak akan dihapus ataupun diganti namanya
• Jenis metrik stabil tidak akan dimodifikasi

Metrik usang dijadwalkan untuk dihapus, tetapi masih tersedia untuk digunakan. Metrik ini mencakup anotasi versi di mana metrik ini dianggap menjadi usang.

Sebagai contoh:

• Sebelum menjadi usang

  # HELP some_counter this counts things
  # TYPE some_counter counter
  some_counter 0
  

• Setelah menjadi usang

  # HELP some_counter (Deprecated since 1.15.0) this counts things
  # TYPE some_counter counter
  some_counter 0
  

Metrik tersembunyi tidak lagi dipublikasikan untuk pengambilan metrik (scraping), tetapi masih tersedia untuk digunakan. Untuk menggunakan metrik tersembunyi, lihat bagian Menampilkan metrik tersembunyi.

Metrik yang terhapus tidak lagi dipublikasikan dan tidak dapat digunakan lagi.

Menampilkan metrik tersembunyi

Seperti yang dijelaskan di atas, admin dapat mengaktifkan metrik tersembunyi melalui opsi baris perintah pada biner (program) tertentu. Ini dimaksudkan untuk digunakan sebagai jalan keluar bagi admin jika mereka melewatkan migrasi metrik usang dalam rilis terakhir.

Opsi show-hidden-metrics-for-version menerima input versi yang kamu inginkan untuk menampilkan metrik usang dalam rilis tersebut. Versi tersebut dinyatakan sebagai x.y, di mana x adalah versi mayor, y adalah versi minor. Versi patch tidak diperlukan meskipun metrik dapat menjadi usang dalam rilis patch, alasannya adalah kebijakan penandaan metrik usang dijalankan terhadap rilis minor.

Opsi tersebut hanya dapat menerima input versi minor sebelumnya sebagai nilai. Semua metrik yang disembunyikan di versi sebelumnya akan dikeluarkan jika admin mengatur versi sebelumnya ke show-hidden-metrics-for-version. Versi yang terlalu lama tidak diperbolehkan karena melanggar kebijakan untuk metrik usang.

Ambil metrik A sebagai contoh, di sini diasumsikan bahwa A sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut:

• Pada rilis 1.n, metrik menjadi usang, dan dapat dikeluarkan secara bawaan.
• Pada rilis 1.n+1, metrik disembunyikan secara bawaan dan dapat dikeluarkan dengan baris perintah show-hidden-metrics-for-version=1.n.
• Pada rilis 1.n+2, metrik harus dihapus dari codebase. Tidak ada jalan keluar lagi.

Jika kamu meningkatkan versi dari rilis 1.12 ke 1.13, tetapi masih bergantung pada metrik A yang usang di 1.12, kamu harus mengatur metrik tersembunyi melalui baris perintah: --show-hidden-metrics = 1.12 dan ingatlah untuk menghapus ketergantungan terhadap metrik ini sebelum meningkatkan versi rilis ke 1.14.

Menonaktifkan metrik akselerator

kubelet mengumpulkan metrik akselerator melalui cAdvisor. Untuk mengumpulkan metrik ini, untuk akselerator seperti GPU NVIDIA, kubelet membuka koneksi dengan driver GPU. Ini berarti untuk melakukan perubahan infrastruktur (misalnya, pemutakhiran driver), administrator klaster perlu menghentikan agen kubelet.

Pengumpulkan metrik akselerator sekarang menjadi tanggung jawab vendor dibandingkan kubelet. Vendor harus menyediakan sebuah kontainer untuk mengumpulkan metrik dan mengeksposnya ke layanan metrik (misalnya, Prometheus).

Gerbang fitur DisableAcceleratorUsageMetrics menonaktifkan metrik yang dikumpulkan oleh kubelet, dengan lini masa (timeline) untuk mengaktifkan fitur ini secara bawaan.

Metrik komponen

Metrik kube-controller-manager

Metrik controller manager memberikan gambaran penting tentang kinerja dan kesehatan controller manager. Metrik ini mencakup metrik runtime bahasa Go yang umum seperti jumlah go_routine dan metrik khusus pengontrol seperti latensi permintaan etcd atau latensi API Cloudprovider (AWS, GCE, OpenStack) yang dapat digunakan untuk mengukur kesehatan klaster.

Mulai dari Kubernetes 1.7, metrik Cloudprovider yang detail tersedia untuk operasi penyimpanan untuk GCE, AWS, Vsphere, dan OpenStack. Metrik ini dapat digunakan untuk memantau kesehatan operasi persistent volume.

Misalnya, untuk GCE metrik-metrik berikut ini dipanggil:

cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}

Metrik kube-scheduler

Penjadwal mengekspos metrik opsional yang melaporkan sumber daya yang diminta dan limit yang diinginkan dari semua pod yang berjalan. Metrik ini dapat digunakan untuk membangun dasbor perencanaan kapasitas, mengevaluasi limit penjadwalan yang digunakan saat ini atau secara historis, dengan cepat mengidentifikasi beban kerja yang tidak dapat dijadwalkan karena kurangnya sumber daya, dan membandingkan permintaan sumber daya oleh pod dengan penggunaannya yang aktual.

kube-scheduler mengidentifikasi permintaan dan limit sumber daya yang dikonfigurasi untuk setiap Pod; jika permintaan atau limit bukan nol, kube-scheduler akan melaporkan deret waktu (timeseries) metrik. Deret waktu diberi label dengan:

• namespace
• nama pod
• node di mana pod dijadwalkan atau string kosong jika belum dijadwalkan
• prioritas
• penjadwal yang ditugaskan untuk pod itu
• nama dari sumber daya (misalnya, cpu)
• satuan dari sumber daya jika diketahui (misalnya, cores)

Setelah pod selesai (memiliki restartPolicy Never atau OnFailure dan berada dalam fase pod Succeeded atau Failed, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai kube_pod_resource_request dan kube_pod_resource_limit.

Metrik diekspos melalui endpoint HTTP /metrics/resources dan memerlukan otorisasi yang sama seperti endpoint /metrics pada penjadwal. Kamu harus menggunakan opsi --show-hidden-metrics-for-version=1.20 untuk mengekspos metrik-metrik stabilitas alfa ini.

Selanjutnya

• Baca tentang format teks Prometheus untuk berbagai metrik
• Baca tentang kebijakan deprecation Kubernetes