全部产品
Search
文档中心

Container Service for Kubernetes:FAQ penskalaan otomatis node

更新时间:Dec 25, 2025

Topik ini menjelaskan masalah umum dan solusi yang mungkin Anda temui saat menggunakan fitur node auto scaling.

Indeks

Kategori

Subkategori

Tautan

Perilaku penskalaan node auto scaling

Batasan yang diketahui

Perilaku scale-out

Perilaku scale-in

Dukungan ekstensi

Apakah cluster-autoscaler mendukung CustomResourceDefinitions (CRDs)?

Perilaku penskalaan kustom

Kontrol perilaku penskalaan berbasis Pod

Kontrol perilaku penskalaan berbasis node

Add-on cluster-autoscaler terkait


Batasan yang diketahui

Ketidakmampuan memprediksi secara sempurna resource node yang tersedia

Resource yang tersedia pada node yang baru disediakan mungkin tidak persis sesuai dengan spesifikasi tipe instans karena OS dasar dan daemon sistem pada instans Elastic Compute Service (ECS) mengonsumsi sebagian resource. Untuk detailnya, lihat Mengapa ukuran memori berbeda dari spesifikasi tipe instans setelah saya membeli instans?

Karena overhead ini, estimasi resource yang digunakan oleh cluster-autoscaler mungkin sedikit lebih tinggi daripada resource yang sebenarnya dapat dialokasikan pada node baru. Meskipun perbedaan ini biasanya kecil, pertimbangkan hal-hal berikut saat mengonfigurasi permintaan resource Pod Anda:

  • Minta kurang dari kapasitas penuh instans. Total permintaan resource, termasuk CPU, memori, dan disk, harus kurang dari spesifikasi tipe instans. Sebagai panduan umum, kami merekomendasikan agar total permintaan resource Pod tidak melebihi 70% kapasitas node.

  • Pertimbangkan Pod non-Kubernetes atau Pod statis. Saat menentukan apakah suatu node memiliki resource yang cukup, cluster-autoscaler hanya mempertimbangkan permintaan resource dari Pod Kubernetes (termasuk Pod yang sedang pending dan Pod DaemonSet). Jika Anda menjalankan Pod statis yang tidak dikelola sebagai DaemonSet, Anda harus secara manual memperhitungkan dan menyisihkan resource untuk mereka.

  • Uji Pod besar terlebih dahulu. Jika suatu Pod meminta jumlah resource yang besar, misalnya lebih dari 70% resource node, Anda harus menguji dan memastikan terlebih dahulu bahwa Pod tersebut dapat dijadwalkan ke node dengan tipe instans yang sama.

Kebijakan penjadwalan terbatas

Add-on cluster-autoscaler hanya mendukung seperangkat kebijakan penjadwalan terbatas untuk menentukan apakah Pod yang tidak dapat dijadwalkan dapat dijadwalkan ke kelompok node tempat Auto Scaling diaktifkan. Untuk detailnya, lihat Kebijakan penjadwalan apa yang digunakan cluster-autoscaler untuk menentukan apakah Pod yang tidak dapat dijadwalkan dapat dijadwalkan ke kelompok node tempat auto scaling diaktifkan?

Hanya kebijakan tipe resource yang didukung

Saat menggunakan ResourcePolicy untuk menyesuaikan prioritas resource elastis, hanya kebijakan tipe resource yang didukung. Untuk detailnya, lihat Menyesuaikan prioritas penjadwalan resource elastis.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx 
  units:
  - resource: ecs
  - resource: eci

Scale out tipe instans tertentu dalam kelompok node multi-tipe tidak didukung

Jika kelompok node Anda dikonfigurasi dengan beberapa tipe instans, Anda tidak dapat mengarahkan cluster-autoscaler untuk menyediakan tipe instans tertentu selama operasi scale-out.

Sebagai gantinya, cluster-autoscaler memodelkan kapasitas seluruh kelompok node berdasarkan tipe instans terkecil yang tersedia (yaitu, tipe dengan jumlah resource seperti CPU dan memori paling sedikit). Untuk detail perhitungan ini, lihat Jika grup penskalaan dikonfigurasi dengan beberapa tipe instans, bagaimana autoscaler menghitung kapasitas grup tersebut untuk pengambilan keputusan penskalaan?

Pod dengan batasan spesifik zona mungkin gagal memicu scale-out dalam kelompok node multi-zona

Jika kelompok node Anda mencakup beberapa zona ketersediaan, Pod yang bergantung pada zona tertentu mungkin tidak memicu scale-out. Hal ini dapat terjadi jika Pod memerlukan zona tertentu karena:

  • Klaim volume persisten (PVC) yang terikat pada volume yang berlokasi di zona tersebut.

  • nodeSelector, nodeAffinity, atau aturan penjadwalan lain yang menargetkan zona tersebut.

Dalam kasus ini, cluster-autoscaler mungkin gagal menyediakan node baru di zona ketersediaan yang diperlukan. Untuk kasus serupa lainnya, lihat Mengapa add-on node auto scaling gagal membuat node?

Batasan penyimpanan

Autoscaler tidak mengetahui batasan penyimpanan spesifik yang mungkin dimiliki oleh suatu Pod. Ini termasuk persyaratan seperti:

  • Perlu berjalan di Zona Ketersediaan tertentu untuk mengakses volume persisten (PV).

  • Memerlukan node yang mendukung tipe disk tertentu (seperti ESSD).

Solusi: Konfigurasi kelompok node khusus

Jika aplikasi Anda memiliki ketergantungan penyimpanan seperti itu, konfigurasikan kelompok node khusus untuknya sebelum mengaktifkan Auto Scaling pada kelompok tersebut.

Dengan menyetel terlebih dahulu Zona Ketersediaan, tipe instans, dan tipe disk dalam konfigurasi kelompok node, Anda memastikan bahwa setiap node yang baru disediakan akan memenuhi persyaratan pemasangan penyimpanan Pod. Hal ini mencegah kegagalan penjadwalan dan error startup Pod yang disebabkan oleh ketidaksesuaian resource.

Sebagai tambahan, pastikan Pod Anda tidak mereferensikan PVC yang terjebak dalam status Terminating. Pod yang tidak dapat dijadwalkan karena PVC-nya sedang terminating akan terus-menerus gagal dijadwalkan. Hal ini dapat menyesatkan cluster-autoscaler sehingga membuat keputusan penskalaan yang salah, seperti mencoba meng-evict Pod atau menskalakan kluster secara tidak perlu.


Perilaku scale-out

Kebijakan penjadwalan apa yang digunakan cluster-autoscaler untuk menentukan apakah Pod yang tidak dapat dijadwalkan dapat dijadwalkan ke kelompok node tempat auto scaling diaktifkan?

Cluster-autoscaler menggunakan kebijakan penjadwalan berikut untuk menentukan hal tersebut:

  • PodFitsResources

  • GeneralPredicates

  • PodToleratesNodeTaints

  • MaxGCEPDVolumeCount

  • NoDiskConflict

  • CheckNodeCondition

  • CheckNodeDiskPressure

  • CheckNodeMemoryPressure

  • CheckNodePIDPressure

  • CheckVolumeBinding

  • MaxAzureDiskVolumeCount

  • MaxEBSVolumeCount

  • ready

  • NoVolumeZoneConflict

Resource apa saja yang dapat cluster-autoscaler simulasikan selama analisis penjadwalan?

Cluster-autoscaler mendukung simulasi dan evaluasi jenis resource berikut:

cpu
memory
sigma/eni
ephemeral-storage
aliyun.com/gpu-mem (hanya GPU bersama)
nvidia.com/gpu

Jika Anda perlu melakukan penskalaan berdasarkan jenis resource lain, lihat Bagaimana cara mengonfigurasi resource kustom untuk kelompok node dengan Auto Scaling yang diaktifkan?

Mengapa add-on node auto scaling gagal membuat node?

Masalah ini dapat disebabkan oleh beberapa skenario umum. Tinjau kemungkinan berikut untuk mendiagnosis masalah:

  • Kelompok node tidak dikonfigurasi dengan Auto Scaling

    Node auto scaling hanya berfungsi untuk kelompok node dengan Auto Scaling yang dikonfigurasi. Pastikan fitur auto scaling tingkat kluster diaktifkan dan mode penskalaan untuk kelompok node diatur ke Auto. Untuk detailnya, lihat Aktifkan node auto scaling.

  • Permintaan resource Pod melebihi kapasitas yang dapat dialokasikan dari tipe instans yang tersedia

    Tipe instans dalam grup penskalaan tidak dapat memenuhi permintaan resource Pod. Spesifikasi yang diiklankan dari instans ECS merepresentasikan kapasitas totalnya. Namun, sebagian resource tersebut selalu dicadangkan oleh ACK untuk memastikan operasi stabil kernel OS, layanan sistem, dan daemon Kubernetes esensial (seperti kubelet, kube-proxy, Terway, dan runtime kontainer).

    Pencadangan ini menciptakan perbedaan kritis antara kapasitas total node dan resource yang dapat dialokasikan—jumlah CPU, memori, dan penyimpanan yang benar-benar tersedia untuk Pod.

    Standar cluster-autoscaler membuat keputusan penskalaannya menggunakan kebijakan pemesanan sumber daya dari Kubernetes versi 1.28 dan sebelumnya.

    Untuk menggunakan kebijakan pemesanan yang lebih akurat dari versi Kubernetes yang lebih baru, kami merekomendasikan beralih ke node instant scaling, yang telah memiliki algoritma baru tersebut. Atau, Anda dapat secara manual menentukan pemesanan resource kustom dalam konfigurasi kelompok node Anda.
  • Batasan spesifik zona Pod mencegah scale-out

    Jika suatu Pod memiliki ketergantungan penjadwalan pada zona ketersediaan tertentu (misalnya karena PVC yang terikat pada volume zonal, atau aturan afinitas node), cluster-autoscaler mungkin tidak dapat menyediakan node baru di zona tersebut, terutama dalam kelompok node multi-zona.

  • Izin yang diperlukan belum diberikan

    Cluster-autoscaler memerlukan izin tertentu untuk mengelola resource kluster. Izin ini bersifat cakupan kluster dan harus diberikan per kluster.

    Pastikan Anda telah menyelesaikan semua langkah otorisasi seperti yang dijelaskan dalam Aktifkan node auto scaling untuk kluster.

  • Autoscaler sementara dijeda karena adanya node tidak sehat

    Autoscaler memiliki mekanisme keamanan (dampening) untuk mencegah kegagalan berulang. Jika autoscaler menyediakan node yang kemudian gagal bergabung ke kluster atau tetap dalam status NotReady dalam periode yang lama, autoscaler akan sementara menghentikan operasi penskalaan lebih lanjut.

    Selesaikan masalah pada node yang tidak sehat tersebut. Penskalaan akan dilanjutkan secara otomatis setelah kondisi tersebut teratasi.

  • Kluster memiliki nol node pekerja

    Cluster-autoscaler sendiri berjalan sebagai Pod di dalam kluster. Jika tidak ada node pekerja, Pod autoscaler tidak dapat berjalan dan karenanya tidak dapat menyediakan node baru.

    Konfigurasikan kelompok node Anda dengan minimal dua node untuk memastikan ketersediaan tinggi bagi add-on inti kluster. Jika kasus penggunaan Anda memerlukan scale-out dari nol node atau scale-down hingga nol node, gunakan fitur node instant scaling.

Jika grup penskalaan dikonfigurasi dengan beberapa tipe instans, bagaimana autoscaler menghitung kapasitas grup tersebut untuk pengambilan keputusan penskalaan?

Untuk grup penskalaan yang dikonfigurasi dengan beberapa tipe instans, cluster-autoscaler memodelkan kapasitas seluruh grup berdasarkan nilai minimum untuk setiap dimensi resource (seperti CPU dan memori) yang ditemukan di seluruh tipe instans yang dikonfigurasi.

Sebagai contoh, pertimbangkan grup penskalaan yang dikonfigurasi dengan dua tipe instans:

  • Tipe instans A: 4 vCPU, 32 GiB memori

  • Tipe instans B: 8 vCPU, 16 GiB memori

Untuk menentukan garis dasar grup ini, autoscaler menghitung nilai minimum untuk setiap resource:

  • CPU minimum: min(4, 8) = 4 vCPU

  • Memori minimum: min(32, 16) = 16 GiB

Akibatnya, autoscaler akan memperlakukan seluruh grup penskalaan ini seolah-olah hanya dapat menyediakan node dengan 4 vCPU dan 16 GiB memori.

Oleh karena itu, jika suatu Pod yang sedang pending meminta lebih dari 4 vCPU atau lebih dari 16 GiB memori, autoscaler tidak akan memicu scale-out untuk grup ini, meskipun salah satu tipe instans (8 vCPU, 16 GiB) secara teoretis dapat memenuhi permintaan CPU tersebut.

Jika Anda menggunakan konfigurasi multi-tipe instans dan juga perlu memperhitungkan pemesanan resource, lihat Mengapa add-on node auto scaling gagal membuat node?

Jika tersedia beberapa kelompok node dengan Auto Scaling yang diaktifkan, bagaimana cluster-autoscaler memilih kelompok mana yang akan diperluas kapasitasnya (scale-out)?

Saat suatu Pod tidak dapat dijadwalkan, cluster-autoscaler menjalankan simulasi untuk menentukan kelompok node mana, jika ada, yang dapat menampung Pod tersebut. Simulasi ini mengevaluasi setiap kelompok node berdasarkan konfigurasinya, termasuk label, taint, dan tipe instans yang tersedia.

Kelompok node dianggap sebagai kandidat untuk scale-out jika simulasi menunjukkan bahwa node baru dari kelompok tersebut memungkinkan Pod tersebut dijadwalkan.

Jika node auto scaling menemukan beberapa kelompok node yang memenuhi kondisi ini, strategi ekspansi default yang digunakan adalah least-waste. Strategi ini memilih kelompok node yang akan memiliki jumlah resource yang tidak terpakai (CPU dan memori) paling sedikit setelah Pod baru dijadwalkan.

Bagaimana cara mengonfigurasi resource kustom untuk kelompok node dengan Auto Scaling yang diaktifkan?

Konfigurasikan tag ECS dengan awalan tertentu untuk kelompok node dengan Auto Scaling yang diaktifkan. Hal ini memungkinkan cluster-autoscaler mengidentifikasi resource kustom yang tersedia di kelompok node tersebut atau nilai pasti dari resource tertentu.

k8s.io/cluster-autoscaler/node-template/resource/{resource_name}:{resource_size}

Contoh:

k8s.io/cluster-autoscaler/node-template/resource/hugepages-1Gi:2Gi

Mengapa saya tidak dapat mengaktifkan Auto Scaling untuk kelompok node?

Mengaktifkan Auto Scaling untuk kelompok node dapat gagal karena salah satu alasan berikut:

  • Ini adalah kelompok node default

    Fitur node auto scaling tidak dapat diaktifkan pada kelompok node default kluster.

  • Kelompok node berisi node yang ditambahkan secara manual

    Auto Scaling tidak dapat diaktifkan pada kelompok node yang sudah berisi node yang ditambahkan secara manual. Untuk mengatasinya, Anda dapat menghapus node yang ditambahkan secara manual terlebih dahulu atau, lebih baik lagi, membuat kelompok node baru yang khusus dengan Auto Scaling yang diaktifkan sejak awal.

  • Kelompok node berisi instans berbasis langganan

    Fitur node auto scaling tidak mendukung node yang ditagih berdasarkan basis langganan. Fitur ini hanya kompatibel dengan instans pay-as-you-go.


Perilaku scale-in

Mengapa cluster-autoscaler gagal melakukan scale-in pada suatu node?

Cluster-autoscaler mungkin dicegah melakukan scale-in pada suatu node karena beberapa alasan. Periksa apakah salah satu kasus berikut berlaku:

  • Pod pada node melebihi ambang batas utilisasi

    Node tidak akan dipertimbangkan untuk scale-in jika total permintaan resource dari Pod yang berjalan di atasnya lebih tinggi daripada ambang batas scale-in yang dikonfigurasi.

  • Node menjalankan Pod kube-system

    Secara default, cluster-autoscaler tidak akan menghapus node yang menjalankan Pod dari namespace kube-system.

  • Pod memiliki batasan penjadwalan yang ketat

    Node tidak dapat di-scale-in jika menjalankan Pod dengan batasan penjadwalan ketat (seperti nodeSelector atau nodeAffinity yang kuat) yang mencegahnya dijadwalkan ulang ke node lain yang tersedia di kluster.

  • Pod dilindungi oleh PodDisruptionBudget (PDB)

    Node tidak dapat di-scale-down jika menjalankan Pod yang merupakan bagian dari beban kerja yang dilindungi oleh PDB, dan meng-evict Pod tersebut akan melanggar pengaturan minAvailable atau maxUnavailable PDB tersebut.

Lihat cluster-autoscaler untuk pertanyaan dan jawaban yang lebih sering diajukan.

Bagaimana cara mengaktifkan atau menonaktifkan eviction untuk DaemonSet tertentu?

Cluster-autoscaler menentukan apakah akan meng-evict Pod DaemonSet berdasarkan konfigurasi Evict DaemonSet Pods. Konfigurasi ini berlaku untuk seluruh kluster dan berlaku untuk semua Pod DaemonSet di kluster. Untuk informasi lebih lanjut, lihat Langkah 1: Aktifkan node auto scaling untuk kluster.

Namun, Anda dapat mengganti pengaturan global ini untuk setiap DaemonSet dengan menambahkan anotasi ke Pod-nya.

  • Untuk secara eksplisit mengaktifkan eviction untuk Pod DaemonSet tertentu, tambahkan anotasi berikut:

    "cluster-autoscaler.kubernetes.io/enable-ds-eviction":"true"

  • Untuk secara eksplisit menonaktifkan eviction untuk Pod DaemonSet tertentu, tambahkan anotasi berikut:

    "cluster-autoscaler.kubernetes.io/enable-ds-eviction":"false"

Catatan
  • Jika Evict DaemonSet Pods dinonaktifkan, anotasi enable-ds-eviction: "true" hanya akan berlaku untuk Pod DaemonSet pada node yang tidak kosong. Untuk mengaktifkan eviction Pod DaemonSet dari node kosong, Anda harus terlebih dahulu mengaktifkan pengaturan eviction DaemonSet global.

  • Anotasi ini harus diterapkan pada Pod DaemonSet itu sendiri (biasanya dengan menambahkannya ke templat Pod dalam manifes DaemonSet), bukan pada objek DaemonSet itu sendiri.

  • Anotasi ini tidak berpengaruh pada Pod yang bukan bagian dari DaemonSet.

  • Secara default, cluster-autoscaler meng-evict Pod DaemonSet secara non-blocking. Artinya, cluster-autoscaler akan melanjutkan ke langkah berikutnya tanpa menunggu proses eviction Pod DaemonSet selesai. Jika Anda memerlukan cluster-autoscaler untuk menunggu hingga Pod DaemonSet tertentu sepenuhnya di-evict sebelum melanjutkan scale-in, tambahkan anotasi "cluster-autoscaler.kubernetes.io/wait-until-evicted": "true" ke Pod tersebut selain anotasi enable-ds-eviction.

Jenis Pod apa saja yang dapat mencegah cluster-autoscaler menghapus suatu node?

Cluster-autoscaler mungkin terhalang menghapus suatu node jika node tersebut berisi Pod yang tidak dibuat oleh controller Kubernetes native (seperti Deployment, ReplicaSet, Job, atau StatefulSet), atau jika Pod pada node tersebut tidak dapat dihentikan atau dimigrasikan secara aman.

Untuk daftar lengkap semua kondisi yang dapat menghalangi scale-in node, lihat Jenis Pod apa saja yang dapat mencegah CA menghapus suatu node?


Dukungan ekstensi

Apakah cluster-autoscaler mendukung CustomResourceDefinitions (CRDs)?

Tidak, cluster-autoscaler saat ini hanya mendukung objek Kubernetes standar dan tidak mendukung CRDs Kubernetes.


Kontrol perilaku penskalaan berbasis Pod

Bagaimana cara mengonfigurasi penundaan scale-out untuk Pod tertentu?

Anda dapat mengontrol perilaku ini dengan menambahkan anotasi cluster-autoscaler.kubernetes.io/pod-scale-up-delay ke Pod tersebut.

Cluster-autoscaler hanya akan mempertimbangkan Pod tersebut untuk scale-out jika Pod tersebut tetap tidak dapat dijadwalkan setelah periode penundaan berlalu. Hal ini memberikan waktu tambahan bagi penjadwal Kubernetes native untuk mencoba menempatkan Pod pada node yang sudah ada sebelum memicu scale-up.

Contoh anotasi: "cluster-autoscaler.kubernetes.io/pod-scale-up-delay": "600s".

Bagaimana cara menggunakan anotasi Pod untuk mengontrol perilaku scale-in cluster-autoscaler?

Gunakan anotasi Pod cluster-autoscaler.kubernetes.io/safe-to-evict untuk secara eksplisit memberi tahu cluster-autoscaler apakah Pod tertentu dapat di-evict dengan aman untuk memungkinkan scale-in node.

  • Untuk mencegah node di-scale-in, tambahkan anotasi "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" ke Pod yang berjalan pada node tersebut. Kehadiran Pod ini akan menghalangi node tersebut dihentikan oleh autoscaler.

  • Untuk mengizinkan node di-scale-in, tambahkan anotasi "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" ke Pod tersebut. Hal ini secara eksplisit menandai Pod tersebut aman untuk di-evict selama operasi scale-in.


Kontrol perilaku penskalaan berbasis node

Bagaimana cara mencegah cluster-autoscaler melakukan scale-in pada node tertentu?

Untuk mencegah node target di-scale-in oleh cluster-autoscaler, tambahkan anotasi "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true" ke node tersebut.

Untuk menambahkan anotasi ini, jalankan perintah kubectl berikut, ganti <nodename> dengan nama node target Anda:

kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

Add-on cluster-autoscaler terkait

Bagaimana cara memutakhirkan cluster-autoscaler ke versi terbaru?

Untuk kluster dengan Auto Scaling yang diaktifkan, mutakhirkan cluster-autoscaler sebagai berikut:

  1. Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.

  2. Pada halaman Clusters, temukan kluster yang ingin dikelola dan klik namanya. Di panel navigasi kiri, pilih Nodes > Node Pools.

  3. Klik Edit di sebelah kanan Node Scaling. Di panel yang muncul, klik OK untuk memutakhirkan add-on ke versi terbaru.

Aksi apa saja yang memicu pembaruan otomatis cluster-autoscaler?

Untuk memastikan konfigurasi cluster-autoscaler selalu mutakhir dan versinya tetap kompatibel dengan kluster Anda, aksi berikut akan memicu pembaruan atau rekonsiliasi otomatis:

  • Memodifikasi konfigurasi auto scaling.

  • Membuat, menghapus, atau memperbarui kelompok node tempat Auto Scaling diaktifkan.

  • Berhasil memutakhirkan versi Kubernetes kluster.

Mengapa node scaling tidak berfungsi pada kluster ACK yang dikelola saya meskipun otorisasi peran yang diperlukan telah selesai?

Kemungkinan penyebab

Masalah ini dapat terjadi jika token yang diperlukan (addon.aliyuncsmanagedautoscalerrole.token) tidak ada dalam Secret di namespace kube-system. Secara default, ACK menggunakan Worker Role kluster untuk mengaktifkan kemampuan autoscaling, dan token ini sangat penting untuk mengotentikasi operasi tersebut.

Solusi

Solusinya adalah menerapkan ulang kebijakan yang diperlukan ke Worker Role kluster dengan menggunakan wizard otorisasi di Konsol ACK.

  1. Pada halaman Clusters, temukan kluster yang ingin dikelola dan klik namanya. Di panel navigasi kiri, pilih Nodes > Node Pools.

  2. Pada halaman Node Pools, klik Enable di sebelah kanan Node Scaling.

  3. Ikuti petunjuk di layar untuk mengotorisasi KubernetesWorkerRole dan melampirkan kebijakan sistem AliyunCSManagedAutoScalerRolePolicy.

    image

  4. Restart secara manual Deployment cluster-autoscaler (node auto scaling) atau Deployment ack-goatscaler (node instant scaling) di namespace kube-system agar izin tersebut langsung berlaku.