Ikhtisar penskalaan node di kluster ACK - Container Service for Kubernetes

Jika kluster ACK Anda tidak dapat menjadwalkan Pod yang tertunda, gunakan penskalaan node untuk menambah atau menghapus node secara otomatis. ACK menyediakan penyesuaian otomatis node dan penskalaan instan node. Dibandingkan dengan penyesuaian otomatis node, penskalaan instan node lebih cepat dan sederhana.

Sebelum memulai

Baca topik ini untuk memahami solusi penskalaan node ACK dan memilih solusi yang paling sesuai dengan workload Anda sebelum mengaktifkan penskalaan node.

Pelajari penskalaan manual, penyesuaian otomatis, skalabilitas horizontal, dan skalabilitas vertikal dalam dokumentasi resmi Kubernetes.

Cara kerja penskalaan node

Penskalaan node Kubernetes berbeda dari model tradisional berbasis ambang batas pemanfaatan resource. Pertimbangkan hal ini saat melakukan migrasi dari pusat data atau sistem orkestrasi lain ke Kubernetes.

Model penskalaan tradisional menambah node ketika pemanfaatan CPU atau memori melebihi ambang batas tertentu. Namun, model ini memiliki beberapa kelemahan berikut.

Bagaimana ambang batas penskalaan ditentukan?

Node panas biasanya memiliki pemanfaatan resource yang lebih tinggi dibandingkan node lainnya.

Jika penskalaan dipicu oleh pemanfaatan rata-rata, permintaan pada node panas akan tersamarkan oleh node yang kurang dimanfaatkan, sehingga mencegah skala keluar yang tepat waktu.
Jika penskalaan dipicu oleh pemanfaatan puncak, biasanya terjadi pemborosan resource di seluruh kluster.

Bagaimana beban dikurangi setelah node ditambahkan?

Di Kubernetes, Pod merupakan unit deployable terkecil. Menambahkan node tidak mendistribusikan ulang beban Pod yang sudah ada — jumlah Pod dan batas resource tetap tidak berubah, sehingga node baru tidak menerima trafik dari Pod yang kelebihan beban.

Bagaimana penskalaan node dipicu dan dilakukan?

Penskalaan berbasis pemanfaatan dapat mengeluarkan (evict) Pod dengan permintaan resource tinggi tetapi penggunaan aktual rendah. Jika banyak Pod seperti ini ada, resource yang dapat dijadwalkan akan habis dan beberapa Pod menjadi tidak dapat dijadwalkan.

ACK menggunakan penskalaan node (lapisan resource) dan penskalaan workload (lapisan penjadwalan) untuk mengatasi hal ini. Penskalaan node memicu penskalaan berdasarkan pemanfaatan resource Pod.

Bagaimana aktivitas skala keluar dipicu?

Model penskalaan node memantau Pod yang tidak dapat dijadwalkan. Ketika Pod gagal dijadwalkan karena kekurangan resource, sistem melakukan simulasi penjadwalan, memilih kelompok node yang telah diaktifkan fitur penyesuaian otomatisnya, lalu menambahkan node ke kluster.

Catatan

Simulasi tersebut mengabstraksikan setiap kelompok node yang diaktifkan penyesuaian otomatisnya sebagai node virtual dengan kapasitas CPU, memori, dan GPU sesuai tipe instans yang dikonfigurasi, serta label dan taint dari kelompok node tersebut. Penjadwal menambahkan node virtual ini ke daftar node yang dapat dijadwalkan, menghitung jumlah node yang diperlukan, lalu menyediakan node tersebut.

Bagaimana aktivitas skala-masuk dipicu?

Skala-masuk hanya berlaku untuk node dalam kelompok node yang diaktifkan fitur penyesuaian otomatisnya; node statis tidak dikelola. Ketika pemanfaatan node turun di bawah ambang batas skala-masuk, model mensimulasikan eviksi Pod untuk memverifikasi apakah node tersebut dapat dikosongkan. Pod non-DaemonSet di namespace kube-system dan Pod yang dilindungi oleh PodDisruptionBudget dilewati. Setelah semua Pod yang memenuhi syarat dievict ke node lain, node tersebut dihapus.

Bagaimana kelompok node dipilih jika terdapat beberapa kelompok node dengan fitur penyesuaian otomatis yang diaktifkan?

Beberapa kelompok node yang diaktifkan penyesuaian otomatisnya diperlakukan sebagai node abstrak. Autoscaler memberi skor berdasarkan kebijakan penjadwalan standar, memprioritaskan aturan afinitas seperti node affinity.

Jika tidak ditemukan kecocokan melalui aturan afinitas, penyesuaian otomatis node kembali menggunakan prinsip least-waste, memilih kelompok node yang menyisakan resource idle paling sedikit setelah skala keluar.

Catatan

Ketika baik kelompok node dengan akselerasi GPU maupun CPU yang diaktifkan penyesuaian otomatisnya memenuhi kondisi skala keluar, kelompok node berakselerasi CPU diprioritaskan.

Secara default, penskalaan instan node mengevaluasi ketersediaan dan biaya instans, memprioritaskan tipe dengan kapasitas mencukupi dan harga terendah.

Bagaimana cara meningkatkan tingkat keberhasilan penyesuaian otomatis?

Tingkat keberhasilan penyesuaian otomatis bergantung pada faktor-faktor berikut:

Apakah kondisi penjadwalan terpenuhi

Setelah membuat kelompok node yang diaktifkan penyesuaian otomatisnya, pastikan kebijakan penjadwalan Pod untuk kelompok node tersebut. Jika ragu, konfigurasikan nodeSelector dengan label kelompok node dan jalankan simulasi penjadwalan.
Apakah resource mencukupi

Setelah simulasi, sistem memilih kelompok node yang diaktifkan penyesuaian otomatisnya dan menambahkan node. Namun, inventaris tipe instans ECS dalam konfigurasi kelompok node memengaruhi tingkat keberhasilan skala keluar. Tentukan beberapa tipe instans di berbagai zona untuk meningkatkan tingkat keberhasilan.

Bagaimana cara mempercepat penyesuaian otomatis?

Metode 1: Gunakan mode swift. Setelah kelompok node yang diaktifkan penyesuaian otomatisnya menyelesaikan satu siklus skala keluar dan satu siklus skala-masuk, kelompok tersebut memasuki mode swift. Lihat Aktifkan penyesuaian otomatis node.
Metode 2: Gunakan custom image berbasis Alibaba Cloud Linux 3 untuk meningkatkan efisiensi pengiriman resource IaaS hingga 50%. Lihat Optimalkan penskalaan dengan custom image.

Solusi penskalaan: penyesuaian otomatis node dan penskalaan instan node

Penskalaan node adalah fitur tingkat resource yang secara otomatis menyesuaikan jumlah node di kluster Anda. Ketika kapasitas yang ada tidak mencukupi untuk penjadwalan Pod, autoscaler menyediakan node tambahan.

ACK menyediakan dua solusi untuk penskalaan node.

Pengantar

Penting

Hanya satu komponen penskalaan yang dapat berjalan di dalam kluster. Kedua solusi tidak dapat digunakan bersamaan. Untuk mengaktifkan penskalaan node, lihat Aktifkan penyesuaian otomatis node dan Aktifkan penskalaan instan node.
Statistik penskalaan dalam topik ini merupakan nilai teoretis berdasarkan custom image. Hasil aktual di lingkungan Anda mungkin berbeda. Lihat Optimalkan penskalaan dengan custom image.
Kedua solusi penskalaan berlaku untuk node dalam kelompok node yang diaktifkan fitur penyesuaian otomatisnya.

Solusi	Komponen	Deskripsi
Solusi 1: penyesuaian otomatis node	cluster-autoscaler	Memeriksa status kluster dalam siklus round-robin dan melakukan penskalaan node ketika kondisi terpenuhi.
Solusi 2: penskalaan instan node	ACK GOATScaler	Autoscaler node berbasis event yang memastikan pengiriman resource efisien di kluster besar dan skenario skala keluar berturut-turut. Kluster dianggap besar jika salah satu kelompok node yang diaktifkan fitur penyesuaian otomatisnya berisi lebih dari 100 node, atau lebih dari 20 kelompok node di kluster tersebut memiliki fitur penyesuaian otomatis yang diaktifkan. Kecepatan penskalaan: 45 detik; tingkat keberhasilan: 99%; pengurangan fragmentasi resource: 30%. Mendukung kebijakan penskalaan kustom untuk ekstensibilitas.

Perbandingan solusi

Untuk kelompok node yang diaktifkan penyesuaian otomatisnya (tanpa mode swift), fitur penskalaan instan node kompatibel dengan konfigurasi kelompok node yang ada dan mendukung semua jenis Pod. Tabel berikut membandingkan penskalaan instan node dengan penyesuaian otomatis node.

Manfaat	Penyesuaian otomatis node	Penskalaan instan node
Kecepatan dan efisiensi penskalaan	60 detik dalam mode standar, 50 detik dalam mode swift.	Dengan penskalaan berbasis event dan Alibaba Cloud ContainerOS, setiap aktivitas penskalaan membutuhkan waktu 35–55 detik.
	Penyesuaian otomatis mencapai bottleneck performa pada 1 menit. Efisiensi berfluktuasi tergantung jumlah kelompok node dan skenario penskalaan — melebihi 100 kelompok node meningkatkan durasi menjadi 100–150 detik.	Durasi penskalaan tetap stabil meskipun jumlah kelompok node atau Pod meningkat, sehingga cocok untuk skenario penskalaan cepat.
	Mode round-robin dengan pembaruan status kluster. Latensi minimum: 5 detik.	Berbasis event. Latensi: 1–3 detik.
Tingkat keberhasilan penskalaan resource	Karena fluktuasi inventaris resource cloud dan variasi tipe instans, tingkat keberhasilan penyesuaian otomatis node sekitar 97%.	Kebijakan pemilihan inventaris otomatis menyaring ribuan tipe instans Alibaba Cloud berdasarkan kondisi dan prioritas yang telah ditentukan, secara otomatis memilih tipe optimal atau alternatif cadangan ketika tipe yang ditentukan tidak tersedia. Hal ini menyederhanakan O&M dan meningkatkan tingkat keberhasilan menjadi 99%.
	Skala keluar menggunakan tipe instans dari konfigurasi kelompok node. Ketika beberapa tipe ditentukan, tipe dengan spesifikasi terendah diprioritaskan.	Anda dapat menentukan beberapa tipe instans untuk aktivitas skala keluar.
	Autoscaler mencoba ulang secara berkala ketika penskalaan resource gagal.	Autoscaler dapat menghasilkan alert ketika tipe instans yang ditentukan tidak mencukupi.
Penggunaan dan O&M	Dibandingkan dengan penyesuaian otomatis node, penskalaan instan node lebih mudah digunakan dalam aspek-aspek berikut: Pemeliharaan konfigurasi kelompok node: Penskalaan instan node secara otomatis memilih instans lintas tipe dan zona untuk menampung Pod yang tertunda. Dengan penyesuaian otomatis node, Anda harus memelihara konfigurasi kelompok node secara manual dan memperbaruinya setiap kali konfigurasi Pod berubah. O&M node: Pengecualian penskalaan ditampilkan melalui event Pod, sehingga developer dapat fokus pada manajemen siklus hidup Pod. Ekstensi fitur: Kedua solusi bekerja dengan Descheduler untuk menyiapkan resource elastis. Penskalaan instan node bersifat non-intrusif dan mendukung aksi kustom dalam kebijakan penyediaan resource dan manajemen siklus hidup node untuk pengembangan sekunder.
Kebijakan penjadwalan	Selain fitur penjadwalan penyesuaian otomatis node, penskalaan instan node juga mendukung: Topology: Memenuhi persyaratan ketersediaan tinggi lintas zona. Pod Disruption Budgets: Membatasi eviksi Pod sukarela simultan dalam aplikasi multi-Pod, memastikan stabilitas selama gangguan terencana.
Kebijakan penjadwalan	Penskalaan instan node mengurangi tingkat fragmentasi resource sebesar 30% menggunakan kebijakan Bin Packing dan PreBind (fitur kustom).

Batasan penskalaan instan node

Batasan berikut berlaku untuk penskalaan instan node. Tinjau batasan ini sebelum mengaktifkan penskalaan instan node.

Penskalaan instan node tidak mendukung mode swift.
Satu kelompok node dapat berisi hingga 180 node per batch skala keluar.
Skala-masuk tidak dapat dinonaktifkan untuk kluster tertentu.

Catatan
Untuk menonaktifkan skala-masuk pada node tertentu, lihat Bagaimana mencegah node agar tidak diskala-masuk oleh penskalaan instan node?
Solusi penskalaan instan node tidak memeriksa inventaris instans preemptible. Jika Billing Method kelompok node diatur ke instans preemptible dan opsi Use Pay-as-you-go Instances When Spot Instances Are Insufficient diaktifkan, instans pay-as-you-go dapat diskala keluar meskipun instans preemptible tersedia dalam jumlah cukup.

Pilih solusi penskalaan node

Lihat Perbandingan solusi dan Batasan penskalaan instan node. Pilih penyesuaian otomatis node jika workload Anda memiliki tuntutan lebih rendah terhadap kecepatan penskalaan dan kepastian pengiriman, serta batasan penskalaan instan node tidak dapat diterima.

Jika workload Anda memiliki salah satu persyaratan berikut, penskalaan instan node direkomendasikan:

Kluster besar sangat menurunkan efisiensi penyesuaian otomatis node. Pilih penskalaan instan node, karena ukuran kluster hampir tidak berdampak pada efisiensi penskalaannya. Kluster dianggap besar jika salah satu kelompok node yang diaktifkan fitur penyesuaian otomatisnya berisi lebih dari 100 node, atau lebih dari 20 kelompok node di kluster tersebut memiliki fitur penyesuaian otomatis yang diaktifkan.
Diperlukan kecepatan penskalaan lebih cepat. Mode standar: penyesuaian otomatis node membutuhkan 60 detik; penskalaan instan node membutuhkan 45 detik.
Batch skala keluar berturut-turut sering terjadi. Dalam skenario penskalaan berturut-turut, performa penyesuaian otomatis node menurun dan berfluktuasi, sedangkan penskalaan instan node mempertahankan waktu penskalaan konsisten sekitar 45 detik.

Catatan penggunaan

Kuota dan batasan

Tabel rute VPC mendukung hingga 200 entri rute kustom. Untuk menambah batas ini, ajukan permohonan di Konsol Pusat Kuota. Untuk kuota resource lainnya, lihat Kuota Produk Cloud Dasar.
Konfigurasikan jumlah maksimum node dalam kelompok node yang diaktifkan penyesuaian otomatisnya dengan hati-hati. Pastikan resource dan kuota dependen mencukupi, seperti Blok CIDR VPC dan vSwitch, atau aktivitas skala keluar dapat gagal. Untuk batasan kelompok node, lihat Aktifkan penyesuaian otomatis node. Untuk perencanaan jaringan, lihat Perencanaan jaringan kluster ACK yang dikelola.
Penskalaan node tidak mendukung node langganan. Jangan mengatur metode penagihan ke langganan saat membuat kelompok node yang diaktifkan penyesuaian otomatisnya. Untuk kelompok node yang sudah ada, pastikan tidak ada node langganan sebelum mengaktifkan penyesuaian otomatis.
Fitur penskalaan node tidak kompatibel dengan SideCar Containers. Deploy workload Sidecar Container ke kelompok node dengan penyesuaian otomatis dinonaktifkan.

Pemeliharaan resource dependen

Jika elastic IP addresses (EIPs) dikaitkan dengan node ECS yang ditambahkan oleh penskalaan node, jangan menghapus node tersebut langsung dari Konsol ECS. EIP tidak akan dilepas secara otomatis.

Referensi

Lihat Aktifkan penyesuaian otomatis node dan Aktifkan penskalaan instan node.

Lihat FAQ penyesuaian otomatis node.

Luaskan untuk melihat indeks FAQ tentang penyesuaian otomatis node

Kategori	Subkategori	Tautan
Perilaku penskalaan penyesuaian otomatis node	Batasan yang diketahui
	Perilaku skala keluar	Kebijakan penjadwalan apa yang digunakan cluster-autoscaler untuk menentukan apakah Pod yang tidak dapat dijadwalkan dapat dijadwalkan ke kelompok node yang diaktifkan penyesuaian otomatisnya? Resource apa saja yang dapat disimulasikan cluster-autoscaler untuk analisis penjadwalan? Mengapa add-on penyesuaian otomatis node gagal melakukan skala keluar node? Bagaimana autoscaler menghitung resource grup penskalaan yang berisi beberapa tipe instans? Saat skala keluar, bagaimana autoscaler memilih antara beberapa kelompok node yang diaktifkan? Bagaimana mengonfigurasi resource kustom untuk kelompok node yang diaktifkan penyesuaian otomatisnya? Mengapa pengaktifan penyesuaian otomatis untuk kelompok node gagal?
	Perilaku skala-masuk	Mengapa cluster-autoscaler gagal melakukan skala-masuk node? Bagaimana mengaktifkan atau menonaktifkan eviksi untuk DaemonSet tertentu? Jenis Pod apa saja yang dapat mencegah cluster-autoscaler menghapus node?
	Dukungan ekstensi	Apakah cluster-autoscaler mendukung CustomResourceDefinitions (CRDs)?
Perilaku penskalaan kustom	Kontrol perilaku penskalaan menggunakan Pod	Bagaimana menunda respons skala keluar cluster-autoscaler terhadap Pod yang tidak dapat dijadwalkan?
Perilaku penskalaan kustom	Kontrol perilaku penskalaan menggunakan node	Bagaimana mencegah node tertentu agar tidak diskala-masuk oleh cluster-autoscaler? Bagaimana memengaruhi skala-masuk node menggunakan anotasi Pod?
Komponen cluster-autoscaler		Bagaimana cara memperbarui cluster-autoscaler ke versi terbaru? Operasi apa saja yang memicu pembaruan otomatis cluster-autoscaler? Mengapa penskalaan node gagal di kluster ACK yang dikelola saya meskipun saya telah memberikan izin peran yang diperlukan?

Luaskan untuk melihat indeks FAQ tentang penskalaan instan node

Kategori	Subkategori	Tautan
Perilaku penskalaan instan node	Batasan yang diketahui
	Perilaku skala keluar	Jenis resource apa saja yang digunakan penskalaan instan node untuk simulasi penskalaan? Apakah penskalaan instan node memilih tipe instans yang sesuai dari kelompok node berdasarkan permintaan resource Pod? Bagaimana penskalaan instan node memilih tipe instans dari kelompok node dengan beberapa tipe? Bagaimana cara memantau inventaris tipe instans di kelompok node saat menggunakan penskalaan instan node? Bagaimana cara mengoptimalkan konfigurasi kelompok node untuk menghindari kegagalan skala keluar akibat inventaris tidak mencukupi? Mengapa penskalaan instan node gagal melakukan skala keluar node? Bagaimana cara mengonfigurasi resource kustom untuk kelompok node yang diaktifkan penskalaan instan node?
	Perilaku skala-masuk	Mengapa penskalaan instan node gagal melakukan skala-masuk node? Jenis Pod apa saja yang dapat mencegah penskalaan instan node menghapus node?
Perilaku penskalaan kustom	Mengontrol penskalaan dengan Pod	Bagaimana cara mengontrol skala-masuk node menggunakan Pod?
Perilaku penskalaan kustom	Mengontrol penskalaan dengan node	Bagaimana cara menentukan node mana yang akan dihapus selama skala-masuk? Bagaimana mencegah node tertentu agar tidak diskala-masuk? Apakah penskalaan instan node dapat dikonfigurasi untuk hanya melakukan skala-masuk pada node kosong?
Add-on penskalaan instan node		Apakah add-on penskalaan instan node diperbarui secara otomatis? Mengapa penskalaan node gagal di kluster ACK yang dikelola saya setelah saya memberikan izin yang diperlukan?