全部产品
Search

搜索本产品

    Container Service for Kubernetes：Ikhtisar penskalaan node

    文档中心

    Container Service for Kubernetes：Ikhtisar penskalaan node

    更新时间：Nov 22, 2025

    Jika perencanaan kapasitas kluster Anda tidak dapat memenuhi persyaratan penjadwalan pod aplikasi, Anda dapat menggunakan fitur penskalaan node untuk secara otomatis menskalakan sumber daya node dan meningkatkan kapasitas penjadwalan. ACK menyediakan dua solusi penskalaan elastis: penskalaan otomatis node dan penskalaan instan node. Penskalaan instan node menawarkan penskalaan yang lebih cepat, efisiensi pengiriman yang lebih tinggi, serta hambatan masuk yang lebih rendah dibandingkan penskalaan otomatis node.

    Sebelum memulai

    Ikhtisar ini membantu Anda memahami solusi penskalaan node yang disediakan oleh ACK dan memilih solusi yang paling sesuai dengan kebutuhan bisnis Anda sebelum mengaktifkan fitur penskalaan node.

    Sebelum membaca topik ini, kami menyarankan agar Anda memahami konsep penskalaan seperti penskalaan manual, penskalaan otomatis, skalabilitas horizontal, dan skalabilitas vertikal dengan membaca dokumentasi resmi Kubernetes.

    Cara kerja

    Di Kubernetes, penskalaan node bekerja berbeda dari model tradisional yang berbasis ambang batas penggunaan. Memahami perbedaan ini penting ketika Anda melakukan migrasi dari pusat data tradisional atau sistem orkestrasi lainnya ke kluster Kubernetes.

    Model penskalaan elastis tradisional berbasis penggunaan. Misalnya, jika penggunaan CPU dan memori node dalam kluster melebihi ambang batas tertentu, sistem akan melakukan skala keluar dengan menambahkan node baru. Namun, model ini memiliki beberapa masalah berikut.

    Bagaimana ambang batas dipilih dan dievaluasi?

    Dalam sebuah kluster, beberapa node hotspot mungkin memiliki utilisasi tinggi sementara node lainnya memiliki utilisasi rendah.

    • Jika penskalaan elastis ditentukan berdasarkan rata-rata utilisasi sumber daya seluruh kluster, utilisasi tinggi pada node hotspot akan dirata-ratakan. Hal ini menyebabkan keterlambatan penskalaan untuk node hotspot.

    • Jika penskalaan elastis ditentukan berdasarkan utilisasi node tertinggi, hal ini dapat menyebabkan pemborosan sumber daya akibat skala keluar yang tidak perlu dan memengaruhi layanan keseluruhan kluster.

    Bagaimana tekanan dikurangi setelah instans diperluas?

    Dalam kluster Kubernetes, aplikasi dideploy sebagai pod di berbagai node. Ketika sebuah pod memiliki utilisasi sumber daya tinggi, hal ini dapat memicu skala keluar pada node atau kluster tersebut. Namun, jumlah replika pod untuk aplikasi dan Limit yang sesuai pada pod tidak berubah. Oleh karena itu, tekanan beban pada node asli tidak dialihkan ke node yang baru ditambahkan.

    Bagaimana evaluasi dan eksekusi skala-masuk instans dilakukan?

    Jika skala-masuk node ditentukan berdasarkan utilisasi sumber daya, pod yang meminta banyak sumber daya tetapi hanya menggunakan sedikit kemungkinan besar akan dievakuasi. Jika kluster berisi banyak pod semacam itu, pod tersebut akan menempati sejumlah besar sumber daya penjadwalan, yang dapat menyebabkan pod lain menjadi tidak dapat dijadwalkan.

    Untuk mengatasi masalah-masalah tersebut, ACK menggunakan model elastis dua lapisan: penskalaan node (lapisan sumber daya) dan penskalaan beban kerja (lapisan penjadwalan). Sebagai contoh, fitur penskalaan node memicu perubahan replika aplikasi—yang merupakan unit penjadwalan—berdasarkan penggunaan sumber daya. Bagian-bagian berikut menjelaskan detail teknisnya.

    Bagaimana cara menentukan apakah sebuah node ditampilkan?

    Penskalaan node memantau pod yang gagal dijadwalkan dan menentukan apakah akan memicu skala keluar. Jika sebuah pod gagal dijadwalkan karena sumber daya tidak mencukupi, penskalaan node menjalankan simulasi penjadwalan. Simulasi ini menghitung kelompok node mana yang telah diaktifkan penskalaan otomatisnya dan dapat menyediakan sumber daya node yang diperlukan untuk pod yang tertunda. Jika ditemukan kelompok node yang sesuai, node yang bersangkutan akan diperluas kapasitasnya.

    Catatan

    Saat simulasi penjadwalan, kelompok node yang diaktifkan penskalaan otomatisnya diperlakukan sebagai node abstrak. Tipe instans yang dikonfigurasi dalam kelompok node tersebut menentukan kapasitas CPU, memori, atau GPU dari node abstrak tersebut. Label dan taint yang dikonfigurasi juga menjadi label dan taint dari node abstrak tersebut. Penjadwal simulasi memasukkan node abstrak ini ke dalam evaluasi penjadwalannya. Jika kondisi penjadwalan terpenuhi, penjadwal simulasi menghitung jumlah node yang diperlukan dan memicu kelompok node untuk melakukan skala keluar.

    Bagaimana evaluasi skala-masuk node dilakukan?

    Penskalaan node hanya melakukan skala-masuk pada node yang berada dalam kelompok node yang telah diaktifkan penskalaan otomatisnya. Fitur ini tidak dapat mengelola node statis. Setiap node dievaluasi secara individual untuk skala-masuk. Ketika utilisasi sumber daya sebuah node turun di bawah ambang batas yang dikonfigurasi, evaluasi skala-masuk akan dipicu. Pada titik ini, penskalaan node mensimulasikan evakuasi beban kerja pada node tersebut untuk menentukan apakah node tersebut dapat dikosongkan dengan aman. Kehadiran pod tertentu, seperti pod non-DaemonSet di namespace kube-system atau pod yang dilindungi oleh Pod Disruption Budget (PDB), akan mencegah node tersebut dikosongkan. Jika sebuah node dapat dikosongkan, pod-nya dievakuasi ke node lain, lalu node tersebut dihapus.

    Bagaimana memilih kelompok node dari beberapa kelompok node yang diaktifkan penskalaan otomatisnya?

    Memilih antara berbagai kelompok node yang diaktifkan penskalaan otomatisnya sama dengan memilih antara berbagai node abstrak. Mirip dengan kebijakan penjadwalan pod, mekanisme penilaian digunakan untuk memilih kelompok node. Komponen penskalaan elastis pertama-tama menyaring kelompok node yang sesuai dengan persyaratan penjadwalan pod, lalu membuat pilihan lebih lanjut berdasarkan kebijakan afinitas seperti affinity.

    Jika kelompok node yang sesuai tidak dapat dipilih berdasarkan kebijakan di atas, penskalaan otomatis node secara default memilih kelompok node berdasarkan kebijakan least-waste. Inti dari kebijakan least-waste adalah menemukan opsi yang menghasilkan sumber daya tidak terpakai paling sedikit setelah simulasi skala keluar.

    Catatan

    Jika kelompok node GPU dan kelompok node CPU yang diaktifkan penskalaan otomatisnya sama-sama dapat diperluas, kelompok node CPU diprioritaskan secara default.

    Secara default, penskalaan instan node secara komprehensif mengevaluasi ketersediaan inventaris dan biaya. Fitur ini memprioritaskan pemilihan tipe instans dengan inventaris yang cukup dan biaya lebih rendah dari berbagai opsi skala keluar yang memungkinkan.

    Bagaimana meningkatkan tingkat keberhasilan penskalaan elastis

    Tingkat keberhasilan penskalaan elastis terutama bergantung pada dua faktor berikut:

    • Apakah kebijakan penjadwalan terpenuhi?

      Setelah Anda mengonfigurasi kelompok node yang diaktifkan penskalaan otomatisnya, Anda harus memastikan rentang kebijakan penjadwalan pod yang dapat didukung oleh kelompok node tersebut. Jika Anda tidak dapat menentukannya secara langsung, Anda dapat menggunakan nodeSelector yang menargetkan label kelompok node untuk melakukan simulasi pra-penskalaan.

    • Konfigurasi sumber daya yang memadai

      Setelah simulasi penjadwalan berhasil, sistem memilih kelompok node yang diaktifkan penskalaan otomatisnya untuk memperluas instans. Namun, inventaris tipe instans ECS yang dikonfigurasi dalam kelompok node tersebut secara langsung memengaruhi apakah instans dapat berhasil diperluas. Oleh karena itu, kami menyarankan agar Anda mengonfigurasi beberapa zona dan berbagai tipe instans untuk meningkatkan tingkat keberhasilan skala keluar.

    Bagaimana meningkatkan kecepatan penskalaan elastis

    • Metode 1: Gunakan mode swift untuk mempercepat kecepatan skala keluar. Setelah kelompok node yang diaktifkan penskalaan otomatisnya melakukan pemanasan dengan menyelesaikan satu siklus skala keluar dan satu siklus skala-masuk, kelompok node tersebut dapat memasuki mode penskalaan swift. Untuk informasi lebih lanjut, lihat Aktifkan penskalaan otomatis node.

    • Metode 2: Gunakan gambar kustom berbasis Alibaba Cloud Linux 3 untuk meningkatkan kecepatan pengiriman sumber daya lapisan IaaS hingga 50%. Untuk informasi lebih lanjut, lihat Optimalkan penskalaan elastis dengan gambar kustom.

    Solusi penskalaan elastis: penskalaan otomatis node dan penskalaan instan node

    Penskalaan node adalah kemampuan penskalaan elastis pada lapisan sumber daya. Fitur ini secara otomatis menskalakan sumber daya node untuk meningkatkan kapasitas penjadwalan ketika kapasitas kluster tidak dapat memenuhi persyaratan penjadwalan pod aplikasi. ACK menyediakan dua solusi penskalaan node.

    Pengantar

    Penting

    • Hanya satu komponen penskalaan elastis yang dapat berjalan dalam sebuah kluster. Dua solusi penskalaan elastis ini tidak dapat digunakan bersamaan. Untuk mengaktifkan fitur penskalaan node, ikuti prosedur standar dalam Aktifkan penskalaan otomatis node atau Aktifkan penskalaan instan node.

    • Data kinerja penskalaan elastis yang disajikan dalam topik ini merupakan nilai teoretis berdasarkan gambar kustom yang dioptimalkan untuk penskalaan elastis. Kinerja aktual dapat bervariasi tergantung pada lingkungan bisnis Anda. Untuk informasi lebih lanjut tentang gambar kustom, lihat Optimalkan penskalaan elastis dengan gambar kustom.

    Solusi

    Komponen penskalaan elastis

    Deskripsi

    Solusi 1: penskalaan otomatis node

    komponen cluster-autoscaler

    Secara berkala memelihara dan memeriksa status kluster menggunakan polling untuk menemukan kondisi yang memenuhi persyaratan skala keluar atau skala-masuk, lalu secara otomatis menskalakan node kluster.

    Solusi 2: penskalaan instan node

    Komponen penskalaan instan node

    Sebuah pengontrol penskalaan node berbasis event-driven. Fitur ini memastikan pengiriman sumber daya elastis yang lebih baik dalam skenario seperti kluster berskala besar (misalnya, kelompok node yang diaktifkan penskalaan otomatisnya memiliki lebih dari 100 node, atau terdapat lebih dari 20 kelompok node semacam itu) dan aktivitas skala keluar berturut-turut. Kecepatan penskalaan (waktu dari kegagalan penjadwalan pod pertama hingga penjadwalan berhasil) stabil di 45 detik, tingkat keberhasilan dapat mencapai 99%, dan fragmentasi sumber daya berkurang sekitar 30%. Fitur ini juga menawarkan ekstensibilitas yang lebih baik untuk kebijakan penskalaan kustom.

    Perbandingan solusi

    Jika kelompok node dalam kluster Anda telah diaktifkan penskalaan elastis otomatis dan Scaling Mode-nya diatur ke Non-swift Mode, penskalaan instan node kompatibel dengan semantik dan perilaku komponen penskalaan otomatis node. Hal ini memungkinkan transisi mulus untuk semua jenis aplikasi. Bagian ini menjelaskan fitur-fitur yang dioptimalkan pada penskalaan instan node dibandingkan dengan penskalaan otomatis node.

    Fitur yang ditingkatkan

    Penskalaan otomatis node

    Penskalaan instan node

    Kecepatan dan efisiensi penskalaan

    Untuk satu aktivitas penskalaan, kecepatan penskalaan sekitar 60 detik dalam mode standar dan 50 detik dalam mode swift.

    Memulai aksi penskalaan melalui mekanisme event-driven dan memanfaatkan kemampuan Alibaba Cloud ContainerOS untuk mempercepat penskalaan elastis. Kecepatan penskalaan sekitar 45±10 detik.

    Ketika waktu penskalaan mencapai 1 menit, kecepatan penskalaan mengalami bottleneck. Kecepatan penskalaan elastis juga menunjukkan jitter signifikan pada skala berbeda (beberapa kelompok node) dan dalam skenario berbeda (penskalaan berturut-turut). Misalnya, ketika jumlah kelompok node melebihi 100, kecepatan penskalaan menurun menjadi kisaran 100–150 detik.

    Kinerja tidak mengalami penurunan signifikan seiring peningkatan jumlah kelompok node dan pod. Hal ini membuatnya lebih cocok untuk skenario dengan persyaratan tinggi terhadap kecepatan pengiriman elastis.

    Menggunakan model polling dan dibatasi oleh ketergantungannya pada pemeliharaan status kluster. Sensitivitas penskalaan elastis minimum adalah 5 detik.

    Berbasis event-driven dan menggunakan model responsif. Sensitivitas penskalaan elastis adalah 1–3 detik.

    Kepastian pengiriman sumber daya

    Inventaris sumber daya cloud sering berubah. Karena isu seperti kombinasi tipe instans yang kompleks dan inventaris tidak mencukupi, tingkat keberhasilan penskalaan elastis penskalaan otomatis node sekitar 97%.

    Mendukung kebijakan pemilihan inventaris otomatis. Fitur ini dapat menyaring tipe instans yang kehabisan stok dari ribuan kombinasi tipe instans Alibaba Cloud berdasarkan kondisi dan urutan filter yang Anda konfigurasi. Fitur ini kemudian memilih tipe yang paling sesuai untuk skala keluar atau mengganti dengan tipe yang memenuhi syarat jika inventaris tidak mencukupi. Hal ini sangat mengurangi beban insinyur O&M dalam memilih tipe instans dan meningkatkan tingkat keberhasilan pengiriman menjadi 99%.

    Mendukung skala keluar dengan tipe instans yang sama seperti yang dikonfigurasi dalam kelompok node. Jika beberapa tipe dikonfigurasi, fitur ini memilih tipe instans terkecil yang memenuhi persyaratan untuk skala keluar.

    Mendukung skala keluar dengan tipe instans berbeda.

    Ketika pengiriman sumber daya gagal, fitur ini melakukan percobaan ulang secara berkala, yang merupakan pendekatan reaktif.

    Ketika pengiriman sumber daya gagal, fitur ini mendukung fitur peringatan inventaris untuk memberikan pemberitahuan awal mengenai potensi risiko terkait kombinasi tipe instans.

    Ambang penggunaan dan O&M

    Dibandingkan dengan penskalaan otomatis node, penskalaan instan node memiliki hambatan masuk yang lebih rendah. Hal ini terutama tercermin dalam aspek-aspek berikut.

    • Pemeliharaan konfigurasi kelompok node: Penskalaan instan node dapat secara otomatis memilih instans dari berbagai tipe instans dan zona berdasarkan properti instans untuk mengakomodasi pod yang tertunda. Sebaliknya, dengan penskalaan otomatis node, Anda harus memelihara konfigurasi setiap kelompok node secara manual untuk memastikan penjadwalan pod yang tepat. Oleh karena itu, ketika konfigurasi pod berubah, konfigurasi kelompok node yang sesuai sering kali perlu diperbarui juga.

    • O&M node: Bagi pengembang, semua pengecualian terkait proses penskalaan disinkronkan melalui event pod. Mereka hanya perlu mengelola siklus hidup pod.

    • Ekstensi fitur: Mendukung mekanisme ekstensi, seperti menggunakan Descheduler untuk menyiapkan sumber daya elastis. Penskalaan instan node mendukung interaksi filter non-intrusif antara kebijakan penyediaan sumber daya, manajemen siklus hidup node, dan perilaku kustom Anda, yang membuka lebih banyak kemungkinan untuk pengembangan kustom.

    Kebijakan penjadwalan

    Selain semua fitur penjadwalan penskalaan otomatis node, penskalaan instan node juga mendukung fitur-fitur berikut:

    • Topologi: Sering digunakan untuk memenuhi persyaratan ketersediaan tinggi lintas zona.

    • Pod Disruption Budgets: Membatasi jumlah pod dalam aplikasi multi-replika yang dapat dievakuasi secara sukarela pada waktu yang sama untuk memastikan stabilitas selama perubahan.

    Penskalaan instan node mendukung pemilihan kebijakan Bin Packing dan PreBind (fitur kustom) yang optimal berdasarkan pod, yang dapat mengurangi tingkat fragmentasi penjadwalan hingga 30%.

    Batasan penskalaan instan node

    Memahami batasan penskalaan instan node merupakan bagian penting dalam mengevaluasi solusi penskalaan instan node.

    • Mode swift tidak didukung.

    • Kelompok node tidak dapat memperluas lebih dari 180 node dalam satu batch.

    • Menonaktifkan skala-masuk di tingkat kluster saat ini tidak didukung.

      Catatan

      Untuk menonaktifkan skala-masuk di tingkat node, lihat Bagaimana cara mencegah node tertentu agar tidak di-skala-masuk oleh penskalaan instan node?.

    • Penskalaan instan node tidak mendukung pemeriksaan inventaris instans spot. Untuk kelompok node yang Billing Method-nya diatur ke Spot Instance dan Use On-Demand Instances To Supplement Spot Instance Capacity diaktifkan, instans sesuai permintaan mungkin diperluas meskipun inventaris instans spot mencukupi.

    Saran pemilihan solusi

    Berdasarkan Perbandingan solusi dan Batasan penskalaan instan node di atas, Anda dapat memilih solusi yang sesuai dengan kebutuhan Anda. Jika bisnis Anda memiliki persyaratan yang relatif rendah terhadap kecepatan penskalaan, kepastian pengiriman sumber daya, dan biaya O&M, serta tidak dapat menerima batasan penskalaan instan node, maka penskalaan otomatis node mungkin sudah cukup. Sebaliknya, jika Anda memiliki persyaratan bisnis berikut, penskalaan instan node adalah solusi yang direkomendasikan.

    • Kluster berukuran besar. Misalnya, jika kelompok node yang diaktifkan penskalaan otomatisnya memiliki lebih dari 100 node, atau terdapat lebih dari 20 kelompok node semacam itu, efisiensi skala keluar penskalaan otomatis node menurun secara signifikan seiring pertumbuhan ukuran kluster. Sebaliknya, kinerja penskalaan instan node mengalami fluktuasi yang lebih kecil.

    • Anda memiliki persyaratan tinggi terhadap kecepatan pengiriman sumber daya (kecepatan penskalaan elastis). Dalam skenario penskalaan tunggal, kecepatan penskalaan elastis penskalaan otomatis node dalam mode standar sekitar 60 detik, sedangkan untuk penskalaan instan node sekitar 45 detik.

    • Batch beban kerja bisnis tidak dapat diprediksi, dan Anda sering perlu melakukan skala keluar berturut-turut untuk kelompok node elastis yang sama. Dalam mode penskalaan berturut-turut, kinerja penskalaan otomatis node menurun dan menunjukkan jitter signifikan. Sebaliknya, penskalaan instan node masih dapat mencapai kecepatan penskalaan sekitar 45 detik.

    Catatan

    Kuota dan batasan

    • Anda dapat menambahkan hingga 200 rute kustom ke tabel rute virtual private cloud (VPC). Untuk meningkatkan kuota ini, buka Quota Center dan ajukan permintaan. Untuk informasi lebih lanjut tentang kuota sumber daya lainnya dan cara meningkatkannya, lihat Kuota untuk dependensi cloud dasar.

    • Kami menyarankan agar Anda mengonfigurasi dengan tepat jumlah maksimum node dalam kelompok node yang diaktifkan penskalaan otomatisnya. Pastikan sumber daya dan kuota dependen, seperti blok CIDR VPC dan vSwitch, mencukupi untuk jumlah node yang ditentukan. Jika tidak, aktivitas skala keluar mungkin gagal. Untuk informasi lebih lanjut tentang cara mengonfigurasi jumlah maksimum node, lihat Konfigurasi jumlah instans. Untuk informasi lebih lanjut tentang perencanaan jaringan untuk ACK, lihat Perencanaan jaringan untuk kluster ACK yang dikelola.

    • Fitur penskalaan node tidak mendukung node langganan. Saat membuat kelompok node baru yang diaktifkan penskalaan otomatisnya, jangan memilih langganan sebagai metode penagihan. Untuk mengaktifkan penskalaan otomatis pada kelompok node yang sudah ada, pastikan kelompok node tersebut tidak berisi node langganan apa pun.

    • Fitur penskalaan node saat ini tidak mendukung Sidecar Containers. Deploy beban kerja yang menggunakan Sidecar Containers ke kelompok node yang tidak diaktifkan penskalaan otomatisnya.

    Pemeliharaan sumber daya dependen

    Jika Anda mengikat EIP ke node, jangan langsung menghapus node ECS yang diperluas oleh penskalaan node di Konsol ECS. Jika tidak, EIP tidak dapat dilepas secara otomatis.

    Langkah selanjutnya