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

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

Pedoman untuk kluster berskala besar

Dibandingkan dengan penggunaan beberapa kluster, membangun satu kluster berskala besar dapat mengurangi beban operasi dan pemeliharaan (O&M) dalam manajemen kluster serta meningkatkan pemanfaatan resource. Namun, dalam beberapa skenario bisnis kompleks, Anda mungkin perlu mendekomposisi layanan ke dalam beberapa kluster berdasarkan logika atau kebutuhan bisnis—misalnya, memisahkan layanan non-produksi (pengujian) dari layanan produksi atau memisahkan layanan database dari aplikasi frontend.

Jika Anda memiliki pertimbangan berikut, sebaiknya gunakan beberapa kluster daripada satu kluster berskala besar.

Kategori	Deskripsi
Isolasi	Penggunaan beberapa kluster menjamin isolasi antar lingkungan berbeda, seperti kluster produksi dan pengujian. Pendekatan ini mencegah masalah pada satu kluster memengaruhi seluruh layanan dan mengurangi radius dampak (blast radius) dari suatu kegagalan.
Lokasi	Beberapa layanan perlu ditempatkan di wilayah geografis tertentu yang lebih dekat dengan pengguna akhir untuk memenuhi persyaratan ketersediaan dan latensi rendah. Dalam skenario ini, sebarkan beberapa kluster di wilayah berbeda.
Batas skala kluster tunggal	Lapisan kontrol managed ACK menggunakan Auto Scaling dan optimasi performa komponen kluster untuk beradaptasi dengan kluster berbagai ukuran. Namun, arsitektur Kubernetes memiliki bottleneck performa inheren. Kluster yang terlalu besar dapat memengaruhi ketersediaan dan performanya. Sebelum merencanakan kluster berskala besar, pahami batas kapasitas dan SLO yang ditetapkan oleh komunitas Kubernetes. Selanjutnya, buka Quota Center untuk melihat dan mengajukan peningkatan kuota untuk Container Service for Kubernetes. Jika kebutuhan Anda melebihi batas yang ditetapkan oleh komunitas dan ACK, pertimbangkan untuk mendekomposisi layanan Anda ke dalam beberapa kluster.

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

Cara menggunakan topik ini

Topik ini ditujukan bagi pengembang dan administrator kluster ACK managed Pro. Topik ini memberikan rekomendasi umum untuk perencanaan dan penggunaan kluster berskala besar. Anda harus 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 untuk layanan kluster. Anda bertanggung jawab atas keamanan aplikasi bisnis yang diterapkan di cloud, serta konfigurasi keamanan dan pembaruan sumber daya cloud Anda. Untuk informasi lebih lanjut, lihat Model tanggung jawab bersama.

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

Gunakan versi kluster terbaru

Komunitas Kubernetes secara rutin merilis versi baru yang memperkenalkan fitur dan optimasi baru. Versi Kubernetes yang lebih baru menawarkan peningkatan dalam stabilitas, performa, dan skalabilitas. Berikut adalah contoh optimasi khas:

Pada versi 1.31, kube-apiserver dapat melakukan pembacaan konsisten untuk permintaan List dari cache. Hal ini mengurangi kebutuhan untuk meneruskan permintaan ke etcd, sehingga 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 performa operasi List dengan melakukan streaming permintaan pengambilan resource. Untuk permintaan List yang melibatkan banyak resource, hal ini secara efektif mengurangi penggunaan memori kube-apiserver dan meningkatkan stabilitas sistem. Untuk informasi lebih lanjut, lihat Streaming List responses.

ACK secara rutin merilis versi Kubernetes yang didukung sesuai jadwal rilis komunitas Kubernetes dan secara bertahap menghentikan dukungan teknis untuk versi yang kedaluwarsa. Untuk versi kedaluwarsa, ACK berhenti merilis fitur baru serta memperbaiki bug fungsional dan keamanan, dan hanya menyediakan dukungan teknis terbatas.

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

Untuk informasi lebih lanjut tentang versi Kubernetes yang didukung oleh ACK, lihat Panduan Versi.
Untuk informasi lebih lanjut tentang upgrade kluster, termasuk dampak, prosedur, catatan, dan metode, lihat Upgrade kluster.
Untuk petunjuk cara melakukan upgrade kluster, lihat Upgrade kluster secara manual dan Upgrade kluster secara otomatis.

Perhatikan batas resource kluster

Untuk memastikan ketersediaan, stabilitas, dan performa kluster berskala besar, Anda harus memperhatikan batas dan solusi yang direkomendasikan dalam tabel berikut.

Batas	Deskripsi	Solusi yang direkomendasikan
Ukuran database etcd (DB size)	Ukuran maksimum database etcd adalah 8 GB. Ukuran yang lebih besar dapat memengaruhi performa, termasuk latensi baca/tulis data, konsumsi resource sistem, dan latensi pemilihan (election). Hal ini juga membuat pemulihan layanan dan data menjadi lebih sulit dan memakan waktu.	Pertahankan ukuran total 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 dengan pembaruan data besar yang sering, etcd mengonsumsi lebih banyak resource saat menyimpan versi historis data tersebut.
Total ukuran data setiap tipe resource di etcd	Jika jumlah total objek resource terlalu besar, permintaan akses data lengkap dari klien dapat menyebabkan konsumsi resource sistem yang signifikan. Dalam kasus parah, hal ini dapat mencegah API Server atau controller kustom untuk melakukan inisialisasi.	Pertahankan ukuran total objek untuk setiap tipe resource di bawah 800 MB. Saat Anda mendefinisikan tipe CRD baru, Anda harus merencanakan jumlah akhir CR yang diharapkan terlebih dahulu untuk memastikan ukuran total setiap resource CRD dapat dikelola. Saat Anda menerapkan Chart menggunakan Helm, Helm membuat release untuk melacak status penerapan. Secara default, Helm menggunakan Secrets untuk menyimpan informasi release. Di kluster berskala besar, menyimpan banyak informasi release di Secrets dapat melebihi batas Kubernetes pada ukuran total Secrets. Sebagai gantinya, Anda dapat menggunakan backend penyimpanan SQL Helm.
Koneksi dan bandwidth CLB API Server	API Server kluster ACK menggunakan instans CLB sebagai load balancer, yang memiliki batas koneksi dan bandwidth. Untuk jumlah koneksi maksimum instans CLB, lihat Instans CLB. Bandwidth maksimum adalah 5120 Mbps. Jika batas koneksi atau bandwidth CLB terlampaui, node dapat menjadi Not Ready.	Untuk kluster dengan lebih dari 1.000 node, pilih instans CLB pay-as-you-go. Untuk meningkatkan konektivitas jaringan dan bandwidth, kluster berskala besar sebaiknya 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 mode koneksi langsung ENI secara default. Untuk informasi lebih lanjut, lihat Kube API Server.
Jumlah layanan per namespace	kubelet menyuntikkan informasi tentang layanan di kluster ke dalam Pod pada node sebagai Variabel lingkungan. Hal ini memungkinkan Pod menemukan dan berkomunikasi dengan layanan menggunakan variabel tersebut. Jika sebuah namespace memiliki terlalu banyak layanan, jumlah Variabel lingkungan yang disuntikkan ke dalam Pod menjadi berlebihan. Hal ini dapat menyebabkan startup Pod lambat atau bahkan gagal.	Pertahankan jumlah layanan di setiap namespace di bawah 5.000. Anda dapat memilih untuk tidak mengisi variabel-variabel lingkungan ini. Atur `enableServiceLinks` di `podSpec` menjadi `false`. Untuk informasi lebih lanjut, lihat Accessing the Service.
Total jumlah layanan di kluster	Terlalu banyak layanan dapat meningkatkan jumlah aturan jaringan yang harus diproses oleh kube-proxy, yang pada gilirannya memengaruhi performa kube-proxy. Untuk layanan LoadBalancer, terlalu banyak layanan dapat meningkatkan latensi sinkronisasi ke SLB. Penundaan dapat mencapai tingkat menit.	Pertahankan jumlah total semua layanan di bawah 10.000. Untuk layanan LoadBalancer, pertahankan jumlah total layanan di bawah 500.
Jumlah maksimum endpoint per layanan	Komponen kube-proxy berjalan di setiap node untuk memantau pembaruan layanan dan segera memperbarui aturan jaringan di node tersebut. Saat sebuah layanan memiliki banyak endpoint, resource Endpoints yang sesuai menjadi besar. Setiap pembaruan objek Endpoints menyebabkan volume lalu lintas yang besar antara kube-apiserver di lapisan kontrol dan kube-proxy di node. Semakin besar kluster, semakin banyak data yang harus diperbarui, dan semakin jelas efek badai (storm effect) yang terjadi. Catatan Untuk mengatasi masalah ini, kube-proxy secara default menggunakan EndpointSlices di kluster versi v1.19 ke atas untuk meningkatkan performa.	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 ditransfer selama setiap perubahan resource secara efektif berkurang. Jika Anda memiliki controller kustom yang bergantung pada resource Endpoints untuk keputusan routing, Anda masih dapat menggunakan objek Endpoints. Namun, Anda harus memastikan bahwa jumlah Pod backend untuk satu Endpoint tidak melebihi 1.000. Jika melebihi, objek Endpoints Pod tersebut akan dipotong secara otomatis. Untuk informasi lebih lanjut, lihat Over-capacity endpoints.
Total jumlah semua endpoint layanan	Terlalu banyak endpoint di kluster dapat menyebabkan beban berlebih pada API Server dan mengakibatkan penurunan performa jaringan.	Pertahankan jumlah total endpoint yang terkait dengan semua layanan di bawah 64.000.
Jumlah Pod pending	Jika terlalu banyak Pod pending, Pod yang baru dikirimkan dapat tetap dalam keadaan menunggu untuk waktu yang 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 (event storm).	Pertahankan jumlah total Pod pending di bawah 10.000.
Jumlah Secrets di kluster dengan enkripsi data diam untuk Secrets menggunakan Alibaba Cloud KMS diaktifkan	Saat Anda menggunakan KMS V1 untuk mengenkripsi data, kunci enkripsi data (DEK) baru dihasilkan untuk setiap enkripsi. Saat kluster dimulai, kluster harus mengakses dan mendekripsi Secrets yang disimpan di etcd. Jika kluster menyimpan terlalu banyak Secrets, kluster harus mendekripsi banyak data selama startup atau upgrade, yang memengaruhi performa kluster.	Pertahankan jumlah Secrets yang disimpan di kluster dengan enkripsi KMS V1 diaktifkan di bawah 2.000.

Konfigurasikan parameter komponen lapisan kontrol dengan benar

Kluster ACK managed Pro menyediakan fitur untuk menyesuaikan parameter komponen lapisan kontrol untuk kluster Pro. Fitur ini mendukung modifikasi parameter untuk komponen managed inti seperti kube-apiserver, kube-controller-manager, dan kube-scheduler. Di kluster berskala besar, Anda harus menyesuaikan parameter pembatasan laju (rate-limiting) komponen lapisan kontrol dengan benar.

kube-apiserver

Untuk mencegah banyak permintaan konkuren membebani lapisan kontrol, kube-apiserver membatasi jumlah permintaan konkuren yang dapat ditangani dalam periode waktu tertentu. Setelah batas ini terlampaui, API Server mulai menerapkan pembatasan laju. Server mengembalikan kode respons HTTP 429, yang berarti terlalu banyak permintaan, dan menginstruksikan klien untuk mencoba lagi nanti. Jika server tidak memiliki langkah pembatasan laju, server dapat kelebihan beban karena memproses permintaan melebihi kapasitasnya. Hal ini dapat secara serius memengaruhi stabilitas dan ketersediaan seluruh layanan atau kluster. Oleh karena itu, Anda harus mengonfigurasi mekanisme pembatasan laju di server untuk menghindari masalah yang lebih luas akibat kegagalan lapisan kontrol.

Kategori pembatasan laju

Pembatasan laju kube-apiserver dibagi menjadi dua jenis.

Versi sebelum v1.18: kube-apiserver hanya mendukung pembatasan laju konkurensi maksimum. Server membedakan antara permintaan baca dan tulis serta menggunakan parameter startup --max-requests-inflight dan --max-mutating-requests-inflight untuk membatasi konkurensi maksimum permintaan baca dan tulis. Metode ini tidak membedakan prioritas permintaan. Beberapa permintaan berprioritas rendah yang lambat mungkin mengonsumsi banyak resource, yang menyebabkan antrian permintaan di API Server. Hal ini dapat mencegah beberapa permintaan berprioritas lebih tinggi atau lebih mendesak diproses tepat waktu.
Kluster ACK managed 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 untuk kluster Pro.

v1.18 dan seterusnya: Mekanisme API Priority and Fairness (APF) diperkenalkan untuk manajemen traffic yang lebih detail halus. 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, sementara mengikuti kebijakan keadilan tertentu untuk menjamin bahwa berbagai jenis permintaan mendapatkan peluang wajar untuk diproses. Fitur ini memasuki tahap beta di v1.20 dan diaktifkan secara default.

Luaskan untuk melihat deskripsi fitur APF

Di kluster Kubernetes versi v1.20 ke atas, kube-apiserver menggunakan jumlah parameter --max-requests-inflight dan --max-mutating-requests-inflight untuk mengonfigurasi jumlah total permintaan yang dapat diproses secara konkuren. Server menggunakan dua jenis CRD, FlowSchema dan PriorityLevelConfiguration, untuk mengontrol konkurensi yang dialokasikan untuk berbagai jenis permintaan, yang memungkinkan kontrol traffic yang lebih tepat.

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

PriorityLevelConfiguration dan FlowSchema dikelola secara otomatis oleh kube-apiserver. Kluster Kubernetes secara otomatis menghasilkan konfigurasi default untuk versi kluster saat ini. Anda dapat menjalankan perintah berikut untuk melihatnya.

Luaskan 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

Luaskan untuk melihat perintah kueri FlowSchema dan output yang diharapkan

Catatan

ACK menambahkan kategori 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 laju dan solusi yang direkomendasikan

Klien dapat menentukan apakah server menerapkan pembatasan laju dengan memeriksa kode status 429 dalam respons atau dengan memantau metrik apiserver_flowcontrol_rejected_requests_total. Saat pembatasan laju terdeteksi, Anda dapat mengatasinya dengan cara berikut.

Pantau penggunaan resource API Server: Saat penggunaan resource rendah, Anda dapat meningkatkan batas laju total dengan menyesuaikan jumlah parameter max-requests-inflight dan max-mutating-requests-inflight.
Untuk kluster dengan lebih dari 500 node, konfigurasikan jumlah parameter antara 2.000 hingga 3.000. Untuk kluster dengan lebih dari 3.000 node, konfigurasikan antara 3.000 hingga 5.000.
Konfigurasi ulang PriorityLevelConfiguration:
- Permintaan berprioritas tinggi: Untuk permintaan yang tidak ingin dibatasi lajunya, Anda dapat membuat FlowSchema baru dan mencocokkannya dengan PriorityLevelConfiguration berprioritas tinggi, seperti workload-high atau exempt. Namun, permintaan dengan prioritas exempt tidak dibatasi lajunya oleh APF, sehingga Anda harus mengonfigurasinya dengan hati-hati. Anda juga dapat mengonfigurasi PriorityLevelConfiguration baru untuk permintaan berprioritas tinggi dan memberinya konkurensi yang lebih tinggi.
- Permintaan berprioritas rendah: Jika permintaan klien lambat tertentu menyebabkan penggunaan resource tinggi atau respons lambat dari API Server, Anda dapat membuat FlowSchema baru untuk permintaan tersebut dan mencocokkannya dengan PriorityLevelConfiguration yang memiliki konkurensi rendah.

Penting

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

kube-controller-manager dan kube-scheduler

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

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

kubelet

Nilai default parameter kube-api-burst/qps komponen kubelet adalah 5/10. Umumnya tidak perlu penyesuaian. Jika kluster Anda mengalami masalah performa signifikan, seperti pembaruan status Pod lambat, penundaan penjadwalan, atau pemasangan volume persisten lambat, Anda dapat meningkatkan nilai parameter tersebut. Untuk prosedur dan deskripsi, lihat Menyesuaikan konfigurasi kubelet untuk kelompok node.

Penting

Meningkatkan parameter kubelet ini meningkatkan QPS komunikasi antara kubelet dan API Server. Jika jumlah permintaan yang dikirim oleh kubelet terlalu tinggi, hal ini dapat meningkatkan beban pada API Server. Anda harus meningkatkan nilainya secara bertahap dan memantau performa 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 dalam satu kelompok node menjadi 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 besar, seperti pembuatan atau penghapusan cepat banyak resource atau penskalaan node berskala besar, tekanan dapat menjadi berlebihan. Hal ini dapat memengaruhi performa dan kecepatan respons kluster.

Sebagai contoh, di kluster 5.000 node dengan jumlah Pod tetap yang berjalan stabil, tekanan pada lapisan kontrol biasanya tidak terlalu tinggi. Namun, di kluster 1.000 node tempat 10.000 job berumur pendek harus dibuat dalam satu menit, atau 2.000 node harus diskalakan keluar secara konkuren, tekanan pada lapisan kontrol melonjak.

Oleh karena itu, saat Anda melakukan operasi perubahan resource di kluster berskala besar, Anda harus merencanakan laju operasi penskalaan dengan cermat berdasarkan status operasi kluster untuk memastikan stabilitas kluster dan lapisan kontrol.

Berikut adalah operasi yang direkomendasikan.

Penting

Karena banyak faktor yang memengaruhi lapisan kontrol kluster, angka berikut hanya sebagai referensi. Saat melakukan operasi, Anda harus memulai dengan laju perubahan kecil dan secara bertahap meningkatkannya. Amati bahwa lapisan kontrol merespons secara normal sebelum Anda meningkatkan laju penskalaan lebih lanjut.

Penskalaan keluar dan masuk node: Untuk kluster dengan lebih dari 2.000 node, saat Anda menskalakan node masuk atau keluar secara manual menggunakan 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.
Penskalaan keluar dan masuk 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 harus diperbarui, yang dapat menyebabkan efek badai kluster. Untuk kluster dengan lebih dari 5.000 node, QPS pembaruan untuk Pod yang tidak terkait dengan Endpoint tidak boleh melebihi 300/detik. QPS pembaruan untuk Pod yang terkait dengan Endpoint tidak boleh melebihi 10/detik. Sebagai contoh, saat Anda mendeklarasikan strategi Rolling Update untuk Pod dalam deployment, Anda dapat mengatur nilai maxUnavailable dan maxSurge lebih kecil terlebih dahulu untuk mengurangi laju pembaruan Pod.

Optimalkan pola akses klien

Di kluster Kubernetes, klien memperoleh informasi resource kluster melalui API Server. Seiring peningkatan jumlah resource di kluster, permintaan sering dari klien dapat meningkatkan beban pada lapisan kontrol kluster. Hal ini dapat menyebabkan penundaan respons atau bahkan kegagalan longsor (avalanche failure) pada lapisan kontrol. Anda harus memahami dan merencanakan ukuran serta frekuensi akses resource. Berikut adalah rekomendasinya.

Utamakan penggunaan informer untuk mengakses data cache lokal

Utamakan penggunaan informer client-go untuk mengambil resource. Anda dapat mengkueri data dari cache lokal untuk menghindari permintaan List yang langsung mengakses API Server. Hal ini 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.

Atur 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, yang memungkinkan respons lebih cepat terhadap permintaan List klien. Berikut adalah contohnya.
```
k8sClient.CoreV1().Pods("").List(metav1.ListOptions{ResourceVersion: "0"})
```
Hindari listing semua resource untuk mencegah pengambilan data berlebihan.
Untuk mengurangi jumlah data yang dikembalikan oleh permintaan, Anda dapat menggunakan filter untuk membatasi cakupan permintaan List, seperti label-selector (filter berdasarkan tag resource) atau field-selector (filter berdasarkan bidang resource).
Catatan
etcd adalah sistem penyimpanan pasangan kunci-nilai (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 Anda menggunakan fitur filter, Anda juga harus mengatur resourceVersion permintaan List menjadi 0. Data permintaan diperoleh dari cache API Server alih-alih 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 dibanding JSON dalam hal penggunaan memori dan lalu lintas jaringan.
Namun, tidak semua tipe resource API mendukung Protobuf. Saat Anda mengirim permintaan, Anda dapat menentukan beberapa tipe konten dalam header permintaan Accept, seperti application/json dan application/vnd.kubernetes.protobuf. Hal ini memungkinkan fallback ke format JSON default saat Protobuf tidak dapat digunakan. Untuk informasi lebih lanjut, lihat Alternate representations of resources . Berikut adalah contohnya.
```
Accept: application/vnd.kubernetes.protobuf, application/json
```

Gunakan controller terpusat

Hindari membuat controller terpisah di setiap node untuk memantau semua data di kluster. Dalam kasus ini, saat controller dimulai, mereka mengirim banyak permintaan List ke API Server hampir secara simultan untuk menyinkronkan status kluster saat ini. Hal ini memberikan tekanan besar pada lapisan kontrol, yang dapat menyebabkan ketidakstabilan layanan atau kegagalan.

Untuk menghindari masalah ini, Anda dapat mengadopsi desain controller terpusat. Buat satu atau sekelompok instans controller 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 jumlah koneksi Watch yang diperlukan, yang secara signifikan mengurangi tekanan pada API Server.

Rencanakan workload berskala besar dengan benar

Nonaktifkan pemasangan otomatis Service Account default

Untuk memastikan Secrets di Pod disinkronkan dan diperbarui, 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, jika jumlah total koneksi Watch yang dibuat oleh semua node terlalu tinggi, banyaknya koneksi Watch dapat memengaruhi performa lapisan kontrol kluster.

Sebelum Kubernetes 1.22: Saat Pod dibuat, jika ServiceAccount tidak ditentukan, Kubernetes secara otomatis memasang ServiceAccount default sebagai Secret untuk Pod tersebut. 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, Anda harus secara eksplisit menonaktifkan pemasangan otomatis token ServiceAccount untuk menghindari pembuatan Secret dan Watch terkait. Untuk informasi lebih lanjut, lihat automountServiceAccountToken. Di kluster berskala besar, operasi ini dapat menghindari pembuatan Secrets dan koneksi Watch yang tidak perlu ke API Server, yang mengurangi beban pada lapisan kontrol kluster.
Kubernetes 1.22 dan seterusnya: Gunakan API TokenRequest untuk mendapatkan token berumur pendek yang secara otomatis diputar dan memasang token ini sebagai volume projected. Meskipun hal ini meningkatkan keamanan Secret, operasi ini juga mengurangi jumlah koneksi Watch yang dibuat kubelet untuk Secret ServiceAccount, yang menurunkan overhead performa kluster.
Untuk informasi lebih lanjut tentang cara mengaktifkan fitur volume proyeksi token ServiceAccount, lihat Menggunakan proyeksi volume token ServiceAccount.

Kontrol jumlah dan ukuran objek Kubernetes

Anda harus segera membersihkan resource Kubernetes yang tidak digunakan, seperti ConfigMap, Secrets, dan klaim volume persisten (PVC), untuk mengurangi konsumsi resource sistem dan menjaga kesehatan serta efisiensi kluster. Berikut adalah rekomendasi penggunaannya.

Batasi riwayat deployment: revisionHistoryLimit mendeklarasikan berapa banyak Set Replika lama yang dipertahankan untuk deployment. Jika nilainya terlalu tinggi, Kubernetes mempertahankan banyak versi historis Set Replika, yang meningkatkan beban manajemen pada kube-controller-manager. Di kluster berskala besar, jika ada banyak deployment dan sering diperbarui, Anda dapat menurunkan nilai revisionHistoryLimit untuk deployment guna membersihkan Set Replika lama. Nilai default revisionHistoryLimit untuk 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 secara otomatis membersihkan Pod lama di kluster. Hal ini menentukan bahwa job dan Pod terkaitnya secara otomatis dibersihkan (dihapus) setelah periode tertentu.

Konfigurasikan resource dengan benar untuk komponen tipe Informer

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 resource memori komponen ini untuk menghindari error kehabisan memori (OOM). Error OOM yang sering dapat menyebabkan masalah dengan pemantauan resource berkelanjutan. 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 petunjuk penggunaan metrik dan deskripsi detail, lihat Pemantauan komponen lapisan kontrol.

Penggunaan sumber daya control plane

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

Nama metrik	PromQL	Deskripsi

kube-apiserver

Untuk informasi lebih lanjut tentang cara melihat metrik dan deskripsi lengkap metrik, lihat Deskripsi metrik pemantauan kube-apiserver.

Jumlah objek resource

Nama	PromQL	Deskripsi
		Nama metrik adalah apiserver_storage_objects jika kluster ACK Anda menjalankan Kubernetes 1.22 atau lebih baru. Nama metrik adalah etcd_object_counts jika kluster ACK Anda menjalankan Kubernetes 1.22 atau 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 yang 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 yang ditampilkan berdasarkan dimensi berikut: Pod API server, verb seperti GET, WATCH, LIST, dan CONNECT, resource, dan cakupan.

Pembatasan laju permintaan

Nama

PromQL

Deskripsi

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 lebih lanjut tentang cara melihat metrik dan deskripsi lengkap metrik, lihat Deskripsi metrik pemantauan kube-scheduler.

Jumlah Pod pending

Nama

PromQL

Deskripsi

Scheduler Pending Pods

scheduler_pending_pods{job="ack-scheduler"}

Jumlah Pod pending. Pod pending terdiri dari tipe berikut:

unschedulable: Pod yang tidak dapat dijadwalkan.
backoff: Pod antrian backoff, yaitu Pod yang gagal dijadwalkan karena alasan tertentu.
active: Pod 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 lebih lanjut tentang cara melihat metrik dan deskripsi lengkap metrik, lihat Deskripsi metrik pemantauan 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 lebih lanjut tentang cara melihat metrik dan deskripsi lengkap metrik, lihat Deskripsi metrik pemantauan 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 lebih lanjut tentang kuota dan batas kluster ACK, lihat Kuota dan batas.
Untuk informasi lebih lanjut tentang cara merencanakan jaringan VPC dan jaringan kontainer untuk kluster dengan benar, lihat Merencanakan jaringan untuk kluster ACK managed.
Untuk informasi lebih lanjut 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 terlebih dahulu melihat Troubleshooting dan FAQ manajemen kluster untuk memecahkan masalah tersebut.