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.

Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS

Anda dapat mengontrol penyebaran beban kerja ke Reservasi Kapasitas. EKS Auto Mode mendukung EC2 On-Demand Capacity Reservations (ODCR), EC2 Capacity Blocks for ML, dan Interruptible Capacity Reservations (IODCR).

Reservasi On-Demand Kapasitas EC2 (ODCR)

Reservasi On-Demand Kapasitas EC2 (ODCR) memungkinkan Anda memesan kapasitas komputasi untuk instans Amazon EC2 di Availability Zone tertentu untuk durasi berapa pun. Saat menggunakan Mode Otomatis EKS, Anda mungkin ingin mengontrol apakah beban kerja Kubernetes Anda diterapkan ke instans cadangan ini untuk memaksimalkan pemanfaatan kapasitas yang telah dibeli sebelumnya atau untuk memastikan beban kerja kritis memiliki akses ke sumber daya yang terjamin.

Secara default, Mode Otomatis EKS secara otomatis diluncurkan ke ODCR terbuka. Namun, dengan mengonfigurasi capacityReservationSelectorTerms pada a NodeClass, Anda dapat secara eksplisit mengontrol ODCR mana yang digunakan beban kerja Anda. Node yang disediakan menggunakan ODCR yang dikonfigurasi akan memiliki karpenter.sh/capacity-type: reserved dan akan diprioritaskan daripada on-demand dan spot. Setelah fitur ini diaktifkan, Mode Otomatis EKS tidak akan lagi secara otomatis menggunakan ODCR terbuka—mereka harus dipilih secara eksplisit oleh a NodeClass, memberi Anda kontrol yang tepat atas penggunaan reservasi kapasitas di seluruh klaster Anda.

Contoh NodeClass

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
  # Optional: Selects upon on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        app: "my-app"
      # Optional owning account ID filter
      owner: "012345678901"

Contoh ini NodeClass menunjukkan dua pendekatan untuk memilih ODCR. Metode pertama secara langsung mereferensikan ODCR tertentu dengan ID ()cr-56fac701cc1951b03. Metode kedua menggunakan pemilihan berbasis tag, menargetkan ODCR dengan tag. Name: "targeted-odcr" Anda juga dapat memfilter secara opsional berdasarkan AWS akun yang memiliki reservasi, yang sangat berguna dalam skenario lintas akun atau saat bekerja dengan reservasi kapasitas bersama.

Label penjadwalan untuk Reservasi Kapasitas

Saat Anda mengonfigurasi capacityReservationSelectorTerms pada sebuah NodeClass, node yang disediakan dari reservasi kapasitas diberi label dengan label penjadwalan tambahan. Anda dapat menggunakan label ini sebagai NodePool persyaratan atau batasan penjadwalan pod (seperti afinitas node) untuk mengontrol penempatan beban kerja.

Label ini hanya ada pada node dengankarpenter.sh/capacity-type: reserved.

Reservasi Kapasitas Interruptible (IODCR)

Reservasi Kapasitas Interruptible memungkinkan Anda untuk berbagi kapasitas Reservasi On-Demand Kapasitas yang tidak terpakai dengan beban kerja lain dalam organisasi Anda. Dengan menggunakan kembali kapasitas yang tidak terpakai sebagai ODCR yang dapat diinterupsi, beban kerja yang cocok untuk operasi yang fleksibel dan toleran terhadap kesalahan, seperti pemrosesan batch dan analisis data, dapat memperoleh manfaat dari kapasitas yang tersedia sementara. Pemilik reservasi dapat mengklaim kembali kapasitasnya kapan saja, sementara konsumen ODCR yang dapat terputus akan menerima pemberitahuan gangguan sebelum penghentian untuk memungkinkan penutupan atau pos pemeriksaan yang anggun sebelum node dihentikan.

Anda memilih reservasi kapasitas interruptible menggunakan cara yang sama seperti capacityReservationSelectorTerms yang Anda lakukan pada ODCR standar—berdasarkan ID atau tag. Untuk mengontrol apakah beban kerja dijadwalkan pada kapasitas cadangan interruptible versus non-interruptible, gunakan label penjadwalan. eks.amazonaws.com/capacity-reservation-interruptible

Ketika kapasitas direklamasi, instans yang sedang berjalan menerima peringatan interupsi 2 menit melalui acara. EventBridge Setelah periode pemberitahuan, instance yang berjalan dalam kapasitas reklamasi memasuki status shutting down dan dihentikan. Mode Otomatis EKS akan secara otomatis mulai menguras node yang diluncurkan dari reservasi kapasitas yang dapat terputus saat peringatan interupsi 2 menit diterima, memungkinkan beban kerja Anda dihentikan dengan baik sebelum node direklamasi.

Blok Kapasitas EC2 untuk ML

Blok Kapasitas untuk MS mencadangkan instans komputasi yang GPU-based dipercepat di masa mendatang untuk mendukung beban kerja machine learning (ML) berdurasi pendek Anda. Instans yang berjalan di dalam Blok Kapasitas secara otomatis ditempatkan berdekatan di dalam Amazon UltraClusters EC2, untuk jaringan latensi rendah, skala petabit, dan non-pemblokiran.

Untuk informasi selengkapnya tentang platform dan jenis instans yang didukung, lihat Blok Kapasitas untuk ML di Panduan Pengguna EC2.

Anda dapat membuat Mode Otomatis EKS NodeClass yang menggunakan Blok Kapasitas untuk ML, mirip dengan ODCR (dijelaskan sebelumnya).

Contoh definisi berikut membuat tiga sumber daya:

Contoh NodeClass

Ini NodeClass mereferensikan Blok Kapasitas tertentu untuk ML dengan ID reservasi. Anda dapat memperoleh ID ini dari konsol EC2.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: gpu
spec:
  # Specify your Capacity Block reservation ID
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03

Untuk informasi selengkapnya, lihat Buat Kelas Node untuk Amazon EKS.

Contoh NodePool

Ini NodePool mereferensikan gpu NodeClass dan menentukan konfigurasi penting:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: gpu
      requirements:
        - key: eks.amazonaws.com/instance-family
          operator: In
          values:
            - g6
            - p4d
            - p4de
            - p5
            - p5e
            - p5en
            - p6
            - p6-b200
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - reserved
            # Enable other capacity types
            # - on-demand
            # - spot
      taints:
        - effect: NoSchedule
          key: nvidia.com/gpu

Untuk informasi selengkapnya, lihat Membuat Kumpulan Simpul untuk Mode Otomatis EKS.

Contoh Pod

Contoh pod ini menunjukkan cara mengonfigurasi beban kerja untuk dijalankan pada node Blok Kapasitas Anda:

apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  nodeSelector:
    # Select specific GPU type - uncomment as needed
    # eks.amazonaws.com/instance-gpu-name: l4
    # eks.amazonaws.com/instance-gpu-name: a100
    eks.amazonaws.com/instance-gpu-name: h200
    # eks.amazonaws.com/instance-gpu-name: b200
    eks.amazonaws.com/compute-type: auto
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
    args:
    - "nvidia-smi"
    resources:
      requests:
        # Uncomment if needed
        # memory: "30Gi"
        # cpu: "3500m"
        nvidia.com/gpu: 1
      limits:
        # Uncomment if needed
        # memory: "30Gi"
        nvidia.com/gpu: 1
  tolerations:
  - key: nvidia.com/gpu
    effect: NoSchedule
    operator: Exists

Untuk informasi selengkapnya, lihat Pods dalam dokumentasi Kubernetes.

Sumber Daya Terkait