Rekomendasi untuk menggunakan kluster ACK Pro berskala besar - Container Service for Kubernetes

Kinerja dan ketersediaan kluster Container Service for Kubernetes (ACK) dipengaruhi oleh jumlah sumber daya kluster, frekuensi akses sumber daya, serta pola akses. Kombinasi variabel ini yang berbeda memberikan tekanan berbeda pada API Server dan menghasilkan kinerja yang berbeda pula. Pada kluster ACK Pro berskala besar—biasanya dengan lebih dari 500 node atau 10.000 Pod—administrator kluster harus merencanakan dan menggunakan kluster secara tepat berdasarkan kondisi bisnis aktual serta memantau metrik secara ketat untuk memastikan stabilitas dan ketersediaan kluster.

Panduan membaca

Topik ini ditujukan bagi pengembang dan administrator kluster ACK Pro, serta menyediakan rekomendasi umum untuk perencanaan dan penggunaan kluster berskala besar. Sesuaikan rekomendasi tersebut dengan lingkungan kluster dan kebutuhan bisnis Anda.

Berdasarkan model tanggung jawab bersama, ACK mengelola keamanan komponen lapisan kontrol kluster—termasuk komponen lapisan kontrol Kubernetes dan etcd—serta infrastruktur Alibaba Cloud yang mendasarinya. Anda bertanggung jawab atas keamanan aplikasi bisnis Anda dan konfigurasi sumber daya cloud Anda. Untuk detailnya, lihat Model tanggung jawab bersama.

Tahap perencanaan

Kluster tunggal vs. beberapa kluster

Kluster berskala besar tunggal mengurangi beban manajemen dan meningkatkan pemanfaatan sumber daya. Namun, dalam beberapa skenario bisnis, membagi layanan ke beberapa kluster justru lebih masuk akal.

Pertimbangkan penggunaan beberapa kluster saat:

Pertimbangan	Kapan membagi
Isolasi	Mencegah masalah di satu lingkungan (misalnya, pengujian) memengaruhi produksi. Pembagian kluster mengurangi jangkauan dampak kegagalan.
Distribusi geografis	Menyebarkan kluster di wilayah tertentu untuk memenuhi persyaratan ketersediaan dan latensi bagi pengguna akhir.
Batas ukuran kluster tunggal	Lapisan kontrol ACK yang dikelola menyesuaikan diri terhadap kluster dengan skala berbeda melalui auto scaling dan optimasi kinerja komponen kluster. Namun, arsitektur Kubernetes memiliki batas kinerja inheren, dan kluster yang terlalu besar dapat memengaruhi ketersediaan serta kinerja. Sebelum merencanakan kluster berskala besar, tinjau batas kapasitas dan SLO dari komunitas, lalu periksa kuota Anda di Quota Center. Jika kebutuhan Anda melebihi batas komunitas atau ACK, bagi menjadi beberapa kluster.

Untuk mengelola beberapa kluster dalam tugas seperti penerapan aplikasi, manajemen trafik, distribusi pekerjaan, dan pemantauan, aktifkan manajemen armada.

Pertahankan kluster pada versi terbaru

Versi Kubernetes yang lebih baru mencakup peningkatan stabilitas, kinerja, dan skalabilitas yang secara langsung menguntungkan kluster berskala besar. Contoh penting:

v1.31: kube-apiserver menyediakan pembacaan konsisten untuk permintaan List dari cache-nya, mengurangi akses langsung ke etcd dan menurunkan beban etcd. Lihat Pembacaan konsisten dari cache.
v1.33: kube-apiserver menggunakan encoding streaming (StreamingCollectionEncodingToJSON dan StreamingCollectionEncodingToProtobuf) untuk operasi List, mengurangi penggunaan memori kube-apiserver pada skala besar. Lihat Respons List streaming.
v1.34: kube-apiserver mendukung caching snapshot dari versi historis resource, meningkatkan kinerja baca dan tulis. Lihat Cache API server yang dapat disnapshot.

ACK merilis versi Kubernetes yang didukung secara sinkron dengan komunitas dan menghentikan dukungan untuk versi yang kedaluwarsa—termasuk menghentikan rilis fitur baru, perbaikan bug, dan patch keamanan—serta hanya memberikan dukungan teknis terbatas untuk versi kedaluwarsa tersebut. Pantau pengumuman rilis versi melalui saluran seperti dokumentasi, pemberitahuan konsol, dan pesan internal, serta segera lakukan peningkatan untuk menghindari potensi masalah keamanan dan stabilitas kluster.

Versi yang didukung: Panduan versi
Pertimbangan dan prosedur peningkatan: Tingkatkan kluster
Peningkatan manual: Tingkatkan kluster ACK secara manual
Peningkatan otomatis: Tingkatkan kluster secara otomatis

Gunakan lapisan kontrol preset ACK Pro

Lapisan kontrol kluster ACK Pro menggunakan arsitektur auto-scaling. Pada kluster ultra-besar atau di bawah konkurensi tinggi yang tiba-tiba, penundaan respons dari scale-out elastis dapat memengaruhi kelangsungan bisnis. Lapisan kontrol preset ACK Pro mengalokasikan dan mematok sumber daya lapisan kontrol di awal, menjaga kapasitas konkurensi API dan penjadwalan Pod pada tingkat tinggi yang dijamin. Solusi ini cocok untuk pelatihan dan inferensi AI, kluster ultra-besar, serta workload yang sangat kritis.

Dengan mematok sumber daya lapisan kontrol dan konfigurasi garis dasar API Server, lapisan kontrol preset ACK Pro menghilangkan ketidakpastian scale-out elastis sejak awal, alih-alih mengandalkan mekanisme elastis untuk mengejar ketinggalan setelah kejadian. Hal ini menjaga kinerja lapisan kontrol tetap dapat diprediksi kapan pun.

Untuk informasi selengkapnya, lihat Lapisan kontrol preset ACK Pro.

Monitor batas sumber daya kluster

Tetap berada di bawah batas berikut untuk menjaga ketersediaan dan kinerja pada kluster berskala besar.

Sumber Daya	Batas	Tindakan
Ukuran database etcd (DB Size)	Pertahankan di bawah 8 GB. Database etcd yang terlalu besar menurunkan kinerja, termasuk latensi baca/tulis data, konsumsi sumber daya sistem, dan latensi pemilihan. Hal ini juga membuat pemulihan layanan dan data menjadi lebih sulit serta memakan waktu lebih lama.	Pertahankan ukuran total DB etcd di bawah 8 GB: Kontrol jumlah total sumber daya kluster dan segera bersihkan sumber daya yang tidak digunakan. Untuk sumber daya yang sering dimodifikasi, pertahankan ukuran setiap objek di bawah 100 KB. Setiap pembaruan pasangan kunci-nilai di etcd menghasilkan versi historis baru. Dalam skenario di mana objek besar diperbarui secara berkala, etcd mengonsumsi lebih banyak sumber daya untuk menyimpan versi historis tersebut.
Total data per jenis sumber daya di etcd	Pertahankan di bawah 800 MB per jenis. Jika volume total suatu jenis sumber daya terlalu besar, klien yang melakukan list semua sumber daya jenis tersebut akan mengonsumsi sumber daya sistem yang signifikan. Dalam kasus parah, API server atau custom controller mungkin gagal melakukan inisialisasi.	Saat mendefinisikan CustomResourceDefinition (CRD) baru, perkirakan jumlah akhir custom resource (CR) terlebih dahulu. Saat menerapkan chart dengan Helm, perhatikan bahwa Helm membuat rilis untuk melacak status penerapan. Secara default, Helm menyimpan informasi rilis dalam Secrets. Di kluster berskala besar, menyimpan informasi rilis dalam jumlah besar di Secrets dapat melebihi batas Kubernetes untuk ukuran total Secret. Gunakan backend penyimpanan SQL Helm sebagai gantinya.
Koneksi dan bandwidth CLB API Server	Bandwidth maksimum: 5.120 Mbps; lihat Instans CLB untuk batas koneksi. Melebihi batas koneksi atau bandwidth CLB dapat menyebabkan node masuk ke status Not Ready.	Untuk kluster dengan 1.000 node atau lebih, gunakan instans Classic Load Balancer (CLB) dengan model pay-by-usage. Gunakan mode koneksi langsung ENI (Elastic Network Interface) saat kluster berskala besar mengakses layanan Kubernetes di namespace Default. Kluster yang dibuat setelah Februari 2023 dengan Kubernetes 1.20 atau lebih baru menggunakan koneksi langsung ENI secara default. Lihat Akses API server menggunakan titik akhir internal.
Layanan per namespace	Pertahankan di bawah 5.000	kubelet menyuntikkan informasi layanan sebagai variabel lingkungan ke dalam Pod. Terlalu banyak layanan per namespace menyebabkan startup Pod lambat atau gagal. Atur `enableServiceLinks: false` dalam `podSpec` untuk menonaktifkannya. Lihat Mengakses layanan.
Total layanan di kluster	Pertahankan di bawah 10.000 total; 500 untuk layanan tipe LoadBalancer	Layanan berlebih meningkatkan aturan jaringan yang diproses kube-proxy, menurunkan kinerjanya. Untuk layanan tipe LoadBalancer, penundaan sinkronisasi ke CLB dapat mencapai hitungan menit saat jumlahnya tinggi.
Pod backend per titik akhir layanan	Pertahankan di bawah 3.000	kube-proxy di setiap node memantau pembaruan Service untuk memperbarui aturan jaringan di node tersebut. Saat suatu layanan memiliki banyak titik akhir, objek Endpoints-nya besar, dan setiap pembaruan objek Endpoints mentransfer trafik signifikan antara API server dan kube-proxy. Semakin besar kluster, efek badai semakin terasa. Untuk mengatasi hal ini, kube-proxy menggunakan EndpointSlices secara default di kluster v1.19 dan lebih baru. Gunakan EndpointSlices alih-alih Endpoints di kluster berskala besar—EndpointSlices membagi titik akhir menjadi chunk yang lebih kecil, mengurangi data yang ditransmisikan per perubahan. Jika Anda menggunakan custom controller yang membaca Endpoints secara langsung, pertahankan jumlah di bawah 1.000 per objek Endpoints; di atas angka ini, objek akan dipotong secara otomatis. Lihat Titik akhir melebihi kapasitas.
Total titik akhir di semua layanan	Pertahankan di bawah 64.000	Titik akhir berlebih membebani API Server dan menurunkan kinerja jaringan.
Pod Tertunda	Pertahankan di bawah 10.000	Jumlah Pod pending yang tinggi menyebabkan scheduler menghasilkan event berulang, yang dapat memicu badai event.
Secrets di kluster dengan enkripsi KMS V1	Pertahankan di bawah 2.000	Dengan KMS V1, setiap enkripsi menghasilkan kunci enkripsi data (DEK) baru. Saat startup atau peningkatan kluster, semua secret didekripsi secara berurutan. Terlalu banyak secret memperlambat startup secara signifikan. Lihat Enkripsi saat diam untuk secret menggunakan KMS.

Tahap konfigurasi

Konfigurasikan parameter komponen lapisan kontrol

kube-apiserver

kube-apiserver membatasi penanganan permintaan konkuren untuk melindungi lapisan kontrol. Saat batas terlampaui, ia mengembalikan HTTP 429 (Too Many Requests) dan menginstruksikan klien untuk mencoba lagi. Tanpa throttling sisi server, permintaan berlebih dapat merusak lapisan kontrol.

Mekanisme throttling

Terdapat dua mekanisme throttling tergantung versi Kubernetes:

Sebelum v1.18: Hanya throttling konkurensi maksimum. Parameter startup --max-requests-inflight dan --max-mutating-requests-inflight masing-masing membatasi konkurensi permintaan baca dan tulis. Tidak ada diferensiasi prioritas—permintaan lambat berprioritas rendah dapat menghalangi permintaan mendesak. Kluster ACK Pro mendukung penyesuaian parameter ini. Lihat Sesuaikan parameter komponen lapisan kontrol.

v1.18 dan lebih baru: API Priority and Fairness (APF) menyediakan manajemen trafik detail halus. APF mengklasifikasikan dan mengisolasi permintaan berdasarkan prioritas, memastikan permintaan prioritas tinggi diproses terlebih dahulu sambil menjaga keadilan. APF masuk fase Beta di v1.20 dan diaktifkan secara default. Di kluster yang menjalankan v1.20 atau lebih baru, kapasitas total permintaan konkuren sama dengan jumlah --max-requests-inflight dan --max-mutating-requests-inflight. APF menggunakan dua jenis CRD untuk mengalokasikan kapasitas tersebut.

PriorityLevelConfiguration: Menentukan level prioritas dan proporsi konkurensi total yang diterima setiap level.
FlowSchema: Memetakan permintaan masuk ke PriorityLevelConfiguration.

kube-apiserver secara otomatis memelihara objek-objek ini. Untuk melihat konfigurasi saat ini, tampilkan PriorityLevelConfiguration:

ACK menambahkan ack-system-leader-election dan ack-default ke FlowSchema untuk komponen inti ACK. Entri lainnya konsisten dengan nilai default komunitas Kubernetes.

kubectl get PriorityLevelConfiguration
# Expected output
NAME              TYPE      ASSUREDCONCURRENCYSHARES   QUEUES   HANDSIZE   QUEUELENGTHLIMIT   AGE
catch-all         Limited   5                          <none>   <none>     <none>             4m20s
exempt            Exempt    <none>                     <none>   <none>     <none>             4m20s
global-default    Limited   20                         128      6          50                 4m20s
leader-election   Limited   10                         16       4          50                 4m20s
node-high         Limited   40                         64       6          50                 4m20s
system            Limited   30                         64       6          50                 4m20s
workload-high     Limited   40                         128      6          50                 4m20s
workload-low      Limited   100                        128      6          50                 4m20s

Tampilkan FlowSchema:

kubectl get flowschemas
# Expected output
NAME                           PRIORITYLEVEL     MATCHINGPRECEDENCE   DISTINGUISHERMETHOD   AGE     MISSINGPL
exempt                         exempt            1                    <none>                4d18h   False
probes                         exempt            2                    <none>                4d18h   False
system-leader-election         leader-election   100                  ByUser                4d18h   False
endpoint-controller            workload-high     150                  ByUser                4d18h   False
workload-leader-election       leader-election   200                  ByUser                4d18h   False
system-node-high               node-high         400                  ByUser                4d18h   False
system-nodes                   system            500                  ByUser                4d18h   False
ack-system-leader-election     leader-election   700                  ByNamespace           4d18h   False
ack-default                    workload-high     800                  ByNamespace           4d18h   False
kube-controller-manager        workload-high     800                  ByNamespace           4d18h   False
kube-scheduler                 workload-high     800                  ByNamespace           4d18h   False
kube-system-service-accounts   workload-high     900                  ByNamespace           4d18h   False
service-accounts               workload-low      9000                 ByUser                4d18h   False
global-default                 global-default    9900                 ByUser                4d18h   False
catch-all                      catch-all         10000                ByUser                4d18h   False

Menanggapi throttling

Deteksi throttling dengan memeriksa respons HTTP 429 atau memantau metrik apiserver_flowcontrol_rejected_requests_total. Saat throttling terjadi:

Gunakan lapisan kontrol preset ACK Pro: Lapisan kontrol preset mematok sumber daya garis dasar API Server dan langsung menyediakan kapasitas pemrosesan konkurensi tinggi yang dijamin. Untuk informasi selengkapnya, lihat Lapisan kontrol preset ACK Pro.
Sesuaikan PriorityLevelConfiguration:
- Untuk permintaan yang tidak boleh mengalami throttling, buat FlowSchema baru dan petakan ke level prioritas tinggi seperti workload-high atau exempt. Gunakan exempt dengan hati-hati karena permintaan exempt tidak mengalami throttling oleh APF. Anda juga dapat membuat PriorityLevelConfiguration baru dengan konkurensi lebih tinggi untuk permintaan prioritas tinggi.
- Untuk klien lambat yang menyebabkan beban tinggi pada API Server, buat FlowSchema yang memetakan permintaan tersebut ke PriorityLevelConfiguration dengan konkurensi rendah.

kube-controller-manager dan kube-scheduler

Setelah meningkatkan ke lapisan kontrol preset ACK Pro, parameter terkait QPS yang digunakan kube-controller-manager dan kube-scheduler untuk berkomunikasi dengan API Server disesuaikan secara otomatis berdasarkan tier yang dipilih.

kubelet

Nilai default kube-api-qps adalah 5 dan nilai default kube-api-burst adalah 10, yang cukup untuk sebagian besar kluster. Jika Anda mengamati pembaruan status Pod yang lambat, penundaan penjadwalan, atau pemasangan volume persisten yang lambat, tingkatkan nilai-nilai ini. Lihat Sesuaikan konfigurasi kubelet untuk kelompok node.

Penting

Menambah QPS kubelet meningkatkan laju komunikasi setiap node dengan API Server. Tingkatkan nilai secara bertahap dan pantau kinerja API Server untuk menghindari kelebihan beban pada lapisan kontrol.
ACK membatasi pembaruan kubelet paralel hingga maksimal 10 node per batch per kelompok node untuk melindungi stabilitas lapisan kontrol selama rollout.

Rencanakan workload berskala besar

Nonaktifkan pemasangan token ServiceAccount otomatis untuk Pod yang tidak memerlukan akses API

kubelet membuat koneksi Watch persisten untuk setiap secret yang dipasang ke dalam Pod. Sejumlah besar koneksi Watch menurunkan kinerja lapisan kontrol.

Sebelum Kubernetes v1.22: Saat tidak ada ServiceAccount yang ditentukan, Kubernetes secara otomatis memasang secret untuk ServiceAccount default. Untuk pekerjaan batch dan Pod aplikasi yang tidak mengakses API Server, atur automountServiceAccountToken: false untuk melewati pemasangan ini. Hal ini menghindari pembuatan secret dan koneksi Watch yang tidak perlu. Lihat Nonaktifkan pemasangan kredensial API otomatis.
Kubernetes v1.22 dan lebih baru: Gunakan TokenRequest API untuk mendapatkan token berumur pendek yang secara otomatis dirotasi, dipasang sebagai volume projected. Hal ini meningkatkan keamanan dan mengurangi jumlah koneksi Watch yang dipelihara kubelet. Lihat Gunakan proyeksi volume token ServiceAccount.

Kendalikan jumlah dan ukuran objek Kubernetes

Bersihkan sumber daya yang tidak digunakan—ConfigMap, Secrets, PVC—segera untuk mengurangi overhead sistem dan menjaga etcd tetap ringkas.

Batasi riwayat penerapan: Atur revisionHistoryLimit ke nilai lebih rendah untuk mengontrol berapa banyak Set Replika lama yang dipertahankan Kubernetes. Nilai default adalah 10. Di kluster dengan banyak deployment yang sering diperbarui, retensi riwayat tinggi meningkatkan overhead manajemen kube-controller-manager. Lihat revisionHistoryLimit.
Bersihkan pekerjaan selesai secara otomatis: Gunakan ttlSecondsAfterFinished untuk menghapus pekerjaan selesai dan Pod-nya setelah periode tertentu. Hal ini mencegah akumulasi objek pekerjaan di kluster yang menjalankan banyak CronJob. Lihat Controller TTL untuk sumber daya selesai.

Konfigurasikan batas sumber daya yang sesuai untuk komponen berbasis informer

Komponen berbasis informer (seperti controller dan kube-scheduler) memelihara cache lokal dari sumber daya yang mereka pantau. Penggunaan memorinya meningkat seiring jumlah dan ukuran sumber daya tersebut.

Di kluster berskala besar, Anda harus memperhatikan konsumsi memori komponen-komponen ini untuk mencegah error kehabisan memori (OOM). Saat komponen kehabisan memori, ia dihentikan dan dimulai ulang. Setiap restart memicu siklus List-Watch baru, yang memberikan tekanan tambahan pada API Server. Restart berulang menciptakan loop yang menurunkan kinerja lapisan kontrol.

Tingkatkan batas memori komponen berbasis informer agar sesuai dengan skala sumber daya aktual yang mereka kelola.

Konfigurasikan webhook dan layanan API secara tepat

Jika webhook atau layanan API dikonfigurasi untuk kluster, permintaan untuk sumber daya tertentu melewati server webhook dan layanan API. Respons lambat dari server webhook atau layanan API kustom menyebabkan permintaan menumpuk di API Server, memperlambat respons. Pantau pemanfaatan sumber daya server webhook dan layanan API serta lakukan scale-out tepat waktu.

Tahap runtime

Rencanakan laju scaling

Lapisan kontrol biasanya mengalami tekanan rendah selama operasi stabil, bahkan di kluster besar. Risiko muncul dari perubahan cepat berskala besar—membuat atau menghapus banyak sumber daya sekaligus, atau melakukan scaling banyak node secara bersamaan.

Sebagai contoh, kluster 5.000 node yang menjalankan workload stabil mungkin menunjukkan sedikit tekanan lapisan kontrol. Namun, kluster 1.000 node yang membuat 10.000 pekerjaan berumur pendek dalam satu menit, atau melakukan scale-out 2.000 node secara bersamaan, dapat mendorong lapisan kontrol ke batasnya.

Penting

Angka-angka berikut merupakan panduan referensi, bukan batas mutlak. Banyak faktor memengaruhi kapasitas lapisan kontrol. Selalu lakukan scaling secara bertahap: tingkatkan laju hanya setelah memastikan lapisan kontrol merespons secara normal.

Node scaling:

Untuk kluster dengan lebih dari 2.000 node, saat melakukan scaling manual melalui kelompok node:

Kelompok node tunggal, operasi tunggal: tidak lebih dari 100 node
Di beberapa kelompok node secara bersamaan: tidak lebih dari 300 node total

Pod Scaling:

Saat Pod dikaitkan dengan titik akhir layanan, setiap event scaling memperbarui Endpoints atau EndpointSlice dan mendorong pembaruan tersebut ke semua node—menciptakan event propagasi data di seluruh kluster. Di kluster besar, efek ini diperkuat.

Untuk kluster dengan lebih dari 5.000 node:

Pod yang tidak dikaitkan dengan titik akhir layanan: QPS pembaruan ≤ 300/detik
Pod yang dikaitkan dengan titik akhir layanan: QPS pembaruan ≤ 10/detik

Untuk deployment yang menggunakan strategi Rolling Update, atur nilai maxUnavailable dan maxSurge lebih kecil untuk mengurangi laju penggantian Pod.

Optimalkan pola akses klien

Saat jumlah sumber daya kluster meningkat, permintaan API Server yang sering memperkuat beban lapisan kontrol dan dapat menyebabkan kegagalan berantai. Ikuti panduan berikut saat membangun controller atau alat yang mengakses API Server.

Gunakan informer untuk akses data dari cache:

Gunakan informer client-go untuk membaca sumber daya dari cache lokal alih-alih mengeluarkan permintaan List langsung ke API Server.
Informers memelihara satu koneksi Watch dan melayani permintaan baca secara lokal, mengurangi beban API Server secara signifikan.

Optimalkan permintaan langsung ke API Server:

Atur resourceVersion=0 dalam permintaan List untuk membaca dari cache API Server alih-alih langsung ke etcd. Hal ini mengurangi round-trip API Server–etcd dan mempercepat respons:
```
k8sClient.CoreV1().Pods("").List(context.Background(), metav1.ListOptions{ResourceVersion: "0"})
```
Gunakan pemilih label dan pemilih bidang untuk mempersempit cakupan permintaan List dan mengurangi ukuran muatan respons. Catatan: etcd adalah penyimpanan kunci-nilai dan tidak dapat memfilter berdasarkan label atau bidang—API Server menangani pemfilteran tersebut dari cache-nya. Selalu gabungkan pemilih dengan resourceVersion=0 untuk menghindari akses langsung ke etcd.
Gunakan protobuf untuk sumber daya non-CRD. protobuf menggunakan memori dan bandwidth lebih sedikit daripada JSON. Tentukan beberapa tipe konten dalam header Accept untuk fallback ke JSON saat protobuf tidak tersedia:
```
Accept: application/vnd.kubernetes.protobuf, application/json
```
Lihat Representasi alternatif sumber daya.

Gunakan desain controller terpusat:

Hindari menyebarluaskan controller independen di setiap node yang masing-masing memantau seluruh status kluster. Saat startup, semua controller tersebut mengeluarkan permintaan List simultan untuk menyinkronkan status, yang dapat merusak lapisan kontrol.

Alih-alih itu, jalankan satu atau sekelompok kecil instance controller yang dikelola terpusat untuk seluruh kluster. Controller terpusat mengeluarkan satu permintaan List saat startup dan memelihara jumlah minimum koneksi Watch, secara dramatis mengurangi tekanan pada API Server.

Tahap observabilitas: monitor metrik lapisan kontrol

Gunakan dasbor pemantauan komponen lapisan kontrol untuk melacak metrik inti dan mendeteksi masalah lebih awal. Lihat Pemantauan komponen lapisan kontrol.

Penggunaan sumber daya lapisan kontrol

Anda dapat melihat penggunaan sumber daya semua komponen lapisan kontrol. Metrik terkait dijelaskan dalam tabel berikut.

Metrik	PromQL	Deskripsi
Penggunaan memori	`memory_utilization_byte{container="kube-apiserver"}`	Penggunaan memori API Server, dalam byte
Penggunaan CPU	`cpu_utilization_core{container="kube-apiserver"}*1000`	Penggunaan CPU API Server, dalam millicore
Konkurensi permintaan API	`sum(apiserver_flowcontrol_current_executing_seats)`	Konkurensi API Server, dalam satuan pengguna
Laju penjadwalan Pod	`rate(scheduler_schedule_attempts_total{result="scheduled"}[2m])`	Laju penjadwalan Pod, dalam Pod/detik
Ukuran database etcd	`max(etcd_mvcc_db_total_size_in_use_in_bytes)`	Ukuran database etcd, dalam byte

kube-apiserver

Untuk daftar lengkap metrik dan instruksi penampilan, lihat Metrik pemantauan komponen kube-apiserver.

Jumlah objek sumber daya:

Metrik	PromQL	Catatan
Jumlah objek sumber daya	`max by(resource)(apiserver_storage_objects)`	Kubernetes 1.22 dan lebih baru
	`max by(resource)(etcd_object_counts)`	Kubernetes 1.22 dan lebih lama; kedua metrik berdampingan di v1.22 untuk kompatibilitas

Latensi permintaan:

Metrik	PromQL	Deskripsi
Latensi permintaan GET	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="GET",resource!="",subresource!~"log\|proxy"}[$interval])) by (pod, verb, resource, subresource, scope, le))`	Waktu respons GET berdasarkan pod API Server, sumber daya, dan cakupan
Latensi permintaan LIST	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le))`	Waktu respons LIST berdasarkan pod API Server, sumber daya, dan cakupan
Write request latency	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb!~"GET\|WATCH\|LIST\|CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le))`	Waktu respons permintaan mutasi berdasarkan verb, sumber daya, dan cakupan

Throttling permintaan:

Metrik	PromQL	Deskripsi
Laju throttling permintaan	`sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name)`	Laju throttling untuk permintaan baca; `No data` atau `0` berarti tidak ada throttling
	`sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name)`	Laju throttling untuk permintaan mutasi

kube-scheduler

Untuk daftar lengkap metrik dan instruksi penampilan, lihat Metrik pemantauan komponen kube-scheduler.

Pod Tertunda:

Metrik	PromQL	Deskripsi
Pod pending scheduler	`scheduler_pending_pods{job="ack-scheduler"}`	Rincian berdasarkan tipe: `unschedulable` (tidak dapat dijadwalkan), `backoff` (gagal dan menunggu untuk mencoba lagi), `active` (siap dijadwalkan)

Latensi permintaan:

Metrik	PromQL	Deskripsi
Latensi permintaan kube-apiserver	`histogram_quantile($quantile, sum(rate(rest_client_request_duration_seconds_bucket{job="ack-scheduler"}[$interval])) by (verb,url,le))`	Waktu antara kube-scheduler mengirim permintaan dan kube-apiserver mengembalikan respons, berdasarkan verb dan URL

kube-controller-manager

Untuk daftar lengkap metrik dan instruksi penampilan, lihat Metrik pemantauan komponen kube-controller-manager.

Workqueue:

Metrik	PromQL	Deskripsi
Kedalaman antrian kerja	`sum(rate(workqueue_depth{job="ack-kube-controller-manager"}[$interval])) by (name)`	Laju perubahan panjang workqueue selama interval yang ditentukan
Penundaan pemrosesan workqueue	`histogram_quantile($quantile, sum(rate(workqueue_queue_duration_seconds_bucket{job="ack-kube-controller-manager"}[5m])) by (name, le))`	Waktu event menunggu di workqueue

etcd

Untuk daftar lengkap metrik dan instruksi penampilan, lihat Metrik pemantauan komponen etcd.

Jumlah pasangan kunci-nilai:

Metrik	PromQL	Deskripsi
Total KV Count	`etcd_debugging_mvcc_keys_total`	Jumlah total pasangan kunci-nilai di kluster etcd

Ukuran database:

Metrik	PromQL	Deskripsi
Ukuran disk	`etcd_mvcc_db_total_size_in_bytes`	Ukuran total database backend etcd
Penggunaan database	`etcd_mvcc_db_total_size_in_use_in_bytes`	Ukuran aktual database backend etcd yang digunakan

Dokumentasi terkait

Kuota dan batas kluster: Kuota dan batas
Perencanaan jaringan: Rencanakan Blok CIDR untuk kluster ACK yang dikelola
Konfigurasi workload keandalan tinggi: Konfigurasi workload yang direkomendasikan
Kemampuan lapisan kontrol untuk kluster skala ultra-besar: Lapisan kontrol preset ACK Pro mengalokasikan dan mematok sumber daya lapisan kontrol di awal untuk menjamin kapasitas konkurensi API dan penjadwalan Pod yang deterministik.
Penyelesaian masalah kluster: Troubleshooting dan FAQ tentang manajemen kluster