**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在 EKS 自動模式叢集中執行範例工作負載
本章節提供如何將不同類型的工作負載部署到在自動模式下執行的 Amazon EKS 叢集的範例。這些範例展示了關鍵的工作負載模式，包括範例應用程式、負載平衡的 Web 應用程式、使用持久性儲存的具狀態工作負載，以及具有特定節點放置要求的工作負載。每個範例都包含完整的資訊清單和逐步部署說明，您可以將其用作自己應用程式的範本。
繼續進行範例之前，請確定您已在自動模式下執行 EKS 叢集，且已安裝 AWS CLI 和 kubectl。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。這些範例假設您基本熟悉 Kubernetes 概念與 kubectl 命令。
您可以使用這些基於使用案例的範例在 EKS 自動模式叢集中執行工作負載。
[在 Amazon EKS 自動模式叢集中部署範例 inflate 工作負載](automode-workload.md)
展示如何使用 `kubectl` 命令將範例工作負載部署到 EKS 自動模式叢集。
[將範例負載平衡器工作負載部署至 EKS 自動模式](auto-elb-example.md)
展示如何在 Amazon EKS 上部署容器化版本的 2048 遊戲。
[部署具狀態工作負載範例至 EKS 自動模式](sample-storage-workload.md)
展示如何將範例具狀態應用程式部署到 EKS 自動模式叢集。
[部署加速工作負載](auto-accelerated.md)
說明如何將硬體加速工作負載部署至 EKS Auto Mode 管理的節點。
[控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)
展示如何使用注釋來控制工作負載是否部署到由 EKS 自動模式管理的節點。
# 在 Amazon EKS 自動模式叢集中部署範例 inflate 工作負載
在本教學中，您將學習如何將範例工作負載部署至 EKS 自動模式叢集，並觀察其如何自動佈建所需的運算資源。您將使用 `kubectl` 命令來監看叢集的行為，並親自了解自動模式如何簡化 Kubernetes 操作 AWS。完成本教學後，您將了解 EKS 自動模式如何透過自動管理底層運算資源來回應工作負載部署，無需手動設定節點群組。
## 先決條件
+ 一個 Amazon EKS 自動模式叢集。請記下叢集的名稱和 AWS 區域。
+ 具備足夠許可的 IAM 主體，如使用者或角色，需能管理聯網、運算與 EKS 資源。
+ 若需詳細資訊，請參閱《IAM 使用者指南》中的[建立角色和附加政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)。
+ 已安裝 `aws` CLI 並以 IAM 身分進行設定。
+ 已安裝 `kubectl` CLI 並連接至叢集。
+ 如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
## 步驟 1：檢閱現有運算資源 (選用)
第一，使用 `kubectl` 列出叢集上的節點集區。
```
kubectl get nodepools
```
輸出範例：
```
general-purpose
```
在本教學中，我們將部署設定為使用 `general-purpose` 節點集區的工作負載。此節點集區內建於 EKS Auto Mode，包含適用於一般工作負載，如微服務和 Web 應用程式的合理預設值。您也可建立自己的節點集區。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
第二，使用 `kubectl` 列出連接到叢集的節點。
```
kubectl get nodes
```
若您剛建立 EKS 自動模式叢集，一開始不會有任何節點。
在本教學中，您將部署一個範例工作負載。若沒有節點，或現有節點無法容納工作負載，EKS 自動模式將會佈建新節點。
## 步驟 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 自動模式節點上。
將部署套用至叢集。
```
kubectl apply -f inflate.yaml
```
## 步驟 3：監看 Kubernetes 事件
使用下列命令以監看 Kubernetes 事件，包括建立新節點。使用 `ctrl+c` 以停止監看事件。
```
kubectl get events -w --sort-by '.lastTimestamp'
```
再次使用 `kubectl` 以列出連接到叢集的節點。請記下新建立的節點。
```
kubectl get nodes
```
## 步驟 4：在 AWS 主控台中檢視節點和執行個體
您可在 EKS 主控台中檢視 EKS 自動模式節點，並且在 EC2 主控台中檢視相關聯的 EC2 執行個體。
由 EKS 自動模式部署的 EC2 執行個體有存取限制。您將無法在 EKS 自動模式節點上執行任意命令。
## 步驟 5：刪除部署
使用 `kubectl` 刪除範例部署
```
kubectl delete -f inflate.yaml
```
若您沒有部署至叢集的其他工作負載，由 EKS 自動模式建立的節點將處於空閒狀態。
在預設組態中，EKS 自動模式會偵測到已空閒達 30 秒的節點，並終止這些節點。
使用 `kubectl` 或 EC2 主控台確認相關聯的執行個體已被刪除。
# 將範例負載平衡器工作負載部署至 EKS 自動模式
本指南將引導您在 Amazon EKS 上部署容器化版本的 2048 遊戲，並包含負載平衡和網際網路可存取性。
## 先決條件
+ EKS 自動模式叢集
+ `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 映像
+ 每個 Pod 請求 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
+ 使用標籤選擇器來尋找 Pod
套用服務：
```
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 自動模式需要子網路標籤來識別公有和私有子網路。
若您使用 `eksctl` 建立叢集，則您已具備這些標籤。
了解如何 [標記 EKS 自動模式的子網路](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 目標類型來進行直接 Pod 路由
+ 將所有流量 (/) 路由到遊戲服務
套用傳入組態：
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## 步驟 5：確認部署
1. 檢查所有 Pod 是否處於執行狀態：
```
kubectl get pods -n game-2048
```
1. 確認服務是否已建立：
```
kubectl get svc -n game-2048
```
1. 取得 ALB 端點：
```
kubectl get ingress -n game-2048
```
傳入輸出中的 ADDRESS 欄位將顯示您的 ALB 端點。等待 2-3 分鐘，讓 ALB 完成佈建並註冊所有目標。
## 步驟 6：存取遊戲
開啟網頁瀏覽器，瀏覽至先前步驟中取得的 ALB 端點 URL。您應會看到 2048 遊戲介面。
## 步驟 7：清除
要移除在本教學課程中建立的全部資源：
```
kubectl delete namespace game-2048
```
這將刪除命名空間中的所有資源，包括部署、服務和傳入資源。
## 幕後情況
1. 部署會建立 5 個執行 2048 遊戲的 Pod
1. 服務為這些 Pod 提供穩定的網路存取
1. EKS 自動模式：
+ 如何在 AWS 建立 Application Load Balancer
+ 為 Pod 設定目標群組
+ 設定路由規則，以將流量導向服務
## 故障診斷
如果遊戲無法載入：
+ 確保所有 Pod 均在執行：`kubectl get pods -n game-2048`
+ 檢查傳入狀態：`kubectl describe ingress -n game-2048`
+ 確認 ALB 運作狀態檢查：在 AWS 主控台中檢查目標群組的運作狀態
# 部署具狀態工作負載範例至 EKS 自動模式
這項教學課程將引導您部署具狀態範例應用程式至 EKS 自動模式叢集。應用程式可將時間戳記寫入持續性磁碟區，從而示範 EKS 自動模式的自動 EBS 磁碟區佈建與持續保留功能。
## 先決條件
+ EKS 自動模式叢集
+ 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` 定義 EKS 自動模式佈建 EBS 磁碟區的方式。
EKS 自動模式不會為您建立 `StorageClass`。您必須建立 `StorageClass` 參考 `ebs.csi.eks.amazonaws.com`，以使用 EKS 自動模式的儲存功能。
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 自動模式
+ `volumeBindingMode: WaitForFirstConsumer` - 延遲建立磁碟區，直至 Pod 需要磁碟區
+ `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. 套用 PVC：
```
kubectl apply -f pvc.yaml
```
**關鍵元件：**
+ `accessModes: ReadWriteOnce` - 磁碟區可一次由一個節點掛載
+ `storage: 8Gi` - 請求 8 GiB 磁碟區
+ `storageClassName: auto-ebs-sc` - 參考我們建立的 `StorageClass`
## 步驟 4：部署應用程式
部署將執行一個容器，這會將時間戳記寫入持續性磁碟區。
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 容器
+ 在 `/data` 掛載 PVC
+ 請求 1 個 CPU 核心
+ 針對 EKS 受管節點使用節點選擇器
## 步驟 5：驗證設定
1. 檢查 Pod 是否在執行中：
```
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. 排程 Pod 時：
1. EKS 自動模式可佈建 EBS 磁碟區
1. 建立 PersistentVolume
1. 連接磁碟區至節點
1. Pod 會掛載磁碟區及開始撰寫時間戳記
## 快照控制器
EKS 自動模式與 Kubernetes CSI 快照器相容，亦稱為快照控制器。然而，EKS 自動模式不包括快照控制器。您將負責安裝及設定快照控制器。如需詳細資訊，請參閱 [啟用 CSI 磁碟區的快照功能](csi-snapshot-controller.md)。
請檢閱下列參考 EKS 自動模式儲存功能的 `VolumeSnapshotClass`。
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[了解 Kubernetes CSI 快照器的相關詳細資訊。](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 部署加速工作負載
本教學課程示範 Amazon EKS Auto Mode 如何簡化硬體加速工作負載的啟動。Amazon EKS 自動模式不僅限於叢集本身，還透過自動化關鍵基礎結構元件來簡化操作，這些元件預設提供運算、聯網、負載平衡、儲存和身分存取管理功能。
Amazon EKS Auto Mode 包含特定執行個體類型所需的驅動程式和裝置外掛程式，例如 NVIDIA 和 AWS Neuron 驅動程式。您無需安裝或更新這些元件。
EKS 自動模式會自動管理這些加速器的驅動程式：
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [Amazon EC2 加速執行個體上的 NVIDIA GPU](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**注意**
EKS 自動模式包含 Kubernetes 專用 NVIDIA 裝置外掛程式。此外掛程式會自動執行，且在您的叢集中不會顯示為常駐程式集。
其他聯網支援：
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
Amazon EKS 自動模式消除了加速器驅動程式和裝置外掛程式管理的繁瑣工作。
您還可以透過將叢集縮減至零來節省成本。您可以設定 EKS 自動模式，在沒有工作負載執行時終止執行個體。這對基於批次的推斷工作負載很有用。
以下提供一個範例，說明如何使用 Amazon EKS 自動模式啟動加速工作負載。
## 先決條件
+ 一個已設定 Amazon EKS 自動模式的 Kubernetes 叢集。
+ 當啟用 `general-purpose` 或 `system` 受管節點集區時，所建立的預設 `default` EKS 節點類別。
## 步驟 1：部署 GPU 工作負載
在此範例中，您將為需要 45GB GPU 記憶體的 NVIDIA 基礎工作負載建立一個 NodePool。透過 EKS 自動模式，您可使用 Kubernetes 排程限制來定義您的執行個體需求。
要部署 Amazon EKS 自動模式的 `NodePool` 和範例 `workload`，請檢閱以下的 NodePool 和 Pod 定義，並分別儲存為 `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 自動模式節點上。NodePool 還設定了一個污點，只允許排程具有 NVIDIA GPU 容忍度的 Pod。
將 NodePool 和工作負載套用至您的叢集。
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
您應該會看到下列輸出：
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
等待幾秒鐘，並檢查叢集中的節點。您現在應該會看到在 Amazon EKS 自動叢集中佈建了一個新節點：
```
> 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 自動模式啟動了一個 `g6e.2xlarge` 而非 `g6.2xlarge`，這是因為根據以下的 Kubernetes 排程限制，工作負載需要一個配備 l40s `GPU` 的執行個體：
```
...
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 自動模式管理。
## 步驟 3：清理
若要移除所有建立的物件，請使用 `kubectl` 刪除範例部署和 NodePool，以便終止節點：
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## NodePools 範例參考
### 建立 NVIDIA NodePool
以下 NodePool 定義：
+ 只啟動 `g6e` 和 `g6` 系列的執行個體
+ 節點閒置 1 小時後進行合併
+ `consolodateAfter` 1 小時的值可支援突增的工作負載，並減少節點波動。您可根據工作負載需求調整 `consolidateAfter`。
**具有 GPU 執行個體系列和合併功能的範例 NodePool**
```
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-family` 來指定執行個體系列，而非設定 `eks.amazonaws.com/instance-gpu-name`。如需其他影響排程的知名標籤，請參閱 [EKS 自動模式支援的標籤](create-node-pool.md#auto-supported-labels)。
若您有特定的儲存需求，可以透過建立自己的 [NodeClass](create-node-class.md) 並在 NodePool 中參考，來調整節點的臨時儲存 `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 設定了 `eks.amazonaws.com/instance-category`，表示僅啟動 Inferentia 與 Trainium 系列的執行個體：
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```