kube state metrics
v2.14.0
kube-state-metrics (KSM) adalah layanan sederhana yang mendengarkan server API Kubernetes dan menghasilkan metrik tentang status objek. (Lihat contoh di bagian Metrik di bawah.) Hal ini tidak terfokus pada kesehatan masing-masing komponen Kubernetes, melainkan pada kesehatan berbagai objek di dalamnya, seperti penerapan, node, dan pod.
kube-state-metrics adalah tentang menghasilkan metrik dari objek API Kubernetes tanpa modifikasi. Hal ini memastikan bahwa fitur-fitur yang disediakan oleh kube-state-metrics memiliki tingkat stabilitas yang sama dengan objek API Kubernetes itu sendiri. Artinya, kube-state-metrics dalam situasi tertentu mungkin tidak menunjukkan nilai yang sama persis dengan kubectl, karena kubectl menerapkan heuristik tertentu untuk menampilkan pesan yang dapat dipahami. kube-state-metrics mengekspos data mentah yang tidak dimodifikasi dari API Kubernetes, dengan cara ini pengguna memiliki semua data yang mereka perlukan dan melakukan heuristik sesuai keinginan mereka.
Metrik diekspor pada titik akhir HTTP /metrics pada port mendengarkan (default 8080). Mereka disajikan sebagai teks biasa. Mereka dirancang untuk digunakan baik oleh Prometheus sendiri atau oleh scraper yang kompatibel dengan scraping titik akhir klien Prometheus. Anda juga dapat membuka /metrics di browser untuk melihat metrik mentah. Perhatikan bahwa metrik yang diekspos pada endpoint /metrics mencerminkan keadaan cluster Kubernetes saat ini. Ketika objek Kubernetes dihapus, objek tersebut tidak lagi terlihat di titik akhir /metrics .
Catatan
README ini dihasilkan dari sebuah template. Silakan buat perubahan Anda di sana dan jalankan make generate-template .
Pembuatan versi
Versi Kubernetes
Matriks kompatibilitas
Kompatibilitas versi grup sumber daya
Gambar Kontainer
Dokumentasi Metrik
Resolusi konflik pada nama label
Metrik mandiri Kube-state-metrics
Rekomendasi sumber daya
Latensi
Catatan tentang penetapan biaya
kube-state-metrics vs. metrik-server
Menskalakan metrik kube-state
Pecahan otomatis
Rekomendasi sumber daya
Pecahan horizontal
Sharding daemonset untuk metrik pod
Pengaturan
Membangun wadah Docker
Penggunaan
Penerapan Kubernetes
Lingkungan hak istimewa terbatas
Bagan Helm
Perkembangan
Kontribusi Pengembang
Masyarakat
kube-state-metrics menggunakan client-go untuk berkomunikasi dengan cluster Kubernetes. Versi cluster Kubernetes yang didukung ditentukan oleh client-go . Matriks kompatibilitas untuk client-go dan cluster Kubernetes dapat ditemukan di sini. Semua kompatibilitas tambahan hanyalah upaya terbaik, atau kebetulan masih/sudah didukung.
Paling banyak, 5 rilis kube-state-metrics dan 5 kubernetes akan dicatat di bawah. Secara umum, disarankan untuk menggunakan rilis terbaru dari kube-state-metrics. Jika Anda menjalankan Kubernetes versi terbaru, Anda mungkin ingin menggunakan versi yang belum dirilis untuk mendapatkan seluruh sumber daya yang didukung. Jika Anda menjalankan Kubernetes versi lama, Anda mungkin perlu menjalankan versi lama agar mendapatkan dukungan penuh untuk semua sumber daya. Sadarilah, bahwa pengelola hanya akan mendukung rilis terbaru. Versi yang lebih lama mungkin didukung oleh pengguna komunitas yang tertarik.
| kube-state-metrik | Versi klien-pergi Kubernetes |
|---|---|
| v2.10.1 | v1.27 |
| v2.11.0 | v1.28 |
| v2.12.0 | v1.29 |
| v2.13.0 | v1.30 |
| v2.14.0 | v1.31 |
| utama | v1.31 |
Sumber daya di Kubernetes dapat berkembang, yaitu versi grup untuk suatu sumber daya dapat berubah dari alfa ke beta dan akhirnya GA dalam versi Kubernetes yang berbeda. Untuk saat ini, kube-state-metrics hanya akan menggunakan API terlama yang tersedia di rilis terbaru.
Gambar container terbaru dapat ditemukan di:
registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.14.0 (lengkungan: amd64 , arm , arm64 , ppc64le dan s390x )
Lihat semua gambar multi-arsitektur di sini
Sumber daya dan metrik apa pun yang didasarkan pada API alfa Kubernetes tidak termasuk dalam jaminan stabilitas apa pun, yang dapat diubah pada rilis apa pun.
Lihat direktori docs untuk informasi lebih lanjut tentang metrik yang terekspos.
Kelompok metrik *_labels menampilkan label Kubernetes sebagai label Prometheus. Karena Kubernetes lebih liberal dibandingkan Prometheus dalam hal karakter yang diperbolehkan dalam nama label, kami secara otomatis mengonversi karakter yang tidak didukung menjadi garis bawah. Misalnya, app.kubernetes.io/name menjadi label_app_kubernetes_io_name .
Konversi ini dapat menimbulkan konflik ketika beberapa label Kubernetes seperti foo-bar dan foo_bar dikonversi ke label Prometheus yang sama label_foo_bar .
Kube-state-metrics secara otomatis menambahkan akhiran _conflictN untuk menyelesaikan konflik ini, sehingga label di atas diubah menjadi label_foo_bar_conflict1 dan label_foo_bar_conflict2 .
Jika Anda ingin memiliki kontrol lebih besar terhadap cara penyelesaian konflik ini, Anda mungkin ingin mempertimbangkan untuk mengatasi masalah ini pada tingkat tumpukan yang berbeda, misalnya dengan menstandardisasi label Kubernetes menggunakan Admission Webhook yang memastikan bahwa tidak ada kemungkinan konflik.
kube-state-metrics memperlihatkan metrik proses umumnya pada --telemetry-host dan --telemetry-port (default 8081).
kube-state-metrics juga memperlihatkan metrik keberhasilan dan kesalahan daftar dan tontonan. Ini dapat digunakan untuk menghitung tingkat kesalahan sumber daya daftar atau tontonan. Jika kamu menemukan kesalahan tersebut pada metrik, kemungkinan besar itu adalah masalah konfigurasi atau izin, dan hal berikutnya yang perlu diselidiki adalah melihat log dari kube-state-metrics.
Contoh metrik yang disebutkan di atas:
kube_state_metrics_list_total{resource="*v1.Node",result="success"} 1
kube_state_metrics_list_total{resource="*v1.Node",result="error"} 52
kube_state_metrics_watch_total{resource="*v1beta1.Ingress",result="success"} 1kube-state-metrics juga memaparkan beberapa metrik permintaan http, contohnya adalah:
http_request_duration_seconds_bucket{handler="metrics",method="get",le="2.5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="10"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="+Inf"} 30
http_request_duration_seconds_sum{handler="metrics",method="get"} 0.021113919999999998
http_request_duration_seconds_count{handler="metrics",method="get"} 30kube-state-metrics juga memperlihatkan metrik build dan konfigurasi:
kube_state_metrics_build_info{branch="main",goversion="go1.15.3",revision="6c9d775d",version="v2.0.0-beta"} 1
kube_state_metrics_shard_ordinal{shard_ordinal="0"} 0
kube_state_metrics_total_shards 1 kube_state_metrics_build_info digunakan untuk mengekspos versi dan informasi build lainnya. Untuk penggunaan lebih lanjut tentang pola info, silakan periksa postingan blog di sini. Metrik sharding mengekspos tanda --shard dan --total-shards dan dapat digunakan untuk memvalidasi konfigurasi run-time, lihat /examples/prometheus-alerting-rules .
kube-state-metrics juga memperlihatkan metrik tentang file konfigurasinya dan file konfigurasi Custom Resource State:
kube_state_metrics_config_hash{filename="crs.yml",type="customresourceconfig"} 2.38272279311849e+14
kube_state_metrics_config_hash{filename="config.yml",type="config"} 2.65285922340846e+14
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="crs.yml",type="customresourceconfig"} 1.6704882592037103e+09
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="config.yml",type="config"} 1.6704882592035313e+09
kube_state_metrics_last_config_reload_successful{filename="crs.yml",type="customresourceconfig"} 1
kube_state_metrics_last_config_reload_successful{filename="config.yml",type="config"} 1Penggunaan sumber daya untuk kube-state-metrics berubah seiring dengan ukuran objek Kubernetes (Pods/Nodes/Deployments/Secrets, dll.) dari cluster. Sampai batas tertentu, objek Kubernetes dalam sebuah cluster berbanding lurus dengan jumlah node cluster tersebut.
Sebagai aturan umum, Anda harus menyoroti:
memori 250MiB
0,1 inti
Perhatikan bahwa jika batas CPU ditetapkan terlalu rendah, antrian internal kube-state-metrics tidak akan dapat diselesaikan dengan cukup cepat, sehingga mengakibatkan peningkatan konsumsi memori seiring bertambahnya panjang antrian. Jika Anda mengalami masalah akibat alokasi memori yang tinggi atau pembatasan CPU, coba tingkatkan batas CPU.
Dalam pengujian penskalaan cluster 100 node, angka latensinya adalah sebagai berikut:
"Perc50": 259615384 ns, "Perc90": 475000000 ns, "Perc99": 906666666 ns.
Secara default, kube-state-metrics memaparkan beberapa metrik untuk kejadian di seluruh klaster Anda. Jika Anda memiliki sejumlah besar sumber daya yang sering diperbarui di klaster Anda, Anda mungkin menemukan bahwa banyak data yang diserap ke dalam metrik ini. Hal ini dapat menimbulkan biaya tinggi pada beberapa penyedia cloud. Harap luangkan waktu sejenak untuk mengonfigurasi metrik apa yang ingin Anda ekspos, serta lihat dokumentasi lingkungan Kubernetes Anda untuk menghindari biaya tinggi yang tidak terduga.
Server metrik adalah proyek yang terinspirasi oleh Heapster dan diimplementasikan untuk memenuhi tujuan pipeline metrik inti dalam arsitektur pemantauan Kubernetes. Ini adalah komponen tingkat cluster yang secara berkala mengambil metrik dari semua node Kubernetes yang dilayani oleh Kubelet melalui Metrics API. Metrik dikumpulkan, disimpan dalam memori, dan disajikan dalam format Metrics API. Server metrik hanya menyimpan nilai terbaru dan tidak bertanggung jawab meneruskan metrik ke tujuan pihak ketiga.
kube-state-metrics difokuskan untuk menghasilkan metrik yang benar-benar baru dari status objek Kubernetes (misalnya metrik berdasarkan penerapan, kumpulan replika, dll.). Ini menyimpan seluruh cuplikan status Kubernetes di memori dan terus-menerus menghasilkan metrik baru berdasarkan data tersebut. Dan sama seperti server metrik, server ini juga tidak bertanggung jawab untuk mengekspor metriknya ke mana pun.
Memiliki kube-state-metrics sebagai proyek terpisah juga memungkinkan akses ke metrik ini dari sistem pemantauan seperti Prometheus.
Untuk melakukan sharding kube-state-metrik secara horizontal, beberapa kemampuan sharding otomatis telah diterapkan. Itu dikonfigurasi dengan tanda berikut:
--shard (diindeks nol)
--total-shards
Sharding dilakukan dengan mengambil jumlah md5 dari UID Objek Kubernetes dan melakukan operasi modulo pada objek tersebut dengan jumlah total shard. Setiap pecahan menentukan apakah objek ditangani oleh masing-masing instance kube-state-metrics atau tidak. Perhatikan bahwa ini berarti semua instance kube-state-metrics, bahkan jika di-sharding, akan memiliki lalu lintas jaringan dan konsumsi sumber daya untuk unmarshaling objek untuk semua objek, bukan hanya objek yang menjadi tanggung jawabnya. Untuk mengoptimalkan hal ini lebih lanjut, Kubernetes API perlu mendukung kemampuan sharded list/watch. Dalam kasus optimal, konsumsi memori untuk setiap shard akan menjadi 1/n dibandingkan dengan pengaturan tanpa shard. Biasanya, metrik kube-state perlu dioptimalkan memori dan latensinya agar dapat mengembalikan metriknya dengan lebih cepat ke Prometheus. Salah satu cara untuk mengurangi latensi antara kube-state-metrics dan kube-apiserver adalah dengan menjalankan KSM dengan flag --use-apiserver-cache . Selain mengurangi latensi, opsi ini juga akan mengurangi beban pada dll.
Sharding harus digunakan dengan hati-hati dan pemantauan tambahan harus dilakukan untuk memastikan bahwa sharding sudah diatur dan berfungsi seperti yang diharapkan (mis. instance untuk setiap shard dari total shard telah dikonfigurasi).
Sharding otomatis memungkinkan setiap shard menemukan posisi nominalnya saat diterapkan dalam StatefulSet yang berguna untuk mengonfigurasi sharding secara otomatis. Ini adalah fitur eksperimental dan dapat rusak atau dihapus tanpa pemberitahuan.
Untuk mengaktifkan sharding otomatis, kube-state-metrics harus dijalankan oleh StatefulSet dan nama pod serta namespace harus diserahkan ke proses kube-state-metrics melalui flag --pod dan --pod-namespace . Contoh manifes yang menunjukkan fungsi autosharding dapat ditemukan di /examples/autosharding .
Cara men-deploy shard ini berguna ketika Anda ingin mengelola shard KSM melalui satu sumber daya Kubernetes (dalam hal ini satu StatefulSet ) daripada memiliki satu Deployment per shard. Keuntungannya bisa sangat signifikan ketika menerapkan pecahan dalam jumlah besar.
Kelemahan menggunakan penyiapan sharded otomatis berasal dari strategi peluncuran yang didukung oleh StatefulSet . Ketika dikelola oleh StatefulSet , pod akan diganti satu per satu dan setiap pod akan dihentikan terlebih dahulu lalu dibuat ulang. Selain peluncurannya lebih lambat, hal ini juga menyebabkan waktu henti yang singkat untuk setiap shard. Jika scrape Prometheus terjadi saat peluncuran, beberapa metrik yang diekspor oleh kube-state-metrics mungkin akan hilang.
Untuk metrik pod, metrik tersebut dapat dipecah per node dengan tanda berikut:
--node=$(NODE_NAME)
Setiap pod kube-state-metrics menggunakan FieldSelector (spec.nodeName) untuk melihat/mendaftar metrik pod hanya pada node yang sama.
Contoh daemonset kube-state-metrics:
apiVersion: apps/v1 kind: DaemonSet spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resource=pods - --node=$(NODE_NAME) env: - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName
Untuk melacak metrik pada pod yang belum ditetapkan, Anda perlu menambahkan penerapan tambahan dan menyetel --track-unscheduled-pods , seperti yang ditunjukkan dalam contoh berikut:
apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resources=pods - --track-unscheduled-pods
Metrik lainnya dapat di-sharding melalui sharding Horizontal.
Instal proyek ini ke $GOPATH Anda menggunakan go get :
go get k8s.io/kube-state-metrics
Cukup jalankan perintah berikut di folder root ini, yang akan membuat biner mandiri yang tertaut secara statis dan membangun image Docker:
make container
Cukup buat dan jalankan kube-state-metrics di dalam pod Kubernetes yang memiliki token akun layanan yang memiliki akses hanya baca ke cluster Kubernetes.
Tumpukan ( kube-prometheus ) menginstal kube-state-metrics sebagai salah satu komponennya; kamu tidak perlu menginstal kube-state-metrics jika kamu menggunakan tumpukan kube-prometheus.
Jika Anda ingin merevisi konfigurasi default untuk kube-prometheus, misalnya untuk mengaktifkan metrik non-default, lihat Menyesuaikan Kube-Prometheus.
Untuk menerapkan proyek ini, Anda cukup menjalankan kubectl apply -f examples/standard dan layanan serta penerapan Kubernetes akan dibuat. (Catatan: Sesuaikan apiVersion dari beberapa sumber daya jika versi cluster kubernetes Anda bukan 1.8+, periksa file yaml untuk informasi lebih lanjut).
Agar Prometheus menemukan instance kube-state-metrics, disarankan untuk membuat konfigurasi scrape Prometheus khusus untuk kube-state-metrics yang mengambil kedua titik akhir metrik. Penemuan berbasis anotasi tidak disarankan karena hanya satu titik akhir yang dapat dipilih, ditambah lagi kube-state-metrics dalam banyak kasus memiliki persyaratan autentikasi dan otorisasi khusus karena pada dasarnya memberikan akses baca melalui titik akhir metrik ke sebagian besar informasi yang tersedia padanya.
Catatan: Pengguna Google Kubernetes Engine (GKE) - GKE memiliki izin peran yang ketat yang akan mencegah pembuatan peran kube-state-metrics dan pengikatan peran. Untuk mengatasinya, Anda dapat memberikan peran admin cluster pada identitas GCP Anda dengan menjalankan kalimat berikut:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud info --format='value(config.account)')
Perlu diperhatikan bahwa identitas GCP Anda peka terhadap huruf besar-kecil, namun gcloud info pada Google Cloud SDK 221.0.0 tidak. Artinya, jika anggota IAM Anda berisi huruf kapital, kalimat di atas mungkin tidak cocok untuk Anda. Jika Anda mendapatkan 403 respons terlarang setelah menjalankan perintah di atas dan kubectl apply -f examples/standard , periksa anggota IAM yang terkait dengan akun Anda di https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID . Jika berisi huruf kapital, Anda mungkin perlu menyetel tanda --user pada perintah di atas ke peran peka huruf besar-kecil yang tercantum di https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID.
Setelah menjalankan langkah di atas, jika Anda melihat Clusterrolebinding "cluster-admin-binding" created , Anda dapat melanjutkan penyiapan layanan ini.
Titik akhir healthcheck berikut tersedia ( self mengacu pada port telemetri, sedangkan main mengacu pada port eksposisi):
/healthz (diekspos di main ): Mengembalikan 200 kode status jika aplikasi sedang berjalan. Kami menyarankan untuk menggunakan ini untuk pemeriksaan startup.
/livez (diekspos di main ): Mengembalikan kode status 200 jika aplikasi tidak terpengaruh oleh pemadaman Server API Kubernetes. Kami merekomendasikan untuk menggunakan ini untuk pemeriksaan keaktifan.
/readyz (expose on self ): Mengembalikan 200 kode status jika aplikasi siap menerima permintaan dan mengekspos metrik. Kami merekomendasikan penggunaan ini untuk pemeriksaan kesiapan.
Perhatikan bahwa tidak disarankan menggunakan titik akhir metrik telemetri untuk penyelidikan apa pun saat memproksi data eksposisi.
Jika kamu ingin menjalankan kube-state-metrics di lingkungan yang tidak memiliki peran pembaca cluster, kamu dapat:
membuat akun layanan
apiVersion: v1kind: ServiceAccountmetadata: nama: kube-state-metrics namespace: namespace-Anda-tempat-metrik-negara-kube-akan-diterapkan
berikan hak istimewa view pada namespace tertentu (menggunakan roleBinding) ( catatan: Anda dapat menambahkan roleBinding ini ke semua NS yang ingin diakses oleh akun layanan Anda )
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: kube-state-metrics namespace: project1roleRef: apiGroup: rbac.authorization.k8s.io jenis: ClusterRole nama: viewsubjek: - jenis: ServiceAccountname: kube-state-metricsnamespace: namespace-Anda-di mana-kube-state-metrics-akan-digunakan
lalu tentukan satu set namespace (menggunakan opsi --namespaces ) dan satu set objek kubernetes (menggunakan --resources ) yang dapat diakses oleh akun layanan Anda dalam konfigurasi penerapan kube-state-metrics
spesifikasi: templat: spesifikasi: wadah:
- nama: kube-state-metricsargs:
- '--resources=pod' - '--namespace=project1'Untuk daftar lengkap argumen yang tersedia, lihat dokumentasi di docs/developer/cli-arguments.md
Dimulai dari bagan kube-state-metrics v2.13.3 (gambar kube-state-metrics v1.9.8 ), bagan Helm resmi dipertahankan di prometheus-community/helm-charts. Mulai dari bagan kube-state-metrics v3.0.0 hanya gambar kube-state-metrics v2.0.0 + yang didukung.
Saat mengembangkan, uji dump metrik terhadap cluster Kubernetes lokal Anda dengan menjalankan:
Pengguna dapat mengganti alamat apiserver di file KUBE-CONFIG dengan baris perintah
--apiserver.
go install kube-state-metrics --port=8080 --telemetry-port=8081 --kubeconfig=<KUBE-CONFIG> --apiserver=<APISERVER>
Lalu keritingkan titik akhir metrik
curl localhost:8080/metrics
Untuk menjalankan tes e2e secara lokal lihat dokumentasi di tes/README.md.
Saat mengembangkan, ada pola kode tertentu yang harus diikuti untuk meningkatkan pengalaman kontribusi Anda dan kemungkinan lulus tes e2e dan ci lainnya. Untuk mempelajari lebih lanjut tentangnya, lihat dokumentasi di docs/developer/guide.md.
Proyek ini disponsori oleh SIG Instrumentasi.
Terdapat juga saluran untuk #kube-state-metrics di Slack Kubernetes.
Anda juga dapat bergabung dengan milis SIG Instrumentation. Biasanya ini akan menambahkan undangan untuk pertemuan berikutnya ke kalendermu, yang mana topik seputar metrik kube-state dapat didiskusikan.
Pertemuan Reguler SIG: Kamis pukul 9:30 PT (Waktu Pasifik) (dua mingguan). Konversikan ke zona waktu Anda.
Pertemuan Triage Reguler: Kamis pukul 9:30 PT (Waktu Pasifik) (dua mingguan - bergantian dengan pertemuan reguler). Konversikan ke zona waktu Anda.
