**帮助改进此页面**
要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。
# 在 EKS 自动模式集群中运行示例工作负载
本章提供的示例演示了如何将不同类型的工作负载部署到在自动模式下运行的 Amazon EKS 集群。这些示例演示了关键的工作负载模式，包括示例应用程序、启用负载均衡的 Web 应用程序、使用持久性存储的有状态工作负载以及具有特定节点放置要求的工作负载。每个示例都包含完整的清单和详细分步部署说明，您可以将其用作自己应用程序的模板。
在开始使用示例之前，请确保您有一个在自动模式下运行的 EKS 集群，并且已经安装了 AWS CLI 和 kubectl。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。这些示例假设您基本熟悉 Kubernetes 的概念和 kubectl 命令。
您可以使用这些基于应用场景的示例，在 EKS 自动模式集群中运行工作负载。
[将示例 inflate 工作负载部署到 Amazon EKS 自动模式集群](automode-workload.md)
演示如何使用 `kubectl` 命令将示例工作负载部署到 EKS 自动模式集群。
[将示例负载均衡器工作负载部署到 EKS 自动模式](auto-elb-example.md)
演示如何在 Amazon EKS 上部署 2048 游戏的容器化版本。
[将示例有状态工作负载部署到 EKS 自动模式](sample-storage-workload.md)
演示如何将示例有状态应用程序部署到 EKS 自动模式集群。
[部署加速型工作负载](auto-accelerated.md)
演示如何将硬件加速的工作负载部署到由 EKS 自动模式管理的节点。
[控制工作负载是否部署在 EKS 自动模式节点上](associate-workload.md)
演示如何使用注释来控制是否将工作负载部署到由 EKS 自动模式管理的节点。
# 将示例 inflate 工作负载部署到 Amazon EKS 自动模式集群
在本教程中，您将了解如何将示例工作负载部署到 EKS 自动模式集群，并观察其如何自动预置所需的计算资源。您将使用 `kubectl` 命令来观察集群行为，并亲眼见证自动模式如何在 AWS 上简化 Kubernetes 的操作。完成本教程后，您将了解 EKS 自动模式如何通过自动管理底层计算资源来响应工作负载部署，无需手动配置节点组。
## 先决条件
+ Amazon EKS 自动模式集群。记下集群的名称和 AWS 区域。
+ 一个具有管理联网、计算和 EKS 资源的足够权限的 IAM 主体，例如用户或角色。
+ 有关更多信息，请参阅《IAM 用户指南》中的[创建角色并附加策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)。
+ 已使用某个 IAM 身份 安装并配置了 `aws` CLI。
+ 已安装 `kubectl` CLI 并连接到集群。
+ 有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
## 第 1 步：检查现有的计算资源（可选）
首先，使用 `kubectl` 列出集群上的节点池。
```
kubectl get nodepools
```
示例输出：
```
general-purpose
```
在本教程中，我们将部署一个配置为使用 `general-purpose` 节点池的工作负载。此节点池已内置在 EKS 自动模式中，包括微服务和 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 自动模式会检测已空三十秒钟的节点，并将其终止。
使用 `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
```
**关键组件：**
+ 创建一个节点端口服务
+ 将端口 80 映射到容器的端口 80
+ 使用标签选择器查找容器组
应用服务：
```
kubectl apply -f 03-service.yaml
```
## 第 4 步：配置负载均衡
您将设置一个 Ingress，以将该应用程序向互联网公开。
首先，创建 `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)。
然后创建该 Ingress 资源。创建一个名为 `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 目标类型
+ 将所有流量 (/) 路由到游戏服务
应用 Ingress 配置：
```
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
```
Ingress 输出中的 ADDRESS 字段将显示您的 ALB 端点。等待 2-3 分钟，让 ALB 完成预置并注册所有目标。
## 第 6 步：访问游戏
打开 Web 浏览器并浏览到之前步骤中的 ALB 端点 URL。您应该会看到 2048 游戏界面。
## 步骤 7：清除
移除本教程中创建的所有资源：
```
kubectl delete namespace game-2048
```
这将删除命名空间中的所有资源，包括部署、服务和 Ingress 资源。
## 幕后发生了什么
1. 此部署创建了 5 个运行 2048 游戏的容器组
1. 该服务为这些容器组提供稳定的网络访问
1. EKS 自动模式：
+ 在 AWS 中创建一个应用程序负载均衡器
+ 为容器组配置目标组
+ 设置路由规则以将流量定向到服务
## 故障排除
如果游戏无法加载：
+ 确保所有容器组都在运行：`kubectl get pods -n game-2048`
+ 检查 Ingress 状态：`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`。您必须创建引用 `ebs.csi.eks.amazonaws.com` 的 `StorageClass`，才能使用 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` – 将卷的创建延迟到容器组需要时
+ `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 容器
+ 将 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 自动模式会预置一个 EBS 卷
1. 创建一个持久性卷
1. 将该卷挂载到节点
1. 容器组会挂载该卷并开始写入时间戳
## 快照控制器
EKS 自动模式与 Kubernetes CSI Snapshotter（也称为快照控制器）兼容。但是，Amazon 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 Snapshotter 的更多信息。](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 部署加速型工作负载
本教程演示了 Amazon EKS 自动模式如何简化硬件加速型工作负载的启动。Amazon EKS 自动模式通过自动执行各种关键基础设施组件操作，提供可开箱即用的计算、联网、负载均衡、存储以及身份访问和管理功能，从而简化集群本身以外的操作。
Amazon EKS 自动模式包含某些实例类型所需的驱动程序和设备插件，例如 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 工作负载
在此示例中，您将为基于 NVIDIA 的工作负载创建一个节点池，需要 45GB GPU 内存。使用 EKS 自动模式时，您可以使用 Kubernetes 调度约束来定义实例要求。
要部署 Amazon EKS 自动模式 `NodePool` 和示例 `workload`，请检查以下节点池和容器组（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 自动模式节点上。该节点池还设置了一个污点，从而只允许调度具有 Nvidia GPU 容忍度的容器组。
将该节点池和工作负载应用到集群：
```
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` 删除示例部署和节点池，从而终止该节点：
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## 节点池引用示例
### 创建 NVIDIA 节点池
以下节点池定义了如下要求：
+ 仅启动 `g6e` 和 `g6` 系列的实例
+ 合并空置达到 1 小时的节点
+ 使用 1 小时的 `consolodateAfter` 值，可支持高峰工作负载并减少节点中断。您可以根据工作负载要求微调 `consolidateAfter`。
**搭载 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 自动模式支持的标签](create-node-pool.md#auto-supported-labels)。
如果您有特定的存储需求，则可以通过在节点池中创建自己的[节点类](create-node-class.md)来引用，从而微调节点的临时存储 `iops`、`size` 和 `throughput`。详细了解[可配置的节点类选项](create-node-class.md)。
**节点类的存储配置示例**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### 定义 AWS Trainium 和 AWS Inferentia 节点池
以下节点池设的 `eks.amazonaws.com/instance-category` 集规定只能启动 Inferentia 和 Trainium 系列的实例：
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```