**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する
[キャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)へのワークロードのデプロイを制御できます。EKS 自動モードは、EC2 On-Demand Capacity Reservations (ODCR) と EC2 Capacity Block for ML をサポートしています。
**ヒント**
デフォルトでは、EKS Auto Mode はオープンマッチングを通じてオープン ODCR に起動できますが、優先順位は付けられません。オープンマッチングによって起動されたインスタンスには、`reserved` ではなく `karpenter.sh/capacity-type: on-demand` というラベルが付けられます。ODCR の使用を優先し、インスタンスに `karpenter.sh/capacity-type: reserved` というラベルを付けるには、NodeClass 定義で `capacityReservationSelectorTerms` を設定します。Capacity Blocks for ML には、常に `capacityReservationSelectorTerms` が必要であり、自動的には使用されません。
## EC2 オンデマンドキャパシティ予約 (ODCR)
EC2 オンデマンドキャパシティ予約 (ODCR) を使用すると、任意の期間中に特定のアベイラビリティーゾーンで Amazon EC2 インスタンスのコンピューティングキャパシティを予約できます。EKS Auto Mode を使用するとき、Kubernetes ワークロードをこれらの予約されたインスタンスにデプロイするかどうかを制御し、事前購入された容量の使用率を最大化したり、重要なワークロードが保証されたリソースにアクセスできるようにしたりすることができます。
デフォルトでは、EKS Auto Mode は自動的にオープン ODCR として起動します。ただし、NodeClass で `capacityReservationSelectorTerms` を設定することで、ワークロードが使用する ODCR を明示的に制御できます。設定された ODCR を使用してプロビジョニングされたノードには `karpenter.sh/capacity-type: reserved` があり、オンデマンドおよびスポットよりも優先されます。この機能を有効にすると、EKS Auto Mode はオープン ODCR を自動的に使用しなくなります。NodeClass で明示的に選択する必要があり、クラスター全体のキャパシティ予約の使用状況を正確に制御できます。
**警告**
クラスター内の NodeClass で `capacityReservationSelectorTerms` を設定した場合、EKS Auto Mode はクラスター内の*すべて*の NodeClass に対してオープン ODCR を自動的に使用しなくなります。
### 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"
```
この NodeClass の例では、ODCR を選択するための 2 つのアプローチが示されています。1 番目の方法では、特定の ODCR が ID (`cr-56fac701cc1951b03`) で直接参照されます。2 番目の方法ではタグベースの選択を使用し、タグ `Name: "targeted-odcr"` で ODCR がターゲットされます。オプションとして、予約を所有する AWS アカウントでフィルタリングすることもできます。アカウント間シナリオや共有キャパシティ予約を使用する場合に特に便利です。
## EC2 Capacity Blocks for ML
Capacity Blocks for ML は、短期間の機械学習ワークロードをサポートするため、GPU ベースの高速コンピューティングインスタンスを将来の日付で予約します。キャパシティブロック内で実行されるインスタンスは、Amazon EC2 UltraClusters 内に自動的に互いに近く配置され、低レイテンシーでペタビットスケールのノンブロッキングネットワーキングを実現します。
サポートされているプラットフォームとインスタンスタイプの詳細については、「EC2 ユーザーガイド」の「[Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」を参照してください。
前述の ODCR と同じく、EKS 自動モードの NodeClass を作成し、その中で Capacity Block for ML を使用できます。
次のサンプル定義では、3 つのリソースを作成しています。
1. キャパシティブロック予約を参照する NodeClass
1. NodeClass を使用し、テイントを適用する NodePool
1. テイントを許容し、GPU リソースをリクエストするポッド仕様
### NodeClass の例
この NodeClass は、特定の Capacity Block for ML をその予約 ID で参照します。この ID は、EC2 コンソールから取得できます。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
### NodePool の例
この NodePool は、`gpu` NodeClass を参照し、以下の重要な設定を指定します。
+ `karpenter.sh/capacity-type: reserved` を設定してリザーブドキャパシティ**のみ**を使用します。
+ ML ワークロードに適した特定の GPU インスタンスファミリーをリクエストします。
+ `nvidia.com/gpu` テイントを適用して、これらのノードで GPU ワークロードのみがスケジュールされるようにします。
```
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
```
詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
### ポッドの例
この例に示したポッドは、キャパシティブロックノードで動作するようにワークロードを設定する方法を示しています。
+ **nodeSelector** を使用して、特定の GPU タイプ (この例では H200 GPU) をターゲットとしています。
+ NodePool で適用される `nvidia.com/gpu` テイントの**許容値**が含まれています。
+ `nvidia.com/gpu` リソースタイプを使用して明示的に **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
```
詳細については、Kubernetes ドキュメントの「[ポッド](https://kubernetes.io/docs/concepts/workloads/pods/)」を参照してください。
### 関連リソース
+ 「Amazon EC2 ユーザーガイド」の「[Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」
+ 「Amazon EC2 ユーザーガイド」の「[キャパシティブロックの検索と購入](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html)」
+ [Amazon EKS で AI/ML ワークロードのコンピューティングリソースを管理する](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ 「EKS ベストプラクティスガイド」の「[GPU リソースの最適化とコスト管理](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management)」