**帮助改进此页面**
要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。
# 使用 EKS 自动模式实现集群基础设施自动化
**提示**
[注册参加](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)即将举办的 Amazon EKS 自动模式讲习会。
EKS 自动模式将 Kubernetes 集群的 AWS 管理扩展到集群本身之外，从而让 AWS 还可以设置和管理基础设施，确保工作负载的平稳运行。您可以将关键基础设施决策委派给 AWS 并利用其专业知识进行日常运营。由 AWS 管理的集群基础设施将多种 Kubernetes 功能作为核心组件包含在内，而不是作为附加组件，例如计算自动扩缩、容器和服务联网、应用程序负载均衡、集群 DNS、块存储和 GPU 支持等。
要开始使用，您可以部署一个新的 EKS 自动模式集群或在现有集群上启用 EKS 自动模式。您可以使用 eksctl、AWS CLI、AWS 管理控制台、EKS API 或偏好的基础设施即代码工具，部署、升级或修改 EKS 自动模式集群。
使用 EKS 自动模式时，您可以继续使用自己偏好的 Kubernetes 兼容工具。EKS 自动模式与 Amazon EC2、Amazon EBS 和 ELB 等 AWS 服务集成，利用遵循最佳实践的 AWS 云资源。这些资源可自动扩展、优化成本并定期更新，有助您尽可能降低运营成本和开销。
## 功能
EKS 自动模式提供以下高级别功能：
**简化 Kubernetes 集群管理**：EKS 自动模式通过提供运行开销极小的生产就绪型集群，来简化 EKS 的管理。使用 EKS 自动模式时，您可以放心地运行要求严苛的动态工作负载，无需深入的 EKS 专业知识。
**应用程序可用性**：EKS 自动模式会根据 Kubernetes 应用程序的需求动态添加或移除 EKS 集群中的节点。这尽可能减少了手动容量规划的需求，确保了应用程序的可用性。
**效率**：EKS 自动模式旨在优化计算成本，同时符合节点池和工作负载要求所定义的灵活性。此外还会终止未使用的实例，并将工作负载整合到其他节点上，从而提高成本效率。
**安全性**：EKS 自动模式使用对节点而言不可变的 AMI。这些 AMI 强制使用锁定软件，启用 SELinux 强制访问控制，并提供只读的根文件系统。此外，由 EKS 自动模式启动的节点最长生命周期为 21 天（并且您可以缩短此周期），之后会自动替换为新节点。这种方法通过定期循环节点来增强安全态势，也符合许多客户已经采用的最佳实践。
**自动升级**：EKS 自动模式使用最新补丁来确保 Kubernetes 集群、节点和相关组件保持最新状态，同时遵守您配置的容器组中断预算（PDB）和节点池中断预算（NDB）。在不超过 21 天最长生命周期的前提下，如果阻止 PDB 或其他配置会妨碍更新，则可能需要进行干预。
**托管式组件**：EKS 自动模式将 Kubernetes 和 AWS 云功能等作为核心组件，而这些组件本来会作为附加组件管理。这包括对容器组 IP 地址分配、容器组网络策略、本地 DNS 服务、GPU 插件、运行状况检查器和 EBS CSI 存储的内置支持。
**可自定义节点池和节点类**：如果工作负载需要更改存储、计算或联网配置，则可以使用 EKS 自动模式创建自定义节点池和节点类。虽然不应编辑默认的节点池和节点类，但可以在默认配置之外添加新的自定义节点池或节点类，来满足自己的特定需求。
## 自动化组件
EKS 自动模式通过自动管理关键基础设施组件来简化 Amazon EKS 集群的操作。启用 EKS 自动模式可进一步减少 EKS 集群管理任务。
以下是自动管理的数据面板组件列表：
+ **计算**：对于许多工作负载而言，使用 EKS 自动模式后，您都无需关注 EKS 集群计算的许多方面。这些方法包括：
+ **节点**：EKS 自动模式节点在设计上可视为设备。EKS 自动模式可完成以下任务：
+ 选择合适的 AMI 并配置运行工作负载所需的多种服务，无需干预。
+ 使用 SELinux 强制实施模式和只读根文件系统锁定对 AMI 上文件的访问权限。
+ 通过禁用 SSH 或 SSM 访问来禁止直接访问节点。
+ 包含 GPU 支持，以及适用于 NVIDIA 和 Neuron GPU 的单独内核驱动程序和插件，从而支持高性能工作负载。
+ 自动处理 [EC2 竞价型实例中断通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)和 EC2 实例运行状况事件
+ **自动扩缩**：依托 [Karpenter](https://karpenter.sh/docs/) 自动扩缩功能，EKS 自动模式可以监控不可调度的容器组，并通过部署新节点来运行这些容器组。当工作负载终止时，EKS 自动模式会动态中断和终止不再需要的节点，从而优化资源使用。
+ **升级**：通过接管节点的控制，简化 EKS 自动模式根据需要提供安全补丁以及操作系统和组件升级的能力。这些升级旨在尽可能减少工作负载的中断。EKS 自动模式强制实施最长 21 天的节点生命周期，以确保始终使用最新的软件和 API。
+ **负载均衡**：EKS 自动模式通过与 Amazon 弹性负载均衡服务集成，自动为 Kubernetes 服务和 Ingress 资源预置和配置负载均衡器，从而简化负载均衡任务。支持应用程序均衡器和网络负载均衡器的高级功能，管理其生命周期，并根据集群需求进行扩展。这种集成提供了符合 AWS 最佳实践的生产就绪型负载均衡解决方案，使您可以专注于应用程序，而无需关注基础设施管理。
+ **存储**：EKS 自动模式通过设置卷类型、卷大小、加密策略以及节点终止时的删除策略，来为您配置临时存储。
+ **联网**：EKS 自动模式可自动执行容器组和服务连接的关键联网任务。这包括 IPv4/IPv6 支持以及使用辅助 CIDR 块来扩展 IP 地址空间。
+ **身份和访问权限管理**：您无需在 EKS 自动模式集群上安装 EKS 容器组身份代理。
有关这些组件的更多信息，请参阅[了解 EKS 自动模式的工作原理](auto-reference.md)。
## 配置
虽然 EKS 自动模式无需您干预即可有效地管理大部分数据面板服务，不过有时您可能需要更改某些服务的行为。您可以通过以下任一方式修改 EKS 自动模式集群的配置：
+ **Kubernetes 进程守护程序集**：您可以使用 Kubernetes 进程守护程序集，而不修改节点上安装的服务。进程守护程序集旨在由 Kubernetes 管理，不过是在集群中的每个节点上运行的。这样，您可以添加特殊服务来监控或以其他方式观察节点。
+ **自定义节点池和节点类**：默认节点池和节点类由 EKS 自动模式配置，不应编辑。要自定义节点行为，您可以针对应用场景创建其他节点池或节点类，例如：
+ 选择特定的实例类型（例如，加速处理器或 EC2 竞价型实例）。
+ 出于安全或成本跟踪目的隔离工作负载。
+ 配置临时存储设置，例如 IOPS、大小和吞吐量等。
+ **负载均衡**：EKS 自动模式作为 Kubernetes 对象运行的某些服务（例如负载均衡），可以直接在 EKS 自动模式集群上配置。
要详细了解配置 EKS 自动模式的选项，请参阅[配置 EKS 自动模式设置](settings-auto.md)。
## 责任共担模式
AWS 责任共担模式定义了 AWS 与客户之间的安全与合规责任。下面的图片和文字比较和对比 EKS 自动模式与 EKS 标准模式之间客户与 AWS 责任的区别。
![\[采用 EKS 自动模式与标准模式的责任共担模式\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/eksautosrm.png)
EKS 自动模式将 Kubernetes 基础设施的大部分共担责任从客户转移到 AWS。使用 EKS 自动模式后，AWS 承担了更多云安全责任，而云安全曾经是客户的责任，现在我们与客户共同承担。现在，客户可以更加专注于自己的应用程序，而 AWS 负责管理底层基础设施。
**客户责任**
在 EKS 自动模式下，客户继续负责应用程序容器，包括可用性、安全性和监控。其还保留对 VPC 基础设施和 EKS 集群配置的控制。此模式使客户能够专注于应用程序特定的问题，同时将集群基础设施管理委派给 AWS。通过 AWS 附加组件可以在集群中加入可选的每节点功能。
**AWS 责任**
使用 EKS 自动模式后，与未使用自动模式的 EKS 集群中已管理的组件相比，AWS 的责任范围扩大到包括管理多个其他关键组件。具体而言，EKS 自动模式接管了启动的 EC2 实例的配置、管理、安全和扩展，以及负载均衡、IP 地址管理、联网策略和块存储等集群功能。在 EKS 自动模式下，以下组件由 AWS 管理：
+ **自动模式启动的 EC2 实例**：AWS 利用 Amazon EC2 托管实例处理节点的整个生命周期。EC2 托管实例负责操作系统配置、修补、监控和运行状况维护。在此模式下，实例本身和在其上运行的客户操作系统均由 AWS 负责。这些节点使用为运行容器而优化的 [Bottlerocket](https://aws.amazon.com/bottlerocket) AMI 的变体。Bottlerocket AMI 具有锁定的软件、不可变的根文件系统，以及安全的网络访问（防止通过 SSH 或 SSM 直接通信）。
+ **集群功能**：AWS 管理计算自动扩展、具有网络策略强制执行的容器组（pod）联网、Elastic Load Balancing 集成，以及存储驱动程序配置。
+ **集群控制面板**：与标准 EKS 一样，AWS 继续管理 Kubernetes API 服务器、跨账户 ENI 和 etcd 数据库。
+ **基础服务和全球基础设施**：AWS 负责底层计算、存储、联网和监控服务，以及区域、本地区域和边缘站点的全球基础设施。
# 创建启用 Amazon EKS 自动模式的集群
本章介绍如何使用各种工具和界面创建启用自动模式的 Amazon EKS 集群。自动模式通过自动配置和管理集群的计算、联网和存储基础设施，来简化集群的创建。您将了解如何使用 AWS CLI、AWS 管理控制台或 eksctl 命令行工具创建自动模式集群。
**注意**
EKS 自动模式需要使用 Kubernetes 版本 1.29 或更高版本。
根据需要选择偏好的工具：AWS 管理控制台提供了直观的界面，非常适合用来了解 EKS 自动模式功能和创建单个集群。AWS CLI 非常适合脚本化和自动化任务，尤其是在将集群创建集成到现有工作流或 CI/CD 管道时。eksctl CLI 提供了 Kubernetes 原生体验，建议熟悉 Kubernetes 工具并且希望使用合理的默认值来简化命令行操作的用户使用。
在开始操作之前，请确保您已安装并配置必要的先决条件，包括具有创建 EKS 集群的适当 IAM 权限。要了解如何安装 `kubectl`、`aws` 和 `eksctl` 等 CLI 工具，请参阅[进行设置以使用 Amazon EKS](setting-up.md)。
您可以使用 AWS CLI、AWS 管理控制台或 eksctl CLI 创建启用 Amazon EKS 自动模式的集群。
**Topics**
+ [使用 eksctl CLI 创建 EKS 自动模式集群](automode-get-started-eksctl.md)
+ [使用 AWS CLI 创建 EKS 自动模式集群](automode-get-started-cli.md)
+ [使用 AWS 管理控制台创建 EKS 自动模式集群](automode-get-started-console.md)
# 使用 eksctl CLI 创建 EKS 自动模式集群
此主题演示如何使用 eksctl 命令行界面（CLI）创建 Amazon EKS 自动模式集群。您可以通过运行单个 CLI 命令或应用 YAML 配置文件来创建自动模式集群。这两种方法提供的功能相同，不过 YAML 方法可以更精细地控制集群设置。
eksctl CLI 通过处理底层 AWS 资源的创建和配置，来简化创建和管理 EKS 自动模式集群的过程。在开始操作之前，请确保在本地计算机上配置了必要的 AWS 凭证和权限。本指南假设您熟悉 Amazon EKS 的基本概念，并且已经安装了必需的 CLI 工具。
**注意**
您必须安装版本 `0.195.0` 或更高版本的 eksctl。有关更多信息，请参阅 GitHub 上的 [eksctl releases](https://github.com/eksctl-io/eksctl/releases)。
## 使用 CLI 命令创建 EKS 自动模式集群
您必须已安装 `aws` 和 `eksctl` 工具。您必须以管理 AWS 资源所需的足够权限登录 AWS CLI，包括 EC2 实例、EC2 联网、EKS 集群和 IAM 角色等。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
运行以下命令以创建新的 EKS 自动模式集群
```
eksctl create cluster --name= --enable-auto-mode
```
## 使用 YAML 文件创建 EKS 自动模式集群
您必须已安装 `aws` 和 `eksctl` 工具。您必须以管理 AWS 资源所需的足够权限登录 AWS CLI，包括 EC2 实例、EC2 联网、EKS 集群和 IAM 角色等。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
检查以下集群配置示例资源中的 EKS 自动模式配置选项。有关完整的 ClusterConfig 规范，请参阅 [eksctl 文档](https://eksctl.io/usage/creating-and-managing-clusters/)。
AWS 建议您启用 EKS 自动模式。如果这是您第一次创建 EKS 自动模式集群，请勿指定 `nodeRoleARN`，以便为 EKS 自动模式创建节点 IAM 角色。如果您的 AWS 账户中已有节点 IAM 角色，AWS 建议重复使用该角色。
AWS 建议不要为 `nodePools` 指定任何值。EKS 自动模式将创建默认节点池。您可以使用 Kubernetes API 来创建其他节点池。
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
将 `ClusterConfig` 文件另存为 `cluster.yaml`，然后使用以下命令创建集群：
```
eksctl create cluster -f cluster.yaml
```
# 使用 AWS CLI 创建 EKS 自动模式集群
EKS 自动模式集群可自动执行计算、存储和联网等方面的例行集群管理任务。例如，EKS 自动模式集群会自动检测何时需要增加节点，并相应预置新的 EC2 实例来满足工作负载的需求。
本主题将演示使用 AWS CLI 创建新的 EKS 自动模式集群，以及（可选）部署示例工作负载的过程。
## 先决条件
+ 已在您的设备上安装并配置了最新版本的 AWS 命令行界面（AWS CLI）。要查看当前版本，请使用 `aws --version`。要安装最新版本，请参阅《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)。
+ 使用创建 AWS 资源所需的充分 IAM 权限登录 CLI，包括 IAM 策略、IAM 角色和 EKS 集群等。
+ 已在您的设备上安装了 kubectl 命令行工具。AWS 建议使用与 EKS 集群的 Kubernetes 版本相同的 kubectl 版本。要安装或升级 kubectl，请参阅[设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
## 指定 VPC 子网
Amazon EKS 自动模式会将节点部署到 VPC 子网。创建 EKS 集群时，必须指定要部署节点的 VPC 子网。可以使用您 AWS 账户中的默认 VPC 子网，也可以创建用于关键工作负载的专用 VPC。
+ AWS 建议为集群创建专用 VPC。了解如何[为您的 Amazon EKS 集群创建 Amazon VPC](creating-a-vpc.md)。
+ EKS 控制台可帮助创建新的 VPC。了解如何[使用 AWS 管理控制台创建 EKS 自动模式集群](automode-get-started-console.md)。
+ 您也可以使用您 AWS 账户的默认 VPC。按照以下说明查找子网 ID。
### 查找默认 VPC 的子网 ID
**使用 AWS CLI：**
1. 运行以下命令，列出默认 VPC 及其子网：
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. 保存输出并记下**子网 ID**。
示例输出：
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## EKS 自动模式集群的 IAM 角色
### 集群 IAM 角色
EKS 自动模式需要集群 IAM 角色才能在您的 AWS 账户中执行操作，例如预置新的 EC2 实例。您必须创建此角色才能向 EKS 授予必要的权限。AWS 建议将以下 AWS 托管式策略附加到集群 IAM 角色：
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### 节点 IAM 角色
创建 EKS 自动模式集群时，需要指定一个节点 IAM 角色。EKS 自动模式创建节点来处理待处理的工作负载时，将为每个新的 EC2 实例节点分配此节点 IAM 角色。此角色允许节点与 EKS 通信，但节点上运行的工作负载通常无法访问此角色。
要向在节点上运行的工作负载授予权限，请使用 EKS 容器组身份。有关更多信息，请参阅 [了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限](pod-identities.md)。
您必须创建此角色并附加以下 AWS 托管式策略：
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
EKS 自动模式还需要一个将由 AWS 自动创建和配置的服务相关角色。有关更多信息，请参阅 [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md)。
## 创建 EKS 自动模式集群 IAM 角色
### 第 1 步：创建信任策略
创建信任策略以允许 Amazon EKS 服务代入该角色。将策略另存为 `trust-policy.json`：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### 第 2 步：创建 IAM 角色
使用信任策略创建集群 IAM 角色：
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### 第 3 步：记下角色 ARN
检索并保存新角色的 ARN，以便在后续步骤中使用：
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### 第 4 步：附加必需的策略
将以下 AWS 托管式策略附加到集群 IAM 角色以授予必要的权限：
**AmazonEKSClusterPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSComputePolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSBlockStoragePolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSLoadBalancingPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
## 创建 EKS 自动模式 节点 IAM 角色
### 第 1 步：创建信任策略
创建信任策略以允许 Amazon EKS 服务代入该角色。将策略另存为 `node-trust-policy.json`：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### 第 2 步：创建节点 IAM 角色
使用上一步中的 **node-trust-policy.json** 文件来定义哪些实体可以代入该角色。运行以下命令以创建节点 IAM 角色：
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### 第 3 步：记下角色 ARN
创建角色后，检索并保存节点 IAM 角色的 ARN。在后续步骤中，您将需要此 ARN。使用以下命令来获取 ARN：
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### 第 4 步：附加必需的策略
将以下 AWS 托管式策略附加到节点 IAM 角色，以提供必要的权限：
**AmazonEKSWorkerNodeMinimalPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**AmazonEC2ContainerRegistryPullOnly**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## 创建 EKS 自动模式集群
### 概述
要使用 AWS CLI 创建 EKS 自动模式集群，您需要以下参数：
+ `cluster-name`：集群的名称。
+ `k8s-version`：Kubernetes 版本（例如 1.31）。
+ `subnet-ids`：之前步骤中确定的子网 ID。
+ `cluster-role-arn`：集群 IAM 角色的 ARN。
+ `node-role-arn`：节点 IAM 角色的 ARN。
#### 默认集群配置
在创建集群之前，请检查以下默认值和功能：
+ `nodePools`：EKS 自动模式包含通用节点池和系统默认节点池。了解有关[节点池](create-node-pool.md)的更多信息。
**注意：**EKS 自动模式下的节点池与 Amazon EKS 托管式节点组不同，但可以共存于同一个集群中。
+ `computeConfig.enabled`：自动执行例行计算任务，例如创建和删除 EC2 实例。
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`：自动执行负载均衡任务，包括创建和删除弹性负载均衡器。
+ `storageConfig.blockStorage.enabled`：自动执行存储任务，例如创建和删除 Amazon EBS 卷。
+ `accessConfig.authenticationMode`：需要 EKS 访问条目。了解有关 [EKS 身份验证模式](grant-k8s-access.md)的更多信息。
#### 运行命令
使用下面的命令创建集群：
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### 检查集群状态
#### 第 1 步：验证集群创建
运行以下命令来检查集群的状态。创建集群通常需要大约 15 分钟时间：
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### 第 2 步：更新 kubeconfig
集群准备就绪后，更新本地 kubeconfig 文件以便 `kubectl` 可以与集群通信。此配置使用 AWS CLI 进行身份验证。
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### 第 3 步：验证节点池
使用以下命令列出集群中的节点池：
```
kubectl get nodepools
```
## 后续步骤
+ 了解如何将[示例工作负载部署](automode-workload.md)到新的 EKS 自动模式集群。
# 使用 AWS 管理控制台创建 EKS 自动模式集群
与其他选项相比，在 AWS 管理控制台中创建 EKS 自动模式集群所需的配置更少。EKS 与 AWS IAM 和 VPC 联网服务集成，可帮助您创建与 EKS 集群关联的资源。
您可以通过两种方式在控制台中创建集群：
+ 快速配置（使用 EKS 自动模式）
+ 自定义配置
在本主题中，您将了解如何使用快速配置选项创建 EKS 自动模式集群。
## 使用快速配置选项创建 EKS 自动模式集群
您必须以管理 AWS 资源所需的足够权限登录 AWS 管理控制台，包括 EC2 实例、EC2 联网、EKS 集群和 IAM 角色等。
1. 导航到 EKS 控制台
1. 单击**创建集群**
1. 确认已选中**快速配置**选项
1. 确定以下值，或使用测试集群的默认值。
+ 集群**名称**
+ Kubernetes 版本
1. 选择集群 IAM 角色。如果您是首次创建 EKS 自动模式集群，请使用**创建推荐角色**选项。
+ 您也可以将 AWS 账户中的单个集群 IAM 角色重复用于所有 EKS 自动模式集群。
+ 集群 IAM 角色包含 EKS 自动模式管理资源（包括 EC2 实例、EBS 卷和 EC2 负载均衡器）所需的权限。
+ **创建推荐角色**选项会使用推荐值预填充所有字段。选择**下一步**，然后选择**创建**。此角色将使用建议的 `AmazonEKSAutoClusterRole` 名称。
+ 如果您最近创建了新角色，请使用**刷新**图标重新加载角色选择下拉列表。
1. 选择节点 IAM 角色。如果您是首次创建 EKS 自动模式集群，请使用**创建推荐角色**选项。
+ 您也可以将 AWS 账户中的单个节点 IAM 角色重复用于所有 EKS 自动模式集群。
+ 此节点 IAM 角色包含自动模式节点连接到集群所需的权限。此节点 IAM 角色必须包含检索容器的 ECR 映像的权限。
+ **创建推荐角色**选项会使用推荐值预填充所有字段。选择**下一步**，然后选择**创建**。此角色将使用建议的 `AmazonEKSAutoNodeRole` 名称。
+ 如果您最近创建了新角色，请使用**刷新**图标重新加载角色选择下拉列表。
1. 为您的 EKS 自动模式集群选择 VPC。选择**创建 VPC** 为 EKS 创建新的 VPC，也可以选择您之前为 EKS 创建的 VPC。
+ 如果您使用 VPC 控制台创建新的 VPC，AWS 建议您在每个可用区至少创建一个 NAT 网关。否则，您可以使用所有其他默认值。
+ 有关 IPv6 集群要求的更多信息和详情，请参阅[为您的 Amazon EKS 集群创建 Amazon VPC](creating-a-vpc.md)。
1. （可选）EKS 自动模式会自动填充所选 VPC 的私有子网。您可以移除不需要的子网。
+ EKS 会按照最佳实践自动选择 VPC 中的私有子网。您可以从 VPC 中选择额外的子网，例如公有子网。
1. （可选）选择**查看快速配置默认值**以查看新集群的所有配置值。该表提示某些值在集群创建后不可编辑。
1. 选择 **Create cluster（创建集群）**。请注意，完成集群创建可能需要 15 分钟时间。
## 后续步骤
+ 了解如何[将示例工作负载部署到新的 EKS 自动模式集群](sample-storage-workload.md)
# 在现有 EKS 集群上启用 EKS 自动模式
您可以在现有 EKS 集群上启用 EKS 自动模式。
**AWS 支持下列迁移：**
+ 从 Karpenter 迁移到 EKS 自动模式节点。有关更多信息，请参阅 [使用 kubectl 从 Karpenter 迁移到 EKS 自动模式](auto-migrate-karpenter.md)。
+ 从 EKS 托管式节点组迁移到 EKS 自动模式节点。有关更多信息，请参阅 [从 EKS 托管式节点组迁移到 EKS 自动模式](auto-migrate-mng.md)。
+ 从 EKS Fargate 迁移到 EKS 自动模式节点。有关更多信息，请参阅 [从 EKS Fargate 迁移到 EKS 自动模式](auto-migrate-fargate.md)。
**AWS 不支持下列迁移：**
+ 将卷从 EBS CSI 控制器（使用 Amazon EKS 附加组件）迁移到 EKS 自动模式 EBS CIS 控制器（由 EKS 自动模式管理）。由不同配置器创建的 PVC 无法互相挂载，因为它们使用的是两个不同的 Kubernetes 卷预调配程序。
+ [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool)（AWS Labs 项目）支持在标准 EBS CSI StorageClass (`ebs.csi.aws.com`) 与 EKS 自动模式 EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`) 之间迁移。请注意，迁移需要删除并重新创建现有的 PersistentVolumeClaim/PersistentVolume 资源，因此在进行迁移之前，必须在非生产环境中进行验证。
+ 将负载均衡器从 AWS 负载均衡器控制器迁移到 EKS 自动模式
您可以在 Amazon EKS 自动模式集群上安装 AWS 负载均衡器控制器。使用 `IngressClass` 或 `loadBalancerClass` 选项将服务和 Ingress 资源关联到 负载均衡器控制器或 EKS 自动模式。
+ 使用备用 CNI 或其他不受支持的网络配置迁移 EKS 集群
## 迁移参考
按照以下迁移参考将 Kubernetes 资源配置为由自主管理型控制器或 EKS 自动模式所有。
| 能力 | 资源 | 字段 | 自主管理型 | EKS 自动模式 |
| --- | --- | --- | --- | --- |
| 数据块存储 | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| 负载均衡 | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| 负载均衡 | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| 负载均衡 | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 负载均衡 | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 计算 | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## 迁移 EBS 卷
将工作负载迁移到 EKS 自动模式时，由于 CSI 驱动程序预调配程序不同，您需要处理 EBS 卷迁移问题：
+ EKS 自动模式预调配程序：`ebs.csi.eks.amazonaws.com`
+ 开源 EBS CSI 预调配程序：`ebs.csi.aws.com`
请按照以下步骤迁移持久性卷：
1. **修改卷保留策略**：将现有平台版本（PV）由 `persistentVolumeReclaimPolicy` 更改为 `Retain`，确保底层 EBS 卷不会删除。
1. **从 Kubernetes 中删除 PV**：删除旧的 PV 资源，但保留实际的 EBS 卷。
1. **通过静态预置创建新 PV**：创建一个引用相同 EBS 卷但与目标 CSI 驱动程序结合使用的新 PV。
1. **绑定到新 PVC**：使用 `volumeName` 字段创建一个专门引用 PV 的新 PVC。
### 注意事项
+ 确保在开始迁移之前应用程序已停止。
+ 在开始迁移过程之前，备份数据。
+ 需要对每个持久性卷执行此过程。
+ 必须更新工作负载才能使用新 PVC。
## 迁移负载均衡器
不能将现有负载均衡器从自主管理型 AWS 负载均衡器控制器直接转移到 EKS 自动模式。相反，您必须实施蓝绿部署策略。这涉及维护现有的负载均衡器配置，同时在托管式控制器下创建新的负载均衡器。
为了尽可能减少服务中断，我们建议采用基于 DNS 的流量转移方法。首先使用 EKS 自动模式创建新的负载均衡器，同时保持现有配置正常运行。然后使用 DNS 路由（例如 Route 53）将流量从旧负载均衡器逐渐转移到新负载均衡器。成功迁移流量并验证新配置后，您可以停用旧负载均衡器和自主管理型控制器。
# 在现有集群上启用 EKS 自动模式
本主题介绍如何在现有的 Amazon EKS 集群上启用 Amazon EKS 自动模式。要在现有集群上启用自动模式，需要更新 IAM 权限并配置核心 EKS 自动模式设置。启用自动模式后，您可以开始迁移现有的计算工作负载，以利用自动模式的简化操作和自动化基础设施管理等优势。
**重要**
启用 EKS 自动模式之前，请确认您已安装某些 Amazon EKS 附加组件的最低所需版本。有关更多信息，请参阅 [必需的附加组件版本](#auto-addons-required)。
在开始操作之前，请确保您拥有 Amazon EKS 集群的管理员访问权限以及修改 IAM 角色的权限。本主题中的步骤将演示使用 AWS 管理控制台或 AWS CLI 启用自动模式的过程。
## AWS 管理控制台
您必须登录 AWS 控制台并拥有管理 IAM、EKS 和 EC2 资源的权限。
**注意**
创建 EKS 集群后，将无法更改其集群 IAM 角色。EKS 自动模式需要此角色拥有额外的权限。您必须为当前角色附加额外的策略。
### 更新集群 IAM 角色
1. 在 AWS 管理控制台中打开集群概述页面。
1. 在**集群 IAM 角色 ARN** 下，选择**在 IAM 中查看**。
1. 从**添加权限**下拉菜单中，选择**附加策略**。
1. 使用**搜索**框查找并选中以下策略：
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. 选择**添加权限**
1. 从**信任关系**选项卡中选择**编辑信任策略**
1. 插入以下集群 IAM 角色信任策略，然后选择**更新策略**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### 启用 EKS 自动模式
1. 在 AWS 管理控制台中打开集群概述页面。
1. 在 **EKS 自动模式**下，选择**管理**
1. 将 **EKS 自动模式**切换为开启。
1. 从 **EKS 节点池**下拉列表中，选择要创建的默认节点池。
+ 详细了解 EKS 自动模式中的节点池。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
1. 如果您之前已为此 AWS 账户创建了 EKS 自动模式节点 IAM 角色，请在**节点 IAM 角色**下拉列表中选中该角色。如果您之前尚未创建该角色，请选择**创建建议角色**，然后按照步骤操作。
## AWS CLI
### 先决条件
+ 现有 EKS 集群的集群 IAM 角色必须包含足够的 EKS 自动模式权限，例如以下策略：
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ 集群 IAM 角色必须更新信任策略，其中应包括 `sts:TagSession` 操作。有关创建集群 IAM 角色的更多信息，请参阅[使用 AWS CLI 创建 EKS 自动模式集群](automode-get-started-cli.md)。
+ 已安装 `aws` CLI，已登录，并且版本充分满足要求。您必须拥有管理 IAM、EKS 和 EC2 资源的权限。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
### 过程
使用以下命令在现有集群上启用 EKS 自动模式。
**注意**
计算、块存储和负载均衡功能必须在同一请求中全部启用或禁用。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## 必需的附加组件版本
如果您计划在现有集群上启用 EKS 自动模式，则可能需要更新某些附加组件。请注意：
+ 这仅适用于将现有集群迁移到 EKS 自动模式。
+ 创建启用 EKS 自动模式的新集群不需要进行这些更新。
如果您安装了以下任何附加组件，请确保这些附加组件至少达到指定的最低版本：
| 附加组件名称 | 最低所需版本 |
| --- | --- |
| 适用于 Kubernetes 的 Amazon VPC CNI 插件 | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/auto-enable-existing.html) |
| Amazon EBS CSI 驱动程序 | v1.37.0-eksbuild.1 |
| CSI 快照控制器 | v8.1.0-eksbuild.2 |
| EKS 容器组身份代理 | v1.3.4-eksbuild.1 |
有关更多信息，请参阅 [更新 Amazon EKS 附加组件](updating-an-add-on.md)。
## 后续步骤
+ 要迁移“管理节点组”工作负载，请参阅[从 EKS 托管式节点组迁移到 EKS 自动模式](auto-migrate-mng.md)。
+ 要从自主管理型 Karpenter 迁移，请参阅[使用 kubectl 从 Karpenter 迁移到 EKS 自动模式](auto-migrate-karpenter.md)。
# 使用 kubectl 从 Karpenter 迁移到 EKS 自动模式
本主题将演示使用 kubectl 将工作负载从 Karpenter 迁移到 Amazon EKS 自动模式的过程。迁移可以逐步执行，从而让您按照自己的节奏移动工作负载，同时在整个迁移期间保持集群稳定性和应用程序可用性。
借助下面概述的分步方法，您可以在迁移期间并行运行 Karpenter 和 EKS 自动模式。借助这种双重运行策略，您可以在完全停用 Karpenter 之前验证 EKS 自动模式下的工作负载行为，从而帮助保证平稳过渡。您可以逐一或分组迁移应用程序，从而灵活地适应自己的具体运行要求和风险承受能力。
## 先决条件
开始迁移之前，请确保您满足以下条件：
+ 您的集群已安装 Karpenter 版本 1.1 或更高版本。有关更多信息，请参阅 Karpenter 文档中的 [Upgrading to 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110)。
+ 已安装 `kubectl` 并连接到集群。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
本主题假设您熟悉 Karpenter 和节点池。有关更多信息，请参阅 [Karpenter 文档](https://karpenter.sh/)。
## 第 1 步：在集群上启用 EKS 自动模式
使用 AWS CLI 或管理控制台在现有集群上启用 EKS 自动模式。有关更多信息，请参阅 [在现有集群上启用 EKS 自动模式](auto-enable-existing.md)。
**注意**
启用 EKS 自动模式时，不要在迁移过程的这一阶段启用 `general purpose` 节点池。此节点池不是选择性的。
有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。
## 第 2 步：创建一个受污染的 EKS 自动模式节点池
为 EKS 自动模式创建一个带有污点的新节点池。这样可以确保不会在新的 EKS 自动模式节点上自动调度现有的容器组。此节点池使用 EKS 自动模式中内置的 `default` `NodeClass`。有关更多信息，请参阅 [为 Amazon EKS 创建节点类](create-node-class.md)。
带有污点的节点池示例：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
更新节点池要求以使其与您要迁移的 Karpenter 配置一致。您至少需要一项要求。
## 第 3 步：更新要迁移的工作负载
识别并更新要迁移到 EKS 自动模式的工作负载。为这些工作负载添加容忍度和节点选择器：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
实施此更改后，将可以在新的 EKS 自动模式节点上调度工作负载。
EKS 自动模式使用的标签与 Karpenter 不同。与 EC2 托管式实例相关的标签以 `eks.amazonaws.com` 开头。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
## 第 4 步：逐步迁移工作负载
对要迁移的每个工作负载重复第 3 步。这样就可以根据自己的要求和风险承受能力逐一或分组移动工作负载。
## 第 5 步：移除原始 Karpenter 节点池
迁移完所有工作负载后，您可以移除原始 Karpenter 节点池：
```
kubectl delete nodepool
```
## 第 6 步：从 EKS 自动模式节点池中移除污点（可选）
要让 EKS 自动模式成为新工作负载的默认模式，您可以从 EKS 自动模式节点池中移除污点：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## 第 7 步：从工作负载中移除节点选择器（可选）
如果您已从 EKS 自动模式节点池中移除污点，则可以选择从工作负载中移除节点选择器，因为 EKS 自动模式现已是默认模式：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## 第 8 步：从集群中卸载 Karpenter
移除 Karpenter 的步骤取决于最初的安装方式。有关更多信息，请参阅 [Karpenter install instructions](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter)。
# 从 EKS 托管式节点组迁移到 EKS 自动模式
在将 Amazon EKS 集群转换为使用 EKS 自动模式时，可以使用 eksctl CLI 工具将现有工作负载从托管节点组（MNG）顺利迁移。此过程可确保应用程序的持续可用，同时 EKS 自动模式也可优化计算资源。迁移过程可以尽可能减少对正在运行的应用程序的干扰。
本主题将演示安全地清空现有托管式节点组中的容器组，让 EKS 自动模式在新预置的实例上重新调度这些容器组的步骤。按照此过程，您既可以利用 EKS 自动模式的智能工作负载整合优势，同时还可以在整个迁移过程中保持应用程序的可用性。
## 先决条件
+ 启用 EKS 自动模式的集群
+ 已安装 `eksctl` CLI 并连接到集群。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
+ 集群上未安装 Karpenter。
## 过程
使用以下 `eksctl` CLI 命令启动清空现有托管式节点组实例中的容器组。EKS 自动模式将创建新节点来支持移位后容器组。
```
eksctl delete nodegroup --cluster= --name=
```
您需要为集群中的每个托管式节点组运行此命令。
有关此命令的更多信息，请参阅 eksctl 文档中的 [Deleting and draining nodegroups](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)。
# 从 EKS Fargate 迁移到 EKS 自动模式
本主题将演示使用 `kubectl` 将工作负载从 EKS Fargate 迁移到 Amazon EKS 自动模式的过程。迁移可以逐步执行，从而让您按照自己的节奏移动工作负载，同时在整个迁移期间保持集群稳定性和应用程序可用性。
借助下面概述的分步方法，您可以在迁移期间并行运行 EKS Fargate 和 EKS 自动模式。借助这种双重运行策略，您可以在完全停用 EKS Fargate 之前验证 EKS 自动模式下的工作负载行为，从而帮助保证平稳过渡。您可以逐一或分组迁移应用程序，从而灵活地适应自己的具体运行要求和风险承受能力。
## 将 Amazon EKS 自动模式与具有 AWS Fargate 的 EKS 进行比较
对于希望运行 EKS 的客户来说，尽管具有 AWS Fargate 的 Amazon EKS 仍是一种选择，但 Amazon EKS 自动模式是未来推荐的首选方法。EKS 自动模式完全符合 Kubernetes 要求，支持所有上游 Kubernetes 原语和平台工具，例如 Fargate 无法支持的 Istio。EKS 自动模式还完全支持所有 EC2 运行时购买选项，包括 GPU 和竞价型实例，有助于客户利用议定的 EC2 折扣以及其他节省机制。但是，将 EKS 与 Fargate 结合使用时，这些功能不可用。
此外，EKS 自动模式允许客户实现与 Fargate 相同的隔离模型，通过标准的 Kubernetes 调度功能确保每个 EC2 实例都运行一个应用程序容器。借助 Amazon EKS 自动模式，客户可以充分享受在 AWS 上运行 Kubernetes 的全部优势。Kubernetes 是一个完全符合 Kubernetes 要求的平台，可以灵活利用所有 EC2 和购买选项，同时保留 Fargate 提供的易用性以及从基础设施管理中抽象化的能力。
### 在 EKS 自动模式下实现与 Fargate 类似的隔离
要复制 Fargate 的容器组（pod）隔离模型（即每个容器组（pod）都运行在其独立的专用实例上），您可以使用 Kubernetes 的拓扑分布约束功能。这是跨节点控制容器组（pod）分布的推荐方法：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
在此配置中：
+ `maxSkew: 1` 确保任意两个节点之间的容器组（pod）数量差异最多为 1，从而有效地为每个节点分配一个容器组（pod）
+ `topologyKey: kubernetes.io/hostname` 将节点定义为拓扑域
+ `whenUnsatisfiable: DoNotSchedule` 在无法满足约束条件时阻止调度
+ `minDomains: 1` 确保在调度之前至少存在一个域（节点）
EKS 自动模式会根据需要自动预置新的 EC2 实例以满足此限制条件，以提供与 Fargate 相同的隔离模型，同时让您能够使用 EC2 实例的所有类型和购买选项。
或者，您可以使用容器组（pod）反关联性规则来实现更严格的隔离：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
带有 `requiredDuringSchedulingIgnoredDuringExecution` 的 `podAntiAffinity` 规则确保不能将两个带有标签 `app: isolated-app` 的容器组（pod）调度到同一个节点上。这种方法提供了与 Fargate 类似的硬隔离保障。
## 先决条件
开始迁移之前，请确保您满足以下条件
+ 设置带有 Fargate 的集群。有关更多信息，请参阅 [开始将 AWS Fargate 用于集群](fargate-getting-started.md)。
+ 已安装 `kubectl` 并将其连接到集群。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
## 步骤 1：检查 Fargate 集群
1. 检查带有 Fargate 的 EKS 集群是否正在运行：
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. 检查正在运行的容器组（pod）：
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. 在名为 `deployment_fargate.yaml` 的文件中创建部署：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 应用部署：
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. 检查容器组（pod）和部署：
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. 检查节点：
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## 步骤 2：在集群上启用 EKS 自动模式
1. 使用 AWS CLI 或管理控制台在现有集群上启用 EKS 自动模式。有关更多信息，请参阅 [在现有集群上启用 EKS 自动模式](auto-enable-existing.md)。
1. 检查节点池：
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## 第 3 步：更新要迁移的工作负载
识别并更新要迁移到 EKS 自动模式的工作负载。
要将工作负载从 Fargate 迁移到 EKS 自动模式，请应用注释 `eks.amazonaws.com/compute-type: ec2`。这可确保工作负载不会被 Fargate 调度（即使存在 Fargate 配置文件），而是由 EKS 自动模式节点池接管。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
1. 修改部署（例如 `deployment_fargate.yaml` 文件）以将计算类型更改为 `ec2`：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 应用部署。实施此更改后，即可在新的 EKS 自动模式节点上调度工作负载：
```
kubectl apply -f deployment_fargate.yaml
```
1. 检查部署是否正在 EKS 自动模式集群中运行：
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. 确认 EKS 自动模式托管式节点中没有正在运行的 Fargate 节点和正在运行的部署：
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## 第 4 步：逐步迁移工作负载
对要迁移的每个工作负载重复第 3 步。这样就可以根据自己的要求和风险承受能力逐一或分组移动工作负载。
## 步骤 5：删除原始 Fargate 配置文件
迁移完所有工作负载后，可以删除原始 `fargate` 配置文件。将 ** 替换为 Fargate 配置文件的名称：
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## 步骤 6：缩减 CoreDNS
由于 EKS 自动模式可以处理 CoreDNS，因此可将 `coredns` 部署缩减到 0：
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# 在 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
```
# 配置 EKS 自动模式设置
本章介绍如何配置 Amazon Elastic Kubernetes Service（EKS）自动模式集群的特定方面。虽然 EKS 自动模式会自动管理大多数基础设施组件，不过您也可以自定义某些功能来满足工作负载的要求。
使用本主题中介绍的配置选项，您可以修改联网设置、计算资源和负载均衡行为，同时继续享受自动化基础设施管理的优势。在进行任何配置更改之前，请检查以下各节中的可用选项，以确定哪种方法最适合您的需求。
| 您要配置哪些功能？ | 配置选项 |
| --- | --- |
| **节点联网和存储** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [为 Amazon EKS 创建节点类](create-node-class.md) |
| **节点计算资源** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [为 EKS 自动模式创建节点池](create-node-pool.md) |
| **静态容量节点池** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode 中的静态容量节点池](auto-static-capacity.md) |
| **应用程序负载均衡器设置** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [创建 IngressClass 以配置应用程序负载均衡器](auto-configure-alb.md) |
| **网络负载均衡器设置** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [使用服务注释配置网络负载均衡器](auto-configure-nlb.md) |
| **存储类设置** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [创建存储类](create-storage-class.md) |
| **控制 ODCR 使用情况** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [使用 EKS 自动模式控制将工作负载部署到容量预留中](auto-odcr.md) |
| **节点高级安全性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [为节点配置高级安全设置](auto-advanced-security.md) |
# 为 Amazon EKS 创建节点类
Amazon EKS 节点类是模板，可对 EKS 自动模式托管式节点的配置进行精细控制。节点类定义了适用于 EKS 集群中节点组的基础设施级别设置，包括网络配置、存储设置和资源标记等。本主题旨在介绍如何创建和配置节点类以满足您的具体运行要求。
如果需要在默认设置之外自定义 EKS 自动模式预置和配置 EC2 实例的方式，创建节点类可让您精准控制关键基础设施参数。例如，您可以指定私有子网放置来增强安全性，为性能敏感型工作负载配置实例临时存储，或者应用自定义标记以满足成本分配的需要。
## 创建节点类
要创建 `NodeClass`，请按以下步骤操作：
1. 创建一个包含节点类配置的 YAML 文件（例如 `nodeclass.yaml`）
1. 使用 `kubectl` 将此配置应用到集群
1. 在节点池配置中引用该节点类。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
您需要已经安装并配置好 `kubectl`。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
### 基本节点类示例
以下是一个节点类示例：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
此节点类增加了节点上的临时存储量。
使用以下命令应用此配置：
```
kubectl apply -f nodeclass.yaml
```
然后在节点池配置中引用该节点类。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
## 创建节点类访问条目
如果您创建自定义节点类，则需要创建 EKS 访问条目以允许节点加入集群。如果您使用内置节点类和节点池，EKS 会自动创建访问条目。
有关访问条目工作原理的信息，请参阅[使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)。
为 EKS 自动模式节点类创建访问条目时，需要使用 `EC2` 访问条目类型。
### 使用 CLI 创建访问条目
**要为 EC2 节点创建访问条目并关联 EKS 自动节点策略，请执行以下操作：**
使用集群名称和节点角色 ARN 更新以下 CLI 命令。在节点类 YAML 中指定节点角色 ARN。
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### 使用 CloudFormation 创建访问条目
**要为 EC2 节点创建访问条目并关联 EKS 自动节点策略，请执行以下操作：**
使用集群名称和节点角色 ARN 更新以下 CloudFormation。在节点类 YAML 中指定节点角色 ARN。
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
有关部署 CloudFormation 堆栈的信息，请参阅 [CloudFormation 入门](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## 节点类规范
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws:kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## 注意事项
+ 如果要验证实例的本地存储空间大小，您可以描述该节点以查看临时存储资源。
+ **卷加密**：EKS 使用配置的自定义 KMS 密钥来加密实例的只读根卷和读/写数据卷。
+ **替换节点 IAM 角色** – 如果您更改与 `NodeClass` 关联的节点 IAM 角色，则需要创建一个新的访问条目。在创建集群期间，EKS 会自动为节点 IAM 角色创建一个访问条目。节点 IAM 角色需要具有 `AmazonEKSAutoNodePolicy` EKS 访问策略。有关更多信息，请参阅 [使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)。
+ **最大容器组（pod）密度**：在 EKS 中，一个节点上最多可以有 110 个容器组（pod）。此限制将在计算现有最大容器组（pod）数量之后应用。有关更多信息，请参阅 [选择最优的 Amazon EC2 节点实例类型](choosing-instance-type.md)。
+ **标签** – 如果要将标签从 Kubernetes 传播到 EC2，则需要配置额外的 IAM 权限。有关更多信息，请参阅 [了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)。
+ **默认节点类** – 不要将自定义节点类命名为 `default`。这是因为 EKS 自动模式包含一个名为 `default` 的 `NodeClass`，您启用至少一个内置 `NodePool` 时，系统会自动预置该节点类。有关启用内置 `NodePools` 的信息，请参阅[启用或禁用内置节点池](set-builtin-node-pools.md)。
+ **多个子网的 `subnetSelectorTerms` 行为** – 如果存在多个符合 `subnetSelectorTerms` 条件或您按照 ID 提供的子网，则 EKS 自动模式会创建分布在子网中的节点。
+ 如果子网位于不同的可用区（AZ），则可以使用 Kubernetes 功能 [例如[容器组（pod）拓扑分布约束](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints)和[拓扑感知路由](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)] 分别在各个区域之间分布容器组（pod）和流量。
+ 如果*同一个可用区中*有多个子网与 `subnetSelectorTerms` 匹配，则 EKS 自动模式会在分布在该可用区子网中的每个节点上创建容器组（pod）。EKS 自动模式在同一可用区内其他子网中的每个节点上创建辅助网络接口。它根据每个子网中可用 IP 地址的数量进行选择，以便更高效地使用子网。但是，您无法指定 EKS 自动模式为每个容器组（pod）使用哪个子网；如果您需要容器组（pod）在特定子网中运行，请改用 [为容器组（pod）配置独立的子网和安全组](#pod-subnet-selector)。
## 为容器组（pod）配置独立的子网和安全组
`podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms` 字段允许容器组（pod）在与其节点不同的子网和安全组中运行，从而实现高级联网配置。两个字段必须同时指定。这种分离增强了对网络流量路由和安全策略的控制。
**注意**
此功能不同于用于非 EKS Auto Mode 计算环境中与 AWS VPC CNI 配合使用的[容器组（pod）安全组](security-groups-for-pods.md)（SGPP）功能。EKS Auto Mode 不支持 SGPP。如需为容器组（pod）流量应用不同的安全组，请改用 `NodeClass` 中的 `podSecurityGroupSelectorTerms`。安全组在 `NodeClass` 级别生效，这意味着使用该 `NodeClass` 的节点上的所有容器组（pod）共享相同的容器组（pod）安全组。
### 工作原理
在配置 `podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms` 时：
1. 节点的主要 ENI 使用来自 `subnetSelectorTerms` 和 `securityGroupSelectorTerms` 的子网与安全组。该接口仅分配节点自身的 IP 地址。
1. EKS Auto Mode 在与 `podSubnetSelectorTerms` 匹配的子网中创建辅助 ENI，并附加 `podSecurityGroupSelectorTerms` 中的安全组。默认情况下，容器组（pod）IP 地址从这些辅助 ENI 中以 /28 前缀分配，当连续前缀块不可用时，自动回退到辅助 IP（/32）。如果 `advancedNetworking` 中的 `ipv4PrefixSize` 设置为 `"32"`，则仅使用辅助 IP。
1. `podSecurityGroupSelectorTerms` 中指定的安全组适用于 VPC 内的容器组（pod）流量。对于发往 VPC 之外的流量，Pod 使用节点的主 ENI（及其安全组），因为源网络地址转换 (SNAT) 会将容器组（pod）IP 转换为节点 IP。您可以通过 `NodeClass` 中的 `snatPolicy` 字段修改此行为。
### 使用案例
在以下场景中，使用 `podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms`：
+ 应用不同的安全组分别控制节点和容器组（pod）的流量。
+ 需要将基础设施流量（节点间通信）与应用流量（容器组（pod）间通信）分开。
+ 对节点子网应用与容器组（pod）子网不同的网络配置。
+ 在不影响容器组（pod）流量的情况下，专门为节点流量配置反向代理或网络筛选。使用 `advancedNetworking` 和 `certificateBundles` 定义您的反向代理以及代理的任何自签名证书或私有证书。
### 示例配置
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### 为容器组（pod）配置独立子网和安全组的注意事项
+ **安全组范围**：`podSecurityGroupSelectorTerms` 中的安全组附加到辅助 ENI，适用于 VPC 内的容器组（pod）流量。当 SNAT 启用时（默认 `snatPolicy: Random`），离开 VPC 的流量会转换为节点主 ENI 的 IP 地址，因此节点的 `securityGroupSelectorTerms` 安全组将应用于此类流量。如果您设置 `snatPolicy: Disabled`，容器组（pod）将使用自己的 IP 地址来处理所有流量，此时必须确保路由和安全组已相应配置。
+ **NodeClass 级别的粒度**：容器组（pod）安全组适用于调度到使用 `NodeClass` 的节点上的所有容器组（pod） 如需为不同工作负载应用不同的安全组，请创建独立的 `NodeClass` 和 `NodePool` 资源，并使用污点、容忍度或节点选择器将工作负载调度到合适的节点。
+ **降低容器组（pod）密度**：每个节点上可运行的容器组（pod）数量减少，因为节点的主网络接口预留给节点 IP，无法用于容器组（pod）。
+ **子网选择器限制**：标准 `subnetSelectorTerms` 和 `securityGroupSelectorTerms` 配置不适用于容器组（pod）子网或安全组选择。
+ **网络规划**：确保节点和容器组（pod）子网中有足够的 IP 地址空间，以满足工作负载需求。
+ **路由配置**：验证容器组（pod）子网的路由表和网络访问控制列表（ACL）是否已针对节点和容器组（pod）子网之间的通信进行正确配置。
+ **可用区**：确认已跨多个可用区创建容器组（pod）子网。如果您使用的是特定容器组（pod）子网，则该子网必须与节点子网可用区位于同一可用区中。
## 容器组（pod）的辅助 IP 模式
`ipv4PrefixSize` 字段通过仅为节点分配辅助 IP 地址的方式，实现高级网络配置。此功能不会为节点分配前缀（/28），并且只保留一个辅助 IP 作为 MinimalIPTarget。
### 使用案例
在需要执行以下操作时使用 `ipv4PrefixSize`：
+ **降低了 IP 利用率**：每个节点中只会预热一个 IP 地址。
+ **降低容器组（pod）流失率**：容器组（pod）的创建速度不是主要问题。
+ **没有前缀分段**：前缀导致的分段是使用自动模式的主要问题或障碍。
### 示例配置
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### 辅助 IP 模式的注意事项
+ **降低了容器组（pod）创建速度**：由于只预热了一个辅助 IP，因此 IPAM 服务需要更多时间在创建更多容器组（pod）时预置 IP。
## 在 IPv6 集群中禁用 IPv6 容器组（pod）的 IPv4 出口。
默认情况下，`enableV4Egress` 字段为 `true`。对于自动模式 IPv6 集群，该功能可以被禁用，这样一来，自动模式就不会为 IPv6 容器组（pod）创建仅用于出站的 IPv4 接口。IPv4 出口接口不受网络策略强制约束，这一点非常重要。网络策略仅在容器组（pod）的主接口（eth0）上强制执行。
### 使用案例
在需要执行以下操作时使用 `enableV4Egress`：
+ **使用 IPv6 集群**：默认情况下允许 IPv4 出口流量。
+ **使用网络策略**：目前 EKS 网络策略不支持双堆栈。禁用 `enableV4Egress` 可防止容器组（pod）流量意外通过 IPv4 流出。
### 示例配置
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### 禁用 enableV4Egress 的注意事项
+ **IPv6 集群中的网络策略**：默认情况下，IPv6 集群允许 IPv4 流量。设置 `enableV4Egress: false` 可阻止 IPv4 出口流量，从而增强安全性，尤其是在与网络策略一起使用时。
# 为 EKS 自动模式创建节点池
借助 Amazon EKS 节点池可以灵活地管理 Kubernetes 集群中的计算资源。本主题演示如何使用 Karpenter 创建和配置节点池，Karpenter 是一种有助于优化集群扩展和资源利用率的节点预置工具。借助 Karpenter 的节点池资源，您可以定义计算资源的具体要求，包括实例类型、可用区、架构和容量类型。
您无法修改内置的 `system` 和 `general-purpose` 节点池，只能启用或禁用这些节点池。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。
借助节点池规范，您可以通过各种受支持的标签和要求对 EKS 集群的计算资源进行精细控制。其中包括用于指定 EC2 实例类别、CPU 配置、可用区、架构（ARM64/AMD64）和容量类型（竞价型或按需型）的选项。您还可以设置有关 CPU 和内存使用量的资源限制，确保集群始终遵守所需的运行界限。
EKS 自动模式利用通用的 Kubernetes 标签，从而通过一致和标准化的方法来标识节点特征。这些标签（例如用于可用区的 `topology.kubernetes.io/zone` 标签和用于 CPU 架构的 `kubernetes.io/arch` 标签）都遵循约定的 Kubernetes 规范。此外，特定于 EKS 的标签（前缀为 `eks.amazonaws.com/`）通过实例类型、CPU 制造商、GPU 功能和联网规范等 AWS 特定属性进一步扩展了此功能。这种标准化的标记系统有利于与现有 Kubernetes 工具的无缝集成，同时实现深入的 AWS 基础设施集成。
## 创建节点池
按照以下步骤为 Amazon EKS 集群创建节点池：
1. 创建一个包含所需节点池配置的 YAML 文件并将其命名为 `nodepool.yaml`。您可以使用以下示例配置。
1. 将节点池应用到集群：
```
kubectl apply -f nodepool.yaml
```
1. 验证节点池是否已成功创建：
```
kubectl get nodepools
```
1. （可选）监控节点池状态：
```
kubectl describe nodepool default
```
确认节点池引用了集群中存在的有效节点类。节点类定义了计算资源的 AWS 特定配置。有关更多信息，请参阅 [为 Amazon EKS 创建节点类](create-node-class.md)。
## 示例节点池
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## 受 EKS 自动模式支持的标签
EKS 自动模式支持以下通用标签。
**注意**
EKS 自动模式使用的标签与 Karpenter 不同。与 EC2 托管式实例相关的标签以 `eks.amazonaws.com` 开头。
| 标签 | 示例 | 描述 |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS 区域 |
| node.kubernetes.io/instance-type | g4dn.8xlarge | AWS 实例类型 |
| kubernetes.io/arch | amd64 | 架构是由实例上的 [GOARCH 值](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)来定义 |
| karpenter.sh/capacity-type | spot | 容量类型包括 `spot`、`on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | 使用特定虚拟机监控程序的实例类型 |
| eks.amazonaws.com/compute-type | 自动 | 标识 EKS 自动模式托管式节点 |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | 支持（或不支持）传输中加密的实例类型 |
| eks.amazonaws.com/instance-category | g | 相同类别的实例类型，通常是代次编号之前的字符串 |
| eks.amazonaws.com/instance-generation | 4 | 实例类别中的实例类型代次编号 |
| eks.amazonaws.com/instance-family | g4dn | 属性相似但资源数量不同的实例类型 |
| eks.amazonaws.com/instance-size | 8xlarge | 资源数量相似但属性不同的实例类型 |
| eks.amazonaws.com/instance-cpu | 32 | 实例上的 CPU 数量 |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU 制造商的名称 |
| eks.amazonaws.com/instance-memory | 131072 | 实例内存兆比字节数 |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | 实例可用 EBS 最大[兆比特](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance)数 |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | 实例可用[基线兆比特](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)数 |
| eks.amazonaws.com/instance-gpu-name | t4 | 实例上 GPU 的名称（如有） |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | CPU 制造商的名称 |
| eks.amazonaws.com/instance-gpu-count | 1 | 实例 GPU 数量 |
| eks.amazonaws.com/instance-gpu-memory | 16384 | GPU 内存兆比字节数 |
| eks.amazonaws.com/instance-local-nvme | 900 | 实例本地 nvme 存储空间千兆比字节数 |
**注意**
EKS 自动模式仅支持某些实例，并对最小大小有要求。有关更多信息，请参阅 [EKS 自动模式支持的实例参考](automode-learn-instances.md#auto-supported-instances)。
## 不受 EKS 自动模式支持的标签
EKS 自动模式不支持以下标签。
+ EKS 自动模式仅支持 Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## 禁用内置节点池
如果创建自定义节点池，则可以禁用内置节点池。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。
## 不含内置节点池的集群
您可以创建不含内置节点池的集群。如果组织创建了自定义节点池，此功能就大有用处。
**注意**
当您创建不含内置节点池的集群时，不会自动预置 `default` NodeClass。您需要创建一个自定义 NodeClass。有关更多信息，请参阅 [为 Amazon EKS 创建节点类](create-node-class.md)。
**概述：**
1. 创建一个 EKS 集群，`nodePools` 值和 `nodeRoleArn` 值皆为空。
+ 示例 eksctl `autoModeConfig`：
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
有关更多信息，请参阅 [使用 eksctl CLI 创建 EKS 自动模式集群](automode-get-started-eksctl.md)。
1. 创建具有节点角色 ARN 的自定义节点类
+ 有关更多信息，请参阅 [为 Amazon EKS 创建节点类](create-node-class.md)。
1. 为自定义节点类创建访问条目
+ 有关更多信息，请参阅 [创建节点类访问条目](create-node-class.md#auto-node-access-entry)。
1. 如上所述，创建自定义节点池。
## 中断
您可以配置 EKS 自动模式，以多种方式通过 NodePool 中断节点。您可以使用 `spec.disruption.consolidationPolicy`、`spec.disruption.consolidateAfter` 或 `spec.template.spec.expireAfter`。您也可以通过 NodePool 的 `spec.disruption.budgets` 对 EKS 自动模式的中断进行速率限制。您还可以控制时间范围和同时中断的节点数量。有关配置此行为的说明，请参阅 Karpenter 文档中的 [Disruption](https://karpenter.sh/docs/concepts/disruption/)。
您可就以下目的配置节点池中断功能：
+ 发现实例未得到充分利用的情况，据此整合工作负载。
+ 创建节点池中断预算，对偏移、空置和整合导致的节点终止进行速率限制。
EKS 自动模式默认会：
+ 整合未得到充分利用的实例。
+ 在 336 小时后终止实例。
+ 将单个中断预算设置为 10% 的节点。
+ 允许在发布新的自动模式 AMI（约每周一次）时由于漂移而更换节点。
## 终止宽限期
如果未在 EKS Auto NodePool 上明确定义 `terminationGracePeriod`，系统会自动对关联的 NodeClaim 应用默认的 24 小时终止宽限期。虽然 EKS Auto 客户不会在其自定义 NodePool 配置中看到默认的 `terminationGracePeriod`，但他们会在 NodeClaim 上看到这个默认值。无论是在 NodePool 上明确设置了宽限期还是在 NodeClaim 上设置了默认宽限期，该功能都保持一致，从而确保整个集群中的节点终止行为可预测。
# EKS Auto Mode 中的静态容量节点池
Amazon EKS Auto Mode 支持静态容量节点池，无论容器组（pod）需求如何，这些节点池都保持固定数量的节点。如果工作负载需要可预测容量、预留实例，或需要保持稳定的基础设施占用空间以满足特定合规性要求，静态容量节点池非常有用。
与基于容器组（pod）调度要求进行扩展的动态节点池不同，静态容量节点池会保留您配置的节点数量。
## 配置静态容量节点池
要创建静态容量节点池，请在 NodePool 规范中设置 `replicas` 字段。`replicas` 字段定义节点池将维持的确切节点数。有关如何配置 `replicas` 的信息，请参阅 [示例](#static-capacity-examples)。
## 静态容量节点池限制
静态容量节点池有几个重要的限制和行为：
**配置限制：**
+ **无法切换模式**：一旦在节点池上设置了 `replicas`，就无法将其移除。节点池无法在静态和动态模式之间切换。
+ **有限的资源限制**：限制部分中仅支持 `limits.nodes` 字段。CPU 和内存限制不适用。
+ **无权重字段**：由于节点选择不是基于优先级，因此无法在静态容量节点池上设置 `weight` 字段。
**操作行为：**
+ **无整合**：静态容量池中的节点不考虑整合。
+ **扩展操作**：扩展操作会绕过节点中断预算，但仍然遵守 PodDisruptionBudgets。
+ **节点更换**：节点仍会因偏差（例如 AMI 更新）或因过期而被替换，具体方式取决于您的配置。
## 最佳实践
**容量规划：**
+ 将 `limits.nodes` 设置为高于 `replicas`，以允许在节点替换操作期间进行临时扩展。
+ 设置限制时，请考虑节点偏差或 AMI 更新期间所需的最大容量。
**实例选择：**
+ 如果您有预留实例或特定的硬件要求，请使用特定的实例类型。
+ 避免要求过于严格，因为这可能会限制扩展期间的实例可用性。
**中断管理：**
+ 配置适当的中断预算，以平衡可用性与维护操作。
+ 在设置预算百分比时，请考虑应用程序对节点替换的容忍度。
**监控：**
+ 定期监控 `status.nodes` 字段，确保保持所需容量。
+ 设置警报，以了解实际节点数何时偏离所需的副本。
**可用区分布：**
+ 为了实现高可用性，请在多个可用区之间分布静态容量。
+ 当您创建跨多个可用区的静态容量节点池时，EKS Auto Mode 会将节点分布到指定可用区，但不能保证分布均匀。
+ 为了在可用区之间实现可预测且均匀的分布，请创建单独的静态容量节点池，每个节点池都根据 `topology.kubernetes.io/zone` 要求固定到特定的可用区。
+ 如果您需要在 3 个可用区中均匀分布 12 个节点，请创建 3 个节点池，每个节点池包含 4 个副本，而不是在 3 个可用区中仅创建 1 个节点池，其中共 12 个副本。
## 扩展静态容量节点池
您可以使用 `kubectl scale` 命令更改静态容量节点池中的副本数量：
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
进行缩减时，EKS 自动模式将正常终止节点，同时遵守 PodDisruptionBudgets，并允许将正在运行的容器组（pod）重新调度至剩余节点。
## 监控静态容量节点池
使用以下命令监控静态容量节点池：
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes` 字段显示节点池当前管理的节点数量，在正常条件下，该数量应与所需的 `replicas` 数量相匹配。
## 问题排查
**节点未到达所需的副本数：**
+ 检查 `limits.nodes` 值是否足够
+ 确认您的要求不会过度限制实例选择
+ 查看您正在使用的实例类型和区域的 AWS 服务配额
**节点替换花费的时间太长：**
+ 调整中断预算，允许更多并发替换
+ 检查 PodDisruptionBudgets 是否阻止了节点终止
**节点意外终止：**
+ 检查 `expireAfter` 和 `terminationGracePeriod` 设置
+ 检查是否存在手动节点终止或 AWS 维护事件
## 示例
### 基本静态容量节点池
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### 特定实例类型的静态容量
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### 多可用区静态容量节点池
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### 带容量预留的静态容量
以下示例展示了如何将静态容量节点池与 EC2 容量预留配合使用。有关在 EKS Auto Mode 中使用 EC2 容量预留的更多信息，请参阅 [使用 EKS 自动模式控制将工作负载部署到容量预留中](auto-odcr.md)。
定义 `capacityReservationSelectorTerms` 的 `NodeClass`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
引用上述 `NodeClass` 并使用 `karpenter.sh/capacity-type: reserved` 的 `NodePool`
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# 创建 IngressClass 以配置应用程序负载均衡器
EKS 自动模式可自动执行例行负载均衡任务，包括向互联网公开集群应用程序等。
AWS 建议使用应用程序负载均衡器（ALB）来处理 HTTP 和 HTTPS 流量。应用程序负载均衡器可以根据请求的内容进行路由。有关应用程序负载均衡器的更多信息，请参阅 [What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
EKS 自动模式会创建和配置应用程序负载均衡器（ALB）。例如，EKS 自动模式会在您创建 `Ingress` Kubernetes 对象时创建一个负载均衡器，并配置为使用该负载均衡器来路由指向集群工作负载的流量。
**概述**
1. 创建您希望向互联网公开的工作负载。
1. 创建一个 `IngressClassParams` 资源并指定 AWS 特定的配置值，例如用于 SSL/TLS 和 VPC 子网的证书。
1. 创建一个 `IngressClass` 资源并将 EKS 自动模式指定为该资源的控制器。
1. 创建一个 `Ingress` 资源，以将某个 HTTP 路径和端口与集群工作负载关联。
EKS 自动模式将使用 `IngressClassParams` 资源中指定的负载均衡器配置，创建一个指向 `Ingress` 资源中指定工作负载的应用程序负载均衡器。
## 先决条件
+ 在 Amazon EKS 集群上启用 EKS 自动模式
+ 配置好 Kubectl 以连接到集群
+ 您可以使用 `kubectl apply -f ` 将以下示例配置 YAML 文件应用到集群。
**注意**
EKS 自动模式需要子网标签来标识公有子网和私有子网。
如果使用 `eksctl` 创建集群，则已包含这些标签。
了解如何[为 EKS 自动模式的子网添加标签](tag-subnets-auto.md)。
## 第 1 步：创建工作负载
首先，创建您希望向互联网公开的工作负载。这可以是任何提供 HTTP 流量的 Kubernetes 资源，例如部署或服务。
此示例使用一个名为 `service-2048`、在端口 `80` 上侦听的简单 HTTP 服务。通过应用以下 `2048-deployment-service.yaml` 清单来创建此服务及其部署：
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
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
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
将配置应用到您的集群：
```
kubectl apply -f 2048-deployment-service.yaml
```
上面列出的资源将在默认命名空间中创建。可以通过运行以下命令进行验证：
```
kubectl get all -n default
```
## 第 2 步：创建 IngressClassParams
创建一个 `IngressClassParams` 对象来指定应用程序负载均衡器的 AWS 特定配置选项。在本示例中，我们创建了一个名为 `alb` 的 `IngressClassParams` 资源（您将在下一步中使用该资源），该资源在名为 `alb-ingressclassparams.yaml` 的文件中将负载均衡器方案指定为 `internet-facing`。
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
将配置应用到您的集群：
```
kubectl apply -f alb-ingressclassparams.yaml
```
## 第 3 步：创建 IngressClass
在名为 `alb-ingressclass.yaml` 的文件中创建 `IngressClass`，它引用 `IngressClassParams` 资源中设置的 AWS 特定配置值。记下 `IngressClass` 的名称。在此示例中，`IngressClass` 和 `IngressClassParams` 的名称都为 `alb`。
使用 `is-default-class` 注释来控制 `Ingress` 资源在默认情况下是否应使用该类。
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
有关配置选项的更多信息，请参阅 [IngressClassParams 参考](#ingress-reference)。
将配置应用到您的集群：
```
kubectl apply -f alb-ingressclass.yaml
```
## 第 4 步：创建 Ingress
在名为 `alb-ingress.yaml` 的文件中创建 `Ingress` 资源。此资源的用途是将应用程序负载均衡器上的路径和端口关联到集群中的工作负载。在本示例中，我们创建了一个名为 `2048-ingress` 的 `Ingress` 资源，该资源将流量路由到端口 80 上名为 `service-2048` 的服务。
有关如何配置此资源的更多信息，请参阅 Kubernetes 文档中的 [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)。
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
将配置应用到您的集群：
```
kubectl apply -f alb-ingress.yaml
```
## 第 5 步：检查状态
使用 `kubectl` 来查找 `Ingress` 的状态。负载均衡器可能需要过几分钟会可用。
使用您在上一步中设置的 `Ingress` 资源的名称。例如：
```
kubectl get ingress 2048-ingress
```
资源准备就绪后，检索负载均衡器的域名。
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
要在 Web 浏览器中查看服务，请检查 `Ingress` 抢救文件中指定的端口和路径。
## 第 6 步：清除
要清理负载均衡器，请使用以下命令：
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS 自动模式会自动删除您的 AWS 账户中关联的负载均衡器。
## IngressClassParams 参考
下表列举了常用配置选项的快速参考。
| 字段 | 说明 | 示例值 |
| --- | --- | --- |
| `scheme` | 定义 ALB 是内部专用还是面向互联网 | `internet-facing` |
| `namespaceSelector` | 限定可以使用此 IngressClass 的命名空间 | `environment: prod` |
| `group.name` | 将多个 Ingress 分组以共享单个 ALB | `retail-apps` |
| `ipAddressType` | 设置 ALB 的 IP 地址类型 | `dualstack` |
| `subnets.ids` | 用于 ALB 部署的子网 ID 列表 | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | 用于为 ALB 选择子网的标签筛选条件 | `Environment: prod` |
| `certificateARNs` | 要使用的 SSL 证书的 ARN | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | AWS 资源的自定义标签 | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | 负载均衡器特定的属性 | `idle_timeout.timeout_seconds: 60` |
## 注意事项
+ 您不能使用在 IngressClass 上的注释来配置用于 EKS 自动模式的负载均衡器。IngressClass 配置应通过 IngressClassParams 完成。但您可以在单个 Ingress 资源上使用注解来配置负载均衡器的行为（例如 `alb.ingress.kubernetes.io/security-group-prefix-lists` 或 `alb.ingress.kubernetes.io/conditions.*`）。
+ 您无法使用 EKS 自动模式设置 [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)。
+ 您必须更新集群 IAM 角色才能支持将标签从 Kubernetes 传播到 AWS 负载均衡器资源。有关更多信息，请参阅 [EKS 自动模式资源的自定义 AWS 标签](auto-learn-iam.md#tag-prop)。
+ 有关将资源关联到 EKS 自动模式或自主管理型 AWS 负载均衡器控制器的信息，请参阅[迁移参考](migrate-auto.md#migration-reference)。
+ 有关修复负载均衡器问题的信息，请参阅 [EKS 自动模式故障排除](auto-troubleshoot.md)。
+ 有关使用 EKS 自动模式的负载均衡功能时的其他注意事项，请参阅[负载均衡](auto-networking.md#auto-lb-consider)。
以下表格详细比较了 EKS 自动模式的 IngressClassParams、Ingress 注释和 TargetGroupBinding 配置的更改。这些表格重点介绍了 EKS 自动模式的负载均衡功能与开源负载均衡器控制器之间的主要区别，包括 API 版本更改、已弃用的功能和更新后的参数名称等。
### IngressClassParams
| 旧版 | New | 说明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本更改 |
| `spec.certificateArn` | `spec.certificateARNs` | 支持多个证书 ARN |
| `spec.subnets.tags` | `spec.subnets.matchTags` | 更改了子网匹配架构 |
| `spec.listeners.listenerAttributes` | 不支持 | 尚未得到 EKS 自动模式的支持 |
### Ingress 注释
| 旧版 | New | 说明 |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | 不支持 | 在 Ingress 对象上使用 `spec.ingressClassName` |
| `alb.ingress.kubernetes.io/group.name` | 不支持 | 仅指定 IngressClass 中的组 |
| `alb.ingress.kubernetes.io/waf-acl-id` | 不支持 | 改用 WAF v2 |
| `alb.ingress.kubernetes.io/web-acl-id` | 不支持 | 改用 WAF v2 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | 不支持 | 禁用了 Shield 集成 |
| `alb.ingress.kubernetes.io/auth-type: oidc` | 不支持 | 当前不支持 OIDC 身份验证类型。 |
### TargetGroupBinding
| 旧版 | New | 说明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本更改 |
| `spec.targetType` 可选 | `spec.targetType` 必需 | 显式目标类型规范 |
| `spec.networking.ingress.from` | 不支持 | 不再支持没有安全组的 NLB |
要使用自定义 TargetGroupBinding 功能，您必须使用带有集群名称的 eks:eks-cluster-name 标签标记目标组，从而向控制器授予必要的 IAM 权限。请注意，当 TargetGroupBinding 资源或集群被删除时，控制器将删除目标组。
# 使用服务注释配置网络负载均衡器
了解如何使用 Kubernetes 服务注释在 Amazon EKS 中配置网络负载均衡器（NLB）。本主题介绍 EKS 自动模式支持的用于自定义 NLB 行为的注释，包括互联网可访问性、运行状况检查、SSL/TLS 终止和 IP 目标模式。
在 EKS 自动模式下创建类型为 `LoadBalancer` 的 Kubernetes 服务时，EKS 会根据您指定的注释自动预置和配置 AWS 网络负载均衡器。借助这种声明式方法，您可以直接通过 Kubernetes 清单来管理负载均衡器配置，确保遵循基础设施即代码实践。
对于所有 LoadBalancer 类型的服务，EKS 自动模式会默认处理网络负载均衡器预置，无需额外的控制器安装或配置。`loadBalancerClass: eks.amazonaws.com/nlb` 规范会自动设置为集群的默认值，这不仅简化了部署过程，同时也保持了与现有 Kubernetes 工作负载的兼容性。
**注意**
EKS 自动模式需要子网标签来标识公有子网和私有子网。
如果使用 `eksctl` 创建集群，则已包含这些标签。
了解如何[为 EKS 自动模式的子网添加标签](tag-subnets-auto.md)。
## 示例服务
有关 Kubernetes `Service` 资源的更多信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/services-networking/service/)。
请参阅下面的示例 `Service` 资源：
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## 常用注释
下表列举了 EKS 自动模式支持的常用注释。请注意，EKS 自动模式可能并非支持所有注释。
**提示**
以下所有注释都需要加上前缀 `service.beta.kubernetes.io/`
| 字段 | 说明 | 示例 |
| --- | --- | --- |
| `aws-load-balancer-type` | 指定负载均衡器类型。新部署请使用 `external`。 | `external` |
| `aws-load-balancer-nlb-target-type` | 指定是将流量路由到节点实例还是直接路由到容器组 IP。标准部署请使用 `instance`，直接路由到容器组请使用 `ip`。 | `instance` |
| `aws-load-balancer-scheme` | 指定负载均衡器是面向内部还是互联网。 | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | 目标组的运行状况检查协议。常用选项是 `TCP`（默认）或 `HTTP`。 | `HTTP` |
| `aws-load-balancer-healthcheck-path` | 使用 HTTP/HTTPS 协议时进行运行状况检查的 HTTP 路径。 | `/healthz` |
| `aws-load-balancer-healthcheck-port` | 用于运行状况检查的端口。可以是特定的端口号，也可以是 `traffic-port`。 | `traffic-port` |
| `aws-load-balancer-subnets` | 指定要在其中创建负载均衡器的子网。可以使用子网 ID 或名称。 | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | 来自 AWS Certication Manager 的适用于 HTTPS/TLS 的 SSL 证书 ARN。 | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | 指定应使用 SSL/TLS 的端口。 | `443, 8443` |
| `load-balancer-source-ranges` | 被允许访问该负载均衡器的 CIDR 范围。 | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | 要应用于负载均衡器和相关资源的其他 AWS 标签。 | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | 指定负载均衡器是使用 IPv4 还是双栈（IPv4 \$1 IPv6）地址。 | `ipv4` 或 `dualstack` |
## 注意事项
+ 您必须更新集群 IAM 角色才能支持将标签从 Kubernetes 传播到 AWS 负载均衡器资源。有关更多信息，请参阅 [EKS 自动模式资源的自定义 AWS 标签](auto-learn-iam.md#tag-prop)。
+ 有关将资源关联到 EKS 自动模式或自主管理型 AWS 负载均衡器控制器的信息，请参阅[迁移参考](migrate-auto.md#migration-reference)。
+ 有关修复负载均衡器问题的信息，请参阅 [EKS 自动模式故障排除](auto-troubleshoot.md)。
+ 有关使用 EKS 自动模式的负载均衡功能时的其他注意事项，请参阅[负载均衡](auto-networking.md#auto-lb-consider)。
将负载均衡模式迁移到 EKS 自动模式进时，需要对服务注释和资源配置进行一些更改。下表总结了旧版和新版实现之间的主要区别，包括不支持的选项和建议的替代方案。
### 服务注释
| 旧版 | New | 说明 |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | 不支持 | 在服务上使用 `spec.loadBalancerSourceRanges` |
| `service.beta.kubernetes.io/aws-load-balancer-type` | 不支持 | 在服务上使用 `spec.loadBalancerClass` |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | 不支持 | 使用 `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | 不支持 | 请改用 `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` |
| 各种负载均衡器属性 | 不支持 | 使用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | 不支持 | 请改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | 不支持 | 请改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | 不支持 | 请改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | 不支持 | 请改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
要迁移已弃用的负载均衡器属性注释，请将这些设置合并到 `service.beta.kubernetes.io/aws-load-balancer-attributes` 注释中。此注释接受以逗号分隔的负载均衡器属性键值对列表。例如，要指定访问日志记录和跨区负载均衡，请使用以下格式：
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
这种合并后的格式让您可以更加一致、灵活地配置负载均衡器属性，同时减少所需的单独注释数量。检查您现有的服务配置并进行更新以使用此合并后的格式。
### TargetGroupBinding
| 旧版 | New | 说明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本更改 |
| `spec.targetType` 可选 | `spec.targetType` 必需 | 显式目标类型规范 |
| `spec.networking.ingress.from` | 不支持 | 不再支持没有安全组的 NLB |
注意：要使用自定义 TargetGroupBinding 功能，您必须使用带有集群名称的 `eks:eks-cluster-name` 标签标记目标组，从而向控制器授予必要的 IAM 权限。请注意，当 TargetGroupBinding 资源或集群被删除时，控制器将删除目标组。
# 创建存储类
Amazon EKS 自动模式中的 `StorageClass` 定义了应用程序请求持久性存储时如何自动预置 Amazon EBS 卷。本页介绍如何创建和配置可与 Amazon EKS 自动模式配合使用的 `StorageClass`，从而预置 EBS 卷。
通过配置 `StorageClass`，您可以指定 EBS 卷的默认设置，包括卷类型、加密、IOPS 和其他存储参数。您还可以将 `StorageClass` 配置为使用 AWS KMS 密钥进行加密管理。
EKS 自动模式不会为您创建 `StorageClass`。您必须创建引用 `ebs.csi.eks.amazonaws.com` 的 `StorageClass`，才能使用 EKS 自动模式的存储功能。
首先创建一个名为 `storage-class.yaml` 的文件：
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
然后将存储类应用于到集群。
```
kubectl apply -f storage-class.yaml
```
**关键组件：**
+ `provisioner: ebs.csi.eks.amazonaws.com` – 使用 EKS 自动模式
+ `allowedTopologies`：指定与 `eks.amazonaws.com/compute-type:auto` 匹配的 `matchLabelExpressions` 将确保，如果容器组（pod）需要使用自动模式自动预置卷，则不会在非自动节点上调度容器组（pod）。
+ `volumeBindingMode: WaitForFirstConsumer` – 将卷的创建延迟到容器组需要时
+ `type: gp3` – 指定 EBS 卷类型
+ `encrypted: "true"` – EBS 将对使用该 `StorageClass` 创建的所有卷进行加密。EBS 将使用默认的 `aws/ebs` 密钥别名。有关更多信息，请参阅《Amazon EBS 用户指南》中的 [How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html)。该值是可选的，但建议使用。
+ `storageclass.kubernetes.io/is-default-class: "true"` – 默认情况下 Kubernetes 将使用此存储类，除非您在持久性卷声明中指定了其他卷类。该值为可选项。如果要从其他存储控制器迁移，请谨慎设置此值。
## 使用自主管理型 KMS 密钥加密 EBS 卷
要使用自主管理型 KMS 密钥加密由 EKS 自动模式自动预置的 EBS 卷，您需要完成以下操作：
1. 创建自主管理型 KMS 密钥。
+ 有关更多信息，请参阅《KMS 用户指南》中的 [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) 或 [How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)。
1. 创建一个允许访问该 KMS 密钥的新策略。
+ 使用以下 IAM 策略示例来创建策略。插入新的自主管理型 KMS 密钥的 ARN。有关更多信息，请参阅《AWS IAM 用户指南》中的[创建角色并附加策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)。
1. 将此策略附加到 EKS 集群角色。
+ 使用 AWS 控制台查找 EKS 集群角色的 ARN。角色信息将在**概述**部分中显示。有关更多信息，请参阅 [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)。
1. 更新 `StorageClass` 以在 `parameters.kmsKeyId` 字段中引用该 KMS 密钥 ID。
### 自主管理型 KMS IAM 策略示例
更新以下策略中的以下值：
+ `` – AWS 账户 ID，例如 `111122223333`
+ `` – 集群所在的 AWS 区域，例如 `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### 自主管理型 KMS `StorageClass` 示例
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass` 参数参考
有关 Kubernetes `StorageClass` 资源的一般信息，请参阅 Kubernetes 文档中的[存储类](https://kubernetes.io/docs/concepts/storage/storage-classes/)。
`StorageClass` 资源的 `parameters` 部分特定于 AWS。请使用下表来查看可用的选项。
| Parameters | 值 | 默认值 | 说明 |
| --- | --- | --- | --- |
| "csi.storage.k8s.io/fstype" | xfs、ext2、ext3、ext4 | ext4 | 将在创建卷时进行格式化的文件系统类型。此参数区分大小写！ |
| "type" | io1、io2、gp2、gp3、sc1、st1、标准、sbp1、sbg1 | gp3 | EBS 卷类型。 |
| "iopsPerGB" | | | 每 GiB 每秒 I/O 读写操作次数。可以为 IO1、IO2 和 GP3 卷指定。 |
| "allowAutoIOPSPerGBIncrease" | true，false | false | 如果为 `"true"`，CSI 驱动程序将在 `iopsPerGB * ` 太小而无法达到 AWS 支持的 IOPS 范围时增加卷的 IOPS。这可确保动态预置始终会成功，即使用户指定的 PVC 容量或 `iopsPerGB` 值太小。不过这可能会带来额外的成本，因为此类卷的 IOPS 高于 `iopsPerGB` 中请求的值。 |
| "iops" | | | 每秒 I/O 读写操作次数。可以为 IO1、IO2 和 GP3 卷指定。 |
| "throughput" | | 125 | 吞吐量以 MiB/s 为单位。仅在指定 gp3 卷类型时有效。 |
| "encrypted" | true，false | false | 是否应对卷进行加密。有效值为“true”或“false”。 |
| "blockExpress" | true，false | false | 允许创建 io2 Block Express 卷。 |
| "kmsKeyId" | | | 加密卷时要使用的密钥的完整 ARN。如果未指定，AWS 将使用该卷所在区域的默认 KMS 密钥。这将是一个自动生成的密钥，名为 `/aws/ebs`（如果未更改）。 |
| "blockSize" | | | 格式化底层文件系统时要使用的块大小。仅支持 linux 节点和文件系统类型 `ext2`、`ext3`、`ext4` 或 `xfs`。 |
| "inodeSize" | | | 格式化底层文件系统时要使用的索引节点大小。仅支持 linux 节点和文件系统类型 `ext2`、`ext3`、`ext4` 或 `xfs`。 |
| "bytesPerInode" | | | 格式化底层文件系统时要使用的 `bytes-per-inode`。仅支持 linux 节点和文件系统类型 `ext2`、`ext3` 或 `ext4`。 |
| "numberOfInodes" | | | 格式化底层文件系统时要使用的 `number-of-inodes`。仅支持 linux 节点和文件系统类型 `ext2`、`ext3` 或 `ext4`。 |
| "ext4BigAlloc" | true，false | false | 通过启用 `bigalloc` 格式化选项，将 `ext4` 文件系统更改为使用集群块分配。警告：对于节点的 Linux 内核，`bigalloc` 可能并非完全受支持。 |
| "ext4ClusterSize" | | | 启用 `bigalloc` 功能后格式化 `ext4` 文件系统时要使用的集群大小。注意：`ext4BigAlloc` 参数必须设置为 true。 |
有关更多信息，请参阅 GitHub 上的 [AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)。
## 注意事项
**注意**
您只能根据 EKS 自动模式节点上的 EKS 自动模式 StorageClasses 部署工作负载。如果您的集群包含混合类型的节点，则需要将工作负载配置为仅在 EKS 自动模式节点上运行。有关更多信息，请参阅 [控制工作负载是否部署在 EKS 自动模式节点上](associate-workload.md)。
EKS 自动模式的块存储功能与 EBS CSI 驱动程序不同。
+ 静态预置
+ 要将外部创建的 EBS 卷与 EKS 自动模式结合使用，需要手动添加键为 `eks:eks-cluster-name`，值为集群名称的 AWS 标签。
+ 节点启动污点
+ 在存储容量准备就绪之前，不能使用节点启动污点功能来阻止容器组调度
+ 动态预置卷上的自定义标签
+ 不能使用 extra-tag CLI 标志在动态预置 EBS 卷上配置自定义标签
+ 可以使用 `StorageClass` 标记功能来添加自定义标签。EKS 自动模式将为关联的 AWS 资源添加标签。您需要更新自定义标签的集群 IAM 角色。有关更多信息，请参阅 [EKS 自动模式资源的自定义 AWS 标签](auto-learn-iam.md#tag-prop)。
+ EBS 详细性能指标
+ 您无法访问 Prometheus 指标来了解 EBS 的详细性能
## 安装 CSI 快照控制器附加组件
EKS 自动模式与 CSI 快照控制器 Amazon EKS 附加组件兼容。
AWS 建议将此附加组件配置为在内置的 `system` 节点池上运行。
有关更多信息，请参阅：
+ [在专用实例上运行关键附加组件](critical-workload.md)
+ [启用或禁用内置节点池](set-builtin-node-pools.md)
+ [为 CSI 卷启用快照功能](csi-snapshot-controller.md)
### 在系统节点池中安装快照控制器
1. 在 AWS 控制台中打开 EKS 集群
1. 在**附加组件**选项卡中，选择**获取更多附加组件**
1. 选择 **CSI 快照控制器**，然后选择**下一步**
1. 在**配置选定附加组件的设置**页面上，选择**可选配置设置**以查看**附加组件配置架构**
1. 插入以下 yaml 以将快照控制器关联到 `system` 节点池。快照控制器包含对 `CriticalAddonsOnly` 污点的容忍度。
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. 选择**下一步**
1. 检查附加组件配置，然后选择**创建**
# 禁用 EKS 自动模式
您可以在现有 EKS 集群上禁用 EKS 自动模式。这是一种破坏性的操作。
+ EKS 将终止所有由 EKS 自动模式运行的 EC2 实例。
+ EKS 将删除所有由 EKS 自动模式运行的负载均衡器。
+ EKS **不会**删除由 EKS 自动模式预置的 EBS 卷。
EKS 自动模式设计为完全托管其创建的资源。手动干预可能会导致在禁用 EKS 自动模式后无法完全清理这些资源。例如，假设您从外部安全组规则中引用某个托管式安全组，但在为集群禁用 EKS 自动模式之前忘记移除该引用，则托管式安全组将会泄露（不会被删除）。以下步骤介绍了在发生安全组泄露时如何移除泄露的安全组。
## 禁用 EKS 自动模式（AWS 控制台）
1. 在 AWS 管理控制台中打开集群概述页面。
1. 在 **EKS 自动模式**下，选择**管理**
1. 将 **EKS 自动模式**切换为 `off`。
如果在此过程结束后未删除任何托管式安全组，则可以使用[删除安全组](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html)中的说明手动将其删除。
## 禁用 EKS 自动模式（AWS CLI）
使用以下命令在现有集群上禁用 EKS 自动模式。
您需要安装 `aws` CLI，并以足够的 EKS 集群管理权限登录。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
**注意**
计算、块存储和负载均衡功能必须在同一请求中全部启用或禁用。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
禁用 EKS 自动模式后，您可以如下所示检查泄露的 EKS 自动模式安全组是否未能删除：
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
然后删除安全组：
```
aws ec2 delete-security-group --group-name=
```
# 更新 EKS 自动模式集群的 Kubernetes 版本
本主题介绍如何更新自动模式集群的 Kubernetes 版本。自动模式通过处理控制面板更新与节点替换之间的协调来简化版本更新过程，同时通过容器组中断预算来保持工作负载的可用性。
在升级自动模式集群时，许多传统上需要手动更新的组件现在都作为服务的一部分进行管理。了解升级过程的自动化方面以及您需要负责的方面，有助于确保集群顺利完成版本过渡。
## 了解使用 EKS 自动模式时的更新
启动控制面板升级后，EKS 自动模式将升级集群中的节点。节点过期后，EKS 自动模式会将其替换为新节点。新节点具有相应的新 Kubernetes 版本。EKS 自动模式会在升级节点时观察容器组中断预算。
此外，您不再需要更新组件，例如：
+ Amazon VPC CNI
+ AWS Load Balancer Controller
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS EBS CSI 驱动程序
EKS 自动模式用服务功能取代了这些组件。
您仍需要负责更新下列方面：
+ 部署到集群的应用程序和工作负载
+ 自主管理型附加组件和控制器
+ Amazon EKS 附加组件
+ 了解如何[更新 Amazon EKS 附加组件](updating-an-add-on.md)
了解[集群升级最佳实践](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## 启动集群更新
要开始集群更新，请参阅[将现有集群更新到新的 Kubernetes 版本](update-cluster.md)。
# 启用或禁用内置节点池
EKS 自动模式有两个内置节点池。您可以使用 AWS 控制台、CLI 或 API 启用或禁用这些节点池。
## 内置节点池参考
+ `system`
+ 此节点池有一个 `CriticalAddonsOnly` 污点。许多 EKS 附加组件（例如 CoreDNS）都容忍此污点。使用此系统节点池来隔离集群关键型应用程序。
+ 同时支持 `amd64` 和 `arm64` 架构。
+ `general-purpose`
+ 此节点池提供了为集群中的通用型工作负载启动节点的支持。
+ 仅使用 `amd64` 架构。
同时启用两个内置节点池：
+ 使用默认的 EKS 节点类
+ 仅使用按需型 EC2 容量
+ 使用 C、M 和 R EC2 实例系列
+ 需要第 5 代或更高版本的 EC2 实例
**注意**
EKS 需要启用至少一个内置节点池才能配置“默认”节点类。如果禁用所有内置节点池，则需要创建自定义节点类并配置节点池才能使用它。有关节点类的更多信息，请参阅[为 Amazon EKS 创建节点类](create-node-class.md)。
## 过程
### 先决条件
+ 已在您的设备上安装并配置了最新版本的 AWS 命令行界面（AWS CLI）。要查看当前版本，请使用 `aws --version`。要安装最新版本，请参阅《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)。
+ 使用创建 AWS 资源所需的充分 IAM 权限登录 CLI，包括 IAM 策略、IAM 角色和 EKS 集群等。
### 使用 AWS CLI 启用
使用以下命令同时启用两个内置节点池：
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
您可以修改命令以有选择地启用节点池。
### 使用 AWS CLI 禁用
使用以下命令同时禁用两个内置节点池：
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# 控制工作负载是否部署在 EKS 自动模式节点上
在启用 EKS 自动模式的 EKS 集群中运行工作负载时，您可能需要控制特定工作负载是在 EKS 自动模式节点上运行还是其他计算类型上运行。本主题介绍如何使用节点选择器和亲和性规则，来确保您的工作负载在需要的计算基础设施上调度。
本主题中的示例演示如何使用 `eks.amazonaws.com/compute-type` 标签要求或阻止在 EKS 自动模式节点上部署工作负载。这在同时运行 EKS 自动模式和其他计算类型（例如自主管理型 Karpenter 预置器或 EKS 托管式节点组）的混合模式集群中特别有用。
EKS 自动模式节点已将标签 `eks.amazonaws.com/compute-type` 的值设置为 `auto`。您可以使用此标签来控制是否将工作负载部署到由 EKS 自动模式管理的节点。
## 要求将工作负载部署到 EKS 自动模式节点
**注意**
此 `nodeSelector` 值对于 EKS 自动模式并非必需。此 `nodeSelector` 值仅当您在混合模式下运行集群，节点类型不由 EKS 自动模式管理时才重要。例如，您可以使用 EKS 托管式节点组将静态计算容量部署到集群，并使用由 EKS 自动模式管理的动态计算容量。
您可以将此 `nodeSelector` 添加到部署或其他工作负载中，以要求 Kubernetes 将其调度到 EKS 自动模式节点上。
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## 要求不将工作负载部署到 EKS 自动模式节点
您可以将此 `nodeAffinity` 添加到部署或其他工作负载中，以要求 Kubernetes **不**将其调度到 EKS 自动模式节点上。
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# 在专用实例上运行关键附加组件
在本主题中，您将了解如何部署具有 `CriticalAddonsOnly` 容忍度的工作负载，以便 EKS 自动模式将其调度到 `system` 节点池中。
EKS 自动模式内置的 `system` 节点池专为在专用实例上运行关键附加组件而设计。这种隔离可确保关键组件拥有专用资源并与一般工作负载隔离，从而增强集群的整体稳定性和性能。
本指南演示了如何利用 `CriticalAddonsOnly` 容忍度和适当的节点选择器将附加组件部署到 `system` 节点池。通过执行这些步骤，您可以利用 EKS 自动模式专用节点池结构提供的隔离和资源分配优势，确保将关键应用程序调度到专用的 `system` 节点上。
EKS 自动模式有以下两个内置节点池：`general-purpose` 和 `system`。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。
`system` 节点池的作用是将关键附加组件隔离到不同的节点上。`system` 节点池预置的节点有一个 `CriticalAddonsOnly` Kubernetes 污点。Kubernetes 仅在具有对应的容忍度时才会将容器组调度到这些节点上。有关更多信息，请参阅 Kubernetes 文档中的[污点和容忍度](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。
## 先决条件
+ 启用内置 `system` 节点池的 EKS 自动模式集群。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)
+ 安装并配置了 `kubectl`。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
## 过程
参阅下面的示例 yaml。请注意以下配置：
+ `nodeSelector` – 这会将工作负载关联到内置的 `system` 节点池。必须使用 AWS API 启用此节点池。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。
+ `tolerations` – 此容忍度会克服 `system` 节点池中节点上的 `CriticalAddonsOnly` 污点。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
要更新要在 `system` 节点池上运行的工作负载，您需要完成以下操作：
1. 更新现有工作负载以添加上文描述的以下配置：
+ `nodeSelector`
+ `tolerations`
1. 使用 `kubectl apply` 将更新后的工作负载部署到集群
工作负载更新后将在专用节点上运行。
# 将网络策略与 EKS 自动模式结合使用
## 概述
随着客户使用 EKS 扩展其应用程序环境，网络流量隔离对于防止未经授权访问集群内外的资源变得越来越重要。对于在集群中同时运行多个不相关工作负载的多租户环境，这一点尤其重要。Kubernetes 网络策略能帮助您改进 Kubernetes 工作负载的网络安全状况，以及它们与集群外部端点的集成。EKS 自动模式支持不同类型的网络策略。
### 第 3 层和第 4 层隔离
标准 Kubernetes 网络策略在 OSI 网络模型的第 3 层和第 4 层上运行，让您能够控制 Amazon EKS 集群中 IP 地址或端口级别的流量。
#### 使用案例
+ 在工作负载之间对网络流量进行分段，确保只有相关的应用程序才能相互通信。
+ 使用策略在命名空间级别隔离租户，以强制执行网络分离。
### 基于 DNS 的执行
客户通常在 EKS 中部署属于更广泛的分布式环境中一部分的工作负载，其中一些工作负载必须与集群外的系统和服务通信（北向流量）。这些系统和服务可以位于 AWS 云中，也可以完全位于 AWS 外部。基于域名系统（DNS）的策略允许您采用更稳定、更可预测的方法来防止容器组（pod）未经授权访问集群外部资源或端点，从而改进您的安全状况。这种机制无需手动跟踪并将特定 IP 地址加入允许列表。通过使用基于 DNS 的方法保护资源，您还可以更灵活地更新外部基础设施，而不必在上游服务器和主机发生变化时放松安全状况或修改网络策略。您可以使用完全限定域名（FQDN）或 DNS 域名的匹配模式筛选传送至外部端点的出口流量。这样您便可以更加灵活地将访问权限扩展到与特定集群外部端点关联的多个子域。
#### 使用案例
+ 使用基于 DNS 的方法进行标准化，用于筛选从 Kubernetes 环境到集群外部端点的访问权限。
+ 在多租户环境中安全访问 AWS 服务。
+ 在混合云环境中管理从容器组（pod）到本地工作负载的网络访问权限。
### 管理员（或集群范围）规则
在某些情况下，例如多租户场景，客户可能需要强制执行适用于整个集群的网络安全标准。无需为每个命名空间重复定义和维护不同的策略，而是可以使用单个策略来集中管理集群中不同工作负载的网络访问权限控制，无论其命名空间如何。这些类型的策略允许您扩大在第 3 层、第 4 层以及使用 DNS 规则时应用的网络筛选规则的实施范围。
#### 使用案例
+ 集中管理 EKS 集群中所有（或部分）工作负载的网络访问权限控制。
+ 定义整个集群的默认网络安全状况。
+ 以更具运营效率的方式，将组织安全标准扩展到集群范围。
## 开始使用
### 先决条件
+ 启用了 EKS 自动模式的 Amazon EKS 集群
+ 配置好 kubectl 以连接到集群
### 第 1 步：启用网络策略控制器
要将网络策略与 EKS 自动模式结合使用，您首先需要通过将 ConfigMap 应用到集群来启用网络策略控制器。
1. 使用以下内容创建名为 `enable-network-policy.yaml` 的文件：
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. 将 ConfigMap 应用到集群：
```
kubectl apply -f enable-network-policy.yaml
```
### 第 2 步：创建和测试网络策略
您的 EKS 自动模式集群现已配置为支持 Kubernetes 网络策略。您可以使用 [Amazon EKS 的网络策略的 Stars 演示](network-policy-stars-demo.md) 进行测试。
### 步骤 3：调整节点类中的网络策略代理配置（可选）
您还可以选择创建一个新的节点类，以更改网络策略代理在节点上的默认行为，或者启用网络策略事件的日志记录功能。为此，请按照以下步骤操作：
1. 创建或编辑包含以下内容的节点类 YAML 文件（例如 `nodeclass-network-policy.yaml`）：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. 将节点类配置应用到集群：
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. 验证节点类是否已创建：
```
kubectl get nodeclass network-policy-config
```
1. 更新节点池以使用此节点类。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
## 如何工作？
### 基于 DNS 的网络策略
![\[在 EKS 自动模式中应用基于 DNS 的策略时的工作流程示意图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[在 EKS 自动模式中应用基于 DNS 的策略时的工作流程示意图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/apply-dns-policy-2.png)
1. 平台团队将基于 DNS 的策略应用于 EKS 集群。
1. 网络策略控制器负责监控集群内策略的创建情况，然后协调策略端点。在此使用案例中，网络策略控制器指示节点代理根据创建的策略中的允许列表域筛选 DNS 请求。使用 FQDN 或与 Kubernetes 资源配置中定义的模式相匹配的域名，将域名列入允许名单。
1. 工作负载 A 尝试解析集群外部端点的 IP。DNS 请求首先通过代理，该代理根据通过网络策略应用的允许列表筛选此类请求。
1. 一旦 DNS 请求通过 DNS 筛选器允许列表，就会被传输到 CoreDNS，
1. 反过来，CoreDNS 会将请求发送到外部 DNS 解析器（Amazon Route 53 Resolver），获取域名背后的 IP 地址列表。
1. 已解析的 IP 连同 TTL 都将在对 DNS 请求的响应中返回。然后，将这些 IP 写入 eBPF 映射中，该映射用于 IP 层执行的下一步。
1. 随后，连接到容器组（pod）veth 接口的 eBPF 探测器将根据现有规则筛选从工作负载 A 到集群外部端点的出口流量。这可确保容器组（pod）只能向已加入允许列表的域 IP 发送集群外部流量。这些 IP 的有效性取决于从外部 DNS 解析器（Amazon Route 53 Resolver）检索到的 TTL。
#### 使用应用程序网络策略
`ApplicationNetworkPolicy` 使用单个自定义资源定义（CRD）在命名空间级别将标准 Kubernetes 网络策略的功能与基于 DNS 的筛选相结合。因此，`ApplicationNetworkPolicy` 可以用于：
1. 使用 IP 块和端口号定义网络堆栈第 3 层和第 4 层的限制。
1. 定义网络堆栈第 7 层运行的规则，并允许您基于 FQDN 筛选流量。
**重要**
使用 `ApplicationNetworkPolicy` 定义的基于 DNS 的规则仅适用于在 EKS Auto Mode 启动的 EC2 实例中运行的工作负载。 `ApplicationNetworkPolicy` 支持标准 Kubernetes `NetworkPolicy` 的所有字段，并为出站规则提供了额外的 FQDN 筛选器。
**警告**
请勿在同一命名空间内为 `ApplicationNetworkPolicy` 和 `NetworkPolicy` 使用相同的名称。如果名称冲突，生成的 `PolicyEndpoints` 对象可能无法正确反映任一策略。这两个资源都会正常接受而不报错，因此该问题难以诊断。
要解决命名冲突，请重命名 `ApplicationNetworkPolicy` 或 `NetworkPolicy`，使其在命名空间内唯一，然后验证对应的 `PolicyEndpoints` 对象是否已正确更新。
#### 示例
您的 EKS 自动模式集群中有一个工作负载，需要与带有 DNS 名称的负载均衡器背后的本地应用程序通信。您可以使用以下网络策略实现此目的：
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
在 Kubernetes 网络级别，这将允许来自标有 `role: backend` 的“galaxy”命名空间中的任何容器组（pod）的出口，通过 TCP 端口 8080 连接到域名 **myapp.mydomain.com**。此外，您还需要为从 VPC 到公司数据中心的出口流量设置网络连接。
![\[EKS 自动模式中的工作负载与本地应用程序通信示意图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### 管理员（或集群）网络策略
![\[EKS 中的网络策略评估顺序示意图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/evaluation-order.png)
#### 使用集群网络策略
使用 `ClusterNetworkPolicy` 时，将首先评估管理员层策略，并且无法被覆盖。在评估管理员层策略后，将使用标准命名空间范围策略来执行应用的网络分段规则。这可以通过使用 `ApplicationNetworkPolicy` 或 `NetworkPolicy` 完成。最后，将强制执行定义了集群工作负载默认网络限制的基准层规则。如有需要，这些基准层规则**可以**被命名空间范围的策略所覆盖。
#### 示例
您的集群中有一个要与其他租户工作负载隔离的应用程序。您可以明确阻止来自其他命名空间的集群流量，防止网络访问敏感的工作负载命名空间。
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## 注意事项
### 了解策略评估顺序
EKS 中支持的网络策略功能按特定顺序进行评估，以确保流量管理可预测且安全。因此，了解评估流程是非常重要的，这样才能为您的环境设计有效的网络安全状况。
1. **管理员层策略（先进行评估）**：首先对所有管理员层 ClusterNetworkPolicies 进行评估，然后再评估任何其他策略。在管理员层中，策略按优先级顺序处理（优先级序号最小者优先）。操作类型决定了接下来的操作。
+ **Deny 操作（优先级最高）**：当具有 Deny 操作的管理员策略与流量匹配时，无论采用何种其他策略，该流量都会立即被阻止。不再处理其他 ClusterNetworkPolicy 或 NetworkPolicy 规则。这样可以确保组织范围的安全控制不会被命名空间级别的策略所覆盖。
+ **Allow 操作**：评估 Deny 规则后，将按优先级顺序处理具有 Allow 操作的管理员策略（优先级序号最小者优先）。当 Allow 操作匹配时，流量将被接受，并且不再进行进一步的策略评估。这些策略可以根据标签选择器授予跨多个命名空间的访问权限，从而集中控制哪些工作负载可以访问特定资源。
+ **Pass 操作**：管理员层策略中的 Pass 操作将决策委托给较低层级。当流量与 Pass 规则匹配时，评估将跳过该流量的所有剩余管理层规则，直接进入 NetworkPolicy 层。这允许管理员将某些流量模式的控制权明确委托给应用程序团队。例如，您可以使用 Pass 规则将命名空间内的流量管理委托给命名空间管理员，同时保持对外部访问权限的严格控制。
1. **网络策略层**：如果没有与 Deny 或 Allow 匹配的管理员层策略，或者匹配了 Pass 操作，则接下来将评估命名空间范围的 ApplicationNetworkPolicy 和传统 NetworkPolicy 资源。这些策略在各个命名空间内提供精细的控制，并由应用程序团队管理。命名空间范围的策略只能比管理员策略更严格。它们无法覆盖管理员策略的 Deny 决策，但可以进一步限制管理员策略允许或通过的流量。
1. **基准层管理员策略**：如果没有管理员或命名空间范围的策略与流量匹配，则会评估基准层 ClusterNetworkPolicies。它们提供了可以被命名空间范围的策略覆盖的默认安全状况，允许管理员设置组织范围的默认值，同时让团队可以灵活地根据需要进行自定义。基准策略按优先级顺序进行评估（优先级序号最小者优先）。
1. **默认拒绝（如果没有匹配的策略）**：这种默认拒绝行为可确保仅允许明确允许的连接，从而保持稳固的安全状况。
### 应用最低权限原则
+ **从限制性策略开始，然后根据需要逐步添加权限**：首先在集群级别实施默认拒绝策略，然后在验证合法的连接要求时，逐步添加允许规则。这种方法迫使团队明确证明每个外部连接的合理性，从而打造更加安全且可审计的环境。
+ **定期审计并删除未使用的策略规则**：随着应用程序的发展，网络策略可能会随着时间的推移而积累，所留下的过时规则会不必要地扩大攻击面。实施定期审查流程，以确定并删除不再需要的策略规则，确保您的安全状况保持严密且可维护。
+ **尽可能使用特定的域名而不是宽泛的模式**：虽然像 `*.amazonaws.com` 这类通配符模式提供了便利，但这也会授予对各种服务的访问权限。只要可行，请指定如 `s3.us-west-2.amazonaws.com` 等确切的域名，仅允许访问应用程序所需的特定服务，从而降低工作负载遭盗用时横向移动的风险。
### 在 EKS 中使用基于 DNS 的策略
+ 使用 `ApplicationNetworkPolicy` 定义的基于 DNS 的规则仅适用于在 EKS 自动模式启动的 EC2 实例中运行的工作负载。如果您运行的是混合模式集群（由 EKS 自动模式和非 EKS 自动模式 Worker 节点组成），则基于 DNS 的规则仅在 EKS 自动模式 Worker 节点（EC2 托管实例）中有效。
### 验证 DNS 策略
+ **使用与生产网络拓扑结构相同的暂存集群进行测试**：您的暂存环境应复制生产的网络架构、外部依赖关系和连接模式，确保进行准确的策略测试。这包括相同的 VPC 配置、DNS 解析行为以及访问生产工作负载所需的相同外部服务。
+ **对关键网络路径实施自动测试**：构建自动化测试，验证与基本外部服务的连接（作为 CI/CD 管道的一部分）。这些测试应验证在阻止未经授权的连接的同时是否允许合法的流量，从而持续验证随着基础设施的演变，您的网络策略是否仍能保持理想的安全状况。
+ **在策略更改后监控应用程序行为**：将新的或经修改的网络策略部署到生产环境后，密切监控应用程序日志、错误率和性能指标，以此快速识别任何连接问题。制定明确的回滚程序，以便在策略更改导致意外应用程序行为或服务中断时可以快速还原这些更改。
### 与 Amazon Route 53 DNS 防火墙互动
当流量启动时，首先在容器组（pod）级别评估 EKS 管理员和网络策略。如果 EKS 网络策略允许出口到特定域，则该容器组（pod）随后会执行 DNS 查询，其随后会到达 Route 53 解析器。此时，将对 Route 53 的 DNS 防火墙规则进行评估。如果 DNS 防火墙阻止域查询，那么即使 EKS 网络策略允许 DNS 解析失败，也无法建立连接。这创建了互补的安全层：基于 EKS DNS 的网络策略为应用程序特定的访问要求和多租户安全边界提供容器组（pod）级别的出口控制，而 DNS 防火墙则提供 VPC 范围内针对已知恶意域的保护，并强制执行组织范围的阻止名单。
# 为 EKS 自动模式的子网添加标签
如果您使用 EKS 自动模式的负载均衡功能，则需要向 VPC 子网添加 AWS 标签。
## 背景
这些标签可将子网标识为与集群相关联，更重要的是能标识出子网是公有子网还是私有子网。
公有子网可以通过互联网网关直接访问互联网。此类子网用于需要可公开访问的资源，例如负载均衡器。
私有子网无法直接访问互联网，需使用 NAT 网关来传输出站流量。此类子网用于内部资源，例如不需要公有 IP 的 EKS 节点。
要了解有关 NAT 网关和互联网网关的更多信息，请参阅《Amazon Virtual Private Cloud（VPC）用户指南》中的[将 VPC 连接到其他网络](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)。
## 要求
目前，EKS 自动模式用于负载平衡的子网需具有以下某个标签。
### 公有子网
公有子网用于面向互联网的负载均衡器。这些子网必须具有以下标签：
| 键 | 值 |
| --- | --- |
| `kubernetes.io/role/elb` | `1` 或 `` |
### 私有子网
私有子网用于内部负载均衡器。这些子网必须具有以下标签：
| 键 | 值 |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` 或 `` |
## 过程
在开始之前，请确定哪些是公有子网（具有互联网网关访问权限），哪些是私有子网（使用 NAT 网关）。必须具备权限才能修改 VPC 资源。
### AWS 管理控制台
1. 打开 Amazon VPC 控制台，然后导航至**子网**。
1. 选择要添加标签的子网。
1. 选择**标签**选项卡，然后选择**添加标签**。
1. 添加相应标签：
+ 对于公有子网：Key=`kubernetes.io/role/elb`
+ 对于私有子网：Key=`kubernetes.io/role/internal-elb`
1. 将**值**设置为 `1` 或留为空白。
1. 保存设置，再重复对其余子网执行前述操作。
### AWS CLI
对于公有子网：
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
对于私有子网：
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
将 `subnet-ID` 替换为您的实际子网 ID。
# 使用 kubectl debug 从 Kubernetes 节点生成 CIS 合规性报告
本主题介绍如何使用 `kubectl debug` 命令，为 Amazon EKS 节点生成 CIS（Center for Internet Security）合规性报告。该命令允许您在 Kubernetes 节点上临时创建调试容器，并使用 `apiclient` 工具运行 CIS 合规性检查。`apiclient` 工具是 Bottlerocket 操作系统（EKS 自动模式节点使用的操作系统）中的一部分。
## 先决条件
在开始之前，请确保您满足以下条件：
+ 访问已配置 `kubectl` 的 Amazon EKS 集群（版本必须至少为 v1.32.0；键入 `kubectl version` 以执行检查）。
+ 具有相应的节点调试 IAM 权限。
+ 具有允许调试操作的有效配置文件（例如 `sysadmin`）。
有关使用包含 `kubectl` 的调试配置文件的更多信息，请参阅 Kubernetes 文档中的[指定应用配置文件来调试容器组（pod）或节点](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)。
## 过程
1. 确定要在其上运行报告的节点的 AWS 实例 ID。使用以下命令列出该集群中的节点。实例 ID 位于名称列中，以 `i-` 开头：
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. 运行以下命令，将 `` 替换为要查询的节点的实例 ID：
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
该命令的组成部分包括：
+ `kubectl debug node/`：在指定的 EC2 实例 ID 上创建调试会话。
+ `-it`：分配 TTY（命令行 Shell）并使 stdin 保持打开状态供交互式使用。
+ `--profile=sysadmin`：使用具有适当权限的指定 `kubectl` 配置文件。
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`：使用 `amazonlinux:2023` 作为容器映像进行调试。
+ `bash -c "…"`：在 Bash Shell 中执行以下命令：
+ `yum install -q -y util-linux-core`：静默安装所需的实用工具包。
+ `nsenter -t 1 -m`：运行 `nsenter` 以进入主机进程（PID 1）的命名空间。
+ `apiclient report cis --level 1 --format text`：在级别 1 运行 CIS 合规性报告，并输出文本。
1. 查看报告文本输出。
## 解析输出
该命令生成一份基于文本的报告，显示各种 CIS 控件的合规性状态。输出包括：
+ 各个 CIS 控件 ID
+ 各个控件的描述
+ 各项检查的“通过”、“失败”或“跳过”状态
+ 解释任何合规性问题的详细信息
以下是在 Bottlerocket 实例上运行的报告输出示例：
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
有关基准的信息，请参阅 Center for Internet Security（CIS）的 [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)。
## 相关资源
+ Bottlerocket 操作系统文档中的 [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/)。
+ Kubernetes 文档中的[调试运行中的 Pod](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)。
+ Center for Internet Security（CIS）中的 [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)
# 在 EKS 自动模式下使用客户自主管理型 KMS 密钥启用 EBS 卷加密
您可以使用客户自主管理型 KMS 密钥对 EKS 自动模式实例的临时根卷进行加密。
在管理 Kubernetes 集群的加密 EBS 卷时，Amazon EKS 自动模式使用服务相关角色向其他 AWS 服务委派权限。本主题介绍当您为 Amazon EBS 加密指定客户自主管理型密钥时，如何设置所需的密钥策略。
注意事项：
+ EKS 自动模式无需额外授权，即可使用默认的 AWS 托管式密钥来保护您账户中的加密卷。
+ 本主题介绍加密临时卷，即 EC2 实例的根卷。有关加密用于工作负载的数据卷的更多信息，请参阅[创建存储类](create-storage-class.md)。
## 概述
以下 AWS KMS 密钥可在 EKS 自动模式启动实例时用于加密 Amazon EBS 根卷：
+ **AWS 托管式密钥**：您账户中由 Amazon EBS 创建、拥有和管理的加密密钥。这是新账户的默认加密密钥。
+ **客户托管密钥**：您创建、拥有和管理的自定义加密密钥。
**注意**
密钥必须是对称的。Amazon EBS 不支持非对称客户托管密钥。
## 第 1 步：配置密钥策略
您的 KMS 密钥必须具有相应的密钥策略，以允许 EKS 自动模式启动具有使用客户自主管理型密钥加密的 Amazon EBS 卷的实例。
请使用以下结构配置密钥策略：
**注意**
此策略仅包含 EKS 自动模式的权限。如果其他身份需要使用密钥或管理授权，则此密钥策略可能需要额外的权限。
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
请务必将 `` 替换为实际的 AWS 账户 ID。
配置密钥策略时：
+ `ClusterServiceRole` 必须具有使用该 KMS 密钥执行加密操作所需的 IAM 权限
+ `kms:GrantIsForAWSResource` 条件可确保只能为 AWS 服务创建授权
## 第 2 步：使用客户自主管理型密钥配置节点类
配置密钥策略后，在 EKS 自动模式的节点类配置中引用该 KMS 密钥：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
请将占位符值替换为实际的值：
+ 请将 `` 替换为您所在的 AWS 区域
+ 请将 `` 替换为您的 AWS 账户 ID
+ 请将 `` 替换为您的 KMS 密钥 ID
您可以使用以下任意一种格式指定 KMS 密钥：
+ KMS 密钥 ID：`1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS 密钥 ARN：` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ 密钥别名名称：`alias/eks-auto-mode-key`
+ 密钥别名 ARN：` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
使用 kubectl 应用节点类配置：
```
kubectl apply -f nodeclass.yaml
```
## 相关资源
+ [为 Amazon EKS 创建节点类](create-node-class.md)
+ 有关更多信息，请参阅《AWS Key Management Service 开发人员指南》。
+ [密钥策略中 AWS 服务的权限](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [更改密钥策略](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [AWS KMS 中的授权](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# 更新 EKS 自动模式的组织控制
某些组织控制可能会阻止 EKS 自动模式正常运行。如果出现这种情况，则必须更新这些控制，以允许 EKS 自动模式拥有代表您管理 EC2 实例所需的权限。
EKS 自动模式使用服务角色启动支持 EKS 自动模式节点的 EC2 实例。服务角色是在您的账户中创建的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)，服务假定该角色代表您执行操作。[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)（SCP）始终适用于使用服务角色执行的操作。这将允许 SCP 禁止自动模式的操作。最常见的情况是使用 SCP 来限制可以启动的亚马逊机器映像（AMI）。要使 EKS 自动模式可以正常工作，请修改 SCP 以允许从 EKS 自动模式账户启动 AMI。
您还可以使用 [EC2 允许的 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 功能来限制其他账户中 AMI 的可见性。如果您使用此功能，则必须扩展映像标准，以包含感兴趣区域中的 EKS 自动模式 AMI 账户。
## 示例 SCP：阻止除 EKS 自动模式 AMI 外的所有 AMI
除非 AMI 属于 us-west-2 或 us-east-1 的 EKS 自动模式 AMI 账户，否则以下 SCP 会阻止调用 `ec2:RunInstances`。
**注意**
切**勿**使用 `ec2:Owner` 上下文键。Amazon 拥有 EKS 自动模式 AMI 账户，该键的值将始终为 `amazon`。如果构建一个 SCP，允许当 `ec2:Owner` 为 `amazon` 时启动 AMI，则将允许启动所有 Amazon 拥有的 AMI，而不仅限于 EKS 自动模式的 AMI。\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## EKS 自动模式 AMI 账户
因区域而异的 AWS 账户托管 EKS 自动模式公有 AMI。
| | |
| --- |--- |
| AWS 区域 | Account |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## 关联公有 IP 地址
调用 `ec2:RunInstances` 时，实例启动的 `AssociatePublicIpAddress` 字段将根据实例启动到的子网类型自动确定。可以使用 SCP 强制将该值显式设置为 false，无论实例启动到哪种类型的子网。在这种情况下，也可以将 NodeClass 字段 `spec.advancedNetworking.associatePublicIPAddress` 设置为 false 以满足 SCP 的要求。
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# 使用 EKS 自动模式控制将工作负载部署到容量预留中
您可以控制工作负载在[容量预留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)中的部署。EKS 自动模式支持 EC2 按需容量预留（ODCR）和适用于机器学习的 EC2 容量块。
**提示**
默认情况下，EKS Auto Mode 可以通过开放匹配在开放 ODCR 中启动实例，但不会优先考虑这些 ODCR。通过开放匹配启动的实例会被标记为 `karpenter.sh/capacity-type: on-demand`，而不是 `reserved`。要优先使用 ODCR 并标记实例 `karpenter.sh/capacity-type: reserved`，请在 NodeClass 定义中配置 `capacityReservationSelectorTerms`。机器学习容量块始终需要 `capacityReservationSelectorTerms`，并且不会自动使用。
## EC2 按需容量预留（ODCR）
通过使用 EC2 按需容量预留（ODCR），您可以在特定可用区中为 Amazon EC2 实例预留计算容量达任意持续时间。使用 EKS 自动模式时，您可能想要控制是否将 Kubernetes 工作负载部署到这些预留实例上，以最大限度地利用预先购买的容量，或确保关键工作负载能够访问有保障的资源。
默认情况下，EKS 自动模式会在开放式 ODCR 中自动启动。但是，通过在 NodeClass 上配置 `capacityReservationSelectorTerms`，您可以显式控制工作负载使用的 ODCR。使用已配置的 ODCR 预置的节点将具有 `karpenter.sh/capacity-type: reserved` 并优先于按需和竞价型节点。启用此功能后，EKS 自动模式将不再自动使用开放式 ODCR – 其必须由 NodeClass 显式选择，这样您就可以精确控制集群中的容量预留使用情况。
**警告**
如果在集群中的 NodeClass 上配置了 `capacityReservationSelectorTerms`，则 EKS 自动模式将不再为集群中的*任何* 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 的方法。第一种方法通过其 ID（`cr-56fac701cc1951b03`）直接引用特定 ODCR。第二种方法使用基于标签的选择，目标是带有标签 `Name: "targeted-odcr"` 的 ODCR。您还可以选择按拥有预留的 AWS 账户进行筛选，这在跨账户场景或使用共享容量预留时特别有用。
## 适用于机器学习的 EC2 容量块
机器学习容量块允许您在未来预留基于 GPU 的加速型计算实例，以支持短期机器学习（ML）工作负载。在容量块内运行的实例会自动紧密放置在 Amazon EC2 UltraClusters 中，以实现低延迟、PB 级非阻塞联网。
有关受支持的平台和实例类型的更多信息，请参阅《EC2 用户指南》中的 [ML 容量块](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)。
您可以创建使用机器学习容量块的 EKS 自动模式 NodeClass，类似于 ODCR（如前所述）。
以下示例定义创建了三个资源：
1. 引用容量块预留的 NodeClass
1. 使用 NodeClass 并应用污点的 NodePool
1. 可以容忍污点并请求 GPU 资源的容器组（pod）规范
### 示例 NodeClass
此 NodeClass 通过其预留 ID 来引用特定机器学习容量块。您可以从 EC2 控制台获取此 ID。
```
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` 来使用预留容量
+ 其请求适用于机器学习工作负载的特定 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 自动模式创建节点池](create-node-pool.md)。
### 示例容器组（pod）
此示例容器组（pod）演示了如何将工作负载配置为在容量块节点上运行：
+ 其使用 **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 文档中的 [Pod](https://kubernetes.io/docs/concepts/workloads/pods/)。
### 相关资源
+ 《Amazon EC2 用户指南》中的 [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 上人工智能/机器学习工作负载的计算资源](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)
# 将 EKS 自动模式节点部署到 Local Zones
EKS 自动模式通过自动节点预置简化了集群管理。AWSLocal Zones 将 AWS 基础设施扩展到离最终用户更近的地理位置，从而减少延迟敏感型应用程序的延迟。本指南将引导您完成将 EKS 自动模式节点部署到 AWS Local Zones 的过程，您随后便能以更低的延迟为特定地理区域的用户运行容器化应用程序。
本指南还演示了如何使用 Kubernetes 污点和容忍度来确保只有特定的工作负载在 Local Zone 节点上运行，从而帮助您控制成本和优化资源使用。
## 先决条件
在开始将 EKS 自动模式节点部署 Local Zones 之前，请确保已满足以下先决条件：
+ [现有的 EKS 自动模式集群](create-auto.md)
+ [在您的 AWS 账户中已选择加入 Local Zone](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## 步骤 1：创建 Local Zone 子网
将 EKS 自动模式节点部署到 Local Zone 的第一步是在该 Local Zone 中创建子网。该子网为您的节点提供网络基础设施，并允许它们与 VPC 的其余部分进行通信。按照《AWS Local Zones 用户指南》中的[创建 Local Zone 子网](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet)说明，在您选择的 Local Zone 中创建子网。
**提示**
记下您的 Local Zone 子网的名称。
## 步骤 2：为 Local Zone 子网创建 NodeClass
创建 Local Zone 子网后，您需要定义一个引用该子网的 NodeClass。NodeClass 是一种 Kubernetes 自定义资源，用于指定节点的基础设施属性，包括要使用的子网、安全组和存储配置。在下面的示例中，我们创建了一个名为“local-zone”的 NodeClass，它根据 Local Zone 子网的名称对其进行定位。您也可以使用子网 ID。您需要调整此配置以定位 Local Zone 子网。
有关更多信息，请参阅 [为 Amazon EKS 创建节点类](create-node-class.md)。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## 步骤 3：使用 NodeClass 和污点创建 NodePool
配置好 NodeClass 后，您现在需要创建一个使用此 NodeClass 的 NodePool。NodePool 定义节点的计算特征，包括实例类型。NodePool 使用 NodeClass 作为参考，以确定在何处启动实例。
在下面的示例中，我们创建了一个引用“local-zone”NodeClass 的 NodePool。我们还将污点添加到节点，确保只有容忍度匹配的容器组（pod）才能在这些 Local Zone 节点上被调度。这对于 Local Zone 节点尤其重要，因为 Local Zone 节点的成本通常更高，只有特别受益于降低延迟的工作负载才应使用此类节点。
有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
带有 `aws.amazon.com/local-zone` 键和 `NoSchedule` 效果的污点可确保容忍度不匹配的容器组（pod）不会在这些节点上被调度。这样可以防止常规工作负载意外在 Local Zone 中运行，这可能会导致意外成本。
## 步骤 4：部署具有容忍度和节点亲和性的工作负载
要对 Local Zone 节点上的工作负载放置进行最佳控制，请同时使用污点/容忍度和节点亲和性。此组合方法具有以下优势：
1. **成本控制**：污点可确保只有具有明确容忍度的容器组（pod）才能使用可能较为昂贵的 Local Zone 资源。
1. **保证放置**：节点亲和性可确保您的延迟敏感型应用程序仅在 Local Zone 中运行，而不是在常规集群节点上运行。
以下是配置为专门在 Local Zone 节点上运行的部署示例：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
此部署有两个关键的调度配置：
1. **容忍度**允许将容器组（pod）在带有 `aws.amazon.com/local-zone` 污点的节点上调度。
1. **节点亲和性**要求可确保这些容器组（pod）只能在带有 `node-type: local-zone` 标签的节点上运行。
它们共同确保您的延迟敏感型应用程序仅在 Local Zone 节点上运行，并且除非明确配置为使用 Local Zone 资源，否则常规应用程序不会消耗 Local Zone 资源。
## 步骤 5：使用 AWS 控制台验证
设置 NodeClass、NodePool 和 Deployments 后，您应验证节点是否按预期在 Local Zone 中预置，并且您的工作负载是否正在这些节点上运行。您可以使用 AWS 管理控制台验证 EC2 实例是否在正确的 Local Zone 子网中启动。
此外，您可以使用 `kubectl get nodes -o wide` 查看 Kubernetes 节点列表，确认这些节点是否以正确的标签和污点加入集群：
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
您还可以验证您的工作负载容器组（pod）是否已在 Local Zone 节点上调度：
```
kubectl get pods -o wide
```
这种方法可确保只有特别容忍 Local Zone 污点的工作负载才会在这些节点上被调度，从而帮助您控制成本并最有效地利用 Local Zone 资源。
# 为节点配置高级安全设置
本主题介绍如何使用节点类中指定的 `advancedSecurity` 规范来为 Amazon EKS 自动模式节点配置高级安全设置。
## 先决条件
在开始之前，请确保您满足以下条件：
+ Amazon EKS 自动模式集群。有关更多信息，请参阅 [创建启用 Amazon EKS 自动模式的集群](create-auto.md)。
+ 安装并配置了 `kubectl`。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。
+ 了解节点类配置。有关更多信息，请参阅 [为 Amazon EKS 创建节点类](create-node-class.md)。
## 配置高级安全设置
要为节点配置高级安全设置，请设置节点类规范中的 `advancedSecurity` 字段：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
应用此配置：
```
kubectl apply -f nodeclass.yaml
```
在节点池配置中引用此节点类。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。
## 字段描述
+ `fips`（布尔值，可选）：设置为 `true` 时，使用具有 FIPS 140-2 验证的加密模块的 AMI 预置节点。此设置选择符合 FIPS 的 AMI；客户需负责管理其相关的合规性要求。有关更多信息，请参阅 [AWS FIPS 合规性](https://aws.amazon.com/compliance/fips/)。默认值：`false`。
+ `kernelLockdown`（字符串，可选）：控制内核锁定安全模块模式。接受的值：
+ `integrity`：阻止用于覆盖内核内存或修改内核代码的方法。防止加载未签名的内核模块。
+ `none`：禁用内核锁定保护。
有关更多信息，请参阅 [Linux 内核锁定文档](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)。
## 注意事项
+ 符合 FIPS 的 AMI 在 AWS 美国东部/西部、AWS GovCloud（美国）和 AWS 加拿大（中部/西部）区域可用。有关更多信息，请参阅 [AWS FIPS 合规性](https://aws.amazon.com/compliance/fips/)。
+ 使用 `kernelLockdown: "integrity"` 时，请确保您的工作负载不需要加载未签名的内核模块或修改内核内存。
## 相关资源
+ [为 Amazon EKS 创建节点类](create-node-class.md)：完整的节点类配置指南
+ [为 EKS 自动模式创建节点池](create-node-pool.md)：节点池配置
# 了解 EKS 自动模式的工作原理
通过本章了解 Amazon EKS 自动模式集群的组件的工作原理。
**Topics**
+ [了解 Amazon EKS 自动模式的托管式实例](automode-learn-instances.md)
+ [了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)
+ [了解 EKS 自动模式下的 VPC 联网和负载均衡](auto-networking.md)
# 了解 Amazon EKS 自动模式的托管式实例
本主题介绍了 Amazon EKS 自动模式如何管理 EKS 集群中的 Amazon EC2 实例。启用 EKS 自动模式后，集群的计算资源将由 EKS 自动预置和管理，从而改变您与作为集群中节点的 EC2 实例的交互方式。
了解 Amazon EKS 自动模式会如何管理实例，对于规划工作负载部署策略和操作程序至关重要。与传统的 EC2 实例或托管式节点组不同，此类实例遵循不同的生命周期模式，EKS 负责许多操作任务，同时限制某些类型的访问和自定义。
Amazon EKS 自动模式可自动执行创建新 EC2 实例的例行任务，并将其作为节点挂载到 EKS 集群。EKS 自动模式会检测现有节点何时不能满足工作负载的需要，并创建新的 EC2 实例。
Amazon EKS 自动模式负责创建、删除和修补 EC2 实例。您负责实例上部署的容器和容器组。
EKS 自动模式创建的 EC2 实例属于托管式实例，这与其他 EC2 实例不同。此类托管式实例由 EKS 所有，并且受到更多限制。您不能直接访问由 EKS 自动模式管理的实例或在此类实例上安装软件。
AWS 建议运行 EKS 自动模式或自主管理型 Karpenter。您可以在迁移过程中或在高级配置中同时安装这两者。如果您同时安装了这两者，请配置节点池，以将工作负载关联到 Karpenter 或 EKS 自动模式。
有关更多信息，请参阅《Amazon EC2 用户指南》中的 [Amazon EC2 managed instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)。
## 比较表
| 标准 EC2 实例 | EKS 自动模式托管式实例 |
| --- | --- |
| 您负责修补和更新实例。 | AWS 会自动修补和更新实例。 |
| EKS 对实例上的软件不承担任何责任。 | EKS 对实例上的某些软件负责，例如 `kubelet`、容器运行时和操作系统。 |
| 您可以使用 EC2 API 来删除 EC2 实例。 | EKS 负责决定将在您账户中部署的实例数量。如果您删除工作负载，EKS 将会减少您账户中的实例数量。 |
| 您可以使用 SSH 访问 EC2 实例。 | 您可以将容器组和容器部署到托管式实例。 |
| 您负责决定操作系统和映像（AMI）。 | AWS 负责决定操作系统和映像。 |
| 您可以部署依赖 Windows 或 Ubuntu 功能的工作负载。 | 您可以部署基于 Linux 但无特定操作系统依赖项的容器。 |
| 您负责决定要启动的实例类型和系列。 | AWS 负责决定要启动的实例类型和系列。您可以使用节点池来限制 EKS 自动模式可选择的实例类型。 |
以下功能对托管式实例和标准 EC2 实例均适用：
+ 您可以在 AWS 控制台中查看实例。
+ 您可以将实例存储用作工作负载的临时存储。
### AMI 支持
通过 EKS 自动模式，AWS 可确定用于计算节点的映像（AMI）。AWS 还会监控新的 EKS 自动模式 AMI 版本的推出。如果遇到与 AMI 版本相关的工作负载问题，请创建支持案例。有关更多信息，请参阅《AWS Support User Guide》中的 [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)。
通常，EKS 每周都会发布一个包含 CVE 和安全修复的新 AMI。
## EKS 自动模式支持的实例参考
EKS 自动模式仅创建属于受支持类型且符合最小大小要求的实例。
EKS 自动模式支持以下实例类型：
| 系列 | 实例类型 |
| --- | --- |
| 计算优化型（C） | c8i、c8i-flex、c8gd、c8gn、c8g、c7a、c7g、c7gn、c7gd、c7i、c7i-flex、c6a、c6g、c6i、c6gn、c6id、c6in、c6gd、c5、c5a、c5d、c5ad、c5n、c4 |
| 通用型（M） | m8i、m8i-flex、m8a、m8gn、m8gb、m8gd、m8g、m7i、m7a、m7g、m7gd、m7i-flex、m6a、m6i、m6in、m6g、m6idn、m6id、m6gd、m5、m5a、m5ad、m5n、m5dn、m5d、m5zn、m4 |
| 内存优化型（R） | r8i、r8i-flex、r8gn、r8gb、r8gd、r8g、r7a、r7iz、r7gd、r7i、r7g、r6a、r6i、r6id、r6in、r6idn、r6g、r6gd、r5、r5n、r5a、r5dn、r5b、r5ad、r5d、r4 |
| 突增型（T） | t4g、t3、t3a、t2 |
| 内存增强型（Z/X） | z1d、x8g、x2gd |
| 存储优化型（I/D） | i8ge、i7i、i8g、i7ie、i4g、i4i、i3、i3en、is4gen、d3、d3en、im4gn |
| 加速计算型（P/G/Inf/Trn） | p5、p4d、p4de、p3、p3dn、gr6、g6、g6e、g5g、g5、g4dn、inf2、inf1、trn1、trn1n |
| 高性能计算型（X2） | x2iezn、x2iedn、x2idn |
此外，EKS 自动模式将仅创建满足以下要求的 EC2 实例：
+ 超过 1 个 CPU
+ 实例大小并非纳米型、微型或小型
有关更多信息，请参阅 [Amazon EC2 实例类型命名约定](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)。
## 实例元数据服务
+ 默认情况下，EKS 自动模式会遵循 AWS 安全最佳实践，强制执行 IMDSv2（跃点限制为 1）。
+ 此默认配置在自动模式下无法修改。
+ 对于通常需要 IMDS 访问权限的附加组件，请在安装过程中提供参数（例如 AWS 区域），以避免 IMDS 查找。有关更多信息，请参阅 [确定可以为 Amazon EKS 附加组件自定义的字段](kubernetes-field-management.md)。
+ 如果容器组在自动模式下运行时确实需要 IMDS 访问权限，则必须将该容器组配置为可以使用 `hostNetwork: true` 运行。这将允许容器组直接访问实例元数据服务。
+ 授予容器组实例元数据访问权限时，应考虑安全影响。
有关 Amazon EC2 实例元数据服务（IMDS）的更多信息，请参阅《Amazon EC2 用户指南》**中的[配置实例元数据服务选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)。
## 注意事项
+ 如果 NodeClass 中配置的临时存储小于实例的 NVMe 本地存储，则 EKS 自动模式会自动执行以下操作，无需手动配置：
+ 使用较小（20 GiB）的 Amazon EBS 数据量来降低成本。
+ 格式化并配置 NVMe 本地存储以供临时数据使用。这包括在具有多个 NVMe 驱动器的情况下设置 RAID 0 阵列。
+ 当 `ephemeralStorage.size` 等于或超过本地 NVMe 容量时，会发生以下操作：
+ 自动模式会跳过小型 EBS 卷。
+ NVMe 驱动器将直接公开给工作负载。
+ Amazon EKS 自动模式不支持下列 AWS 故障注入服务操作：
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS 自动模式支持 AWS 故障注入服务 EKS 容器组（pod）操作。有关更多信息，请参阅[管理故障注入服务试验](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html)和《AWS 韧性监测中心用户指南》中的[执行 AWS FIS aws:eks:pod 操作](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account)。
+ 不需要在 EKS 自动模式节点上安装 `Neuron Device Plugin`。
如果集群中有其他类型的节点，则需要将 Neuron Device 插件配置为不在自动模式节点上运行。有关更多信息，请参阅 [控制工作负载是否部署在 EKS 自动模式节点上](associate-workload.md)。
# 了解 EKS 自动模式中的身份和访问权限
本主题介绍使用 EKS 自动模式所需的 Identity and Access Management（IAM）角色和权限。EKS 自动模式使用两个主要 IAM 角色：一个集群 IAM 角色和一个节点 IAM 角色。这两个角色与 EKS 容器组身份和 EKS 访问条目配合使用，从而为 EKS 集群提供全面的访问管理。
配置 EKS 自动模式时，您需要设置这两个 IAM 角色，为其授予允许 AWS 服务与集群资源交互所需的特定权限，包括管理计算资源、存储卷、负载均衡器和网络组件的权限。了解这些角色配置对于确保集群的正常运行和安全至关重要。
在 EKS 自动模式下，AWS IAM 角色会自动通过 EKS 访问条目映射到 Kubernetes 权限，无需手动配置 `aws-auth` ConfigMaps 或自定义绑定。创建新的自动模式集群时，EKS 会使用访问条目自动创建相应的 Kubernetes 权限，从而确保 AWS 服务和集群组件在 AWS 和 Kubernetes 授权系统中都具有适当的访问权限级别。这种自动集成可减少配置的复杂性，有助于防止在管理 EKS 集群时常见的权限相关问题。
## 集群 IAM 角色
集群 IAM 角色是 Amazon EKS 用来管理 Kubernetes 集群权限的 AWS Identity and Access Management（IAM）角色。此角色向 Amazon EKS 授予代表集群与其他 AWS 服务进行交互的必要权限，并且使用 EKS 访问条目自动配置了 Kubernetes 权限。
+ 您必须将 AWS IAM 策略附加到此角色。
+ EKS 自动模式使用 EKS 访问条目自动为此角色附加 Kubernetes 权限。
+ 使用 EKS 自动模式时，AWS 建议为每个 AWS 账户创建一个集群 IAM 角色。
+ AWS 建议将此角色命名为 `AmazonEKSAutoClusterRole`。
+ 此角色需要具有允许多个 AWS 服务管理资源的权限，包括 EBS 卷、弹性负载均衡器和 EC2 实例等。
+ 此角色的建议配置包括与 EKS 自动模式的不同功能相关的多个 AWS 托管式 IAM 策略。
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
有关集群 IAM 角色和 AWS 托管式 IAM 策略的更多信息，请参阅：
+ [Amazon Elastic Kubernetes Service 的AWS托管策略](security-iam-awsmanpol.md)
+ [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)
有关 Kubernetes 访问权限的更多信息，请参阅：
+ [检查访问策略权限](access-policy-permissions.md)
## 节点 IAM 角色
节点 IAM 角色是 Amazon EKS 用来管理 Kubernetes 集群中 Worker 节点权限的 AWS Identity and Access Management（IAM）角色。此角色向作为 Kubernetes 节点运行的 EC2 实例授予与 AWS 服务和资源进行交互所需的必要权限，并使用 EKS 访问条目自动配置 Kubernetes RBAC 权限。
+ 您必须将 AWS IAM 策略附加到此角色。
+ EKS 自动模式使用 EKS 访问条目自动为此角色附加 Kubernetes RBAC 权限。
+ AWS 建议将此角色命名为 `AmazonEKSAutoNodeRole`。
+ 使用 EKS 自动模式时，AWS 建议为每个 AWS 账户创建一个节点 IAM 角色。
+ 此角色具有的权限较为有限。主要权限包括代入容器组身份角色以及从 ECR 中拉取映像的权限。
+ AWS 建议使用以下 AWS 托管式 IAM 策略：
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
有关集群 IAM 角色和 AWS 托管式 IAM 策略的更多信息，请参阅：
+ [Amazon Elastic Kubernetes Service 的AWS托管策略](security-iam-awsmanpol.md)
+ [Amazon EKS 节点 IAM 角色](create-node-role.md)
有关 Kubernetes 访问权限的更多信息，请参阅：
+ [检查访问策略权限](access-policy-permissions.md)
## 服务相关角色
Amazon EKS 会使用一个服务相关角色（SLR）来执行某些操作。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。
AWS 会自动创建和配置此 SLR。只有首先删除 SLR 的相关资源后才能将其删除。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。
SLR 策略会向 Amazon EKS 授予观察和删除核心基础设施组件的权限：EC2 资源（实例、网络接口、安全组）、ELB 资源（负载均衡器、目标组）、CloudWatch 功能（日志记录和指标）以及带有“eks”前缀的 IAM 角色。此策略还支持通过 VPC/托管区关联来实现私有端点联网，并且包括 EventBridge 监控和清理带有 EKS 标签的资源的权限。
有关更多信息，请参阅：
+ [AWS托管策略：AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Amazon EKS 的服务相关角色权限](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## EKS 自动模式资源的自定义 AWS 标签
默认情况下，与 EKS 自动模式相关的托管式策略不允许将用户定义的标签应用于自动模式预置的 AWS 资源。如果要将用户定义的标签应用于 AWS 资源，则必须为集群 IAM 角色附加额外的权限，以提供在 AWS 资源上创建和修改标签的充分权限。以下示例策略将允许不受限制的标记访问权限：
### 查看自定义标签策略示例
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## 访问策略参考
要详细了解 EKS 自动模式使用的 Kubernetes 权限，请参阅[检查访问策略权限](access-policy-permissions.md)。
# 了解 EKS 自动模式下的 VPC 联网和负载均衡
本主题介绍如何在 EKS 自动模式下配置虚拟私有云（VPC）联网和负载均衡功能。虽然 EKS 自动模式会自动管理大多数联网组件，但您仍然可以通过 `NodeClass` 资源和负载均衡器注释来自定义集群联网配置的某些方面。
使用 EKS 自动模式时，AWS 会管理集群的 VPC 容器网络接口（CNI）配置和负载均衡器预置。您可以通过定义 `NodeClass` 对象并对服务和 Ingress 资源应用特定的注释来影响联网行为，同时保持 EKS 自动模式提供的自动运行模式优势。
## 联网功能
EKS 自动模式具有一个能够处理节点和容器组（pod）联网的新联网功能。您可以通过创建 `NodeClass` Kubernetes 对象来对其进行配置。
以前的 AWS VPC CNI 配置选项不适用于 EKS 自动模式。
### 使用 `NodeClass` 配置联网
借助 EKS 自动模式中的 `NodeClass` 资源，您可以自定义联网功能的某些方面。通过 `NodeClass`，您可以指定安全组选择，控制 VPC 子网中的节点放置，设置 SNAT 策略，配置网络策略以及启用网络事件日志记录。这种方法既可保持 EKS 自动模式的自动化运行模式，同时又可灵活自定义网络。
您可以使用 `NodeClass` 来：
+ 选择节点的安全组
+ 控制节点在 VPC 子网上的放置方式
+ 将节点 SNAT 策略设置为 `random` 或 `disabled`
+ 启用 Kubernetes *网络策略*，包括：
+ 将网络策略设置为“默认拒绝”或“默认允许”
+ 启用将网络事件日志记录到文件。
+ 通过将容器组（pod）连接到不同的子网，将容器组（pod）流量与节点流量隔离开来。
了解如何[创建 Amazon EKS 节点类](create-node-class.md)。
### 注意事项
EKS 自动模式支持下列功能：
+ EKS 网络策略。
+ Kubernetes 容器组的 `HostPort` 和 `HostNetwork` 选项。
+ 公有子网或私有子网中的节点和容器组（pod）。
+ 在节点上缓存 DNS 查询。
EKS 自动模式**不**支持下列功能：
+ 每容器组的安全组（SGPP）。要在自动模式下将不同的安全组应用于容器组（pod）流量，请改用 `NodeClass` 中的 `podSecurityGroupSelectorTerms`。有关更多信息，请参阅 [为容器组（pod）配置独立的子网和安全组](create-node-class.md#pod-subnet-selector)。
+ `ENIConfig` 中的自定义联网。您可以将容器组（pod）放在多个子网中，也可以使用 [为容器组（pod）配置独立的子网和安全组](create-node-class.md#pod-subnet-selector) 专门将它们与节点流量隔离开来。
+ 暖 IP、暖前缀和暖 ENI 配置。
+ 最低 IP 目标配置。
+ 开源 AWS VPC CNI 支持的其他配置。
+ 网络策略配置，例如 conntrack 计时器自定义（默认为 300 秒）。
+ 将网络事件日志导出到 CloudWatch。
### 网络资源管理
EKS 自动模式通过监控用于网络配置的节点类资源来处理前缀、IP 寻址及网络接口管理。该服务会自动执行多项关键操作：
**前缀委派**
EKS 自动模式会默认使用前缀委托（/28 前缀）进行容器组（pod）联网，并维护可根据调度的容器组（pod）数量进行扩展的预定义 IP 热池。检测到容器组（pod）子网碎片时，自动模式会预置辅助 IP 地址（/32）。由于这种默认的容器组（pod）联网算法，自动模式会根据每种实例类型支持的 ENI 和 IP 数量来计算每个节点的最大容器组（pod）数（假设是最坏的碎片化情况）。有关每个实例类型的最大 ENI 和 IP 数量的更多信息，请参阅《EC2 用户指南》中的[每个网络接口的最大 IP 地址数](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)。新一代（Nitro v6 及更高版本）实例系列通常会增加每种实例类型的 ENI 和 IP，自动模式会相应地调整最大容器组（pod）计算。
对于 IPv6 集群，仅使用前缀委派，自动模式始终使用每个节点 110 个容器组（pod）的最大容器组（pod）限制。
**冷却管理**
该服务为不再使用的前缀或辅助 IPv4 地址设置了冷却池。冷却时间到期后，这些资源将释放回 VPC。但是，如果容器组（pod）在冷却时间内重复使用这些资源，它们将从冷却池中恢复。
**IPv6 支持**
对于 IPv6 集群，EKS 自动模式会在主网络接口上为每个节点预置 `/80` IPv6 前缀。使用时 `podSubnetSelectorTerms`，前缀将在容器组（pod）子网的辅助网络接口上分配。
该服务还可确保对所有网络接口进行适当管理和垃圾回收。
## 负载均衡
您可以使用服务和 Ingress 资源上的注释来配置由 EKS 自动模式预置的 AWS 弹性负载均衡器。
有关更多信息，请参阅 [创建 IngressClass 以配置应用程序负载均衡器](auto-configure-alb.md) 或 [使用服务注释配置网络负载均衡器](auto-configure-nlb.md)。
### EKS 自动模式负载均衡的注意事项
+ 默认目标模式是 IP 模式，而不是实例模式。
+ EKS 自动模式仅支持网络负载均衡器的安全组模式。
+ AWS 不支持将负载均衡器从自主管理型 AWS 负载均衡器控制器迁移到由 EKS 自动模式管理。
+ 不支持 `TargetGroupBinding` 规范中的 `networking.ingress.ipBlock` 字段。
+ 如果 Worker 节点使用自定义安全组（非 `eks-cluster-sg- ` 命名模式），则集群角色需要额外的 IAM 权限。默认 EKS 托管式策略仅允许 EKS 修改名为 `eks-cluster-sg-` 的安全组。如果没有修改自定义安全组的权限，EKS 将无法添加允许 ALB/NLB 流量到达容器组所需的 Ingress 规则。
#### CoreDNS 注意事项
EKS 自动模式不使用传统的 CoreDNS 部署在集群内提供 DNS 解析。相反，自动模式节点利用 CoreDNS 作为系统服务直接在每个节点上运行。如果将传统集群过渡到自动模式，则可以在工作负载移至自动模式节点后，从集群中移除 CoreDNS 部署。
**重要**
如果您计划维护同时包含自动模式和非自动模式节点的集群，则必须保留 CoreDNS 部署。非自动模式节点依赖传统的 CoreDNS 容器组（pod）进行 DNS 解析，因为它们无法访问自动模式提供的节点级 DNS 服务。
# EKS 自动模式的可观测性
通过本章了解 Amazon EKS 自动模式集群的可观测性选项。
**Topics**
+ [访问 EKS 自动模式的 AWS 托管组件日志](auto-managed-component-logs.md)
# 访问 EKS 自动模式的 AWS 托管组件日志
您可以从 EKS 自动模式访问 AWS 托管组件日志，以更深入地了解集群操作。EKS 自动模式支持以下来源的日志：
+ 计算自动扩缩 - Karpenter
+ 数据块存储 - EBS CSI
+ 负载均衡 - AWS 负载均衡器控制器
+ 容器组（pod）联网 - VPC CNI IP 地址管理
日志可以传输到您选择的[交付目标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)。
创建 EKS 自动集群时，您可以选择启用控制面板日志记录（API 服务器、审计、身份验证器、控制器管理器、调度器）。EKS 自动托管组件日志（例如计算、数据块存储、负载均衡和 IPAM）需要通过日志传输进行单独配置。
## 设置日志传输
要为您的 EKS 自动模式集群配置 AWS 托管的组件日志传输，请使用 Amazon CloudWatch Logs API。有关详细设置说明，请参阅《Amazon CloudWatch Logs 用户指南》中的[从 AWS 服务中启用日志记录](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html)。每种自动模式功能都可以单独配置为一个 CloudWatch Vended Logs 传输源，这样您就可以选择想要访问的哪些日志了。
EKS 自动模式支持以下日志类型：
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### 使用 Amazon CloudWatch API
设置日志记录需要三个步骤：
1. 使用 CloudWatch PutDeliverySource API 为该功能创建传输源
1. 使用 PutDeliveryDestination 创建传输目标
1. 使用 CreateDelivery 创建传输以连接来源和目标
您可以使用 CloudWatch PutDeliveryDestination API 中的 deliveryDestinationConfiguration 对象来配置自动模式日志目标的详细信息。它采用 CloudWatch 日志组、S3 存储桶或 Kinesis Data Firehose 传输流的 ARN。
您可以将单个自动模式功能（传输源）配置为通过创建多个传输将日志发送到多个目标。您也可以创建多个传输来配置多个传输源，以将日志发送到同一个传输目标。
### IAM 权限
根据所选的目标，您可能需要为 CloudWatch 日志组、S3 存储桶和 Kinesis Data Firehose 配置 IAM 策略或角色，以确保日志能够成功传输。此外，如果您要跨 AWS 账户发送日志，则需要使用 PutDeliveryDestinationPolicy API 来配置允许向目标传输日志的 IAM 策略。有关更多信息，请参阅 [CloudWatch Vended Logs 权限文档](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)。
## 查看日志
日志传输一经配置，日志就会被传输至您指定的目标。访问日志的方法取决于您选择的目标类型：
+ **CloudWatch Logs**：在 CloudWatch Logs 控制台中查看日志、使用 AWS CLI 命令，或使用 CloudWatch Logs Insights 进行查询
+ **Amazon S3**：通过 S3 控制台、AWS CLI 或 Amazon Athena 等分析工具以 S3 存储桶中的对象形式访问日志
+ **Amazon Data Firehose**：日志将流式传输到您配置的 Firehose 目标（例如 S3、OpenSearch Service、Redshift 等）
## 定价
CloudWatch Vended Logs 会根据您选择的传输目标来收取日志传输及存储费用。与标准的 CloudWatch Logs 相比，CloudWatch Vended Logs 通过内置的 AWS 身份验证和授权实现可靠、安全的日志传输，且价格更低。有关更多详细信息，请参阅 [CloudWatch 定价页面的 Vended Logs 部分](https://aws.amazon.com/cloudwatch/pricing/)。
### 相关资源
+ [Amazon EKS 控制面板日志记录](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ CloudWatch Logs API 参考中的 [PutDeliverySource API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)
+ CloudWatch Logs API 参考中的 [PutDeliveryDestination API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)
+ CloudWatch Logs API 参考中的 [CreateDelivery API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)
# EKS 自动模式故障排除
使用 EKS 自动模式时，AWS 对您 AWS 账户中的 EC2 实例承担更多责任。EKS 负责节点上的容器运行时、节点上的操作系统和某些控制器。这包括块存储控制器、负载均衡控制器和计算控制器。
您必须使用 AWS 和 Kubernetes API 来排除节点故障。您可以：
+ 通过 [节点监控代理](#auto-node-monitoring-agent) 使用 Kubernetes `NodeDiagnostic` 资源检索节点日志。有关更多步骤，请参阅[使用 kubectl 和 S3 检索托管式节点的节点日志](auto-get-logs.md)。
+ 使用 AWS EC2 CLI 命令 `get-console-output` 检索节点的控制台输出。有关更多步骤，请参阅[使用 AWS EC2 CLI 获取 EC2 托管式实例的控制台输出](#auto-node-console)。
+ 使用 Kubernetes *调试容器*检索节点日志。有关更多步骤，请参阅[使用*调试容器*和 `kubectl` CLI 获取节点日志](#auto-node-debug-logs)。
**注意**
EKS 自动模式使用 EC2 托管式实例。您不能直接访问 EC2 托管式实例，包括通过 SSH。
您可能遇到以下问题，这些问题都有针对 EKS 自动模式组件的解决方案：
+ 容器组（pod）卡在 `Pending` 状态，无法调度到自动模式节点。有关解决方案，请参阅[对容器组（pod）无法调度到自动模式节点进行问题排查](#auto-troubleshoot-schedule)。
+ EC2 托管实例不作为 Kubernetes 节点加入集群。有关解决方案，请参阅[对节点无法加入集群进行问题排查](#auto-troubleshoot-join)。
+ `NodePools`、`PersistentVolumes` 以及使用 EKS 自动模式涉及的控制器的 `Services` 方面出现错误和问题。有关解决方案，请参阅[对自动模式涉及的控制器进行问题排查](#auto-troubleshoot-controllers)。
+ 容器组（pod）安全性增强后，无法在容器组（pod）之间共享卷。有关解决方案，请参阅[在容器组（pod）之间共享卷](#auto-troubleshoot-share-pod-volumes)。
您可以使用以下方法对 EKS 自动模式组件进行问题排查：
+ [使用 AWS EC2 CLI 获取 EC2 托管式实例的控制台输出](#auto-node-console)
+ [使用*调试容器*和 `kubectl` CLI 获取节点日志](#auto-node-debug-logs)
+ [在 AWS 控制台中查看与 EKS 自动模式关联的资源](#auto-node-ec2-web)
+ [查看您 AWS 账户中的 IAM 错误](#auto-node-iam)
+ [使用 `VPC Reachability Analyzer` 检测节点连接问题](#auto-node-reachability)
## 节点监控代理
EKS 自动模式包含 Amazon EKS 节点监控代理。您可以使用此代理来查看有关节点的故障排除和调试信息。节点监控代理会发布 Kubernetes `events` 和节点 `conditions`。有关更多信息，请参阅 [检测节点运行状况问题并启用自动节点修复](node-health.md)。
## 使用 AWS EC2 CLI 获取 EC2 托管式实例的控制台输出
此过程有助于排除启动时或内核级别的问题。
首先，您需要确定与工作负载关联的实例的 EC2 实例 ID。其次，使用 AWS CLI 检索控制台输出。
1. 确认您已安装 `kubectl` 并连接到集群
1. （可选）使用 Kubernetes 部署的名称来列出关联的容器组。
```
kubectl get pods -l app=
```
1. 使用 Kubernetes 容器的名称来确定所关联节点的 EC2 实例 ID。
```
kubectl get pod -o wide
```
1. 使用 EC2 实例 ID 检索控制台输出。
```
aws ec2 get-console-output --instance-id --latest --output text
```
## 使用*调试容器*和 `kubectl` CLI 获取节点日志
从 EKS 自动模式节点检索日志的推荐方法是使用 `NodeDiagnostic` 资源。有关步骤，请参阅[使用 kubectl 和 S3 检索托管式节点的节点日志](auto-get-logs.md)。
但是，也可使用 `kubectl debug node` 命令从实例实时流式传输日志。此命令会在要调试的节点上启动一个新的容器组（pod），然后您就能以交互方式使用它。
1. 启动调试容器。以下命令使用 `i-01234567890123456` 作为节点的实例 ID，`-it` 会分配 `tty` 并附加 `stdin` 供交互式使用，并使用 kubeconfig 文件中的 `sysadmin` 配置文件。
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
示例输出如下。
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. 现在，您可以从 Shell 中安装提供 `nsenter` 命令的 `util-linux-core`。使用 `nsenter` 进入主机上 PID 1 (`init`) 的挂载命名空间，然后运行 `journalctl` 命令以从 `kubelet` 流式传输日志：
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
为安全起见，默认情况下，Amazon Linux 容器映像不会安装很多个二进制文件。您可以使用 `yum whatprovides` 命令来确定为提供给定二进制文件而必须安装的软件包。
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## 在 AWS 控制台中查看与 EKS 自动模式关联的资源
您可以使用 AWS 控制台查看与 EKS 自动模式集群关联的资源的状态。
+ [EBS 卷](https://console.aws.amazon.com/ec2/home#Volumes)
+ 通过搜索标签键 `eks:eks-cluster-name` 查看 EKS 自动模式卷
+ [负载均衡器](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ 通过搜索标签键 `eks:eks-cluster-name` 查看 EKS 自动模式负载均衡器
+ [EC2 实例](https://console.aws.amazon.com/ec2/home#Instances)
+ 通过搜索标签键 `eks:eks-cluster-name` 查看 EKS 自动模式实例
## 查看您 AWS 账户中的 IAM 错误
1. 导航到 CloudTrail 控制台
1. 从左侧导航窗格中选择“事件历史记录”
1. 应用错误代码筛选条件：
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
查找与您的 EKS 集群相关的错误。使用错误消息更新 EKS 访问条目、集群 IAM 角色或节点 IAM 角色。您可能需要为这些角色附加一个具有 EKS 自动模式权限的新策略。
## 对容器组（pod）无法调度到自动模式节点进行问题排查
如果容器组（pod）处于 `Pending` 状态且没有调度到自动模式节点，请确认容器组（pod）或部署清单中是否有 `nodeSelector`。如果有 `nodeSelector`，请确保它在使用 `eks.amazonaws.com/compute-type: auto`，以便在由 EKS 自动模式生成的节点上进行调度。有关 EKS 自动模式所用节点标签的更多信息，请参阅[控制工作负载是否部署在 EKS 自动模式节点上](associate-workload.md)。
## 对节点无法加入集群进行问题排查
EKS 自动模式会自动使用正确的信息配置新的 EC2 实例以加入集群，包括集群端点和集群证书颁发机构（CA）。但是，这些实例可能仍无法作为节点加入 EKS 集群。运行以下命令以确定无法加入集群的实例：
1. 运行 `kubectl get nodeclaim` 以检查是否存在状态为 `Ready = False` 的 `NodeClaims`。
```
kubectl get nodeclaim
```
1. 运行 `kubectl describe nodeclaim ` 并在**状态**下检查，找出阻止该节点加入集群的任何问题。
```
kubectl describe nodeclaim
```
**常见错误消息：**
`Error getting launch template configs`
如果您使用默认集群 IAM 角色权限在 `NodeClass` 中设置自定义标签，则可能会收到此错误消息。请参阅[了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)。
`Error creating fleet`
从 EC2 API 调用 `RunInstances` 调用时可能会出现某些授权问题。检查 AWS CloudTrail 错误，并参阅[Amazon EKS 自动模式集群 IAM 角色](auto-cluster-iam-role.md)以了解所需的 IAM 权限。
### 使用 `VPC Reachability Analyzer` 检测节点连接问题
**注意**
您需要为运行 VPC Reachability Analyzer 的每项分析付费。有关定价详细信息，请参阅 [Amazon VPC 定价](https://aws.amazon.com/vpc/pricing/)。
实例无法加入集群的原因之一是网络连接问题，导致其无法访问 API 服务器。要诊断此问题，可以使用 [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 对无法加入集群的节点与 API 服务器之间的连接进行分析。您需要提供两条信息：
+ 无法加入集群的节点的**实例 ID**
+ **Kubernetes API 服务器端点**的 IP 地址
要获取**实例 ID**，需要在集群上创建工作负载，以使 EKS 自动模式启动 EC2 实例。此操作还会在集群中创建一个具有实例 ID 的 `NodeClaim` 对象。运行 `kubectl get nodeclaim -o yaml` 以打印集群中的所有 `NodeClaims`。每个 `NodeClaim` 都包含实例 ID 作为字段，并且再次包含在 providerID 中：
```
kubectl get nodeclaim -o yaml
```
示例输出如下。
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
您可以通过运行 `kubectl get endpoint kubernetes -o yaml` 来确定 **Kubernetes API 服务器端点**。地址位于地址字段中：
```
kubectl get endpoints kubernetes -o yaml
```
示例输出如下。
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
有了这两条信息，您就可以执行 s 分析了。首先导航到 AWS 管理控制台中的 VPC Reachability Analyzer。
1. 单击“创建和分析路径”
1. 提供分析名称（例如“节点加入失败”）
1. 在“源类型”中选择“实例”
1. 输入故障节点的实例 ID 作为“源”
1. 在“路径目标”中选择“IP 地址”
1. 输入 API 服务器的其中一个 IP 地址作为“目标地址”
1. 展开“其他数据包标头配置部分”
1. 输入 443 的“目标端口”
1. 如果尚未选择“协议”，请选择 TCP
1. 单击“创建和分析路径”
1. 该分析可能需要几分钟才能完成。如果分析结果表明无法访问，则将指示网络路径中发生故障的位置，便于您解决问题。
## 在容器组（pod）之间共享卷
由于 EKS 自动模式节点在强制执行模式下使用 SELinux 进行配置，因而会将在同一节点上运行的容器组（pod）分隔开。启用 SELinux 后，大多数非特权容器组（pod）将自动应用自己的多类别安全性（MCS）标签。此 MCS 标签对于每个容器组（pod）都是唯一的，旨在确保一个容器组（pod）中的进程无法操作任何其他容器组（pod）或主机上的进程。即使带标签的容器组（pod）以 root 身份运行并有权访问主机文件系统，也无法操作文件、在主机上进行敏感的系统调用、访问容器运行时或获取 kubelet 的密钥材料。
因此，尝试在容器组（pod）之间共享数据时可能会遇到问题。例如，访问模式为 `ReadWriteOnce` 的 `PersistentVolumeClaim` 仍不允许多个容器组（pod）同时访问该卷。
要在容器组（pod）之间实现此共享，可以使用容器组（pod）的 `seLinuxOptions`，在这些容器组（pod）上配置相同的 MCS 标签。在此示例中，我们向容器组（pod）分配三个类别 `c123,c456,c789`。这不会与自动向节点上的容器组（pod）分配的任何类别发生冲突，因为这些容器组只会分配到两个类别。
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## 在控制面板日志中查看 Karpenter 事件
对于启用了控制面板日志的 EKS 集群，您可以通过查询日志来深入了解 Karpenter 的操作和决策过程。这对于排查与节点预置、扩展和终止相关的 EKS 自动模式问题特别有用。要查看与 Karpenter 相关的事件，请使用以下 CloudWatch Logs Insights 查询：
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
此查询会筛选 kube-apiserver 审计日志中[与 Karpenter 相关的特定事件](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go)。这些事件包括各种中断状态、调度失败、容量问题和节点相关问题。通过分析这些日志，您可以更好地了解：
+ Karpenter 采取某些操作的原因。
+ 任何妨碍正常节点预置、扩展或终止的问题。
+ 实例类型可能存在的容量或兼容性问题。
+ 节点生命周期事件，例如中断、驱逐或终止。
要使用此查询，请执行以下操作：
1. 导航到 CloudWatch 控制台
1. 从左侧导航窗格中选择“Logs Insights”
1. 选择 EKS 集群控制面板日志的日志组
1. 将该查询粘贴到查询编辑器中
1. 根据需要调整时间范围
1. 运行查询
结果将显示与 Karpenter 相关事件的时间线，帮助您排查问题，并了解集群中 EKS 自动模式的行为。要查看特定节点上的 Karpenter 操作，可以在上述查询中添加以下行筛选器，从而指定实例 ID：
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**注意**
要使用此查询，必须在 EKS 集群上启用控制面板日志记录。如果尚未启用，请参阅[将控制面板日志发送到 CloudWatch Logs](control-plane-logs.md)。
## 对自动模式涉及的控制器进行问题排查
如果您在使用控制器时遇到问题，请检查以下方面：
+ 与该控制器关联的资源是否格式正确且有效。
+ 是否为您的集群正确配置了 AWS IAM 和 Kubernetes RBAC 资源。有关更多信息，请参阅 [了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)。
## 相关资源
阅读 AWS re:Post 中的以下文章，了解问题排查高级步骤：
+ [如何排查 EKS 自动模式中常见的扩展问题？](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [如何排查 Amazon EKS 自动模式下的自定义 nodepool 和 nodeclass 预置问题？](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [如何排查状态未知的 EKS 自动模式内置节点池问题？](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# 查看 EKS 自动模式发布说明
本页面记录了 Amazon EKS 自动模式的更新内容。您可以定期查看此页面，了解有关功能、错误修复、已知问题及已弃用功能的公告。
要接收此特定文档页面的所有源文件更改通知，您可以通过 RSS 阅读器订阅以下 URL：
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2026 年 2 月 2 日
**功能**：新增了在 EKS 自动模式 IPv6 集群中禁用 IPv6 容器组（pod）的 v4Egress 流量的功能。有关更多信息，请参阅 [在 IPv6 集群中禁用 IPv6 容器组（pod）的 IPv4 出口。](create-node-class.md#enableV4Egress)。
## 2025 年 12 月 19 日
**功能**：新增了对辅助 IP 模式的支持，该模式会为自动节点预置辅助 IP 地址，而非前缀。该模式会保留一个辅助 IP 地址作为 MinimalIPTarget，并为那些无需额外预热辅助 IP 或前缀的客户节省 IP 资源。有关更多信息，请参阅[节点类规范](create-node-class.md#auto-node-class-spec)和[容器组（pod）的辅助 IP 模式](create-node-class.md#secondary-IP-mode)。
## 2025 年 11 月 19 日
**功能**：为具有本地 NVMe 存储的 G、P 和 Trn 系列实例启用 Seekable OCI（SOCI）并行拉取和解压缩。这些具有 EKS 自动模式的实例系列始终使用 SOCI 并行拉取和解压缩，并且无需更改配置即可启用该模式。有关 SOCI 的更多信息，请参阅[发布博客](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/)。
## 2025 年 11 月 19 日
**功能**：新增了对保持固定数量节点的静态容量节点池的支持。有关更多信息，请参阅 [EKS Auto Mode 中的静态容量节点池](auto-static-capacity.md)。
## 2025 年 10 月 23 日
**功能：**在美国地区拥有集群的用户现在可以通过在其 NodeClass 定义中指定 `spec.advancedSecurity.fips` 来请求使用兼容 FIPS 的 AMI。
## 2025 年 10 月 1 日
**功能：**EKS 自动模式现在支持将节点部署到 AWS Local Zones。有关更多信息，请参阅 [将 EKS 自动模式节点部署到 Local Zones](auto-local-zone.md)。
## 2025 年 9 月 30 日
**功能：**为 NodeClass `spec.instanceProfile` 添加了对 instanceProfile 的支持，该支持与 `spec.role` 字段互斥。
## 2025 年 9 月 29 日
EKS 自动模式目前不支持 DRA。
## 2025 年 9 月 10 日
**琐事：**从自动模式计算控制器触发的事件现在将使用名称 `eks-auto-mode/compute` 而非 `karpenter`。
## 2025 年 8 月 24 日
**错误修复**：若 VPC 使用的 DHCP 选项集包含带有大写字母的自定义域名，会导致节点无法加入集群，原因是会生成无效的主机名。此问题已得到解决，包含大写字母的域名现在可以正常使用。
## 2025 年 8 月 15 日
**错误修复：**容器组身份代理现在只能侦听 IPv4 EKS 集群中的 IPv4 链路本地地址，以避免出现容器组（pod）无法访问 IPv6 地址的问题。
## 2025 年 8 月 6 日
**功能：**在 NodeClass `spec.advancedNetworking.associatePublicIPAddress` 中新增配置，可用于防止为 EKS 自动模式节点分配公有 IP 地址
## 2025 年 6 月 30 日
**功能：**自动模式 NodeClass 现在使用配置的自定义 KMS 密钥，对实例的只读根卷以及读/写数据卷进行加密。以前，自定义 KMS 密钥仅用于加密数据卷。
## 2025 年 6 月 20 日
**功能：**支持控制将工作负载部署到 EC2 按需容量预留（ODCR）。此功能向 NodeClass 添加可选密钥 `capacityReservationSelectorTerms`，允许您显式控制工作负载使用的 ODCR。有关更多信息，请参阅 [使用 EKS 自动模式控制将工作负载部署到容量预留中](auto-odcr.md)。
## 2025 年 6 月 13 日
**功能：**对 `NodeClass` 中单独的容器组（pod）子网的支持。这将添加可选键 ``podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms`，以便为容器组（pod）设置子网和安全组。有关更多信息，请参阅 [为容器组（pod）配置独立的子网和安全组](create-node-class.md#pod-subnet-selector)。
## 2025 年 4 月 30 日
**功能：**支持 `NodeClass` 中的转发网络代理。这将添加可选的 `advancedNetworking` 键来设置 HTTPS 代理。有关更多信息，请参阅 [节点类规范](create-node-class.md#auto-node-class-spec)。
## 2025 年 4 月 18 日
**功能：**支持通过单播 DNS 解析 .local 域（通常为组播 DNS 保留）。
## 2025 年 4 月 11 日
**功能：**向 `NodeClass` 新增了 `certificateBundles` 和 `ephemeralStorage.kmsKeyID`。有关更多信息，请参阅 [节点类规范](create-node-class.md#auto-node-class-spec)。
**功能：**提高了映像拉取速度，特别针对具有本地实例存储的实例类型，可以利用更快的映像解压缩功能。
**错误修复：**解决了导致 FailedCreatePodSandBox 的争用情况（拨号时出现错误：dial tcp 127.0.0.1:50051: connect: connection refused to sometimes occur for Pods scheduling to a Node immediately at startup.）
## 2025 年 4 月 4 日
**功能：**将 `registryPullQPS` 从 5 提升至 25，将 `registryBurst` 从 10 提升至 50，从而减少了客户端强制执行的映像拉取限制 (`Failed to pull image xyz: pull QPS exceeded`)
## 2025 年 3 月 31 日
**错误修复：**修复了一个问题，即当 Core DNS 容器组（pod）在自动模式节点上运行时，该节点上容器组（pod）的 DNS 查询会直接访问 Core DNS 容器组（pod）而不是节点本地 DNS 服务器。来自自动模式节点上容器组（pod）的 DNS 查询将始终指向节点本地 DNS。
## 2025 年 3 月 21 日
**错误修复：**现在，自动模式节点可在集群中未安装 `kube-dns` 服务的情况下，正确解析 `kube-dns.kube-system.svc.cluster.local`。GitHub 问题 [\$12546](https://github.com/aws/containers-roadmap/issues/2546) 得以解决。
## 2025 年 3 月 14 日
**功能**：在 `IPv6` 集群中启用了 `IPv4` 出口。现在，从 `IPv6` 自动模式集群输出的 `IPv4` 流量将自动转换为节点主 ENI 的 `v4` 地址。