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

Kinerja dan ketersediaan kluster ACK dipengaruhi oleh faktor-faktor seperti jumlah resource, frekuensi akses resource, dan mode akses. Kombinasi variabel ini yang berbeda dapat memberikan tekanan bervariasi pada API Server dan memengaruhi kinerjanya. Pada ACK managed cluster Pro berskala besar—yang biasanya memiliki lebih dari 500 node atau 10.000 Pod—administrator kluster harus merencanakan dan menggunakan kluster sesuai kebutuhan bisnis serta memantau metrik secara ketat untuk memastikan stabilitas dan ketersediaan kluster.

Pertimbangan dalam menggunakan kluster berskala besar

Membangun satu kluster berskala besar dapat mengurangi overhead manajemen dan operasi serta meningkatkan pemanfaatan resource dibandingkan dengan menggunakan beberapa kluster. Namun, dalam beberapa skenario bisnis kompleks, Anda mungkin perlu memisahkan layanan ke dalam beberapa kluster berdasarkan logika atau kebutuhan bisnis. Misalnya, Anda dapat memisahkan layanan non-produksi (pengujian) dari layanan produksi (pengembangan), atau memisahkan layanan database dari aplikasi frontend.

Jika Anda memiliki pertimbangan berikut, kami merekomendasikan penggunaan beberapa kluster daripada satu kluster berskala besar.

Klasifikasi	Deskripsi
Isolasi	Penggunaan beberapa kluster menjamin isolasi antar lingkungan berbeda, seperti kluster produksi dan pengujian. Praktik ini mencegah masalah di satu kluster memengaruhi seluruh layanan bisnis dan mengurangi radius dampak kegagalan.
Lokasi	Beberapa layanan harus ditempatkan di wilayah geografis tertentu yang lebih dekat dengan pengguna akhir untuk memenuhi persyaratan ketersediaan dan latensi rendah. Dalam skenario ini, kami merekomendasikan penempatan beberapa kluster di wilayah berbeda.
Batas ukuran kluster tunggal	Lapisan kontrol terkelola ACK menggunakan skalabilitas elastis dan optimasi kinerja komponen kluster untuk beradaptasi dengan kluster berbagai ukuran. Namun, arsitektur Kubernetes itu sendiri memiliki bottleneck kinerja. Kluster yang terlalu besar dapat memengaruhi ketersediaan dan kinerjanya. Sebelum merencanakan kluster berskala besar, pahami batas kapasitas dan SLO yang ditetapkan oleh komunitas Kubernetes. Selanjutnya, kunjungi Quota Center untuk melihat dan mengajukan peningkatan batas kuota untuk Container Service for Kubernetes. Jika kebutuhan Anda melebihi batas komunitas dan ACK, pertimbangkan untuk membagi bisnis Anda ke dalam beberapa kluster.

Untuk mengelola beberapa kluster dalam tugas seperti penerapan aplikasi, manajemen traffic, distribusi job, dan pemantauan global, Anda dapat mengaktifkan fleet management.

Cara menggunakan topik ini

Topik ini menyediakan rekomendasi umum untuk perencanaan dan penggunaan kluster berskala besar, ditujukan bagi pengembang dan administrator ACK managed cluster Pro. Anda dapat menyesuaikan rekomendasi ini berdasarkan lingkungan kluster dan kebutuhan bisnis spesifik Anda.

Catatan

Sesuai dengan model tanggung jawab bersama, ACK bertanggung jawab atas keamanan default komponen lapisan kontrol kluster, termasuk komponen lapisan kontrol Kubernetes dan etcd, serta infrastruktur Alibaba Cloud terkait. Anda bertanggung jawab atas perlindungan keamanan aplikasi bisnis yang diterapkan di cloud, serta konfigurasi aman dan pembaruan resource cloud Anda. Untuk informasi lebih lanjut, lihat Model tanggung jawab bersama.

Gunakan versi kluster terbaru
Pantau batas resource kluster
Konfigurasikan parameter komponen lapisan kontrol
Rencanakan laju penskalaan resource kluster
Optimalkan pola akses klien ke kluster
Rencanakan workload berskala besar
Pantau metrik lapisan kontrol

Gunakan versi kluster terbaru

Komunitas Kubernetes secara berkala merilis versi baru yang memperkenalkan fitur dan optimasi baru. Versi Kubernetes yang lebih baru menawarkan peningkatan dalam stabilitas, kinerja, dan skalabilitas. Optimasi khas meliputi hal-hal berikut:

Pada versi 1.31, kube-apiserver menyediakan pembacaan konsisten untuk permintaan List dari cache. Ini mengurangi kebutuhan untuk meneruskan permintaan ke etcd, meningkatkan efisiensi permintaan List, dan secara signifikan menurunkan beban pada etcd. Untuk informasi lebih lanjut, lihat Consistent Reads from Cache.
Pada versi 1.33, kube-apiserver menggunakan mekanisme encoding streaming, termasuk StreamingCollectionEncodingToJSON dan StreamingCollectionEncodingToProtobuf. Peningkatan ini mengoptimalkan kinerja operasi List dengan memproses permintaan pengambilan resource sebagai aliran. Untuk permintaan List yang melibatkan banyak resource, ini secara efektif mengurangi penggunaan memori kube-apiserver dan meningkatkan stabilitas sistem. Untuk informasi lebih lanjut, lihat Streaming List responses.

ACK secara berkala merilis versi Kubernetes yang didukung sejalan dengan komunitas Kubernetes dan secara bertahap menghentikan dukungan teknis untuk versi yang kedaluwarsa. Untuk versi kedaluwarsa, ACK berhenti merilis fitur baru, memperbaiki bug fungsional atau keamanan, dan hanya menyediakan dukungan teknis terbatas.

Anda dapat mengikuti informasi rilis versi melalui dokumen bantuan, pesan konsol, dan pesan internal. Segera lakukan upgrade kluster untuk menghindari potensi masalah keamanan dan stabilitas.

Untuk informasi tentang versi Kubernetes yang didukung oleh ACK, lihat Panduan Versi.
Untuk informasi tentang upgrade kluster, termasuk dampak, prosedur, catatan, dan metode, lihat Upgrade kluster.
Untuk informasi tentang operasi upgrade kluster, lihat Upgrade manual kluster ACK dan Upgrade otomatis kluster.

Pantau batas resource kluster

Untuk memastikan ketersediaan, stabilitas, dan kinerja kluster berskala besar, pantau batas-batas tersebut dan ikuti solusi yang direkomendasikan dalam tabel berikut.

Batas	Deskripsi	Solusi yang direkomendasikan
Ukuran database etcd (DB Size)	Database yang terlalu besar memengaruhi kinerja, termasuk latensi baca-tulis data, penggunaan resource sistem, dan penundaan pemilihan. Hal ini juga membuat pemulihan layanan dan data menjadi lebih sulit dan memakan waktu.	Pertahankan total ukuran DB etcd di bawah 8 GB. Kontrol jumlah total resource kluster dan segera bersihkan resource yang tidak digunakan. Untuk resource yang sering dimodifikasi, pertahankan ukuran satu resource di bawah 100 KB. Di etcd, setiap pembaruan pasangan kunci-nilai menghasilkan versi historis baru. Dalam skenario di mana objek data besar diperbarui secara berkala, etcd mengonsumsi lebih banyak resource untuk menyimpan versi historisnya.
Total ukuran data setiap tipe resource di etcd	Jika jumlah total objek untuk suatu tipe resource terlalu besar, permintaan klien untuk mencantumkan semuanya dapat mengonsumsi banyak resource sistem. Dalam kasus parah, hal ini dapat mencegah inisialisasi API Server atau custom controller.	Pertahankan total ukuran objek untuk setiap tipe resource di bawah 800 MB. Saat mendefinisikan CustomResourceDefinition (CRD) baru, rencanakan jumlah CR yang diharapkan sejak awal untuk memastikan total ukuran setiap resource CRD dapat dikendalikan. Saat menggunakan Helm untuk menerapkan chart, Helm membuat release untuk melacak status penerapan. Secara default, Helm menggunakan secret untuk menyimpan informasi release. Di kluster berskala besar, menyimpan banyak informasi release dalam secret dapat melebihi batas Kubernetes pada ukuran total secret. Sebagai gantinya, Anda dapat menggunakan backend penyimpanan SQL Helm.
API Server: Koneksi dan bandwidth CLB	API Server kluster ACK menggunakan instans Classic Load Balancer (CLB), yang memiliki batas koneksi dan bandwidth. Bandwidth maksimum adalah 5120 Mbps. Untuk informasi lebih lanjut tentang jumlah maksimum koneksi, lihat Instans CLB. Melebihi batas koneksi atau bandwidth SLB dapat menyebabkan node menjadi NotReady.	Untuk kluster dengan 1.000 node atau lebih, kami merekomendasikan memilih instans CLB pay-by-usage. Untuk meningkatkan kecepatan konektivitas jaringan dan bandwidth, kluster berskala besar harus menggunakan mode koneksi langsung ENI saat mengakses layanan Kubernetes di namespace default. Kluster yang dibuat setelah Februari 2023 dengan versi 1.20 atau lebih baru menggunakan koneksi langsung ENI secara default. Untuk informasi lebih lanjut, lihat Akses API server kluster ACK menggunakan titik akhir internal.
Jumlah layanan per namespace	kubelet menyuntikkan informasi tentang layanan yang didefinisikan di kluster sebagai Variabel lingkungan ke dalam Pod yang berjalan di node tersebut. Hal ini memungkinkan Pod menemukan dan berkomunikasi dengan layanan melalui Variabel lingkungan. Jumlah layanan yang berlebihan di setiap namespace dapat menyebabkan terlalu banyak Variabel lingkungan disuntikkan ke dalam Pod, yang dapat menyebabkan Pod mulai lambat atau bahkan gagal.	Pertahankan jumlah layanan di setiap namespace di bawah 5.000. Anda dapat memilih untuk tidak mengisi Variabel lingkungan ini dengan mengatur `enableServiceLinks` di `podSpec` menjadi `false`. Untuk informasi lebih lanjut, lihat Accessing the Service.
Total jumlah layanan di kluster	Jumlah layanan yang berlebihan meningkatkan jumlah aturan jaringan yang perlu diproses oleh kube-proxy, yang pada gilirannya memengaruhi kinerja kube-proxy. Untuk layanan tipe LoadBalancer, jumlah layanan yang berlebihan meningkatkan penundaan saat sinkronisasi ke SLB. Penundaan dapat mencapai tingkat menit.	Pertahankan total jumlah semua layanan di bawah 10.000. Untuk layanan tipe LoadBalancer, pertahankan total jumlah layanan di bawah 500.
Jumlah maksimum endpoint per layanan	Komponen kube-proxy berjalan di setiap node dan memantau pembaruan terkait layanan untuk segera memperbarui aturan jaringan di node tersebut. Saat suatu layanan memiliki banyak endpoint, resource Endpoints-nya juga menjadi besar. Setiap pembaruan objek Endpoints menyebabkan banyak traffic antara kube-apiserver lapisan kontrol dan kube-proxy di node. Semakin besar kluster, semakin banyak data yang perlu diperbarui, dan semakin jelas efek badai yang terjadi. Catatan Untuk mengatasi masalah ini, kube-proxy di kluster v1.19 dan versi lebih baru menggunakan EndpointSlices secara default untuk meningkatkan kinerja.	Pertahankan jumlah Pod backend untuk endpoint satu layanan di bawah 3.000. Di kluster berskala besar, gunakan EndpointSlices alih-alih Endpoints untuk membagi dan mengelola endpoint jaringan. Setelah dibagi, jumlah data yang ditransmisikan selama setiap perubahan resource secara efektif berkurang. Jika Anda memiliki custom controller yang bergantung pada resource Endpoints untuk keputusan routing, Anda masih dapat menggunakan objek Endpoints. Namun, pastikan jumlah Pod backend untuk satu objek Endpoints tidak melebihi 1.000. Jika melebihi, objek Endpoints layanan tersebut akan dipotong secara otomatis. Untuk informasi lebih lanjut, lihat Over-capacity endpoints.
Total jumlah endpoint untuk semua layanan	Jumlah endpoint yang berlebihan di kluster dapat menyebabkan beban berlebih pada API Server dan mengarah pada penurunan kinerja jaringan.	Pertahankan total jumlah endpoint yang terkait dengan semua layanan di bawah 64.000.
Jumlah Pod pending	Saat jumlah Pod pending terlalu tinggi, Pod yang baru diajukan mungkin tetap dalam keadaan menunggu dalam waktu lama dan tidak dapat dijadwalkan ke node yang sesuai. Selama proses ini, jika Pod tidak dapat dijadwalkan, penjadwal secara berkala menghasilkan event, yang dapat menyebabkan badai event.	Pertahankan jumlah total Pod pending di bawah 10.000.
Jumlah secret di kluster dengan enkripsi data diam untuk secret menggunakan KMS diaktifkan	Saat Anda menggunakan KMS v1 untuk mengenkripsi data, kunci enkripsi data (DEK) baru dihasilkan untuk setiap enkripsi. Saat kluster dimulai, kluster perlu mengakses dan mendekripsi secret yang disimpan di etcd. Jika kluster menyimpan terlalu banyak secret, kluster perlu mendekripsi banyak data selama startup atau upgrade, yang memengaruhi kinerja kluster.	Pertahankan jumlah secret yang disimpan di kluster dengan enkripsi KMS V1 diaktifkan di bawah 2.000.

Konfigurasikan parameter komponen lapisan kontrol

ACK managed cluster Pro menyediakan fitur yang memungkinkan Anda menyesuaikan parameter komponen lapisan kontrol. Fitur ini mendukung modifikasi parameter komponen inti terkelola seperti kube-apiserver, kube-controller-manager, dan kube-scheduler. Di kluster berskala besar, Anda perlu menyesuaikan parameter terkait Pembatasan kecepatan komponen lapisan kontrol secara tepat.

kube-apiserver

Untuk mencegah banyak permintaan konkuren membebani lapisan kontrol, kube-apiserver membatasi jumlah permintaan konkuren yang dapat ditangani pada waktu tertentu. Setelah batas ini terlampaui, API Server mulai melakukan Pembatasan kecepatan permintaan, mengembalikan kode respons HTTP 429 (Too Many Requests) ke klien, dan menginstruksikan klien untuk mencoba lagi nanti. Jika sisi server tidak memiliki langkah Pembatasan kecepatan, lapisan kontrol dapat kelebihan beban karena menangani permintaan melebihi kapasitasnya, yang secara serius memengaruhi stabilitas dan ketersediaan seluruh layanan atau kluster. Oleh karena itu, Anda harus mengonfigurasi mekanisme Pembatasan kecepatan sisi server untuk mencegah masalah luas akibat crash lapisan kontrol.

Klasifikasi Pembatasan kecepatan

Pembatasan kecepatan kube-apiserver dibagi menjadi dua jenis.

Versi sebelum v1.18: kube-apiserver hanya mendukung Pembatasan kecepatan konkurensi maksimum. Permintaan dibedakan sebagai tipe baca atau tulis dan membatasi konkurensi maksimum permintaan baca dan tulis melalui parameter startup --max-requests-inflight dan --max-mutating-requests-inflight. Metode ini tidak membedakan prioritas permintaan. Beberapa permintaan lambat berprioritas rendah dapat mengonsumsi banyak resource, menyebabkan antrian permintaan API Server dan mencegah beberapa permintaan berprioritas lebih tinggi atau lebih mendesak diproses tepat waktu.
ACK managed cluster Pro mendukung konfigurasi kustom parameter max-requests-inflight dan max-mutating-requests-inflight untuk kube-apiserver. Untuk informasi lebih lanjut, lihat Menyesuaikan parameter komponen lapisan kontrol di kluster ACK Pro.

v1.18 dan versi lebih baru: Mekanisme API Priority and Fairness (APF) diperkenalkan untuk manajemen traffic yang lebih detail. Mekanisme ini mendukung klasifikasi dan isolasi permintaan berdasarkan aturan dan prioritas yang telah ditentukan. Hal ini memastikan bahwa permintaan yang lebih penting dan mendesak diproses terlebih dahulu, serta mengikuti kebijakan keadilan tertentu untuk memastikan berbagai jenis permintaan mendapatkan peluang pemrosesan yang wajar. Fitur ini memasuki tahap Beta di v1.20 dan diaktifkan secara default.

Buka untuk melihat APF deskripsi

Di kluster Kubernetes v1.20 dan versi lebih baru, kube-apiserver mengonfigurasi jumlah total permintaan yang dapat diproses secara konkuren melalui jumlah parameter --max-requests-inflight dan --max-mutating-requests-inflight. Mekanisme ini menggunakan dua jenis CustomResourceDefinitions (CRDs), FlowSchema dan PriorityLevelConfiguration, untuk mengontrol alokasi konkurensi di antara berbagai jenis permintaan guna pengendalian traffic yang lebih detail.

PriorityLevelConfiguration: Konfigurasi prioritas yang menentukan proporsi konkurensi total yang dapat dialokasikan untuk tingkat prioritas tertentu.
FlowSchema: Menentukan PriorityLevelConfiguration mana yang dimiliki suatu permintaan.

PriorityLevelConfiguration dan FlowSchema dipelihara secara otomatis oleh kube-apiserver. Konfigurasi default untuk versi kluster saat ini dihasilkan secara otomatis di kluster Kubernetes. Anda dapat menjalankan perintah berikut untuk melihatnya.

Klik untuk melihat perintah kueri PriorityLevelConfiguration dan output yang diharapkan

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

Klik untuk melihat perintah kueri FlowSchema dan output yang diharapkan

Catatan

ACK menambahkan klasifikasi ack-system-leader-election dan ack-default yang terkait dengan komponen inti ACK ke FlowSchema. Sisanya konsisten dengan komunitas.

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

Pemantauan Pembatasan kecepatan dan solusi yang direkomendasikan

Klien dapat menentukan apakah sisi server melakukan Pembatasan kecepatan dengan memeriksa kode status respons 429 atau dengan memantau metrik apiserver_flowcontrol_rejected_requests_total. Saat perilaku Pembatasan kecepatan teramati, Anda dapat mengatasinya dengan cara berikut.

Pantau penggunaan resource API Server. Saat penggunaan resource rendah, Anda dapat menyesuaikan jumlah parameter max-requests-inflight dan max-mutating-requests-inflight untuk meningkatkan batas Pembatasan kecepatan total.
Untuk kluster dengan lebih dari 500 node, kami merekomendasikan menyetel jumlah parameter antara 2.000 dan 3.000. Untuk kluster dengan lebih dari 3.000 node, kami merekomendasikan menyetelnya antara 3.000 dan 5.000.
Konfigurasi ulang PriorityLevelConfiguration.
- Permintaan berprioritas tinggi: Untuk permintaan yang tidak ingin Anda batasi, Anda dapat membuat FlowSchema baru dan mencocokkannya dengan PriorityLevelConfiguration berprioritas tinggi, seperti workload-high atau exempt. Namun, permintaan dengan prioritas exempt tidak dibatasi oleh APF, sehingga Anda harus mengonfigurasinya dengan hati-hati. Anda juga dapat mengonfigurasi PriorityLevelConfiguration baru untuk permintaan berprioritas tinggi agar mendapatkan konkurensi lebih tinggi.
- Permintaan berprioritas rendah: Saat permintaan klien lambat tertentu menyebabkan penggunaan resource API Server tinggi atau respons lambat, Anda dapat menambahkan FlowSchema baru untuk jenis permintaan ini dan mencocokkannya dengan PriorityLevelConfiguration berkonkurensi rendah.

Penting

ACK managed cluster Pro mengelola komponen kube-apiserver untuk Anda. Secara default, kube-apiserver tersedia tinggi di beberapa zona, yang menjamin setidaknya 2 replika. Komponen ini secara bertahap menyesuaikan hingga maksimum 6 replika seiring peningkatan penggunaan resource lapisan kontrol. Total permintaan konkuren aktual = Jumlah replika × Total permintaan per replika.
Memodifikasi parameter kustom kube-apiserver memicu pembaruan rolling API Server. Hal ini dapat menyebabkan controller klien melakukan kembali operasi List-Watch. Di kluster berskala besar, hal ini dapat menyebabkan beban API Server terlalu tinggi, yang mengarah pada ketidaktersediaan layanan sementara.

kube-controller-manager dan kube-scheduler

kube-controller-manager dan kube-scheduler mengontrol QPS komunikasi dengan API Server melalui parameter kubeAPIQPS/kubeAPIBurst dan connectionQPS/connectionBurst, masing-masing. Untuk informasi lebih lanjut, lihat Menyesuaikan parameter komponen lapisan kontrol di kluster ACK Pro dan Menyesuaikan parameter penjadwal.

kube-controller-manager: Untuk kluster dengan lebih dari 1.000 node, kami merekomendasikan menyesuaikan kubeAPIQPS/kubeAPIBurst menjadi 300/500 atau lebih tinggi.
kube-scheduler: Umumnya, tidak perlu penyesuaian. Saat laju Pod melebihi 300/detik, kami merekomendasikan menyesuaikan connectionQPS/connectionBurst menjadi 800/1000.

kubelet

Nilai default parameter komponen kubelet kube-api-burst/qps adalah 5/10, yang umumnya tidak perlu disesuaikan. Saat kluster Anda mengalami masalah kinerja signifikan seperti pembaruan status Pod lambat, penundaan penjadwalan, atau pemasangan volume persisten lambat, kami merekomendasikan peningkatan nilai parameter tersebut. Untuk prosedur dan deskripsi, lihat Menyesuaikan konfigurasi kubelet untuk kelompok node.

Penting

Menambah parameter kubelet ini meningkatkan QPS komunikasi antara kubelet dan API Server. Jika kubelet mengirim terlalu banyak permintaan, hal ini dapat meningkatkan beban pada API Server. Kami merekomendasikan peningkatan nilai secara bertahap dan memantau kinerja serta penggunaan resource API Server untuk memastikan stabilitas lapisan kontrol.
Saat Anda melakukan perubahan pada kubelet node, Anda harus mengontrol frekuensi pembaruan. Untuk memastikan stabilitas lapisan kontrol selama proses perubahan, ACK membatasi jumlah maksimum pembaruan paralel per batch di satu kelompok node hingga tidak lebih dari 10.

Rencanakan laju penskalaan resource kluster

Di kluster berskala besar, lapisan kontrol biasanya berada di bawah tekanan rendah selama operasi stabil. Namun, saat kluster mengalami perubahan berskala besar, seperti membuat atau menghapus banyak resource secara cepat atau menskalakan banyak node, tekanan dapat menjadi berlebihan, yang memengaruhi kinerja dan kecepatan respons kluster.

Misalnya, di kluster 5.000 node dengan banyak Pod tetap yang berjalan stabil, tekanan pada lapisan kontrol biasanya tidak terlalu tinggi. Namun, di kluster 1.000 node, jika Anda membuat 10.000 job berumur pendek dalam satu menit atau secara konkuren memperluas kapasitas 2.000 node, tekanan pada lapisan kontrol akan melonjak.

Oleh karena itu, saat melakukan operasi perubahan resource di kluster berskala besar, Anda harus merencanakan laju perubahan operasi penskalaan secara hati-hati berdasarkan kondisi kluster untuk memastikan stabilitas kluster dan lapisan kontrol.

Operasi yang direkomendasikan adalah sebagai berikut.

Penting

Karena banyak faktor yang memengaruhi lapisan kontrol kluster, angka berikut hanya sebagai referensi. Selama operasi aktual, tingkatkan laju perubahan secara bertahap. Pastikan lapisan kontrol merespons secara normal sebelum meningkatkan laju penskalaan lebih lanjut.

Skala-masuk dan skala-keluar node: Untuk kluster dengan lebih dari 2.000 node, saat Anda menskalakan node secara manual melalui kelompok node, jumlah node dalam satu operasi untuk satu kelompok node tidak boleh melebihi 100. Jumlah total node dalam satu operasi di beberapa kelompok node tidak boleh melebihi 300.
Skala-masuk dan skala-keluar Pod aplikasi: Jika aplikasi Anda terkait dengan layanan, pembaruan Endpoint dan EndpointSlice selama penskalaan didorong ke semua node. Di skenario dengan banyak node, banyak data perlu diperbarui, yang dapat menyebabkan efek badai kluster. Untuk kluster dengan lebih dari 5.000 node, kami merekomendasikan QPS pembaruan Pod yang tidak terkait dengan Endpoint tidak melebihi 300/detik. QPS pembaruan Pod yang terkait dengan Endpoint tidak melebihi 10/detik. Misalnya, saat Anda mendeklarasikan strategi Rolling Update untuk deployment, kami merekomendasikan menyetel nilai maxUnavailable dan maxSurge lebih kecil terlebih dahulu untuk mengurangi laju pembaruan Pod.

Optimalkan pola akses klien ke kluster

Di kluster Kubernetes, klien memperoleh informasi resource kluster melalui API Server. Seiring peningkatan jumlah resource di kluster, permintaan berkala dari klien dapat meningkatkan beban pada lapisan kontrol kluster, yang mengarah pada penundaan respons atau bahkan efek avalan. Anda harus memahami dan merencanakan ukuran serta frekuensi akses resource. Rekomendasi adalah sebagai berikut.

Utamakan penggunaan informer untuk mengakses data cache lokal

Utamakan penggunaan informer client-go untuk mengambil resource. Kueri data dari cache lokal untuk menghindari permintaan List yang langsung mengakses API Server, yang mengurangi beban pada API Server.

Optimalkan cara mendapatkan resource melalui API Server

Untuk cache lokal yang belum diakses, Anda tetap perlu mengambil resource langsung melalui API Server. Namun, Anda dapat mengikuti rekomendasi berikut.

Tetapkan resourceVersion=0 dalam permintaan List.
resourceVersion menunjukkan versi status resource. Saat diatur ke 0, permintaan mengambil data cache dari API Server alih-alih langsung mengakses etcd. Hal ini mengurangi jumlah interaksi internal antara API Server dan etcd serta memungkinkan respons lebih cepat terhadap permintaan List klien. Berikut contohnya.
```
k8sClient.CoreV1().Pods("").List(context.Background(), metav1.ListOptions{ResourceVersion: "0"})
```
Hindari mencantumkan semua resource untuk mencegah pengambilan data berlebihan.
Untuk mengurangi jumlah data yang dikembalikan oleh permintaan, Anda dapat menggunakan kondisi filter untuk membatasi cakupan permintaan List, seperti label-selector (berdasarkan tag resource) atau field-selector (berdasarkan bidang resource).
Catatan
etcd adalah sistem penyimpanan key-value (KV) dan tidak memiliki fungsi untuk memfilter data berdasarkan label atau bidang. Kondisi filter yang disertakan dalam permintaan sebenarnya diproses oleh API Server. Oleh karena itu, saat menggunakan fungsi filter, kami merekomendasikan menyetel resourceVersion permintaan List ke 0 secara bersamaan. Data permintaan diambil dari cache API Server dan tidak langsung mengakses etcd, yang mengurangi tekanan pada etcd.
Gunakan protobuf (bukan JSON) untuk mengakses resource non-CRD.
API Server dapat mengembalikan objek resource ke klien dalam berbagai format data, termasuk JSON dan protobuf. Secara default, saat klien meminta API Kubernetes, Kubernetes mengembalikan objek yang diserialisasi sebagai JSON, dengan tipe konten application/json. Klien dapat menentukan bahwa permintaan menggunakan format protobuf. Protobuf memiliki keunggulan dibandingkan JSON dalam hal penggunaan memori dan traffic transmisi jaringan.
Namun, tidak semua tipe resource API mendukung protobuf. Saat mengirim permintaan, Anda dapat menentukan beberapa tipe konten dalam header permintaan Accept (misalnya, application/json dan application/vnd.kubernetes.protobuf). Hal ini mendukung fallback ke format JSON default saat protobuf tidak dapat digunakan. Untuk informasi lebih lanjut, lihat Alternate representations of resources . Berikut contohnya.
```
Accept: application/vnd.kubernetes.protobuf, application/json
```

Gunakan pengontrol terpusat

Anda harus menghindari pembuatan controller independen di setiap node untuk memantau data lengkap kluster. Dalam kasus ini, saat controller dimulai, mereka mengirim banyak permintaan List ke API Server hampir secara bersamaan untuk menyinkronkan status kluster saat ini. Hal ini memberikan tekanan besar pada lapisan kontrol, yang dapat menyebabkan ketidakstabilan atau crash layanan.

Untuk menghindari masalah ini, kami merekomendasikan desain controller terpusat. Anda dapat membuat satu atau sekelompok instans controller terkelola terpusat untuk seluruh kluster, yang berjalan di satu node atau beberapa node. Controller terpusat bertanggung jawab untuk mendengarkan dan memproses data kluster yang diperlukan. Controller hanya memulai satu (atau beberapa) permintaan List dan mempertahankan hanya jumlah koneksi Watch yang diperlukan, yang secara signifikan mengurangi tekanan pada API Server.

Rencanakan workload berskala besar

Nonaktifkan pemasangan otomatis Service Account default

Untuk memastikan pembaruan sinkron secret di Pod, kubelet membuat koneksi Watch persisten untuk setiap secret yang dikonfigurasi untuk Pod tersebut. Mekanisme Watch memungkinkan kubelet menerima notifikasi real-time tentang pembaruan secret. Namun, saat jumlah total Watch yang dibuat oleh semua node terlalu tinggi, banyak koneksi Watch dapat memengaruhi kinerja lapisan kontrol kluster.

Sebelum Kubernetes versi 1.22: Saat Pod dibuat, jika ServiceAccount tidak ditentukan, Kubernetes secara otomatis memasang secret untuk ServiceAccount default ke dalam Pod. Hal ini memungkinkan aplikasi di dalam Pod berkomunikasi secara aman dengan API Server.
Untuk sistem pemrosesan batch dan Pod aplikasi yang tidak perlu mengakses API Server, kami merekomendasikan Anda secara eksplisit mendeklarasikan larangan pemasangan otomatis token ServiceAccount. Hal ini menghindari pembuatan secret dan Watch terkait (untuk informasi lebih lanjut, lihat automountServiceAccountToken). Di kluster berskala besar, operasi ini dapat menghindari pembuatan secret dan koneksi Watch yang tidak perlu dengan API Server, yang mengurangi beban pada lapisan kontrol kluster.
Kubernetes 1.22 dan versi lebih baru: Anda dapat menggunakan TokenRequest API untuk mendapatkan token jangka pendek yang diputar secara otomatis dan memasang token ini sebagai volume diproyeksikan. Selain meningkatkan keamanan secret, operasi ini juga mengurangi jumlah koneksi Watch yang dibuat kubelet untuk secret ServiceAccount, yang menurunkan overhead kinerja kluster.
Untuk informasi tentang cara mengaktifkan fitur volume token ServiceAccount diproyeksikan, lihat Menggunakan proyeksi volume token ServiceAccount.

Kontrol jumlah dan ukuran objek Kubernetes

Anda harus segera membersihkan resource Kubernetes yang tidak digunakan, seperti ConfigMap, secret, dan PVC, untuk mengurangi penggunaan resource sistem dan menjaga kesehatan serta efisiensi kluster. Berikut rekomendasi penggunaannya.

Batasi riwayat deployment: revisionHistoryLimit mendeklarasikan berapa banyak ReplicaSet lama yang dipertahankan untuk deployment. Jika nilainya terlalu tinggi, Kubernetes mempertahankan banyak versi historis ReplicaSet, yang meningkatkan beban manajemen pada kube-controller-manager. Di kluster berskala besar, jika ada banyak deployment dan sering diperbarui, Anda dapat menurunkan nilai revisionHistoryLimit deployment untuk membersihkan ReplicaSet lama. Nilai default revisionHistoryLimit deployment adalah 10.
Bersihkan job dan Pod terkait yang tidak digunakan: Jika banyak objek job dibuat di kluster melalui CronJob atau mekanisme lain, Anda dapat menggunakan ttlSecondsAfterFinished untuk membersihkan job selesai dan Pod terkait secara otomatis. Hal ini menentukan bahwa job dan Pod terkait dihapus secara otomatis setelah periode tertentu.

Konfigurasikan resource komponen tipe Informer dengan tepat

Komponen tipe Informer terutama digunakan untuk memantau dan menyinkronkan status resource kluster Kubernetes. Komponen tipe Informer membuat koneksi Watch ke status resource API Server kluster dan mempertahankan cache lokal objek resource untuk merespons perubahan status resource dengan cepat.

Untuk komponen tipe Informer, seperti komponen controller dan kube-scheduler, penggunaan memori komponen terkait dengan ukuran resource yang dipantau. Di kluster berskala besar, Anda harus memperhatikan konsumsi memori komponen ini untuk mencegah error kehabisan memori (OOM). OOM yang sering dapat menyebabkan masalah pada pemantauan resource berkelanjutan oleh komponen. Saat komponen sering restart, operasi List-Watch yang dilakukan setiap kali juga memberikan tekanan ekstra pada lapisan kontrol kluster, terutama API Server.

Pantau metrik lapisan kontrol

Anda dapat melihat dasbor pemantauan komponen lapisan kontrol untuk mendapatkan daftar metrik komponen lapisan kontrol inti, analisis masalah metrik abnormal, dan lainnya. Di kluster berskala besar, Anda harus fokus pada metrik berikut. Untuk informasi lebih lanjut tentang instruksi penggunaan dan deskripsi detail metrik, lihat Pemantauan komponen lapisan kontrol.

Kontrol penggunaan resource

Saat ini, penggunaan resource semua komponen lapisan kontrol tersedia untuk dilihat. Metrik terkait dan deskripsinya adalah sebagai berikut:

Nama metrik	Prometheus Query Language (PromQL)	Deskripsi

kube-apiserver

Untuk informasi tentang cara melihat metrik dan deskripsi lengkapnya, lihat Metrik pemantauan komponen kube-apiserver.

Jumlah objek resource

Nama	PromQL	Deskripsi
		Nama metrik adalah apiserver_storage_objects jika kluster ACK Anda menjalankan Kubernetes 1.22 atau versi lebih baru. Nama metrik adalah etcd_object_counts jika kluster ACK Anda menjalankan Kubernetes 1.22 atau versi lebih lama. Catatan Karena masalah kompatibilitas, kedua metrik apiserver_storage_objects dan etcd_object_counts ada di Kubernetes 1.22.

Latensi permintaan

Nama	PromQL	Deskripsi

		Waktu respons permintaan LIST ditampilkan berdasarkan dimensi berikut: Pod API server, verb LIST, resource, dan cakupan.
Write request delay P[0.9]	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 Mutating ditampilkan berdasarkan dimensi berikut: Pod API server, verb seperti GET, WATCH, LIST, dan CONNECT, resource, dan cakupan.

Pembatasan kecepatan permintaan

Name

PromQL

Description

Request Limit Rate

sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name)

sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name)

Laju pembatasan kecepatan kube-apiserver. No data atau 0 menunjukkan bahwa pembatasan permintaan tidak dipicu.

kube-scheduler

Untuk informasi tentang cara melihat metrik dan deskripsi lengkapnya, lihat Metrik pemantauan komponen kube-scheduler.

Jumlah Pod pending

Name

PromQL

Description

Scheduler Pending Pods

scheduler_pending_pods{job="ack-scheduler"}

Jumlah Pod yang sedang pending. Pod pending terdiri atas jenis-jenis berikut:

unschedulable: Pod yang tidak dapat dijadwalkan.
backoff: Pod dalam antrian backoff, yaitu Pod yang gagal dijadwalkan karena alasan tertentu.
active: Pod dalam antrian aktif, yaitu Pod yang siap dijadwalkan.

Latensi permintaan

Nama

PromQL

Deskripsi

Kube API Request Latency

histogram_quantile($quantile, sum(rate(rest_client_request_duration_seconds_bucket{job="ack-scheduler"}[$interval])) by (verb,url,le))

Interval waktu antara permintaan yang dikirim oleh kube-scheduler dan respons yang dikembalikan oleh kube-apiserver. Latensi dihitung berdasarkan Verbs dan URL.

kube-controller-manager

Untuk informasi tentang cara melihat metrik dan deskripsi lengkapnya, lihat Metrik pemantauan komponen kube-controller-manager.

Workqueue

Nama

PromQL

Deskripsi

Workqueue depth

sum(rate(workqueue_depth{job="ack-kube-controller-manager"}[$interval])) by (name)

Perubahan panjang workqueue dalam interval yang ditentukan.

Workqueue processing delay

histogram_quantile($quantile, sum(rate(workqueue_queue_duration_seconds_bucket{job="ack-kube-controller-manager"}[5m])) by (name, le))

Durasi event di workqueue.

etcd

Untuk informasi tentang cara melihat metrik dan deskripsi lengkapnya, lihat Metrik pemantauan komponen etcd.

Total jumlah KV
Nama
PromQL
Deskripsi
total kv
etcd_debugging_mvcc_keys_total
Jumlah total pasangan kunci-nilai di kluster etcd.
Ukuran database (DB Size)
Nama
PromQL
Deskripsi
Disk Size
etcd_mvcc_db_total_size_in_bytes
Ukuran database backend etcd.
etcd_mvcc_db_total_size_in_use_in_bytes
Penggunaan database backend etcd.

Referensi

Untuk informasi tentang kuota dan batas kluster ACK, lihat Kuota dan batas.
Untuk informasi tentang cara merencanakan jaringan VPC dan jaringan kontainer kluster dengan tepat, lihat Merencanakan Blok CIDR untuk kluster ACK terkelola.
Untuk informasi tentang cara mencapai konfigurasi keandalan tinggi untuk pembuatan kluster dan workload, lihat Konfigurasi workload yang direkomendasikan.
Jika Anda mengalami error atau masalah terkait saat menggunakan kluster ACK, Anda dapat melihat Troubleshooting dan FAQ tentang manajemen kluster untuk informasi troubleshooting.