Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Autoscaler klaster
Tip
Jelaj
Gambaran umum
Kubernetes Cluster Autoscaler .DesiredReplicas bidang Grup Penskalaan Otomatis EC2 Anda.
Panduan ini akan memberikan model mental untuk mengonfigurasi Cluster Autoscaler dan memilih rangkaian pertukaran terbaik untuk memenuhi persyaratan organisasi Anda. Meskipun tidak ada konfigurasi terbaik tunggal, ada serangkaian opsi konfigurasi yang memungkinkan Anda untuk menukar kinerja, skalabilitas, biaya, dan ketersediaan. Selain itu, panduan ini akan memberikan tips dan praktik terbaik untuk mengoptimalkan konfigurasi Anda untuk AWS.
Glosarium
Terminologi berikut akan sering digunakan di seluruh dokumen ini. Istilah-istilah ini dapat memiliki arti luas, tetapi terbatas pada definisi di bawah ini untuk tujuan dokumen ini.
Skalabilitas mengacu pada seberapa baik kinerja Cluster Autoscaler saat Cluster Kubernetes Anda meningkat dalam jumlah pod dan node. Ketika 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 mengeksekusi 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 bahwa pod dapat dijadwalkan dengan cepat dan tanpa gangguan. Ini termasuk kapan pod yang baru dibuat perlu dijadwalkan dan ketika node yang diperkecil mengakhiri pod yang tersisa yang dijadwalkan untuk itu.
Biaya ditentukan oleh keputusan di balik skala dan skala dalam acara. Sumber daya terbuang jika node yang ada kurang dimanfaatkan atau node baru ditambahkan yang terlalu besar untuk pod masuk. Tergantung pada kasus penggunaan, mungkin ada biaya yang terkait dengan penghentian pod sebelum waktunya karena keputusan penurunan skala yang agresif.
Grup Node adalah konsep Kubernetes abstrak untuk sekelompok node dalam cluster. Ini bukan sumber daya Kubernetes sejati, tetapi ada sebagai abstraksi di Cluster Autoscaler, Cluster API, dan komponen lainnya. Node dalam Grup Node berbagi properti seperti label dan noda, tetapi dapat terdiri dari beberapa Zona Ketersediaan atau Jenis Instans.
Grup Penskalaan Otomatis EC2 dapat digunakan sebagai implementasi Grup Node di EC2. Grup Penskalaan Otomatis EC2 dikonfigurasi untuk meluncurkan instans yang secara otomatis bergabung dengan Cluster Kubernetes mereka dan menerapkan label dan noda ke sumber daya Node yang sesuai di API Kubernetes.
Grup Node Terkelola EC2 adalah implementasi lain dari Grup Node di EC2. Mereka menghilangkan kompleksitas yang secara manual mengkonfigurasi Grup Penskalaan Otomatis EC2 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 versi silang tidak diuji atau didukung
. -
Penemuan Otomatis
diaktifkan, kecuali Anda memiliki kasus penggunaan lanjutan tertentu yang mencegah penggunaan mode ini.
Gunakan akses yang paling tidak memiliki hak istimewa ke peran IAM
Saat Auto Discovery autoscaling:SetDesiredCapacity dan autoscaling:TerminateInstanceInAutoScalingGroup ke grup Penskalaan Otomatis yang dicakup ke cluster saat ini.
Ini akan mencegah Cluster Autoscaler yang berjalan dalam satu cluster memodifikasi grup node di cluster yang berbeda bahkan jika --node-group-auto-discovery argumen tidak dicakup ke grup simpul 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": "*" } ] }
Mengkonfigurasi Grup Node Anda
Penskalaan otomatis yang efektif dimulai dengan mengkonfigurasi satu set Grup Node untuk cluster Anda dengan benar. 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 Penskalaan Otomatis EC2, yang fleksibel untuk sejumlah besar kasus penggunaan. Namun, Cluster Autoscaler membuat beberapa asumsi tentang Grup Node Anda. Menjaga konfigurasi Grup Penskalaan Otomatis EC2 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 Instans harus memiliki bentuk yang sama untuk CPU, Memori, dan GPU
-
Jenis Instans pertama yang ditentukan dalam kebijakan akan digunakan untuk mensimulasikan penjadwalan.
-
Jika kebijakan Anda memiliki Tipe Instans tambahan dengan lebih banyak sumber daya, sumber daya mungkin terbuang setelah diperbesar.
-
Jika kebijakan Anda memiliki Tipe Instans tambahan dengan sumber daya yang lebih sedikit, pod mungkin gagal menjadwalkan instans.
-
-
Grup Node dengan banyak node lebih disukai daripada banyak Grup Node dengan node lebih sedikit. Ini akan memiliki dampak terbesar pada skalabilitas.
-
Jika memungkinkan, pilih fitur EC2 ketika kedua sistem memberikan dukungan (misalnya Wilayah, MixedInstancePolicy)
catatan
Sebaiknya gunakan EKS Managed Node Groups. Grup Node Terkelola hadir dengan fitur manajemen yang kuat, termasuk fitur untuk Cluster Autoscaler seperti penemuan Grup Penskalaan Otomatis EC2 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 utama untuk menyesuaikan skalabilitas Cluster Autoscaler adalah sumber daya yang disediakan untuk proses, interval pemindaian algoritma, dan jumlah Grup Node dalam cluster. Ada faktor lain yang terlibat dalam kompleksitas runtime sebenarnya dari algoritma ini, seperti kompleksitas plugin penjadwalan 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 cluster ke dalam memori, termasuk Pod, Node, dan Grup Node. Pada setiap interval pemindaian, algoritma mengidentifikasi pod yang tidak dapat dijadwalkan dan mensimulasikan penjadwalan untuk setiap Grup Node. Menyetel faktor-faktor ini datang dengan pertukaran yang berbeda yang harus dipertimbangkan dengan cermat untuk kasus penggunaan Anda.
Penskalaan Otomatis Secara Vertikal pada Autoscaler Cluster
Cara paling sederhana 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 autoscaling menyimpan semua pod dan node dalam memori, yang dapat menghasilkan jejak memori yang lebih besar dari satu gigabyte dalam beberapa kasus. Peningkatan sumber daya biasanya dilakukan secara manual. Jika Anda menemukan bahwa penyetelan sumber daya konstan menciptakan beban operasional, pertimbangkan untuk menggunakan Addon Resizer
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 GPU), tetapi dalam banyak kasus ada desain alternatif yang mencapai efek yang sama saat menggunakan sejumlah kecil grup.
Pastikan bahwa:
-
Isolasi pod dilakukan menggunakan Namespace daripada Node Groups.
-
Ini mungkin tidak mungkin dilakukan dalam cluster multi-penyewa dengan kepercayaan rendah.
-
Pod ResourceRequests dan ResourceLimits diatur dengan benar untuk menghindari perselisihan 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 Penskalaan Otomatis EC2 tunggal dengan beberapa Zona Ketersediaan.
Mengurangi Interval Pemindaian
Interval pemindaian yang rendah (misalnya 10 detik) akan memastikan bahwa Cluster Autoscaler merespons secepat mungkin ketika pod menjadi tidak dapat dijadwalkan. Namun, setiap pemindaian menghasilkan banyak panggilan API ke API Kubernetes dan EC2 Auto Scaling Group atau EKS Managed Node Group API. Panggilan API ini dapat mengakibatkan pembatasan tarif atau bahkan tidak tersedianya layanan untuk Pesawat Kontrol Kubernetes Anda.
Interval pemindaian default adalah 10 detik, tetapi di AWS, meluncurkan 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 membutuhkan waktu 2 menit untuk meluncurkan node, mengubah interval menjadi 1 menit akan menghasilkan pengorbanan panggilan API yang berkurang 6x untuk peningkatan skala yang lebih lambat 38%.
Sharding di Seluruh Grup Node
Cluster Autoscaler dapat dikonfigurasi untuk beroperasi pada kumpulan 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 Grup Node dalam jumlah besar secara sewenang-wenang, biaya perdagangan untuk skalabilitas. Kami hanya merekomendasikan penggunaan ini sebagai upaya terakhir untuk meningkatkan kinerja.
Cluster Autoscaler awalnya tidak dirancang untuk konfigurasi ini, jadi ada beberapa efek samping. Karena pecahan tidak berkomunikasi, dimungkinkan bagi beberapa autoscaler untuk mencoba menjadwalkan pod yang tidak dapat dijadwalkan. Hal ini dapat mengakibatkan skala yang tidak perlu dari beberapa Grup Node. Node tambahan ini akan ditingkatkan 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 Penskalaan Otomatis EC2
-
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 dan menghemat hingga 90% dari harga sesuai permintaan, dengan pertukaran Instans Spot dapat terganggu kapan saja ketika EC2 membutuhkan kapasitas kembali. Kesalahan Kapasitas Tidak Mencukupi akan terjadi ketika grup Penskalaan Otomatis EC2 Anda tidak dapat meningkatkan skala karena kurangnya kapasitas yang tersedia. Memaksimalkan keragaman dengan memilih banyak keluarga instans dapat meningkatkan peluang Anda mencapai skala yang diinginkan dengan memanfaatkan banyak kumpulan kapasitas Spot, dan mengurangi dampak gangguan Instans Spot terhadap ketersediaan cluster Anda. Kebijakan Instans Campuran dengan Instans Spot adalah cara yang bagus untuk meningkatkan keragaman tanpa meningkatkan jumlah grup simpul. Perlu diingat, jika Anda memerlukan sumber daya yang dijamin, gunakan On-Demand Instans alih-alih Instans Spot.
Sangat penting bahwa semua Jenis Instans memiliki kapasitas sumber daya yang sama saat mengonfigurasi Kebijakan Instans Campuran. Simulator penjadwalan autoscaler menggunakan yang pertama InstanceType di. MixedInstancePolicy Jika Jenis Instans 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 a. MixedInstancePolicy Alat Pemilih Instans
Disarankan untuk mengisolasi On-Demand dan Spot kapasitas ke dalam grup Penskalaan Otomatis EC2 yang terpisah. Ini lebih disukai daripada menggunakan strategi kapasitas dasar karena properti penjadwalan secara fundamental berbeda. Karena Instans Spot diinterupsi kapan saja (ketika EC2 membutuhkan kapasitas kembali), pengguna akan sering mencemari node preemptable mereka, yang memerlukan toleransi pod eksplisit untuk perilaku preemption. Noda-noda ini menghasilkan properti penjadwalan yang berbeda untuk node, sehingga mereka harus dipisahkan menjadi beberapa Grup Penskalaan Otomatis EC2.
Cluster Autoscaler memiliki konsep Expanders--expander=least-waste ini adalah default tujuan umum yang baik, dan jika Anda akan menggunakan beberapa grup node untuk diversifikasi Instance Spot (seperti yang dijelaskan pada gambar di atas), ini dapat membantu mengoptimalkan biaya lebih lanjut grup node dengan menskalakan grup yang akan paling baik digunakan setelah aktivitas penskalaan.
Memprioritaskan grup node/ASG
Anda juga dapat mengonfigurasi penskalaan otomatis berbasis prioritas dengan menggunakan Expander Priority. --expander=prioritymemungkinkan cluster Anda untuk memprioritaskan grup node/ASG, dan jika tidak dapat menskalakan karena alasan apa pun, ia akan memilih grup node berikutnya dalam daftar prioritas. Ini berguna dalam situasi di mana, misalnya, Anda ingin menggunakan jenis instans P3 karena GPU-nya 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 dalamnya--max-node-provision-time, ia akan mencoba untuk menskalakan grup Penskalaan Otomatis EC2 yang cocok dengan nama p 2-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 keluarnya skala yang tidak perlu.
Penyediaan Berlebih
Cluster Autoscaler meminimalkan biaya dengan memastikan bahwa node hanya ditambahkan ke cluster bila diperlukan dan dihapus saat tidak digunakan. Ini secara signifikan berdampak pada latensi penerapan karena banyak pod akan dipaksa untuk menunggu peningkatan 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 dari overprovisioning. Tanpa kelebihan penyediaan, salah satu efek samping dari cluster yang sangat digunakan 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 menggunakan AntiAffinity. Overprovisioning dapat secara signifikan meningkatkan kemungkinan bahwa node dari zona yang benar tersedia.
Jumlah kapasitas yang kelebihan pasokan adalah keputusan bisnis yang cermat untuk organisasi Anda. Pada intinya, ini adalah pertukaran antara kinerja dan biaya. Salah satu cara untuk membuat keputusan ini adalah dengan menentukan frekuensi peningkatan skala rata-rata Anda dan membaginya dengan jumlah waktu yang dibutuhkan 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 Instans EC2 tambahan. Untuk meningkatkan keputusan penjadwalan zona, berikan jumlah node yang sama dengan jumlah zona ketersediaan di Grup Penskalaan Otomatis EC2 Anda untuk memastikan penjadwal dapat memilih zona terbaik untuk pod masuk.
Cegah Mengurangi Pengusiran
Beberapa beban kerja terlalu mahal untuk dikosongkan. Analisis data besar, tugas pembelajaran mesin, dan pelari tes pada akhirnya akan selesai, tetapi harus dimulai ulang jika terganggu. Cluster Autoscaler akan mencoba untuk menurunkan skala node apa pun di bawah ambang penggunaan skala turun, yang akan mengganggu 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:
-
Pod yang mahal untuk mengusir memiliki anotasi
cluster-autoscaler.kubernetes.io/safe-to-evict=false
Kasus Penggunaan Lanjutan
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 yang berbeda dan Volume EBS.
Co-Scheduling
Tugas-tugas pelatihan yang didistribusikan machine learning mendapatkan manfaat signifikan dari latensi yang diminimalkan atas konfigurasi simpul zona yang sama. Beban kerja ini menerapkan beberapa pod ke zona tertentu. Hal ini dapat dicapai dengan menyetel Pod Affinity untuk semua pod yang dijadwalkan bersama atau menggunakan topologyKey: failure-domain.beta.kubernetes.io/zone Node Affinity. Cluster Autoscaler kemudian akan menskalakan zona tertentu agar sesuai dengan permintaan. Anda mungkin ingin mengalokasikan beberapa Grup Penskalaan Otomatis EC2, 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
and/or Pod Preemption digunakan ketika cluster menyertakan Grup Node Regional dan Zonal. -
Gunakan Node Affinity
untuk memaksa atau mendorong pod regional untuk menghindari Grup Node zona, dan sebaliknya. -
Jika pod zonal menjadwalkan ke grup node regional, ini akan mengakibatkan ketidakseimbangan kapasitas untuk pod regional Anda.
-
Jika beban kerja zona 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 tidak terlalu diperebutkan.
-
Akselerator
Beberapa cluster memanfaatkan akselerator perangkat keras khusus seperti GPU. Saat meningkatkan skala, 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 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 diperkecil, 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 diperkecil jika mereka memiliki akselerator kosong.
Untuk memastikan perilaku yang benar untuk 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 Akselerator 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 Penskalaan Otomatis dengan memeriksa yang InstanceType ditentukan dalam LaunchConfiguration atau 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 Penskalaan Otomatis EC2. 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 menskalakan ke nol kapasitas Anda dikembalikan ke 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 |
|
paralelisme max-scale-down- |
Jumlah maksimum node (kosong dan membutuhkan drainase) yang dapat dihapus secara paralel. Cluster Autoscaler v1.32.0 tidak digunakan lagi dan menggantinya dengan. |
10 |
|
Scale-down-tunda-sesudah menambahkan |
Berapa lama setelah menaikkan, evaluasi skala turun dilanjutkan |
10 menit |
|
Scale-down-tunda-setelah menghapus |
Berapa lama setelah penghapusan node, evaluasi penurunan skala dilanjutkan, defaultnya adalah interval pemindaian |
interval pemindaian |
|
Scale-down-tunda-sesudah kegagalan |
Berapa lama setelah mengurangi kegagalan, evaluasi yang diperkecil dilanjutkan |
3 menit |
|
menskala-turun-waktu yang tidak diperlukan |
Berapa lama node seharusnya tidak dibutuhkan sebelum memenuhi syarat untuk diturunkan |
10 menit |
|
kecurunkan-waktu yang belum siap |
Berapa lama node yang tidak siap seharusnya tidak dibutuhkan sebelum memenuhi syarat untuk diturunkan |
20 menit |
|
menskalakan ambang penggunaan |
Tingkat pemanfaatan node, didefinisikan sebagai jumlah sumber daya yang diminta dibagi dengan kapasitas, di bawahnya node dapat dipertimbangkan untuk diperkecil |
0.5 |
|
kurangi jumlah kandidat yang tidak kosong |
Jumlah maksimum node tidak kosong yang dipertimbangkan dalam satu iterasi sebagai kandidat untuk mengurangi skala dengan drain. Nilai yang lebih rendah berarti respons CA yang lebih baik tetapi kemungkinan mengurangi latensi yang 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 dipertimbangkannya. ” |
30 |
|
menskalakan rasio kumpulan kandidat |
Rasio node yang dianggap sebagai kandidat non-kosong tambahan untuk diperkecil ketika beberapa kandidat dari iterasi sebelumnya tidak lagi valid. Nilai yang lebih rendah berarti respons CA yang lebih baik tetapi kemungkinan mengurangi latensi yang lebih lambat. Nilai yang lebih tinggi dapat mempengaruhi kinerja CA dengan cluster besar (ratusan node). Setel ke 1.0 untuk mematikan heuristik ini - CA akan mengambil semua node sebagai kandidat tambahan. |
0.1 |
|
kecilkan-kecilan-kecilan-kecilan-kecil-kecilan-kandidat- |
Jumlah minimum node yang dianggap sebagai kandidat non-kosong tambahan untuk diperkecil 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.
| Presentation/Demo | Presenter |
|---|---|
|
Penskalaan Otomatis dan Optimalisasi Biaya di Kubernetes: Dari 0 hingga 100 |
Guy Templeton, Skyscanner & Jiaxin Shan, Amazon |
|
Maciek Pytel & Marcin Wielgus |
Referensi
-
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
-
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md
-
https://github.com/aws/amazon-ec2-instance-selector
-
https://github.com/aws/aws-node-termination-handler