

 **Bantu meningkatkan 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 GitHub ** tautan ** Edit halaman ini di 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
<a name="auto-odcr"></a>

Anda dapat mengontrol penyebaran beban kerja ke Reservasi [Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). EKS Auto Mode mendukung EC2 On-Demand Capacity Reservations (ODCR), EC2 Capacity Blocks for ML, dan Interruptible Capacity Reservations (IODCR).

**Tip**  
Secara default, Mode Otomatis EKS dapat diluncurkan ke ODCR terbuka melalui pencocokan terbuka, tetapi tidak memprioritaskannya. Instans yang diluncurkan melalui pencocokan terbuka diberi label`karpenter.sh/capacity-type: on-demand`, bukan. `reserved` Untuk memprioritaskan penggunaan ODCR dan memiliki instance berlabel`karpenter.sh/capacity-type: reserved`, konfigurasikan dalam definisi. `capacityReservationSelectorTerms` NodeClass Blok Kapasitas untuk ML selalu membutuhkan `capacityReservationSelectorTerms` dan tidak digunakan secara otomatis.

## Reservasi On-Demand Kapasitas EC2 (ODCR)
<a name="_ec2_on_demand_capacity_reservations_odcrs"></a>

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.

**Awas**  
Jika Anda mengonfigurasi `capacityReservationSelectorTerms` di NodeClass dalam cluster, Mode Otomatis EKS tidak akan lagi secara otomatis menggunakan ODCR terbuka untuk *salah satu* NodeClass di cluster.

### Contoh NodeClass
<a name="_example_nodeclass"></a>

```
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
<a name="_scheduling_labels_for_capacity_reservations"></a>

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 | Contoh | Deskripsi | 
| --- | --- | --- | 
|  `eks.amazonaws.com/capacity-reservation-id`  |  `cr-56fac701cc1951b03`  | ID reservasi kapasitas | 
|  `eks.amazonaws.com/capacity-reservation-type`  |  `default` atau `capacity-block`  | Jenis reservasi kapasitas | 
|  `eks.amazonaws.com/capacity-reservation-interruptible`  |  `true` atau `false`  | Apakah reservasi kapasitas dapat diinterupsi | 

Label ini hanya ada pada node dengan`karpenter.sh/capacity-type: reserved`.

## Reservasi Kapasitas Interruptible (IODCR)
<a name="_interruptible_capacity_reservations_iodcrs"></a>

 [Reservasi Kapasitas Interruptible memungkinkan Anda untuk berbagi kapasitas Reservasi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interruptible-capacity-reservations.html) 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
<a name="_ec2_capacity_blocks_for_ml"></a>

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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) 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:

1. A NodeClass yang mereferensikan reservasi Blok Kapasitas Anda

1. A NodePool yang menggunakan NodeClass dan menerapkan noda

1. Spesifikasi Pod yang mentolerir taint dan meminta sumber daya GPU

### Contoh NodeClass
<a name="_example_nodeclass_2"></a>

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](create-node-class.md).

### Contoh NodePool
<a name="_example_nodepool"></a>

Ini NodePool mereferensikan `gpu` NodeClass dan menentukan konfigurasi penting:
+ Ini **hanya** menggunakan kapasitas cadangan dengan pengaturan `karpenter.sh/capacity-type: reserved` 
+ Ini meminta keluarga instance GPU tertentu yang sesuai untuk beban kerja ML
+ Ini menerapkan `nvidia.com/gpu` noda untuk memastikan hanya beban kerja GPU yang dijadwalkan pada node ini

```
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](create-node-pool.md).

### Contoh Pod
<a name="_example_pod"></a>

Contoh pod ini menunjukkan cara mengonfigurasi beban kerja untuk dijalankan pada node Blok Kapasitas Anda:
+ Ini menggunakan **NodeSelector** untuk menargetkan jenis GPU tertentu (dalam hal ini, GPU H200)
+ Ini termasuk **toleransi** untuk `nvidia.com/gpu` noda yang diterapkan oleh NodePool
+ Ini secara eksplisit **meminta sumber daya GPU menggunakan tipe sumber daya** `nvidia.com/gpu`

```
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](https://kubernetes.io/docs/concepts/workloads/pods/) dalam dokumentasi Kubernetes.

### Sumber Daya Terkait
<a name="_related_resources"></a>
+  [Blok Kapasitas untuk ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) di Panduan Pengguna Amazon EC2
+  [Temukan dan beli Blok Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) di Panduan Pengguna Amazon EC2
+  [Reservasi Kapasitas yang Dapat Diputus](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interruptible-capacity-reservations.html) di Panduan Pengguna Amazon EC2
+  [Mengelola sumber daya komputasi untuk AI/ML beban kerja di Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html) 
+  [Optimalisasi Sumber Daya GPU dan Manajemen Biaya](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) dalam Panduan Praktik Terbaik EKS