View a markdown version of this page

Kelola komputasi untuk AI/ML beban kerja di Amazon EKS dengan grup node - Amazon EKS

Bantu tingkatkan halaman ini

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

Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.

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

Kelola komputasi untuk AI/ML beban kerja di Amazon EKS dengan grup node

Tip

Daftar untuk AI/ML lokakarya Amazon EKS mendatang.

Bagian ini membahas cara mengelola komputasi yang dipercepat (AWS Trainium, NVIDIA GPU) untuk pelatihan AI dan beban kerja inferensi menggunakan grup node terkelola Amazon EKS atau node yang dikelola sendiri.

Grup node yang dikelola EKS dan node yang dikelola sendiri menggunakan EC2 Auto Scaling Groups (ASG). Grup node terkelola EKS telah mendedikasikan API EKS untuk membuat, memperbarui, dan menghapus node, dan juga memiliki fungsionalitas perbaikan node dan kait penghentian siklus hidup bawaan. Node yang dikelola sendiri EKS diterapkan dan dikelola secara langsung melalui API EC2.

Dengan opsi ini, Anda menentukan jenis instans, jumlah yang diinginkan, batas penskalaan, dan templat peluncuran EC2 di muka. Pertimbangkan untuk menggunakan grup node terkelola EKS atau node yang dikelola sendiri jika Anda juga memiliki beban kerja non-EKS dan lebih memilih konsistensi konfigurasi melalui templat peluncuran EC2. Grup simpul EKS cocok untuk pelatihan dan penyempurnaan beban kerja di mana jejak komputasi yang dipercepat diketahui sebelumnya. Catatan, baik Mode Otomatis EKS dan Karpenter juga mendukung penyediaan kapasitas statis, lihat Kelola komputasi untuk AI/ML beban kerja dengan EKS Auto Mode dan Karpenter untuk informasi selengkapnya.

Grup node terkelola EKS dan node yang dikelola sendiri mendukung semua opsi pembelian komputasi yang dipercepat (On-Demand, Spot, Reservasi On-Demand Kapasitas, Blok Kapasitas untuk ML). Anda membuat grup node terkelola atau dikelola sendiri terpisah per jenis kapasitas, masing-masing dengan templat peluncuran, jenis instans, dan konfigurasi penskalaannya sendiri. Ini memberi Anda ASG-backed kontrol eksplisit atas setiap kumpulan kapasitas tanpa logika penyediaan dinamis yang heterogen.

Grup simpul yang dikelola EKS vs. node yang dikelola sendiri

Memilih antara grup node terkelola EKS dan node yang dikelola sendiri tergantung pada tingkat penyesuaian dan kontrol yang Anda butuhkan. Grup node terkelola EKS memungkinkan subset kustomisasi template peluncuran EC2, sedangkan node yang dikelola sendiri mendukung luasnya template peluncuran EC2. Jika Anda tidak memiliki alasan khusus untuk menyesuaikan dan mengelola siklus hidup node sendiri, mulailah dengan grup node terkelola EKS dan hanya pindah ke node yang dikelola sendiri ketika persyaratan tertentu memaksanya.

Gunakan grup node terkelola saat: Anda ingin EKS menangani pemilihan AMI, bootstrap node, pembaruan bergulir, perbaikan node, dan alur kerja drain yang anggun atas nama Anda. Grup simpul terkelola EKS adalah titik awal yang disarankan jika Anda tidak lebih suka menggunakan Mode Otomatis EKS atau Karpenter untuk beban kerja pelatihan dan inferensi. Saat menggunakan Blok Kapasitas untuk ML, grup node terkelola EKS secara otomatis membuat kebijakan penskalaan terjadwal yang menguras grup node 40 menit sebelum reservasi berakhir, menghilangkan kebutuhan untuk menggunakan AWS Node Termination Handler atau otomatisasi penskalaan Anda sendiri. Gunakan grup node terkelola EKS saat Anda menggunakan EKS-optimized AMI yang didukung, saat Anda tidak memerlukan kustomisasi template peluncuran tingkat kernel atau EC2 yang mendalam, dan saat Anda menginginkan jalur peningkatan node yang lebih sederhana untuk versi Kubernetes.

Gunakan grup node yang dikelola sendiri saat: Anda memerlukan kontrol penuh atas template peluncuran EC2, AMI, parameter kernel, konfigurasi runtime kontainer, atau skrip bootstrap khusus. Skenario MS yang umum termasuk menyetel kernel dan pengaturan NIC untuk pelatihan terdistribusi dengan Elastic Fabric Adapter (EFA), atau mengintegrasikan dengan pengontrol siklus hidup node kustom. Self-managed node memberi Anda fleksibilitas untuk mengirimkan data pengguna dan profil instans IAM yang Anda butuhkan, tetapi Anda bertanggung jawab atas pembaruan, kebijakan penskalaan terjadwal, dan kait siklus hidup seperti Node Termination Handler.AWS

Cadangan GPU dengan Blok Kapasitas untuk ML

Blok Kapasitas untuk pembelajaran mesin (ML) memungkinkan Anda untuk memesan instans GPU di masa mendatang untuk pelatihan terikat waktu atau beban kerja inferensi. Untuk informasi selengkapnya, lihat Blok Kapasitas untuk ML di Panduan Pengguna Amazon EC2.

Anda dapat menggunakan reservasi Blok Kapasitas melalui grup node terkelola EKS dan node yang dikelola sendiri. Konfigurasi template peluncuran EC2 sama dalam kedua kasus. Alur kerja pembuatan node, perilaku penskalaan, dan kait siklus hidup untuk penghentian beban kerja berbeda di seluruh opsi penyediaan.

Pertimbangan-pertimbangan

  • Blok Kapasitas hanya tersedia untuk jenis dan AWS Wilayah instans Amazon EC2 tertentu. Lihat Prasyarat Blok Kapasitas Bekerja dengan Kapasitas untuk informasi lebih lanjut.

  • Blok Kapasitas bersifat zonal. Selama pembuatan grup node, Anda harus menggunakan subnet di Availability Zone (AZ) yang sama dengan reservasi Blok Kapasitas.

  • Jika Anda membuat grup node sebelum reservasi Blok Kapasitas menjadi aktif, atur kapasitas yang diinginkan 0 selama pembuatan grup node.

  • Untuk memberikan waktu untuk menguras beban kerja yang anggun, jadwalkan skala ke nol lebih dari 30 menit sebelum reservasi Blok Kapasitas berakhir. EC2 mulai mematikan instans 30 menit sebelum reservasi berakhir.

Buat grup simpul dengan Blok Kapasitas untuk ML

Grup node terkelola EKS dan node yang dikelola sendiri memerlukan penggunaan templat peluncuran EC2 kustom yang menargetkan reservasi Blok Kapasitas. Berikut ini menunjukkan bidang wajib minimal untuk grup node terkelola EKS dan node yang dikelola sendiri. Bidang tambahan diperlukan untuk node yang dikelola sendiri seperti yang ditunjukkan pada langkah-langkah Self-managed node di bawah ini.

Yang LaunchTemplateData harus mencakup:

  • InstanceMarketOptionsdengan MarketType set ke "capacity-block"

  • CapacityReservationSpecification: CapacityReservationTargetdengan CapacityReservationId disetel ke ID Blok Kapasitas. Misalnya, cr-0123456789abcdef0.

  • InstanceTypeatur ke jenis instans reservasi Blok Kapasitas Anda. Misalnya, p5.48xlarge.

Persyaratan ini ditunjukkan dalam contoh di bawah ini untuk membuat template peluncuran untuk grup node terkelola EKS dan node yang dikelola sendiri.

Managed node groups
  1. Buat file bernama eks-capacity-block-lt.json dengan isi berikut ini.

    Ganti konten untuk CapacityReservationId dan InstanceType dengan nilai untuk Blok Kapasitas Anda. Untuk informasi selengkapnya tentang bidang template peluncuran EC2 tambahan, lihat Sesuaikan node terkelola dengan templat peluncuran dan Gunakan Blok Kapasitas untuk beban kerja pembelajaran mesin.

    { "LaunchTemplateData": { "InstanceMarketOptions": { "MarketType": "capacity-block" }, "CapacityReservationSpecification": { "CapacityReservationTarget": { "CapacityReservationId": "cr-0123456789abcdef0" } }, "InstanceType": "p5.48xlarge" } }
  2. Buat templat peluncuran .

    aws ec2 create-launch-template \ --launch-template-name EKS-Capacity-Block-Launch-Template \ --launch-template-data file://eks-capacity-block-lt.json
  3. Gunakan template peluncuran untuk membuat grup node terkelola EKS. Ganti placeholder dalam perintah di bawah ini dengan nilai yang berlaku untuk lingkungan Anda. Perintah di bawah ini disetel --ami-type ke AMI NVIDIA EKS-optimized AL2023. Lihat Gunakan AMI yang EKS-optimized dipercepat untuk instans GPU untuk informasi lebih lanjut tentang EKS-optimized AMI yang tersedia. Jika Anda menggunakan AMI kustom dengan grup node terkelola EKS, tentukan ID AMI Anda di template peluncuran.

    Saat membuat grup node terkelola EKS yang menggunakan Blok Kapasitas, lakukan hal berikut:

    • Atur --capacity-type ke "CAPACITY_BLOCK".

    • Hanya tentukan subnet di Availability Zone yang sama dengan reservasi kapasitas.

    • Jika Anda menentukan bukan nol desiredSize sebelum reservasi aktif, Grup Auto Scaling melaporkan kesalahan peluncuran hingga reservasi menjadi aktif. Setelah aktif, instans diluncurkan dan ASG menskalakan hingga yang diminta. desiredSize

      aws eks create-nodegroup \ --cluster-name my-eks-cluster \ --nodegroup-name eks-cb-nodes \ --node-role "arn:aws: iam::111122223333:role/myNodeRole" \ --region region-code \ --subnets subnet-ExampleID1 \ --ami-type "AL2023_x86_64_NVIDIA" \ --scaling-config minSize=0,maxSize=2,desiredSize=0 \ --capacity-type "CAPACITY_BLOCK" \ --launch-template name="EKS-Capacity-Block-Launch-Template"
  4. Jika Anda desiredSize mengatur 0 pada waktu pembuatan, tingkatkan grup node saat reservasi menjadi aktif menggunakan salah satu dari:

  5. Verifikasi node bergabung dengan cluster setelah peningkatan skala.

  6. EKS secara otomatis membuat kebijakan penskalaan terjadwal bernama Amazon EKS Node Group Capacity Scaledown Sebelum Reservasi Berakhir untuk menurunkan skala grup node menjadi 0 40 menit sebelum reservasi berakhir. Ini memberi waktu Pod untuk dikeringkan dengan baik sebelum EC2 mulai menghentikan instans pada tanda 30 menit. Jangan mengedit atau menghapus tindakan terjadwal ini.

Self-managed nodes
  1. Buat file bernama eks-capacity-block-lt.json dengan isi berikut ini.

    Ganti konten untuk CapacityReservationId dan InstanceType dengan nilai untuk Blok Kapasitas Anda. Untuk informasi selengkapnya tentang bidang template peluncuran EC2 tambahan, lihat Sesuaikan node terkelola dengan templat peluncuran dan Gunakan Blok Kapasitas untuk beban kerja pembelajaran mesin.

    Ganti konten untukIamInstanceProfile,ImageId, SecurityGroupIdsUserData,, KeyName dengan nilai untuk lingkungan Anda.

    { "LaunchTemplateData": { "InstanceMarketOptions": { "MarketType": "capacity-block" }, "CapacityReservationSpecification": { "CapacityReservationTarget": { "CapacityReservationId": "cr-0123456789abcdef0" } }, "IamInstanceProfile": { "Arn": "arn:aws: iam::111122223333:role/myNodeRole" }, "ImageId": "image-id", "InstanceType": "p5.48xlarge", "KeyName": "key-name", "SecurityGroupIds": "sg-05b1d815d1EXAMPLE" ], "UserData": "user-data" } }
  2. Buat templat peluncuran .

    aws ec2 create-launch-template \ --launch-template-name EKS-Capacity-Block-Launch-Template \ --launch-template-data file://eks-capacity-block-lt.json
  3. Gunakan template peluncuran untuk membuat Grup Auto Scaling mengikuti langkah-langkahnya. Buat node Amazon Linux yang dikelola sendiri Jika reservasi belum aktif, setel DesiredCapacity ke0. Hanya tentukan subnet di Availability Zone tempat kapasitas dicadangkan.

  4. Setelah node yang dikelola sendiri dibuat dengan DesiredCapacity set to0, buat kebijakan penskalaan terjadwal pada grup Auto Scaling yang disejajarkan dengan waktu reservasi Blok Kapasitas. Untuk informasi selengkapnya, lihat Penskalaan Terjadwal untuk Amazon EC2 Auto Scaling.

    Anda dapat menggunakan instans yang dipesan hingga 30 menit sebelum waktu akhir reservasi. Jadwalkan skala ke nol lebih dari 30 menit sebelum waktu berakhir sehingga Pod memiliki waktu untuk menguras.

    Jika Anda lebih suka menskalakan secara manual, perbarui kapasitas yang diinginkan ASG pada waktu mulai reservasi dan lagi lebih dari 30 menit sebelum waktu berakhir.

  5. Untuk menguras Pod dengan baik, siapkan AWS Node Termination Handler. Ini mengawasi peristiwa siklus hidup scale-in ASG dari Amazon EC2 Auto Scaling EventBridge menggunakan dan memungkinkan bidang kontrol Kubernetes bertindak sebelum instance menjadi tidak tersedia. Tanpa itu, objek Pod dan Kubernetes bisa macet dalam keadaan tertunda. Untuk informasi selengkapnya, lihat AWS Node Termination Handler di GitHub.

    Jika Anda tidak mengatur Node Termination Handler, tiriskan Pod secara manual sebelum jendela 30 menit sehingga mereka memiliki waktu untuk terkuras dengan baik.