View a markdown version of this page

Autoscaler klaster - Amazon EKS

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

Autoscaler klaster

Tip

Jelaj ahi praktik terbaik melalui lokakarya Amazon EKS.

Gambaran umum

Kubernetes Cluster Autoscaler adalah solusi Cluster Autoscaling populer yang dikelola oleh SIG Autoscaling. https://github.com/kubernetes/community/tree/master/sig-autoscaling Ini bertanggung jawab untuk memastikan bahwa cluster 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 Penskalaan Otomatis EC2 Anda.

arsitektur

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 di klaster Anda. Ini menggunakan pemilihan pemimpin untuk memastikan ketersediaan tinggi, tetapi pekerjaan dilakukan oleh satu replika pada satu waktu. Itu tidak dapat diskalakan secara horizontal. Untuk pengaturan dasar, defaultnya 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 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 digunakan, kami sangat menyarankan agar Anda menggunakan akses hak istimewa paling sedikit dengan membatasi Tindakan 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 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 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 EC2 dapat membantu Anda mengidentifikasi jenis instans serupa.

spot_mix_instance_policy

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, yang menyediakan strategi berbeda untuk memilih Grup Node mana yang akan diskalakan. Strategi --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, yang membutuhkan biaya transaksi untuk latensi penjadwalan. Overprovisioning diimplementasikan menggunakan pod sementara 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 didahulukan untuk memberi ruang. Pod sementara kemudian menjadi tidak dapat dijadwalkan, memicu Cluster Autoscaler untuk menskalakan node baru yang kelebihan pasokan.

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 mengaktifkan kasus penggunaan ini di Kubernetes, tetapi terbatas pada zona tertentu. Aplikasi ini dapat sangat tersedia jika dipecah di beberapa AZ menggunakan Volume EBS terpisah untuk setiap AZ. Cluster Autoscaler kemudian dapat menyeimbangkan penskalaan Grup Penskalaan Otomatis 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 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. --max-empty-bulk-delete --max-scale-down-parallelism Jika Anda menggunakan versi Autoscaler Cluster lebih awal dari v1.32.0, gunakan sebagai gantinya. --max-empty-bulk-delete

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 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.

Presentation/Demo Presenter

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

Guy Templeton, Skyscanner & Jiaxin Shan, Amazon

SIG-Autoscaling Menyelam Mendalam

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