Kubernetes Hulu SLOs

Amazon EKS menjalankan kode yang sama dengan rilis Kubernetes hulu dan memastikan bahwa kluster EKS beroperasi dalam yang SLOs ditentukan oleh komunitas Kubernetes. Kubernetes Scalability Special Interest Group (SIG) mendefinisikan tujuan skalabilitas dan menyelidiki kemacetan dalam kinerja melalui dan. SLIs SLOs

SLIs adalah bagaimana kami mengukur sistem seperti metrik atau ukuran yang dapat digunakan untuk menentukan seberapa “baik” sistem berjalan, misalnya meminta latensi atau hitungan. SLOs tentukan nilai yang diharapkan saat sistem berjalan “baik”, misalnya latensi permintaan tetap kurang dari 3 detik. Kubernetes SLOs dan SLIs fokus pada kinerja komponen Kubernetes dan sepenuhnya independen dari Amazon EKS Service SLAs yang berfokus pada ketersediaan endpoint kluster EKS.

Kubernetes memiliki sejumlah fitur yang memungkinkan pengguna untuk memperluas sistem dengan add-on atau driver khusus, seperti driver CSI, webhook masuk, dan auto-scaler. Ekstensi ini dapat secara drastis memengaruhi kinerja klaster Kubernetes dengan berbagai cara, yaitu webhook penerimaan dengan failurePolicy=Ignore dapat menambahkan latensi ke permintaan API K8s jika target webhook tidak tersedia. SIG Kubernetes Scalability mendefinisikan skalabilitas menggunakan kerangka kerja “you promise, we promise”:

Kubernetes SLOs

Kubernetes SLOs tidak memperhitungkan semua plugin dan batasan eksternal yang dapat memengaruhi klaster, seperti penskalaan node pekerja atau webhook masuk. Ini SLOs berfokus pada komponen Kubernetes dan memastikan bahwa tindakan dan sumber daya Kubernetes beroperasi sesuai harapan. SLOs Bantuan pengembang Kubernetes memastikan bahwa perubahan pada kode Kubernetes tidak menurunkan kinerja untuk seluruh sistem.

Kuberntes Scalability SIG mendefinisikan SLO/ resmi berikut. SLIs Tim Amazon EKS secara teratur menjalankan tes skalabilitas pada kluster EKS SLOs/SLIs untuk memantau penurunan kinerja saat perubahan dibuat dan versi baru dirilis.

Tujuan	Definisi	SLO
Latensi permintaan API (bermutasi)	Latensi pemrosesan panggilan API yang bermutasi untuk objek tunggal untuk setiap pasangan (sumber daya, kata kerja), diukur sebagai persentil ke-99 selama 5 menit terakhir	Dalam instalasi Kubernetes default, untuk setiap pasangan (sumber daya, kata kerja), tidak termasuk sumber daya virtual dan agregat dan Definisi Sumber Daya Kustom, persentil ke-99 per hari klaster <= 1s
Latensi permintaan API (hanya-baca)	Latensi pemrosesan panggilan API hanya-baca non-streaming untuk setiap pasangan (sumber daya, ruang lingkup), diukur sebagai persentil ke-99 selama 5 menit terakhir	Dalam instalasi Kubernetes default, untuk setiap pasangan (sumber daya, cakupan), tidak termasuk sumber daya virtual dan agregat dan Definisi Sumber Daya Kustom, persentil ke-99 per hari klaster: (a) <= 1 detik jika (b) <= 30 detik sebaliknya (jika atau) scope=resource scope=namespace scope=cluster
Latensi startup pod	Latensi startup pod stateless yang dapat dijadwalkan, tidak termasuk waktu untuk menarik gambar dan menjalankan kontainer init, diukur dari stempel waktu pembuatan pod hingga saat semua kontainernya dilaporkan sebagai dimulai dan diamati melalui jam tangan, diukur sebagai persentil ke-99 selama 5 menit terakhir	Dalam instalasi Kubernetes default, persentil ke-99 per hari cluster <= 5s

Latensi Permintaan API

kube-apiserverTelah --request-timeout didefinisikan sebagai secara 1m0s default, yang berarti permintaan dapat berjalan hingga satu menit (60 detik) sebelum waktunya habis dan dibatalkan. Yang SLOs didefinisikan untuk Latensi dipecah oleh jenis permintaan yang sedang dibuat, yang dapat bermutasi atau hanya-baca:

Bermutasi

Mutasi permintaan di Kubernetes membuat perubahan pada sumber daya, seperti kreasi, penghapusan, atau pembaruan. Permintaan ini mahal karena perubahan tersebut harus ditulis ke backend etcd sebelum objek yang diperbarui dikembalikan. Etcd adalah penyimpanan nilai kunci terdistribusi yang digunakan untuk semua data klaster Kubernetes.

Latensi ini diukur sebagai persentil ke-99 selama 5 menit untuk pasangan (resource, verb) sumber daya Kubernetes, misalnya ini akan mengukur latensi untuk permintaan Create Pod dan Update Node request. Latensi permintaan harus <= 1 detik untuk memenuhi SLO.

Hanya baca

Permintaan hanya-baca mengambil satu sumber daya (seperti Dapatkan Pod X) atau koleksi (seperti “Dapatkan semua Pod dari Namespace X”). kube-apiserverMemelihara cache objek, sehingga sumber daya yang diminta dapat dikembalikan dari cache atau mereka mungkin perlu diambil dari etcd terlebih dahulu. Latensi ini juga diukur dengan persentil ke-99 selama 5 menit, namun permintaan hanya-baca dapat memiliki cakupan terpisah. SLO mendefinisikan dua tujuan yang berbeda:

• Untuk permintaan yang dibuat untuk satu sumber daya (yaitukubectl get pod -n mynamespace my-controller-xxx), latensi permintaan harus tetap <= 1 detik.

• Untuk permintaan yang dibuat untuk beberapa sumber daya dalam namespace atau cluster (misalnya,kubectl get pods -A) latensi harus tetap <= 30 detik

SLO memiliki nilai target yang berbeda untuk cakupan permintaan yang berbeda karena permintaan yang dibuat untuk daftar sumber daya Kubernetes mengharapkan detail semua objek dalam permintaan dikembalikan dalam SLO. Pada kelompok besar, atau koleksi sumber daya yang besar, ini dapat menghasilkan ukuran respons yang besar yang dapat memakan waktu untuk kembali. Misalnya, dalam klaster yang menjalankan puluhan ribu Pod dengan masing-masing Pod kira-kira 1 KiB saat dikodekan di JSON, mengembalikan semua Pod di cluster akan terdiri dari 10MB atau lebih. Klien Kubernetes dapat membantu mengurangi ukuran respons ini menggunakan APIList Chunking untuk mengambil koleksi sumber daya yang besar.

Latensi Startup Pod

SLO ini terutama berkaitan dengan waktu yang dibutuhkan dari pembuatan Pod hingga saat kontainer di Pod itu benar-benar memulai eksekusi. Untuk mengukur ini perbedaan dari stempel waktu pembuatan yang direkam pada Pod, dan ketika WATCH pada Pod tersebut melaporkan kontainer telah dimulai dihitung (tidak termasuk waktu untuk penarikan image kontainer dan eksekusi kontainer init). Untuk memenuhi SLO, persentil ke-99 per hari klaster Latensi Startup Pod ini harus tetap <=5 detik.

Perhatikan bahwa SLO ini mengasumsikan bahwa node pekerja sudah ada di klaster ini dalam keadaan siap untuk Pod yang akan dijadwalkan. SLO ini tidak memperhitungkan penarikan gambar atau eksekusi kontainer init, dan juga membatasi pengujian ke “pod stateless” yang tidak memanfaatkan plugin penyimpanan persisten.

Metrik Kubernetes SLI

Kubernetes juga meningkatkan Observabilitas di sekitar dengan SLIs menambahkan metrik Prometheus ke komponen Kubernetes yang melacak ini dari waktu ke waktu. SLIs Menggunakan Prometheus Query Language (PromQL) kita dapat membangun kueri yang menampilkan kinerja SLI dari waktu ke waktu di alat seperti dasbor Prometheus atau Grafana, di bawah ini adalah beberapa contoh di atas. SLOs

Latensi Permintaan Server API

Metrik	Definisi
apiserver_request_sli_duration_seconds	Distribusi latensi respons (tidak termasuk durasi webhook dan waktu tunggu antrian prioritas & keadilan) dalam hitungan detik untuk setiap kata kerja, grup, versi, sumber daya, subsumber daya, ruang lingkup, dan komponen.
apiserver_request_duration_seconds	Distribusi latensi respons dalam hitungan detik untuk setiap kata kerja, nilai dry run, grup, versi, sumber daya, subsumber daya, ruang lingkup, dan komponen.

catatan

apiserver_request_sli_duration_secondsMetrik tersedia mulai dari Kubernetes 1.27.

Anda dapat menggunakan metrik ini untuk menyelidiki waktu respons API Server dan jika ada hambatan dalam komponen Kubernetes atau plugin/komponen lainnya. Kueri di bawah ini didasarkan pada dasbor SLO komunitas.

API Request latency SLI (mutating) - kali ini tidak termasuk eksekusi webhook atau waktu menunggu dalam antrian. histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"CREATE|DELETE|PATCH|POST|PUT", subresource!~"proxy|attach|log|exec|portforward"}[5m])) by (resource, subresource, verb, scope, le)) > 0

Latensi Permintaan API Total (bermutasi) - ini adalah total waktu yang dibutuhkan permintaan di server API, kali ini mungkin lebih lama dari waktu SLI karena mencakup eksekusi webhook dan waktu tunggu Prioritas dan Keadilan API. histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"CREATE|DELETE|PATCH|POST|PUT", subresource!~"proxy|attach|log|exec|portforward"}[5m])) by (resource, subresource, verb, scope, le)) > 0

Dalam kueri ini kami mengecualikan permintaan API streaming yang tidak segera kembali, seperti kubectl port-forward atau kubectl exec request (subresource!~"proxy|attach|log|exec|portforward"), dan kami memfilter hanya untuk kata kerja Kubernetes yang memodifikasi objek (). verb=~"CREATE|DELETE|PATCH|POST|PUT" Kami kemudian menghitung persentil ke-99 dari latensi itu selama 5 menit terakhir.

Kita dapat menggunakan kueri serupa untuk permintaan API hanya baca, kita cukup memodifikasi kata kerja yang kita filter untuk menyertakan tindakan LIST Read only dan. GET Ada juga ambang batas SLO yang berbeda tergantung pada ruang lingkup permintaan, yaitu mendapatkan satu sumber daya atau mencantumkan sejumlah sumber daya.

API Request latency SLI (read-only) - kali ini tidak termasuk eksekusi webhook atau waktu menunggu dalam antrian. Untuk sumber daya tunggal (cakupan = sumber daya, ambang batas = 1s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Untuk kumpulan sumber daya di namespace yang sama (scope=namespace, threshold = 5s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))

Untuk kumpulan sumber daya di seluruh cluster (scope=cluster, threshold = 30s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Latensi Permintaan API Total (hanya-baca) - ini adalah total waktu yang dibutuhkan permintaan di server API, kali ini mungkin lebih lama dari waktu SLI karena termasuk eksekusi webhook dan waktu tunggu. Untuk sumber daya tunggal (cakupan = sumber daya, ambang batas = 1s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Untuk kumpulan sumber daya di namespace yang sama (scope=namespace, threshold = 5s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))

Untuk kumpulan sumber daya di seluruh cluster (scope=cluster, threshold = 30s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Metrik SLI memberikan wawasan tentang kinerja komponen Kubernetes dengan mengecualikan waktu yang dihabiskan permintaan untuk menunggu dalam antrean API Priority dan Fairness, bekerja melalui webhook masuk, atau ekstensi Kubernetes lainnya. Metrik total memberikan tampilan yang lebih holistik karena mencerminkan waktu aplikasi Anda menunggu respons dari server API. Membandingkan metrik ini dapat memberikan wawasan tentang di mana penundaan dalam pemrosesan permintaan diperkenalkan.

Latensi Startup Pod

Metrik	Definisi
kubelet_pod_start_sli_duration_seconds	Durasi dalam hitungan detik untuk memulai pod, tidak termasuk waktu untuk menarik gambar dan menjalankan kontainer init, diukur dari stempel waktu pembuatan pod hingga saat semua kontainernya dilaporkan seperti yang dimulai dan diamati melalui jam tangan
kubelet_pod_start_duration_seconds	Durasi dalam hitungan detik dari kubelet melihat pod untuk pertama kalinya hingga pod mulai berjalan. Ini tidak termasuk waktu untuk menjadwalkan pod atau skala kapasitas node pekerja.

catatan

kubelet_pod_start_sli_duration_secondstersedia mulai Kubernetes 1.27.

Mirip dengan kueri di atas, Anda dapat menggunakan metrik ini untuk mendapatkan wawasan tentang berapa lama penskalaan node, penarikan gambar, dan container init menunda peluncuran pod dibandingkan dengan tindakan Kubelet.

Latensi startup Pod SLI - ini adalah waktu dari pod yang dibuat hingga saat container aplikasi dilaporkan sedang berjalan. Ini termasuk waktu yang diperlukan untuk kapasitas node pekerja untuk tersedia dan pod dijadwalkan, tetapi ini tidak termasuk waktu yang diperlukan untuk menarik gambar atau untuk menjalankan container init. histogram_quantile(0.99, sum(rate(kubelet_pod_start_sli_duration_seconds_bucket[5m])) by (le))

Latensi startup Pod Total - ini adalah waktu yang dibutuhkan kubelet untuk memulai pod untuk pertama kalinya. Ini diukur dari saat kubelet menerima pod melalui WATCH, yang tidak menyertakan waktu untuk penskalaan atau penjadwalan node pekerja. Ini termasuk waktu untuk menarik gambar dan wadah init untuk dijalankan. histogram_quantile(0.99, sum(rate(kubelet_pod_start_duration_seconds_bucket[5m])) by (le))

SLOs di Cluster Anda

Jika Anda mengumpulkan metrik Prometheus dari sumber daya Kubernetes di kluster EKS Anda, Anda dapat memperoleh wawasan yang lebih dalam tentang kinerja komponen bidang kontrol Kubernetes.

Repo perf-tests mencakup dasbor Grafana yang menampilkan latensi dan metrik kinerja penting untuk cluster selama pengujian. Konfigurasi perf-tests memanfaatkan proyek open source yang dikonfigurasi untuk mengumpulkan metrik Kubernetes kube-prometheus-stack, tetapi Anda juga dapat menggunakan Amazon Managed Prometheus dan Amazon Managed Grafana.

Jika Anda menggunakan kube-prometheus-stack atau solusi Prometheus serupa, Anda dapat menginstal dasbor yang sama untuk mengamati di cluster Anda secara real SLOs time.

1. Pertama-tama Anda harus menginstal Aturan Prometheus yang digunakan di dasbor dengan. kubectl apply -f prometheus-rules.yaml Anda dapat mengunduh salinan aturan di sini: https://github.com/kubernetes/perf- tests/blob/master/clusterloader2/pkg/prometheus/manifests/prometheus -rules.yaml

   1. Pastikan untuk memeriksa namespace dalam file yang cocok dengan lingkungan Anda

   2. Verifikasi bahwa label cocok dengan nilai prometheus.prometheusSpec.ruleSelector helm jika Anda menggunakan kube-prometheus-stack

2. Anda kemudian dapat menginstal dasbor di Grafana. Dasbor json dan skrip python untuk menghasilkannya tersedia di sini: perf- https://github.com/kubernetes/ tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards

   1. slo.jsondasbor menampilkan kinerja cluster dalam kaitannya dengan Kubernetes SLOs

Pertimbangkan bahwa SLOs mereka berfokus pada kinerja komponen Kubernetes di klaster Anda, tetapi ada metrik tambahan yang dapat Anda tinjau yang memberikan perspektif atau wawasan berbeda ke klaster Anda. Proyek komunitas Kubernetes seperti K ube-state-metrics dapat membantu Anda menganalisis tren di klaster dengan cepat. Sebagian besar plugin dan driver umum dari komunitas Kubernetes juga memancarkan metrik Prometheus, memungkinkan Anda untuk menyelidiki hal-hal seperti autoscaler atau penjadwal kustom.

Panduan Praktik Terbaik Observabilitas memiliki contoh metrik Kubernetes lainnya yang dapat Anda gunakan untuk mendapatkan wawasan lebih lanjut.