Pilih preferensi cookie Anda

Kami menggunakan cookie penting serta alat serupa yang diperlukan untuk menyediakan situs dan layanan. Kami menggunakan cookie performa untuk mengumpulkan statistik anonim sehingga kami dapat memahami cara pelanggan menggunakan situs dan melakukan perbaikan. Cookie penting tidak dapat dinonaktifkan, tetapi Anda dapat mengklik “Kustom” atau “Tolak” untuk menolak cookie performa.

Jika Anda setuju, AWS dan pihak ketiga yang disetujui juga akan menggunakan cookie untuk menyediakan fitur situs yang berguna, mengingat preferensi Anda, dan menampilkan konten yang relevan, termasuk iklan yang relevan. Untuk menerima atau menolak semua cookie yang tidak penting, klik “Terima” atau “Tolak”. Untuk membuat pilihan yang lebih detail, klik “Kustomisasi”.

Autoscaler klaster

Mode fokus
Autoscaler klaster - Amazon EKS

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Gambaran Umum

Kubernetes Cluster Autoscaler adalah solusi Cluster Autoscaling populer yang dikelola oleh SIG Autoscaling. Ini bertanggung jawab untuk memastikan bahwa klaster Anda memiliki cukup node untuk menjadwalkan pod Anda tanpa membuang sumber daya. Ini mengawasi pod yang gagal menjadwalkan dan untuk node yang kurang dimanfaatkan. Kemudian mensimulasikan penambahan atau penghapusan node sebelum menerapkan perubahan ke cluster Anda. Implementasi AWS Cloud Provider dalam Cluster Autoscaler mengontrol .DesiredReplicas bidang Grup Auto Scaling EC2 Anda.

arsitektur

Panduan ini akan memberikan model mental untuk mengonfigurasi Cluster Autoscaler dan memilih rangkaian pengorbanan terbaik untuk memenuhi persyaratan organisasi Anda. Meskipun tidak ada satu konfigurasi terbaik, ada serangkaian opsi konfigurasi yang memungkinkan Anda menukar kinerja, skalabilitas, biaya, dan ketersediaan. Selain itu, panduan ini akan memberikan tips dan praktik terbaik untuk mengoptimalkan konfigurasi AWS Anda.

Glosarium

Terminologi berikut akan sering digunakan di seluruh dokumen ini. Istilah-istilah ini dapat memiliki arti yang luas, tetapi terbatas pada definisi di bawah ini untuk keperluan dokumen ini.

Skalabilitas mengacu pada seberapa baik kinerja Cluster Autoscaler saat Cluster Kubernetes Anda bertambah dalam jumlah pod dan node. Saat batas skalabilitas tercapai, kinerja dan fungsionalitas Cluster Autoscaler menurun. Karena Cluster Autoscaler melebihi batas skalabilitasnya, ia mungkin tidak lagi menambah atau menghapus node di cluster Anda.

Kinerja mengacu pada seberapa cepat Cluster Autoscaler mampu membuat dan melaksanakan keputusan penskalaan. Cluster Autoscaler yang berkinerja sempurna akan langsung membuat keputusan dan memicu tindakan penskalaan sebagai respons terhadap rangsangan, seperti pod menjadi tidak dapat dijadwalkan.

Ketersediaan berarti pod dapat dijadwalkan dengan cepat dan tanpa gangguan. Ini termasuk ketika Pod yang baru dibuat perlu dijadwalkan dan ketika node yang diperkecil menghentikan semua Pod yang tersisa yang dijadwalkan untuk itu.

Biaya ditentukan oleh keputusan di balik skala dan skala dalam peristiwa. Sumber daya terbuang jika node yang ada kurang dimanfaatkan atau node baru ditambahkan yang terlalu besar untuk pod yang masuk. Bergantung pada kasus penggunaan, mungkin ada biaya yang terkait dengan penghentian pod sebelum waktunya karena keputusan penurunan skala yang agresif.

Node Groups adalah konsep Kubernetes abstrak untuk sekelompok node dalam sebuah cluster. Ini bukan sumber daya Kubernetes yang sebenarnya, tetapi ada sebagai abstraksi di Cluster Autoscaler, Cluster API, dan komponen lainnya. Node dalam Grup Node berbagi properti seperti label dan taints, tetapi dapat terdiri dari beberapa Availability Zone atau Instance Type.

EC2 Grup Auto Scaling dapat digunakan sebagai implementasi Grup Node pada. EC2 EC2 Grup Auto Scaling dikonfigurasi untuk meluncurkan instans yang secara otomatis bergabung dengan Kluster Kubernetes mereka dan menerapkan label dan taint ke sumber daya Node yang sesuai di API Kubernetes.

EC2 Grup Node Terkelola adalah implementasi lain dari Grup Node padaEC2. Mereka mengabstraksikan kompleksitas secara manual mengonfigurasi Grup EC2 Penskalaan Otomatis dan menyediakan fitur manajemen tambahan seperti peningkatan versi node dan penghentian node yang anggun.

Mengoperasikan Cluster Autoscaler

Cluster Autoscaler biasanya diinstal sebagai Deployment di klaster Anda. Ini menggunakan pemilihan pemimpin untuk memastikan ketersediaan tinggi, tetapi pekerjaan dilakukan oleh satu replika pada satu waktu. Ini tidak dapat diskalakan secara horizontal. Untuk pengaturan dasar, default itu harus bekerja di luar kotak menggunakan instruksi instalasi yang disediakan, tetapi ada beberapa hal yang perlu diingat.

Pastikan bahwa:

  • Versi Cluster Autoscaler cocok dengan Versi Cluster. Kompatibilitas lintas versi tidak diuji atau didukung.

  • Penemuan Otomatis diaktifkan, kecuali jika Anda memiliki kasus penggunaan lanjutan khusus yang mencegah penggunaan mode ini.

Gunakan akses paling tidak istimewa ke peran IAM

Saat Auto Discovery digunakan, kami sangat menyarankan agar Anda menggunakan akses hak istimewa paling sedikit dengan membatasi Tindakan autoscaling:SetDesiredCapacity dan autoscaling:TerminateInstanceInAutoScalingGroup grup Auto Scaling yang tercakup pada klaster saat ini.

Ini akan mencegah Cluster Autoscaler yang berjalan di satu cluster memodifikasi nodegroup di cluster yang berbeda bahkan jika --node-group-auto-discovery argumen tidak dicakup ke nodegroup cluster menggunakan tag (misalnya). k8s.io/cluster-autoscaler/<cluster-name>

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true", "aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned" } } }, { "Effect": "Allow", "Action": [ "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeScalingActivities", "autoscaling:DescribeTags", "ec2:DescribeImages", "ec2:DescribeInstanceTypes", "ec2:DescribeLaunchTemplateVersions", "ec2:GetInstanceTypesFromInstanceRequirements", "eks:DescribeNodegroup" ], "Resource": "*" } ] }

Mengonfigurasi Grup Node Anda

Penskalaan otomatis yang efektif dimulai dengan mengonfigurasi satu set Grup Node dengan benar untuk klaster Anda. Memilih kumpulan Grup Node yang tepat adalah kunci untuk memaksimalkan ketersediaan dan mengurangi biaya di seluruh beban kerja Anda. AWS mengimplementasikan Grup Node menggunakan Grup EC2 Auto Scaling, yang fleksibel untuk sejumlah besar kasus penggunaan. Namun, Cluster Autoscaler membuat beberapa asumsi tentang Grup Node Anda. Menjaga konfigurasi Grup EC2 Auto Scaling Anda konsisten dengan asumsi ini akan meminimalkan perilaku yang tidak diinginkan.

Pastikan bahwa:

  • Setiap Node dalam Grup Node memiliki properti penjadwalan yang identik, seperti Label, Taints, dan Resources.

    • Untuk MixedInstancePolicies, Jenis Instance harus memiliki bentuk yang sama untuk CPU, Memori, dan GPU

    • Jenis Instance pertama yang ditentukan dalam kebijakan akan digunakan untuk mensimulasikan penjadwalan.

    • Jika kebijakan Anda memiliki Jenis Instance tambahan dengan lebih banyak sumber daya, sumber daya mungkin terbuang setelah skala habis.

    • Jika kebijakan Anda memiliki Tipe Instance tambahan dengan sumber daya yang lebih sedikit, pod mungkin gagal menjadwalkan instans.

  • Grup Node dengan banyak node lebih disukai daripada banyak Grup Node dengan lebih sedikit node. Ini akan memiliki dampak terbesar pada skalabilitas.

  • Jika memungkinkan, pilih EC2 fitur ketika kedua sistem memberikan dukungan (misalnya Wilayah, MixedInstancePolicy)

Catatan: Sebaiknya gunakan Grup Node Terkelola EKS. Grup Node Terkelola hadir dengan fitur manajemen yang kuat, termasuk fitur untuk Cluster Autoscaler seperti penemuan EC2 Auto Scaling Group otomatis dan penghentian node yang anggun.

Mengoptimalkan Kinerja dan Skalabilitas

Memahami kompleksitas runtime algoritma autoscaling akan membantu Anda menyetel Cluster Autoscaler untuk terus beroperasi dengan lancar di cluster besar dengan lebih dari 1.000 node.

Tombol-tombol utama untuk menyetel skalabilitas Cluster Autoscaler adalah sumber daya yang disediakan untuk proses, interval pemindaian algoritma, dan jumlah Grup Node di cluster. Ada faktor lain yang terlibat dalam kompleksitas runtime sebenarnya dari algoritma ini, seperti menjadwalkan kompleksitas plugin dan jumlah pod. Ini dianggap sebagai parameter yang tidak dapat dikonfigurasi karena alami untuk beban kerja cluster dan tidak dapat dengan mudah disetel.

Cluster Autoscaler memuat seluruh status klaster ke dalam memori, termasuk Pod, Nodes, dan Node Groups. Pada setiap interval pemindaian, algoritme mengidentifikasi pod yang tidak dapat dijadwalkan dan mensimulasikan penjadwalan untuk setiap Grup Node. Menyetel faktor-faktor ini datang dengan pengorbanan yang berbeda yang harus dipertimbangkan dengan cermat untuk kasus penggunaan Anda.

Penskalaan Otomatis Secara Vertikal Cluster Autoscaler

Cara termudah untuk menskalakan Cluster Autoscaler ke cluster yang lebih besar adalah dengan meningkatkan permintaan sumber daya untuk penerapannya. Baik memori dan CPU harus ditingkatkan untuk cluster besar, meskipun ini bervariasi secara signifikan dengan ukuran cluster. Algoritma penskalaan otomatis menyimpan semua pod dan node dalam memori, yang dapat menghasilkan footprint memori yang lebih besar dari satu gigabyte dalam beberapa kasus. Meningkatkan sumber daya biasanya dilakukan secara manual. Jika Anda menemukan bahwa penyetelan sumber daya konstan menciptakan beban operasional, pertimbangkan untuk menggunakan Addon Resizer atau Vertical Pod Autoscaler.

Mengurangi jumlah Grup Node

Meminimalkan jumlah grup node adalah salah satu cara untuk memastikan bahwa Cluster Autoscaler akan terus berkinerja baik pada cluster besar. Ini mungkin menantang bagi beberapa organisasi yang menyusun grup node mereka per tim atau per aplikasi. Meskipun ini sepenuhnya didukung oleh Kubernetes API, ini dianggap sebagai anti-pola Cluster Autoscaler dengan dampak untuk skalabilitas. Ada banyak alasan untuk menggunakan beberapa grup node (misalnya Spot atau GPUs), tetapi dalam banyak kasus ada desain alternatif yang mencapai efek yang sama saat menggunakan sejumlah kecil grup.

Pastikan bahwa:

  • Isolasi Pod dilakukan dengan menggunakan Namespaces daripada Node Groups.

    • Ini mungkin tidak mungkin dilakukan di cluster multi-tenant dengan kepercayaan rendah.

    • Pod ResourceRequests dan ResourceLimits diatur dengan benar untuk menghindari pertentangan sumber daya.

    • Jenis instans yang lebih besar akan menghasilkan pengemasan bin yang lebih optimal dan pengurangan overhead pod sistem.

  • NodeTaints atau NodeSelectors digunakan untuk menjadwalkan pod sebagai pengecualian, bukan sebagai aturan.

  • Sumber daya regional didefinisikan sebagai Grup EC2 Auto Scaling tunggal dengan beberapa Availability Zone.

Mengurangi Interval Pemindaian

Interval pemindaian yang rendah (misalnya 10 detik) akan memastikan bahwa Cluster Autoscaler merespons secepat mungkin ketika pod menjadi tidak terjadwal. Namun, setiap pemindaian menghasilkan banyak panggilan API ke Kubernetes API dan EC2 Auto Scaling Group atau EKS Managed Node Group. APIs Panggilan API ini dapat mengakibatkan pembatasan tarif atau bahkan tidak tersedianya layanan untuk Kubernetes Control Plane Anda.

Interval pemindaian default adalah 10 detik, tetapi di AWS, peluncuran node membutuhkan waktu lebih lama untuk meluncurkan instance baru. Ini berarti bahwa ada kemungkinan untuk meningkatkan interval tanpa secara signifikan meningkatkan waktu untuk menaikkan skala keseluruhan. Misalnya, jika dibutuhkan 2 menit untuk meluncurkan node, mengubah interval menjadi 1 menit akan menghasilkan tradeoff 6x panggilan API berkurang untuk peningkatan skala 38% lebih lambat.

Sharding Lintas Grup Node

Cluster Autoscaler dapat dikonfigurasi untuk beroperasi pada satu set Grup Node tertentu. Dengan menggunakan fungsi ini, dimungkinkan untuk menerapkan beberapa instance Cluster Autoscaler, masing-masing dikonfigurasi untuk beroperasi pada kumpulan Grup Node yang berbeda. Strategi ini memungkinkan Anda menggunakan sejumlah besar Grup Node secara sewenang-wenang, biaya perdagangan untuk skalabilitas. Kami hanya merekomendasikan menggunakan ini sebagai upaya terakhir untuk meningkatkan kinerja.

Cluster Autoscaler awalnya tidak dirancang untuk konfigurasi ini, jadi ada beberapa efek samping. Karena pecahan tidak berkomunikasi, beberapa autoscaler dapat mencoba menjadwalkan pod yang tidak dapat dijadwalkan. Hal ini dapat mengakibatkan skala yang tidak perlu dari beberapa Grup Node. Node tambahan ini akan menskalakan kembali setelahscale-down-delay.

metadata: name: cluster-autoscaler namespace: cluster-autoscaler-1 ... --nodes=1:10:k8s-worker-asg-1 --nodes=1:10:k8s-worker-asg-2 --- metadata: name: cluster-autoscaler namespace: cluster-autoscaler-2 ... --nodes=1:10:k8s-worker-asg-3 --nodes=1:10:k8s-worker-asg-4

Pastikan bahwa:

  • Setiap pecahan dikonfigurasi untuk menunjuk ke satu set unik Grup EC2 Auto Scaling

  • Setiap pecahan dikerahkan ke namespace terpisah untuk menghindari konflik pemilihan pemimpin

Mengoptimalkan Biaya dan Ketersediaan

Instans Spot

Anda dapat menggunakan Instans Spot di grup node Anda dan menghemat hingga 90% dari harga sesuai permintaan, dengan trade-off Instans Spot dapat terganggu kapan saja ketika membutuhkan kapasitas kembali. EC2 Kesalahan Kapasitas Tidak Cukup akan terjadi ketika grup EC2 Auto Scaling Anda tidak dapat meningkatkan skala karena kurangnya kapasitas yang tersedia. Memaksimalkan keragaman dengan memilih banyak kelompok instans dapat meningkatkan peluang Anda untuk mencapai skala yang Anda inginkan dengan memanfaatkan banyak kumpulan kapasitas Spot, dan mengurangi dampak interupsi Instans Spot pada ketersediaan klaster Anda. Kebijakan Instans Campuran dengan Instans Spot adalah cara yang bagus untuk meningkatkan keragaman tanpa meningkatkan jumlah grup simpul. Perlu diingat, jika Anda membutuhkan sumber daya yang terjamin, gunakan Instans Sesuai Permintaan, bukan Instans Spot.

Sangat penting bahwa semua Jenis Instance memiliki kapasitas sumber daya yang sama saat mengonfigurasi Kebijakan Instance Campuran. Simulator penjadwalan autoscaler menggunakan yang pertama di. InstanceType MixedInstancePolicy Jika Jenis Instance berikutnya lebih besar, sumber daya mungkin terbuang setelah peningkatan skala. Jika lebih kecil, pod Anda mungkin gagal menjadwalkan instans baru karena kapasitas yang tidak mencukupi. Misalnya, instance M4, M5, M5a, dan M5n semuanya memiliki jumlah CPU dan Memori yang sama dan merupakan kandidat yang bagus untuk file. MixedInstancePolicy Alat Pemilih EC2 Instance dapat membantu Anda mengidentifikasi jenis instance yang serupa.

spot_mix_instance_policy

Disarankan untuk mengisolasi kapasitas On-Demand dan Spot ke dalam grup Auto EC2 Scaling yang terpisah. Ini lebih disukai daripada menggunakan strategi kapasitas dasar karena properti penjadwalan pada dasarnya berbeda. Karena Instans Spot terputus kapan saja (saat EC2 membutuhkan kapasitas kembali), pengguna akan sering mencemari node preemptable mereka, membutuhkan toleransi pod eksplisit terhadap perilaku preemption. Taints ini menghasilkan properti penjadwalan yang berbeda untuk node, sehingga mereka harus dipisahkan menjadi beberapa Grup Auto EC2 Scaling.

Cluster Autoscaler memiliki konsep Expander, yang menyediakan strategi berbeda untuk memilih Grup Node mana yang akan diskalakan. Strateginya --expander=least-waste adalah default tujuan umum yang baik, dan jika Anda akan menggunakan beberapa grup simpul untuk diversifikasi Instans Spot (seperti yang dijelaskan pada gambar di atas), ini dapat membantu mengoptimalkan biaya lebih lanjut grup node dengan menskalakan grup yang paling baik digunakan setelah aktivitas penskalaan.

Memprioritaskan grup simpul/ASG

Anda juga dapat mengonfigurasi penskalaan otomatis berbasis prioritas dengan menggunakan Expander Prioritas. --expander=prioritymemungkinkan klaster Anda untuk memprioritaskan grup simpul/ASG, dan jika tidak dapat menskalakan karena alasan apa pun, ia akan memilih grup node berikutnya dalam daftar yang diprioritaskan. Ini berguna dalam situasi di mana, misalnya, Anda ingin menggunakan jenis instans P3 karena GPU mereka memberikan kinerja optimal untuk beban kerja Anda, tetapi sebagai opsi kedua Anda juga dapat menggunakan jenis instans P2.

apiVersion: v1 kind: ConfigMap metadata: name: cluster-autoscaler-priority-expander namespace: kube-system data: priorities: |- 10: - .*p2-node-group.* 50: - .*p3-node-group.*

Cluster Autoscaler akan mencoba meningkatkan grup EC2 Auto Scaling yang cocok dengan nama p3-node-group. Jika operasi ini tidak berhasil di dalam--max-node-provision-time, ia akan mencoba untuk menskalakan grup EC2 Auto Scaling yang cocok dengan nama p2-node-group. Nilai ini default menjadi 15 menit dan dapat dikurangi untuk pemilihan grup node yang lebih responsif, meskipun jika nilainya terlalu rendah, itu dapat menyebabkan pemutusan skala yang tidak perlu.

Penyediaan berlebihan

Cluster Autoscaler meminimalkan biaya dengan memastikan bahwa node hanya ditambahkan ke cluster bila diperlukan dan dihapus ketika tidak digunakan. Ini secara signifikan memengaruhi latensi penerapan karena banyak pod akan dipaksa untuk menunggu skala node sebelum dapat dijadwalkan. Simpul membutuhkan waktu beberapa menit untuk tersedia, yang dapat meningkatkan latensi penjadwalan pod melalui urutan besarnya.

Ini dapat dikurangi menggunakan kelebihan penyediaan, yang membutuhkan biaya transaksi untuk latensi penjadwalan. Overprovisioning diimplementasikan menggunakan pod temporer dengan prioritas negatif, yang menempati ruang di cluster. Ketika pod yang baru dibuat tidak dapat dijadwalkan dan memiliki prioritas yang lebih tinggi, pod sementara akan didahului untuk memberi ruang. Pod sementara kemudian menjadi tidak dapat dijadwalkan, memicu Cluster Autoscaler untuk menskalakan node baru yang telah dilebih-lebihkan.

Ada manfaat lain yang kurang jelas untuk penyediaan berlebihan. Tanpa overprovisioning, salah satu efek samping dari cluster yang sangat dimanfaatkan adalah bahwa pod akan membuat keputusan penjadwalan yang kurang optimal menggunakan preferredDuringSchedulingIgnoredDuringExecution aturan Pod atau Node Affinity. Kasus penggunaan umum untuk ini adalah memisahkan pod untuk aplikasi yang sangat tersedia di seluruh zona ketersediaan yang menggunakan AntiAffinity. Penyediaan berlebihan dapat secara signifikan meningkatkan kemungkinan node dari zona yang benar tersedia.

Jumlah kapasitas yang dilebih-lebihkan adalah keputusan bisnis yang cermat untuk organisasi Anda. Pada intinya, ini adalah tradeoff antara kinerja dan biaya. Salah satu cara untuk membuat keputusan ini adalah dengan menentukan frekuensi skala rata-rata Anda dan membaginya dengan jumlah waktu yang diperlukan untuk meningkatkan node baru. Misalnya, jika rata-rata Anda memerlukan node baru setiap 30 detik dan EC2 membutuhkan waktu 30 detik untuk menyediakan node baru, satu node overprovisioning akan memastikan bahwa selalu ada node tambahan yang tersedia, mengurangi latensi penjadwalan hingga 30 detik dengan biaya satu Instance tambahan. EC2 Untuk meningkatkan keputusan penjadwalan zona, berikan lebih banyak jumlah node yang sama dengan jumlah zona ketersediaan di Grup EC2 Auto Scaling Anda untuk memastikan bahwa penjadwal dapat memilih zona terbaik untuk pod yang masuk.

Mencegah Penggusuran Scale Down

Beberapa beban kerja terlalu mahal untuk dikosongkan. Analisis data besar, tugas pembelajaran mesin, dan pelari uji pada akhirnya akan selesai, tetapi harus dimulai ulang jika terganggu. Cluster Autoscaler akan mencoba untuk menurunkan setiap node di bawah scale-down-utilization-threshold, yang akan mengganggu setiap pod yang tersisa pada node. Hal ini dapat dicegah dengan memastikan bahwa pod yang mahal untuk diusir dilindungi oleh label yang dikenali oleh Cluster Autoscaler.

Pastikan bahwa:

  • Mahal untuk mengusir pod memiliki anotasi cluster-autoscaler.kubernetes.io/safe-to-evict=false

Kasus Penggunaan Tingkat Lanjut

Volume EBS

Penyimpanan persisten sangat penting untuk membangun aplikasi stateful, seperti database atau cache terdistribusi. Volume EBS mengaktifkan kasus penggunaan ini di Kubernetes, tetapi terbatas pada zona tertentu. Aplikasi ini dapat sangat tersedia jika di-sharded di beberapa AZs menggunakan Volume EBS terpisah untuk setiap AZ. Cluster Autoscaler kemudian dapat menyeimbangkan penskalaan Grup Autoscaling. EC2

Pastikan bahwa:

  • Penyeimbangan grup simpul diaktifkan dengan pengaturan balance-similar-node-groups=true.

  • Grup Node dikonfigurasi dengan pengaturan yang identik kecuali untuk zona ketersediaan dan Volume EBS yang berbeda.

Penjadwalan Bersama

Tugas-tugas pelatihan yang didistribusikan machine learning mendapatkan manfaat signifikan dari latensi yang diminimalkan atas konfigurasi simpul zona yang sama. Beban kerja ini menyebarkan beberapa pod ke zona tertentu. Hal ini dapat dicapai dengan menetapkan Pod Affinity untuk semua Pod yang dijadwalkan bersama atau Node Affinity menggunakan. topologyKey: failure-domain.beta.kubernetes.io/zone Cluster Autoscaler kemudian akan menskalakan zona tertentu agar sesuai dengan permintaan. Anda mungkin ingin mengalokasikan beberapa Grup EC2 Auto Scaling, satu per zona ketersediaan untuk mengaktifkan failover untuk seluruh beban kerja yang dijadwalkan bersama.

Pastikan bahwa:

  • Penyeimbang group simpul diaktifkan dengan pengaturan balance-similar-node-groups=false

  • Node Affinity dan/atau Pod Preemption digunakan ketika cluster mencakup Grup Node Regional dan Zonal.

Akselerator

Beberapa cluster memanfaatkan akselerator perangkat keras khusus seperti GPU. Saat menskalakan, plugin perangkat akselerator dapat memakan waktu beberapa menit untuk mengiklankan sumber daya ke cluster. Cluster Autoscaler telah mensimulasikan bahwa node ini akan memiliki akselerator, tetapi sampai akselerator menjadi siap dan memperbarui sumber daya node yang tersedia, pod yang tertunda tidak dapat dijadwalkan pada node. Hal ini dapat mengakibatkan menskalakan keluar tidak diperlukan yang berulang.

Selain itu, node dengan akselerator dan pemanfaatan CPU atau Memori yang tinggi tidak akan dipertimbangkan untuk menurunkan skala, bahkan jika akselerator tidak digunakan. Perilaku ini bisa mahal karena biaya relatif akselerator. Sebagai gantinya, Cluster Autoscaler dapat menerapkan aturan khusus untuk mempertimbangkan node untuk menurunkan skala jika mereka memiliki akselerator kosong.

Untuk memastikan perilaku yang benar untuk kasus-kasus ini, Anda dapat mengonfigurasi kubelet pada node akselerator Anda untuk memberi label pada node sebelum bergabung dengan cluster. Cluster Autoscaler akan menggunakan pemilih label ini untuk memicu perilaku akselerator yang dioptimalkan.

Pastikan bahwa:

  • Kubelet untuk node GPU dikonfigurasi dengan --node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE

  • Node dengan Accelerators mematuhi aturan properti penjadwalan identik yang disebutkan di atas.

Penskalaan dari 0

Cluster Autoscaler mampu menskalakan Grup Node ke dan dari nol, yang dapat menghasilkan penghematan biaya yang signifikan. Ini mendeteksi sumber daya CPU, memori, dan GPU dari Grup Auto Scaling dengan memeriksa yang ditentukan InstanceType dalam atau. LaunchConfiguration LaunchTemplate Beberapa pod memerlukan sumber daya tambahan seperti WindowsENI atau PrivateIPv4Address atau spesifik NodeSelectors atau Taints yang tidak dapat ditemukan dari. LaunchConfiguration Cluster Autoscaler dapat menjelaskan faktor-faktor ini dengan menemukannya dari tag pada Grup Auto EC2 Scaling. Sebagai contoh:

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME Value: 5 Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY Value: $LABEL_VALUE Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY Value: NoSchedule

Catatan: Perlu diingat, saat penskalaan ke nol kapasitas Anda dikembalikan EC2 dan mungkin tidak tersedia di masa mendatang.

Parameter Tambahan

Ada banyak opsi konfigurasi yang dapat digunakan untuk menyesuaikan perilaku dan kinerja Cluster Autoscaler. Daftar lengkap parameter tersedia di GitHub.

Parameter Deskripsi Default

interval pemindaian

Seberapa sering cluster dievaluasi ulang untuk skala naik atau turun

10 detik

max-empty-bulk-delete

Jumlah maksimum node kosong yang dapat dihapus secara bersamaan.

10

scale-down-delay-after-tambahkan

Berapa lama setelah skala naik, evaluasi skala ke bawah dilanjutkan

10 menit

scale-down-delay-after-hapus

Berapa lama setelah penghapusan node yang menurunkan evaluasi dilanjutkan, default ke interval pemindaian

interval pemindaian

scale-down-delay-after-kegagalan

Berapa lama setelah penurunan skala kegagalan yang menurunkan evaluasi dilanjutkan

3 menit

scale-down-unneeded-time

Berapa lama sebuah node seharusnya tidak dibutuhkan sebelum memenuhi syarat untuk menurunkan skala

10 menit

scale-down-unready-time

Berapa lama node yang belum siap seharusnya tidak dibutuhkan sebelum memenuhi syarat untuk menurunkan skala

20 menit

scale-down-utilization-threshold

Tingkat pemanfaatan node, didefinisikan sebagai jumlah sumber daya yang diminta dibagi dengan kapasitas, di bawahnya node dapat dipertimbangkan untuk menurunkan skala

0,5

scale-down-non-empty-kandidat-hitung

Jumlah maksimum node yang tidak kosong dipertimbangkan dalam satu iterasi sebagai kandidat untuk menurunkan skala dengan drain. Nilai yang lebih rendah berarti respons CA yang lebih baik tetapi kemungkinan penurunan latensi skala lebih lambat. Nilai yang lebih tinggi dapat mempengaruhi kinerja CA dengan cluster besar (ratusan node). Setel ke nilai non positif untuk mematikan heuristik ini - CA tidak akan membatasi jumlah node yang dianggapnya. ”

30

scale-down-candidates-pool-rasio

Rasio node yang dianggap sebagai kandidat tambahan yang tidak kosong untuk menurunkan skala ketika beberapa kandidat dari iterasi sebelumnya tidak lagi valid. Nilai yang lebih rendah berarti respons CA yang lebih baik tetapi kemungkinan penurunan latensi skala lebih lambat. Nilai yang lebih tinggi dapat mempengaruhi kinerja CA dengan cluster besar (ratusan node). Setel ke 1.0 untuk menonaktifkan heuristik ini - CA akan mengambil semua node sebagai kandidat tambahan.

0,1

scale-down-candidates-pool-min-hitung

Jumlah minimum node yang dianggap sebagai kandidat tambahan yang tidak kosong untuk menurunkan skala ketika beberapa kandidat dari iterasi sebelumnya tidak lagi valid. Saat menghitung ukuran kolam untuk kandidat tambahan yang kami ambil max(#nodes * scale-down-candidates-pool-ratio, scale-down-candidates-pool-min-count)

50

Sumber Daya Tambahan

Halaman ini berisi daftar presentasi dan demo Cluster Autoscaler. Jika Anda ingin menambahkan presentasi atau demo di sini, silakan kirim permintaan tarik.

Presentasi/Demo Penyaji

Penskalaan Otomatis dan Optimalisasi Biaya di Kubernetes: Dari 0 hingga 100

Guy Templeton, Skyscanner & Jiaxin Shan, Amazon

Penyelaman Dalam Penskalaan Otomatis SIGG

Maciek Pytel & Marcin Wielgus

Referensi

PrivasiSyarat situsPreferensi cookie
© 2025, Amazon Web Services, Inc. atau afiliasinya. Semua hak dilindungi undang-undang.