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.DesiredReplicas
bidang Grup Auto Scaling EC2 Anda.

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
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 Discoveryautoscaling: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
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
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

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--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=priority
memungkinkan 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
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
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. -
Gunakan Node Affinity
untuk memaksa atau mendorong pod regional untuk menghindari Zonal Node Groups, dan sebaliknya. -
Jika pod zonal dijadwalkan ke grup node regional, ini akan mengakibatkan ketidakseimbangan kapasitas untuk pod regional Anda.
-
Jika beban kerja zonal Anda dapat mentolerir gangguan dan relokasi, konfigurasikan Pod Preemption untuk mengaktifkan pod yang diskalakan secara regional untuk memaksa preemption
dan penjadwalan ulang pada zona yang kurang diperebutkan.
-
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 |
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 |
Maciek Pytel & Marcin Wielgus |