**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS 自動モードl クラスターでワークロードを実行する
この章では自動モードl で実行されている アマゾン EKS クラスターにさまざまなタイプのワークロードをデプロイする方法の例を示します。この例ではサンプルアプリケーション、ロードバランシングされたウェブアプリケーション、永続的ストレージを使用するステートフルワークロード、特定のノード配置要件があるワークロードなどの主要なワークロードパターンを示しています。各例には独自のアプリケーションのテンプレートとして使用できる、完全なマニフェストとステップバイステップのデプロイステップが含まれています。
例に進む前に、EKS クラスターが 自動モードl で実行され、AWS CLI と kubectl がインストールされた状態にしてください。詳細については「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。この例ではKubernetes の概念と kubectl コマンドに関する基本的な知識があることを前提としています。
これらのユースケースベースのサンプルを使用して、EKS 自動モードl クラスターでワークロードを実行できます。
[Amazon EKS Auto Mode クラスターにサンプルの拡張ワークロードをデプロイする](automode-workload.md)
`kubectl` コマンドを使用してサンプルワークロードを EKS 自動モードl クラスターにデプロイする方法を示しています。
[サンプルロードバランサーワークロードを EKS 自動モードl にデプロイする](auto-elb-example.md)
アマゾン EKS で 2048 ゲームのコンテナ化されたバージョンをデプロイする方法を示しています。
[ステートフルワークロードのサンプルを EKS Auto Mode にデプロイする](sample-storage-workload.md)
サンプルステートフルアプリケーションを EKS 自動モードl クラスターにデプロイする方法を示しています。
[加速ワークロードをデプロイする](auto-accelerated.md)
EKS 自動モードで管理されるノードにハードウェアアクセラレーションワークロードをデプロイする方法を示します。
[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)
注釈を使用して、EKS 自動モードl によって管理されるノードにワークロードがデプロイされるかどうかを制御する方法を示しています。
# Amazon EKS Auto Mode クラスターにサンプルの拡張ワークロードをデプロイする
このチュートリアルでは、サンプルワークロードを EKS Auto Mode クラスターにデプロイする方法と、必要なコンピューティングリソースがどのように自動的にプロビジョニングされるか説明します。`kubectl` コマンドを使用してクラスターの動作を監視し、Auto Mode により AWS での Kubernetes オペレーションがどのように簡素化されるかを直接確認します。このチュートリアルを終了すると、基盤となるコンピューティングリソースを自動的に管理することで、ノードグループを手動で設定する必要なく、EKS Auto Mode がワークロードのデプロイにどのように対応するかがわかります。
## 前提条件
+ Amazon EKS Auto Mode クラスター。クラスターの名前と AWS リージョンをメモします。
+ ネットワーキング、コンピューティング、および EKS リソースを管理するのに十分なアクセス許可を持つ、ユーザーやロールなどの IAM プリンシパル。
+ 詳細については、「IAM ユーザーガイド」の「[Creating roles and attaching policies in the IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)」を参照してください。
+ IAM ID で `aws` CLI がインストールおよび設定されている。
+ `kubectl` CLI がインストールされ、クラスターに接続されている。
+ 詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
## ステップ 1: 既存のコンピューティングリソースを確認する (任意)
まず、`kubectl` を使用してクラスターのノードプールを一覧表示します。
```
kubectl get nodepools
```
サンプル出力:
```
general-purpose
```
このチュートリアルでは、`general-purpose` ノードプールを使用するように設定されたワークロードをデプロイします。このノードプールは EKS Auto Mode に組み込まれ、マイクロサービスやウェブアプリケーションなどの一般的なワークロードに適したデフォルトが含まれます。独自のノードプールを作成できます。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
次に、`kubectl` を使用してクラスターに接続されているノードを一覧表示します。
```
kubectl get nodes
```
EKS Auto Mode クラスターを作成したばかりの場合は、ノードはありません。
このチュートリアルでは、サンプルワークロードをデプロイします。ノードがない場合、またはワークロードが既存のノードに収まらない場合、EKS Auto Mode は新しいノードをプロビジョニングします。
## ステップ 2: サンプルアプリケーションをクラスターにデプロイする
次の Kubernetes デプロイを確認し、`inflate.yaml` として保存します
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
`eks.amazonaws.com/compute-type: auto` セレクターでは、ワークロードを Amazon EKS Auto Mode ノードにデプロイする必要があることに注意してください。
デプロイをクラスターに適用します。
```
kubectl apply -f inflate.yaml
```
## ステップ 3: Kubernetes イベントを監視する
次のコマンドを使用して、新しいノードの作成などの Kubernetes イベントを監視します。`ctrl+c` を使用してイベントの監視を停止します。
```
kubectl get events -w --sort-by '.lastTimestamp'
```
`kubectl` を使用して、クラスターに接続されているノードを再度一覧表示します。新しく作成されたノードをメモします。
```
kubectl get nodes
```
## ステップ 4: AWS コンソールでノードとインスタンスを表示する
EKS Auto Mode ノードは EKS コンソールで表示でき、関連付けられた EC2 インスタンスは EC2 コンソールで表示できます。
EKS Auto Mode によってデプロイされた EC2 インスタンスは制限されています。EKS Auto Mode ノードで任意のコマンドを実行することはできません。
## ステップ 5: デプロイを削除する
`kubectl` を使用してサンプルデプロイを削除します
```
kubectl delete -f inflate.yaml
```
クラスターに他のワークロードがデプロイされていない場合、EKS Auto Mode によって作成されたノードは空になります。
デフォルト設定では、EKS Auto Mode は空のノードを 30 秒間検出し、そのノードを終了します。
`kubectl` または EC2 コンソールを使用して、関連付けられたインスタンスが削除されたことを確認します。
# サンプルロードバランサーワークロードを EKS 自動モードl にデプロイする
このガイドではロードバランシングとインターネットアクセシビリティを備えて、コンテナ化されたバージョンの 2048 ゲームを Amazon EKS にデプロイする方法について説明します。
## 前提条件
+ EKS 自動モードl クラスター
+ クラスターとやり取りするように設定された `kubectl`
+ ALB リソースを作成するための適切な IAM アクセス許可
## ステップ 1: 名前空間を作成する
まず、2048 ゲームアプリケーション専用の名前空間を作成します。
`01-namespace.yaml` という名前のファイルを作成します：
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
この名前空間設定を適用します：
```
kubectl apply -f 01-namespace.yaml
```
## ステップ 2: アプリケーションをデプロイする
アプリケーションは 2048 ゲームコンテナの複数のレプリカを実行してください。
`02-deployment.yaml` という名前のファイルを作成します：
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**注記**
イメージ `public.ecr.aws/l6m2t8p7/docker-2048:latest` のロード中にエラーが表示された場合は、ノード IAM ロールに ECR からイメージをプルするための十分なアクセス許可があることを確認します。詳細については、「[ノード の IAM ロール](auto-learn-iam.md#auto-learn-node-iam-role)」を参照してください。また、この例の `docker-2048` イメージは `x86_64` イメージであり、他のアーキテクチャでは実行できません。
**主要コンポーネント:**
+ アプリケーションのレプリカ 5 つをデプロイ
+ パブリック ECR イメージを使用
+ ポッドあたり 0.5 CPU コアをリクエスト
+ HTTP トラフィック用にポート 80 を公開
デプロイを適用します：
```
kubectl apply -f 02-deployment.yaml
```
## ステップ 3: サービスを作成する
サービスによりデプロイがクラスターネットワークに公開されます。
`03-service.yaml` という名前のファイルを作成します：
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**主要コンポーネント:**
+ NodePort サービスを作成
+ ポート 80 をコンテナのポート 80 にマップ
+ ラベルセレクターを使用してポッドを検索
サービスを適用します：
```
kubectl apply -f 03-service.yaml
```
## ステップ 4: ロードバランシングを設定する
アプリケーションがインターネットに公開されるようにイングレスを設定します。
まず `IngressClass` を作成します。`04-ingressclass.yaml` という名前のファイルを作成します：
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**注記**
EKS Auto Mode では、パブリックサブネットとプライベートサブネットを識別するためにサブネットタグが必要です。
`eksctl` を使用してクラスターを作成した場合は、これらのタグは既にあります。
「[EKS Auto Mode のサブネットにタグを付ける](tag-subnets-auto.md)」ではその方法を説明しています。
次に、イングレスリソースを作成します。`05-ingress.yaml` という名前のファイルを作成します：
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**主要コンポーネント:**
+ インターネット向け ALB を作成
+ 直接ポッドルーティングに IP ターゲットタイプを使用
+ すべてのトラフィックをルーティングまたはゲームサービスにルーティング
イングレス設定を適用します：
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## ステップ 5: デプロイを検証する
1. すべてのポッドが実行されていることを確認します：
```
kubectl get pods -n game-2048
```
1. サービスが作成されていることを確認します：
```
kubectl get svc -n game-2048
```
1. ALB エンドポイントを取得します：
```
kubectl get ingress -n game-2048
```
イングレス出力の ADDRESS フィールドに ALB エンドポイントが表示されます。ALB がすべてのターゲットをプロビジョニングして登録するまで 2～3 分待ちます。
## ステップ 6: ゲームにアクセスする
ウェブブラウザを開き、前のステップの ALB エンドポイント URL にアクセスします。2048 ゲームインターフェイスが表示されるはずです。
## ステップ 7: クリーンアップ
このチュートリアルで作成したリソースをすべて削除するには:
```
kubectl delete namespace game-2048
```
これにより、デプロイ、サービス、イングレスリソースなど、名前空間内のすべてのリソースが削除されます。
## シーンの背後で起こっていること
1. デプロイでは2048 ゲームを実行するポッドが 5 つ作成されます
1. このサービスではこれらのポッドに安定したネットワークアクセスを提供します
1. EKS 自動モードl:
+ AWS で Application Load Balancer を作成します
+ ポッドのターゲットグループを設定します
+ サービスにトラフィックを誘導するルーティングルールを設定します
## トラブルシューティング
ゲームがロードされない場合:
+ すべてのポッドが実行されていることを確認: `kubectl get pods -n game-2048`
+ イングレスステータスの確認: `kubectl describe ingress -n game-2048`
+ ALB ヘルスチェックの検証: AWS コンソールでターゲットグループのヘルスを確認します
# ステートフルワークロードのサンプルを EKS Auto Mode にデプロイする
このチュートリアルでは、EKS Auto Mode クラスターにステートフルアプリケーションのサンプルをデプロイする方法について説明します。このアプリケーションは永続ボリュームにタイムスタンプを書き込み、EBS Auto Mode の自動 EBS ボリュームプロビジョニングと永続化機能を示します。
## 前提条件
+ EKS Auto Mode クラスター
+ 適切なアクセス許可で設定された AWS CLI
+ インストールおよび設定済みの `kubectl`
+ 詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
## ステップ 1: 環境を設定する
1. 環境変数を設定する:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. kubeconfig を更新します:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## ステップ 2: ストレージクラスを作成する
`StorageClass`は、EBS ボリュームを EKS Auto Mode でプロビジョニングする方法を定義します。
EKS Auto Mode では、お客様用の `StorageClass` は作成されません。EKS Auto Mode のストレージ機能を使用するには、`ebs.csi.eks.amazonaws.com` を参照する `StorageClass` を作成する必要があります。
1. `storage-class.yaml` という名前のファイルを作成します：
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. `StorageClass` を適用します。
```
kubectl apply -f storage-class.yaml
```
**主要コンポーネント:**
+ `provisioner: ebs.csi.eks.amazonaws.com` - EKS Auto Mode を使用する
+ `volumeBindingMode: WaitForFirstConsumer` - ポッドが必要とするまでボリュームの作成を遅らせる
+ `type: gp3` - EBS ボリュームタイプを指定する
+ `encrypted: "true"` - EBS はデフォルトの `aws/ebs` キーを使用して、このクラスで作成されたボリュームを暗号化します。これはオプションですが推奨されます。
+ `storageclass.kubernetes.io/is-default-class: "true"` - 永続ボリュームのクレームで別のボリュームクラスを指定しない限り、Kubernetes はデフォルトでこのストレージクラスを使用します。別のストレージコントローラーから移行する場合は、この値を設定するときに注意してください 。(オプション)
## ステップ3: 永続的なボリューム要求を作成する
PVC は`StorageClass`からのストレージをリクエストします。
1. `pvc.yaml` という名前のファイルを作成します：
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. SCP を適用します:
```
kubectl apply -f pvc.yaml
```
**主要コンポーネント:**
+ `accessModes: ReadWriteOnce` - ボリュームは一度に 1 つのノードからマウントすることができます
+ `storage: 8Gi` - 8 GiB ボリュームをリクエストします
+ `storageClassName: auto-ebs-sc` - 作成した`StorageClass`を参照します
## ステップ 4: アプリケーションのデプロイ
Deployment は、永続的ボリュームにタイムスタンプを書き込むコンテナを実行します。
1. `deployment.yaml` という名前のファイルを作成します：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. デプロイを適用します。
```
kubectl apply -f deployment.yaml
```
**主要コンポーネント:**
+ ファイルにタイムスタンプを書き込むシンプルな bash コンテナ
+ PVC を `/data` にマウントします
+ 1 CPU コアをリクエストします
+ EKS マネージドノードのノードセレクタを使用します
## ステップ 5: セットアップを検証する
1. ポッドが稼働していることを確認します:
```
kubectl get pods -l app=inflate-stateful
```
1. PVC がバインドされていることを確認します:
```
kubectl get pvc auto-ebs-claim
```
1. EBS ボリュームを確認します:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. データが書き込まれていることを確認します:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## ステップ 6: クリーンアップ
次のコマンドを実行して、このチュートリアルで作成したすべてのリソースを削除します。
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## シーンの背後で起こっていること
1. PVC は`StorageClass`からのストレージをリクエストします
1. ポッドがスケジュールされている場合:
1. EKS Auto Mode が EBS ボリュームをプロビジョニングします
1. PersistentVolume を作成します
1. ボリュームをノードにアタッチします。
1. ポッドはボリュームをマウントし、タイムスタンプの書き込みを開始します
## Snapshot Controller
EKS Auto Mode は、スナップショットコントローラーとも呼ばれる Kubernetes CSI Snapshotter と互換性があります。ただし、EKS Auto Mode にはスナップショットコントローラーがありません。スナップショットコントローラーのインストールと設定はお客様の責任となります。詳細については、「[CSI ボリュームのためにスナップショット機能を有効にする](csi-snapshot-controller.md)」を参照してください。
EKS Auto Mode のストレージ機能を参照する以下の `VolumeSnapshotClass` を確認してください。
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Kubernetes CSI Snapshotter の詳細をご覧ください。](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 加速ワークロードをデプロイする
このチュートリアルでは、Amazon EKS 自動モードがハードウェアアクセラレーションワークロードの開始をどのようにシンプルにしているかを説明します。Amazon EKS Auto Mode は、コンピューティング、ネットワーキング、ロードバランシング、ストレージ、Identity Access and Management の各機能を追加の設定なしで実現する主要なインフラストラクチャコンポーネントを自動化することで、クラスター自体にとどまらずさまざまな運用を簡素化します。
Amazon EKS Auto Mode には、NVIDIA ドライバーや AWS Neuron ドライバーなど、特定のインスタンスタイプに必要なドライバーとデバイスプラグインが含まれています。これらのコンポーネントをお客様側でインストールおよび更新する必要はありません。
EKS Auto Mode が次のアクセラレーター用のドライバーを自動的に管理します。
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [NVIDIA GPUs on Amazon EC2 加速インスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**注記**
EKS Auto Mode には、Kubernetes 用の NVIDIA デバイスプラグインが含まれています。このプラグインは、自動的に動作し、クラスターにデーモンセットとして表示されません。
ネットワーキングに関するその他のサポート:
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
Amazon EKS Auto Mode により、アクセラレーター用のドライバーとデバイスプラグインを管理するという手間が不要になります。
また、クラスターがゼロにスケーリングされるので、コスト削減というメリットも得られます。実行中のワークロードがなくなったらインスタンスを終了するように、EKS Auto Mode を設定できます。これはバッチベースの推論ワークロードに便利です。
以下に、Amazon EKS Auto Mode で加速ワークロードを開始する方法の例を示します。
## 前提条件
+ Amazon EKS Auto Mode で Kubernetes クラスターが設定されていること。
+ `general-purpose` または `system` のいずれかのマネージドノードプールが有効であれば、`default` EKS ノードクラスが作成されること。
## ステップ 1: GPU ワークロードをデプロイする
この例では、45 GB の GPU メモリを必要とする NVIDIA ベースのワークロード用に NodePool を作成します。EKS Auto Mode では、Kubernetes スケジュール制約を使用して、インスタンス要件を定義します。
Amazon EKS Auto Mode `NodePool` とサンプルの `workload` をデプロイするには、NodePool とポッドに関する以下の定義を確認し、`nodepool-gpu.yaml` および `pod.yaml` として保存します。
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
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:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
`eks.amazonaws.com/compute-type: auto` セレクターでは、ワークロードを Amazon EKS Auto Mode ノードにデプロイする必要があることに注意してください。また、NodePool は Nvidia GPU に対する許容範囲が設定されたポッドに限りスケジュールできるというテイントを設定します。
NodePool とワークロードをクラスターに適用します。
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
以下の出力が表示されます。
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
数秒待ってからクラスター内のノードを確認します。これで、新しいノードが Amazon EKS Auto Mode クラスターにプロビジョニングされるはずです。
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## ステップ 2: 検証する
Amazon EKS Auto Mode が以下の Kubernetes スケジュール制約に従って、l40s `GPU` 搭載のインスタンスを必要とするワークロードとして `g6.2xlarge` ではなく `g6e.2xlarge` を開始したことを確認できます。
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
次のコマンドを実行して、コンテナのログを参照します。
```
kubectl logs nvidia-smi
```
サンプル出力:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
出力を見ると、コンテナは `NVIDIA` GPU 搭載のインスタンスで実行されていること、デバイスドライバーは Amazon EKS Auto Mode によって管理されるためインストールする必要がなかったことを確認できます。
## ステップ 3: クリーンアップする
作成されたすべてのオブジェクトを削除するには、`kubectl` を使用してサンプルのデプロイと NodePool を削除します。これでノードが終了します。
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## NodePool 参照の例
### NVIDIA NodePool を作成する
NodePool で定義する内容は次のとおりです。
+ `g6e` と `g6` ファミリーのインスタンスを開始するのみ
+ 1 時間が過ぎても空のままであればノードを統合する
+ `consolodateAfter` が 1 時間というのは、ワークロードの急増に対応し、ノードのチャーンを抑制するのに十分な値です。`consolidateAfter` はワークロード要件に基づいて調整できます。
**NodePool を GPU インスタンスファミリーおよび統合で使用する例**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
`eks.amazonaws.com/instance-gpu-name` を設定するのではなく、`eks.amazonaws.com/instance-family` を使用してインスタンスファミリーを指定することもできます。この他にスケジュールのレビューに影響を与えるラベルとしてよく知られたものについては、「[EKS Auto Mode でサポートされているラベル](create-node-pool.md#auto-supported-labels)」を参照してください。
固有のストレージ要件がある場合は、NodePool で参照する [NodeClass](create-node-class.md) を独自に作成することで、ノードのエフェメラルストレージの `iops`、`size`、`throughput` を調整できます。[設定可能な NodeClass オプション](create-node-class.md)について確認してください。
**NodeClass 用にストレージを設定する例**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### AWS Trainium と AWS Inferentia の NodePool を定義する
以下の NodePool では、Inferentia と Trainium ファミリーのインスタンスを開始するだけという `eks.amazonaws.com/instance-category` 設定を定義しています。
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```