Container Service for Kubernetes:FAQ penskalaan otomatis node

Resource node yang tersedia mungkin tidak sesuai dengan spesifikasi tipe instans

Resource yang tersedia pada node yang baru disediakan selalu sedikit lebih kecil daripada spesifikasi yang diiklankan oleh tipe instans tersebut. OS dasar dan daemon sistem pada instans Elastic Compute Service (ECS) mengonsumsi sebagian CPU, memori, dan penyimpanan sebelum pod mana pun dijadwalkan. Untuk detailnya, lihat Mengapa ukuran memori berbeda dari spesifikasi tipe instans setelah saya membeli instans?

Karena overhead ini, perhatikan hal-hal berikut saat mengonfigurasi permintaan resource pod:

• Jaga total permintaan di bawah kapasitas penuh instans. Sebagai panduan umum, total permintaan resource pod sebaiknya tidak melebihi 70% dari kapasitas node.

• Pertimbangkan pod statis yang tidak dikelola sebagai DaemonSet. cluster-autoscaler hanya mempertimbangkan permintaan resource pod Kubernetes (termasuk pod pending dan pod DaemonSet) saat mengevaluasi kapasitas node. Cadangkan resource secara manual untuk pod statis apa pun di luar cakupan ini.

• Uji pod yang membutuhkan banyak resource sebelum menerapkan dalam skala besar. Jika sebuah pod meminta lebih dari 70% resource node, uji dan pastikan terlebih dahulu bahwa pod tersebut dapat dijadwalkan ke node dengan tipe instans yang sama.

Dukungan kebijakan penjadwalan terbatas

cluster-autoscaler hanya mendukung seperangkat kebijakan penjadwalan terbatas saat menentukan apakah pod yang tidak dapat dijadwalkan cocok dengan kelompok node yang memiliki Auto Scaling diaktifkan. Untuk detailnya, lihat Kebijakan penjadwalan apa saja yang digunakan cluster-autoscaler?

Hanya kebijakan tipe resource yang didukung dalam ResourcePolicy

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

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

Tidak didukung penskalaan keluar tipe instans tertentu dalam kelompok node multi-tipe

Jika kelompok node dikonfigurasi dengan beberapa tipe instans, Anda tidak dapat mengarahkan cluster-autoscaler untuk menyediakan tipe instans tertentu selama skala keluar. Autoscaler memodelkan kapasitas seluruh kelompok node berdasarkan tipe instans terkecil—yaitu yang memiliki resource paling sedikit di antara semua tipe yang dikonfigurasi. Untuk detailnya, lihat Bagaimana autoscaler menghitung kapasitas untuk kelompok node dengan beberapa tipe instans?

Pod dengan batasan zona spesifik mungkin tidak memicu skala keluar dalam kelompok node multi-zona

Jika kelompok node mencakup beberapa zona ketersediaan, pod dengan ketergantungan zona mungkin tidak memicu skala keluar. Hal ini berlaku untuk pod yang memerlukan zona tertentu karena:

• klaim volume persisten (PVC) yang terikat ke volume di zona tersebut.

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

Dalam kasus ini, cluster-autoscaler mungkin gagal menyediakan node di zona yang diperlukan. Untuk skenario lainnya, lihat Mengapa kelompok node saya gagal menyediakan node baru?

Batasan penyimpanan tidak terlihat oleh autoscaler

Autoscaler tidak mengetahui batasan penyimpanan tingkat pod, seperti:

• Harus berjalan di zona ketersediaan tertentu untuk mengakses volume persisten (PV).

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

Solusi: Konfigurasikan kelompok node khusus untuk aplikasi dengan ketergantungan penyimpanan sebelum mengaktifkan Auto Scaling. Tetapkan zona ketersediaan, tipe instans, dan tipe disk dalam konfigurasi kelompok node untuk memastikan node yang baru disediakan memenuhi persyaratan penyimpanan pod.

Pastikan juga pod Anda tidak mereferensikan PVC dalam status Terminating. Pod yang tidak dapat dijadwalkan karena PVC-nya sedang dalam proses terminasi akan terus gagal, yang dapat menyebabkan cluster-autoscaler membuat keputusan skala keluar atau skala masuk yang salah (misalnya, mengevakuasi pod tersebut).

Kebijakan penjadwalan apa saja yang digunakan cluster-autoscaler untuk menentukan apakah pod yang tidak dapat dijadwalkan dapat dijadwalkan ke kelompok node dengan Auto Scaling diaktifkan?

cluster-autoscaler mengevaluasi kebijakan penjadwalan berikut:

• PodFitsResources

• GeneralPredicates

• PodToleratesNodeTaints

• MaxGCEPDVolumeCount

• NoDiskConflict

• CheckNodeCondition

• CheckNodeDiskPressure

• CheckNodeMemoryPressure

• CheckNodePIDPressure

• CheckVolumeBinding

• MaxAzureDiskVolumeCount

• MaxEBSVolumeCount

• ready

• NoVolumeZoneConflict

Jenis resource apa saja yang dapat disimulasikan cluster-autoscaler selama analisis penjadwalan?

cluster-autoscaler dapat mensimulasikan dan mengevaluasi jenis resource berikut:

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

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

Mengapa kelompok node saya gagal menyediakan node baru?

Periksa penyebab umum berikut:

Auto Scaling tidak diaktifkan pada kelompok node

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

Permintaan resource pod melebihi kapasitas yang dapat dialokasikan

Spesifikasi yang diiklankan oleh instans ECS mewakili kapasitas total, bukan kapasitas yang dapat dialokasikan. ACK mencadangkan sebagian CPU, memori, dan penyimpanan untuk kernel OS, layanan sistem, dan daemon Kubernetes (kubelet, kube-proxy, Terway, dan runtime kontainer), yang menciptakan kesenjangan antara kapasitas total node dan resource yang dapat dialokasikan.

Saat membuat keputusan skala keluar, cluster-autoscaler menggunakan kebijakan pemesanan sumber daya dari Kubernetes 1.28 dan versi sebelumnya, terlepas dari versi kluster ACK.

Untuk menggunakan kebijakan pemesanan yang lebih akurat, beralihlah ke penskalaan instan node, yang menggunakan algoritma terbaru. Atau, definisikan pemesanan resource kustom dalam konfigurasi kelompok node.

Untuk detail tentang konsumsi resource:

• Resource sistem: Mengapa instans yang dibeli memiliki ukuran memori berbeda dari tipe instans?

• Node default menginstal add-on sistem; jaga permintaan resource pod di bawah kapasitas yang diiklankan oleh tipe instans. Kebijakan pemesanan sumber daya

Batasan zona pod mencegah skala keluar

Jika pod memiliki ketergantungan penjadwalan pada zona ketersediaan tertentu—karena PVC yang terikat ke volume zonal atau aturan afinitas node—cluster-autoscaler mungkin tidak dapat menyediakan node di zona tersebut, terutama dalam kelompok node multi-zona.

Izin yang diperlukan tidak ada

cluster-autoscaler memerlukan izin cakupan kluster yang diberikan per kluster. Lengkapi semua langkah otorisasi yang dijelaskan dalam Aktifkan penskalaan otomatis node untuk kluster.

Perilaku redaman untuk node tidak sehat

Autoscaler memasuki keadaan redaman ketika salah satu kondisi berikut terjadi dalam kelompok node penskalaan otomatis:

• Node gagal bergabung ke kluster dalam waktu yang diharapkan.

• Node tetap dalam status NotReady melebihi durasi yang diizinkan.

Selama dalam keadaan redaman ini, semua operasi penskalaan ditangguhkan hingga node yang tidak sehat diselesaikan, memastikan akurasi keputusan penskalaan berikutnya.

Tidak ada node dalam kluster

cluster-autoscaler tidak dapat berjalan ketika kluster tidak memiliki node. Konfigurasikan setiap kelompok node dengan minimal dua node untuk memastikan operasi normal add-on dan komponen kluster.

Untuk penskalaan dari nol atau hingga nol node, gunakan penskalaan instan node.

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

Untuk grup penskalaan dengan beberapa tipe instans, cluster-autoscaler memodelkan kapasitas grup menggunakan nilai minimum untuk setiap dimensi resource di antara semua tipe yang dikonfigurasi.

Sebagai contoh, dengan dua tipe instans:

• Tipe instans A: 4 vCPU, 32 GiB memori

• Tipe instans B: 8 vCPU, 16 GiB memori

Autoscaler menghitung:

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

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

Seluruh grup penskalaan dianggap hanya dapat menyediakan node dengan 4 vCPU dan 16 GiB. Pod pending yang meminta lebih dari 4 vCPU atau lebih dari 16 GiB tidak akan memicu skala keluar untuk grup ini, meskipun tipe instans B dapat memenuhi permintaan CPU.

Jika tersedia beberapa kelompok node dengan Auto Scaling diaktifkan, bagaimana cluster-autoscaler memilih kelompok mana yang akan diskala keluar?

Saat pod tidak dapat dijadwalkan, cluster-autoscaler mensimulasikan kelompok node mana yang dapat menampungnya. Simulasi ini mengevaluasi label, taint, dan tipe instans yang tersedia di setiap kelompok node.

Jika beberapa kelompok node memenuhi syarat, autoscaler menggunakan strategi least-waste secara default: memilih kelompok node yang menyisakan resource CPU dan memori tidak terpakai paling sedikit setelah pod dijadwalkan.

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

Tambahkan tag ECS dengan awalan berikut ke kelompok node agar autoscaler dapat mengenali resource kustom yang tersedia dalam kelompok tersebut atau nilai tepat untuk 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?

Auto Scaling tidak dapat diaktifkan dalam kasus-kasus berikut:

• Ini adalah kelompok node default. Fitur penskalaan otomatis node tidak mendukung kelompok node default kluster.

• Kelompok node berisi node yang ditambahkan secara manual. Hapus terlebih dahulu node yang ditambahkan secara manual, atau buat kelompok node khusus baru dengan Auto Scaling yang diaktifkan sejak awal.

• Kelompok node menggunakan instans berbasis langganan. Penskalaan otomatis node hanya berfungsi dengan instans pay-as-you-go.

Mengapa cluster-autoscaler tidak melakukan skala masuk pada node?

cluster-autoscaler melewatkan node selama skala masuk jika salah satu kondisi berikut berlaku:

• Pemanfaatan pod melebihi ambang batas. Total permintaan resource pod pada node berada di atas ambang batas skala masuk yang dikonfigurasi.

• Node menjalankan pod dari namespace kube-system. Secara default, cluster-autoscaler tidak menghapus node yang menjalankan pod dari namespace kube-system.

• Pod memiliki batasan penjadwalan ketat. Jika pod menggunakan nodeSelector atau nodeAffinity yang mencegahnya dijadwalkan ulang ke node lain, node tersebut tidak dapat diskala masuk.

• Pod dilindungi oleh PodDisruptionBudget (PDB). Jika mengevakuasi pod akan melanggar pengaturan minAvailable PDB, node tersebut dipertahankan. Untuk detailnya, lihat PodDisruptionBudget.

• Selama periode penundaan skala turun, jika pod yang baru dijadwalkan (seperti pod sementara yang dibuat oleh Job) membuat pemanfaatan resource tetap di atas ambang batas, node tidak akan diskala masuk. Pod yang tidak dibuat oleh Deployment, ReplicaSet, Job, atau StatefulSet secara default menghalangi penghapusan node.

Untuk daftar lengkap kondisi yang dapat menghalangi skala masuk node, lihat FAQ cluster-autoscaler.

Bagaimana cara mengaktifkan atau menonaktifkan eviksi untuk DaemonSet tertentu?

Pengaturan Evict DaemonSet Pods dalam konfigurasi kluster mengontrol eviksi DaemonSet secara global. Untuk informasi lebih lanjut, lihat Langkah 1: Aktifkan penskalaan otomatis node untuk kluster.

Timpa pengaturan ini per DaemonSet dengan menambahkan anotasi ke pod DaemonSet (dalam templat pod, bukan pada objek DaemonSet itu sendiri):

• Aktifkan eviksi untuk pod DaemonSet tertentu:

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

• Nonaktifkan eviksi untuk pod DaemonSet tertentu:

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

Jika pengaturan global Evict DaemonSet Pods dinonaktifkan, enable-ds-eviction: "true" hanya berlaku untuk pod DaemonSet pada node yang tidak kosong. Untuk mengevakuasi pod DaemonSet dari node kosong, aktifkan terlebih dahulu pengaturan global.

Secara default, cluster-autoscaler mengevakuasi pod DaemonSet secara non-blocking dan melanjutkan tanpa menunggu eviksi selesai. Untuk membuat autoscaler menunggu pod DaemonSet tertentu sepenuhnya dievakuasi sebelum melanjutkan, tambahkan anotasi berikut bersamaan dengan enable-ds-eviction:

cluster-autoscaler.kubernetes.io/wait-until-evicted: "true"

Anotasi ini tidak berpengaruh pada pod yang bukan bagian dari DaemonSet.

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

cluster-autoscaler mungkin menghalangi penghapusan node dalam kasus-kasus berikut:

• Pod tidak dibuat oleh pengontrol Kubernetes native (misalnya, tidak dibuat oleh Deployment, ReplicaSet, Job, atau StatefulSet).

• Pod pada node tidak dapat dihentikan atau dimigrasikan dengan aman.

Untuk daftar lengkap kondisi yang menghalangi skala masuk node, lihat Jenis pod apa saja yang dapat mencegah CA menghapus node?

Apakah cluster-autoscaler mendukung CustomResourceDefinitions (CRDs)?

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

Bagaimana cara menunda skala keluar untuk pod tertentu?

Tambahkan anotasi cluster-autoscaler.kubernetes.io/pod-scale-up-delay ke pod tersebut. cluster-autoscaler tidak akan mempertimbangkan pod tersebut untuk skala keluar hingga pod tetap tidak dapat dijadwalkan lebih lama dari penundaan yang ditentukan. Hal ini memberi penjadwal Kubernetes waktu tambahan untuk menempatkan pod pada node yang sudah ada sebelum memicu skala keluar.

Contoh:

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

Bagaimana cara menggunakan anotasi pod untuk mengontrol perilaku skala masuk?

Gunakan anotasi cluster-autoscaler.kubernetes.io/safe-to-evict untuk secara eksplisit menandai pod sebagai aman atau tidak aman untuk dievakuasi selama skala masuk:

• Cegah skala masuk untuk node: Tambahkan "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" ke pod yang berjalan pada node tersebut. Autoscaler tidak akan menghentikan node selama pod ini ada.

• Izinkan skala masuk untuk node: Tambahkan "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" untuk secara eksplisit menandai pod tersebut sebagai aman untuk dievakuasi.

Bagaimana cara mencegah cluster-autoscaler melakukan skala masuk pada node tertentu?

Tambahkan anotasi cluster-autoscaler.kubernetes.io/scale-down-disabled: "true" ke node tersebut. Ganti <nodename> dengan nama node target:

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

Bagaimana cara meningkatkan cluster-autoscaler ke versi terbaru?

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

2. Di halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Nodes > Node Pools.

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

Aksi apa saja yang memicu pembaruan otomatis cluster-autoscaler?

cluster-autoscaler diperbarui secara otomatis ketika:

• Konfigurasi penskalaan otomatis diubah.

• Kelompok node dengan Auto Scaling diaktifkan dibuat, dihapus, atau diperbarui.

• Versi Kubernetes kluster berhasil ditingkatkan.

Penskalaan node tidak berfungsi di kluster ACK yang dikelola saya meskipun otorisasi role telah selesai

Hal ini biasanya berarti token addon.aliyuncsmanagedautoscalerrole.token tidak ada dalam Secret di namespace kube-system. ACK menggunakan Worker Role kluster untuk mengaktifkan penskalaan otomatis, dan token ini diperlukan untuk otentikasi.

Terapkan ulang kebijakan yang diperlukan ke Worker Role menggunakan konsol ACK:

1. Di halaman Clusters ACK, klik nama kluster Anda. Di panel navigasi kiri, klik Nodes > Node Pools.

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

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

   Di kotak dialog Node Scaling Configuration, setelah pemeriksaan awal berhasil, klik tautan nama role di area prompt untuk membuka Resource Access Management (RAM) dan menyelesaikan otorisasi.

4. Restart secara manual Deployment cluster-autoscaler (penskalaan otomatis node) atau Deployment ack-goatscaler (penskalaan instan node) di namespace kube-system agar izin berlaku segera.