**帮助改进此页面**
要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。
# Amazon EKS 集群生命周期与配置
本节提供有关 Kubernetes 集群完整生命周期管理以及配置集群的不同方法的深入指导。内容涵盖集群创建、监控集群运行状况、更新 Kubernetes 版本和删除集群。本节还包括高级主题，内容涉及如何配置端点访问权限、启用/禁用 Windows 支持、设置私有集群、实现自动扩展，以及如何在多可用区设置中使用可用区转移进行流量重定向以增强恢复能力。
**Topics**
+ [创建 Amazon EKS 自动模式集群](create-cluster-auto.md)
+ [创建一个 Amazon EKS 集群。](create-cluster.md)
+ [Amazon EKS 预置式控制面板](eks-provisioned-control-plane.md)
+ [利用集群见解为 Kubernetes 版本升级做好准备并对错误配置进行问题排查](cluster-insights.md)
+ [将现有集群更新到新的 Kubernetes 版本](update-cluster.md)
+ [删除集群](delete-cluster.md)
+ [集群 API 服务器端点](cluster-endpoint.md)
+ [在 EKS 集群上部署 Windows 节点](windows-support.md)
+ [禁用 Windows 支持](disable-windows-support.md)
+ [部署具有有限互联网访问权限的私有集群](private-clusters.md)
+ [使用 Karpenter 和 Cluster Autoscaler 扩展集群计算](autoscaling.md)
+ [了解 Amazon EKS 中的 Amazon 应用程序恢复控制器（ARC）可用区转移](zone-shift.md)
+ [启用 EKS 可用区转移以避开损坏的可用区](zone-shift-enable.md)
# 创建 Amazon EKS 自动模式集群
本主题提供了有关使用高级配置选项创建 Amazon EKS 自动模式集群的详细说明。其中包括先决条件、联网选项和附加组件配置等。整个过程包括设置 IAM 角色、配置集群设置、指定联网参数和选择附加组件等。用户可以使用 AWS 管理控制台或 AWS CLI 创建集群，这两种方法都有详细的分步指南。
如果用户需要不太复杂的设置过程，请参阅以下内容，了解简化的集群创建步骤：
+ [使用 eksctl CLI 创建 EKS 自动模式集群](automode-get-started-eksctl.md)
+ [使用 AWS CLI 创建 EKS 自动模式集群](automode-get-started-cli.md)
+ [使用 AWS 管理控制台创建 EKS 自动模式集群](automode-get-started-console.md)
本高级配置指南适用于需要更精细地控制 EKS 自动模式集群设置，并且熟悉 Amazon EKS 概念和要求的用户。在开始高级配置之前，请确保您已满足所有先决条件，并全面了解 EKS 自动模式集群的联网和 IAM 要求。
EKS 自动模式需要额外的 IAM 权限。有关更多信息，请参阅：
+ [EKS 自动模式集群的 IAM 角色](automode-get-started-cli.md#auto-mode-create-roles)
+ [了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)
**注意**
要创建未启用 EKS 自动模式的集群，请参阅[创建一个 Amazon EKS 集群。](create-cluster.md)。
本主题介绍高级配置。如果您需要学习使用 EKS 自动模式，请参阅[创建启用 Amazon EKS 自动模式的集群](create-auto.md)。
## 先决条件
+ 满足 [Amazon EKS 要求](network-reqs.md)的现有 VPC 和子网。在部署集群用于生产用途前，我们建议您彻底了解 VPC 和子网要求。如果您没有 VPC 和子网，则可以使用 [Amazon EKS 提供的 AWS CloudFormation 模板](creating-a-vpc.md)创建它们。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。例如，如果您的集群版本为 `1.29`，则可以将 `kubectl` 的 `1.28`、`1.29` 或 `1.30` 版本与之配合使用。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version`。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。
+ 一个具有创建和修改 EKS 和 IAM 资源的权限的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)。
## 创建集群 – AWS 控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 请选择 **Add cluster**（添加集群），然后选择 **Create**（创建）。
1. 在*配置选项*下，选择**自定义配置**。
+ 本主题介绍自定义配置。有关快速配置的信息，请参阅[使用 AWS 管理控制台创建 EKS 自动模式集群](automode-get-started-console.md)。
1. 确认已启用**使用 EKS 自动模式**。
+ 本主题介绍创建启用 EKS 自动模式的集群。有关创建不启用 EKS 自动模式的集群的更多信息，请参阅[创建一个 Amazon EKS 集群。](create-cluster.md)。
1. 在 **Configure cluster**（配置集群）页面上，输入以下字段：
+ **Name**（名称）– 集群的名称。名称只能包含字母数字字符（区分大小写）、连字符和下划线。该名称必须以字母数字字符开头，且不得超过 100 个字符。对于您在其中创建集群的 AWS 区域和 AWS 账户，该名称必须在其内具有唯一性。
+ **集群 IAM 角色** – 选择您创建的 Amazon EKS 集群 IAM 角色，以允许 Kubernetes 控制面板来代表您管理 AWS 资源。如果您之前尚未为 EKS 自动模式创建集群 IAM 角色，请在 IAM 控制台中选择**创建推荐角色**按钮，以创建具有所需权限的角色。
+ **Kubernetes version（Kubernetes 版本）**– 要用于集群的 Kubernetes 的版本。建议选择最新版本，除非您需要早期版本。
+ **升级策略** – 要为集群设置的 Kubernetes 版本策略。如果您希望集群仅根据标准支持版本运行，则可以选择**标准**。如果您希望集群在某个版本的标准支持终止时进入扩展支持，则可以选择**扩展**。如果您选择的 Kubernetes 版本当前处于延期支持状态，则无法选择标准支持选项。
1. 在“配置集群”页面的**自动模式计算**部分中，输入以下字段：
+ **节点池** – 确定是否要使用内置节点池。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。
+ **节点 IAM 角色** – 如果您启用任何内置节点池，则需要选择节点 IAM 角色。EKS 自动模式会将此角色分配给新节点。创建集群后，您无法更改此值。如果您之前尚未为 EKS 自动模式创建节点 IAM 角色，请选择“创建推荐角色”按钮，以创建具有所需权限的角色。有关该角色的更多信息，请参阅[了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)。
1. 在“配置集群”页面的**集群访问权限**部分中，输入以下字段：
+ **引导集群管理员访问权限** – 集群创建者自动成为 Kubernetes 管理员。如果要禁用此功能，请选择**不允许集群管理员访问权限**。
+ **集群身份验证模式** – EKS 自动模式需要 EKS 访问条目，即 EKS API 身份验证模式。您也可以通过选择 **EKS API 和 ConfigMap** 来启用 `ConfigMap` 身份验证模式。
1. 输入“配置集群”页面上的剩余字段：
+ **Secrets encryption**（密钥加密）–（可选）选择此选项以使用 KMS 密钥启用 Kubernetes 密钥的密钥加密。您也可以在创建集群后启用此功能。在启用此功能之前，请确保您熟悉[在现有集群上使用 KMS 加密 Kubernetes 密钥](enable-kms.md)中的信息。
+ **ARC 可用区转移** – EKS 自动模式不支持 ARC 可用区转移。
+ **Tags（标签）**– （可选）向集群添加任何标签。有关更多信息，请参阅 [使用标签整理 Amazon EKS 资源](eks-using-tags.md)。
完成此页面后，请选择**下一步**。
1. 在 **Specify networking (指定联网)** 页面上，为以下字段选择值：
+ **VPC** – 选择符合 [Amazon EKS VPC 要求](network-reqs.md#network-requirements-vpc)的现有 VPC 以在其中创建集群。在选择 VPC 之前，我们建议您熟悉 [查看 Amazon EKS 对 VPC 和子网的联网要求](network-reqs.md) 中的所有要求和考虑因素。集群创建后，您无法更改要使用的 VPC。如果没有列出任何 VPC，则需要先创建一个。有关更多信息，请参阅 [为您的 Amazon EKS 集群创建 Amazon VPC](creating-a-vpc.md)。
+ **Subnets**（子网）– 预设情况下，已预先选中在之前字段中指定的 VPC 中的所有可用子网。您必须至少选择两个子网。
您选择的子网必须符合 [Amazon EKS 子网要求](network-reqs.md#network-requirements-subnets)。在选择子网之前，我们建议您熟悉所有的 [Amazon EKS VPC 以及子网要求和注意事项](network-reqs.md)。
**Security groups**（安全组）–（可选）指定您希望 Amazon EKS 将之与其创建的网络接口关联的一个或多个安全组。
无论您是否选择任何安全组，Amazon EKS 都会创建一个安全组，以实现集群和 VPC 之间的通信。Amazon EKS 将此安全组以及您选择的任何安全组与它创建的网络接口关联起来。有关 Amazon EKS 创建的集群安全组的更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。您可以修改 Amazon EKS 创建的集群安全组中的规则。
+ **选择集群 IP 地址系列** - 您可以选择 **IPv4** 和 **IPv6**。
默认情况下，Kubernetes 会将 `IPv4` 地址分配给容器组（pod）和服务。在决定使用 `IPv6` 系列前，请确保您熟悉 [VPC 要求和注意事项](network-reqs.md#network-requirements-vpc)、[子网要求和注意事项](network-reqs.md#network-requirements-subnets)、[查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)和 [了解如何将 IPv6 地址分配给集群、容器组（pod）和服务](cni-ipv6.md) 主题中的所有注意事项和要求。如果选择 `IPv6` 系列，则不同于可为其指定地址范围的 `IPv4` 系列，您无法指定从中分配 `IPv6` 服务地址的 Kubernetes 的地址范围。Kubernetes 从唯一的本地地址范围 (`fc00::/7`) 分配服务地址。
+ （可选）选择 **Configure Kubernetes Service IP address range**（配置 Kubernetes 服务 IP 地址范围），然后指定**服务 `IPv4` 范围**。
指定自己的范围有助于防止 Kubernetes 服务与对等或连接到 VPC 的其他网络之间发生冲突。使用 CIDR 表示法输入范围。例如：`10.2.0.0/16`。
此 CIDR 块必须满足以下要求：
+ 处于以下范围之一：`10.0.0.0/8`、`172.16.0.0/12` 或 `192.168.0.0/16`。
+ 具有最小大小 `/24` 和最大大小 `/12`。
+ 与您的 Amazon EKS 资源的 VPC 范围不重叠。
您只能在使用 `IPv4` 地址系列和创建集群时指定此选项。如果没有指定此选项，Kubernetes 会从 `10.100.0.0/16` 或 `172.20.0.0/16` CIDR 块分配服务 IP 地址。
+ 对于**集群端点访问**中，选择一个选项。创建集群后，您可以更改此选项。在选择非默认选项之前，请务必熟悉这些选项及其影响。有关更多信息，请参阅 [集群 API 服务器端点](cluster-endpoint.md)。
完成此页面后，请选择**下一步**。
1. （可选）在**配置可观测性**页面上，选择要开启的**指标**和**控制面板日志记录**选项。默认情况下，每种日志类型都处于关闭状态。
+ 有关 Prometheus 指标选项的更多信息，请参阅[第 1 步：开启 Prometheus 指标](prometheus.md#turn-on-prometheus-metrics)。
+ 有关**控制面板日志记录**选项的更多信息，请参阅 [将控制面板日志发送到 CloudWatch Logs](control-plane-logs.md)。
+ 完成此页面后，请选择**下一步**。
1. 在 **Select add-ons**（选择附加组件）页面上，选择要添加到集群的附加组件。您可以根据需要选择任意数量的 **Amazon EKS 附加组件**和 **AWS Marketplace 附加组件**。如果未列出要安装的 **AWS Marketplace 附加组件**，则您可以单击页码编号查看更多页面结果或通过在搜索框中输入文本来搜索可用的 **AWS Marketplace 附加组件**。您也可以按**类别**、**供应商**或**定价模式**进行搜索，然后从搜索结果中选择附加组件。创建集群时，您可以查看、选择和安装任何支持 EKS 容器组身份的附加组件，详情请参阅[了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限](pod-identities.md)。
+ EKS 自动模式会自动执行某些附加组件的功能。如果您计划将 EKS 托管式节点组部署到 EKS 自动模式集群，请选择**其他 Amazon EKS 附加组件**并检查选项。可能需要安装诸如 CoreDNS 和 kube-proxy 之类的附加组件。EKS 仅在自主管理型节点和节点组上安装本节中的附加组件。
+ 完成此页面后，请选择**下一步**。
1. 在**配置选定插件设置**页面上，选择要安装的版本。创建集群后，您可以随时更新到更高版本。
对于支持 EKS 容器组身份的附加组件，您可以使用控制台自动生成角色，其中包含专门为该附加组件预先填充的名称、AWS 托管策略和信任策略。您可以重复使用现有角色或为支持的附加组件创建新角色。有关使用控制台为支持 EKS 容器组身份的附加组件创建角色的步骤，请参阅[创建附加组件（AWS 控制台）](creating-an-add-on.md#create_add_on_console)。如果附加组件不支持 EKS 容器组身份，则系统会显示一条消息，说明如何在创建集群后使用向导为服务账户（IRSA）创建 IAM 角色。
创建集群后，您可以更新每个附加组件的配置。有关配置附加组件的更多信息，请参阅[更新 Amazon EKS 附加组件](updating-an-add-on.md)。完成此页面后，请选择**下一步**。
1. 在 **Review and create (审核和创建)** 页面上，审核您在之前页面输入或选择的信息。如果需要进行更改，请选择 **Edit**（编辑）。在您感到满意后，选择**创建**。**Status**（状态）字段在预置集群时显示 **CREATING**（正在创建）。
**注意**
您可能会收到一个错误，指示请求中的可用区之一没有足够容量来创建 Amazon EKS 集群。如果发生这种情况，错误输出将包含可支持新集群的可用区。再次尝试使用至少两个位于您账户中支持的可用区的子网创建集群。有关更多信息，请参阅 [容量不足](troubleshooting.md#ice)。
集群预配置需要几分钟时间。
## 创建集群 – AWS CLI
以下 CLI 说明介绍创建 IAM 资源和创建集群的过程。
### 创建 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
```
### 创建集群
1. 使用以下命令创建集群。在运行命令之前，进行以下替换：
+ 将 *region-code* 替换为您要在其中创建集群的 AWS 区域。
+ 将 *my-cluster* 替换为您的集群名称。名称只能包含字母数字字符（区分大小写）、连字符和下划线。该名称必须以字母数字字符开头，且不得超过 100 个字符。对于您在其中创建集群的 AWS 区域和 AWS 账户，该名称必须在其内具有唯一性。
+ 将 *1.30* 替换为任何 [Amazon EKS 支持的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。
+ 请将 *111122223333* 替换为您的账户 ID
+ 如果您为集群和节点角色创建了其他名称的 IAM 角色，请相应替换 ARN。
+ 将 `subnetIds` 的值替换为您自己的值。您还可以添加其他 ID。您必须指定至少两个子网 ID。
您选择的子网必须符合 [Amazon EKS 子网要求](network-reqs.md#network-requirements-subnets)。在选择子网之前，我们建议您熟悉所有的 [Amazon EKS VPC 以及子网要求和注意事项](network-reqs.md)。
+ 如果您不想指定安全组 ID，请从命令中删除 `,securityGroupIds=sg-`。如果您想指定一个或多个安全组 ID，请将 `securityGroupIds` 的值替换为您自己的值。您还可以添加其他 ID。
无论您是否选择任何安全组，Amazon EKS 都会创建一个安全组，以实现集群和 VPC 之间的通信。Amazon EKS 将此安全组以及您选择的任何安全组与它创建的网络接口关联起来。有关 Amazon EKS 创建的集群安全组的更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。您可以修改 Amazon EKS 创建的集群安全组中的规则。
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws:iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**注意**
您可能会收到一个错误，指示请求中的可用区之一没有足够容量来创建 Amazon EKS 集群。如果发生这种情况，错误输出将包含可支持新集群的可用区。再次尝试使用至少两个位于您账户中支持的可用区的子网创建集群。有关更多信息，请参阅 [容量不足](troubleshooting.md#ice)。
以下是可选设置，如果需要，必须将这些设置添加到上一个命令中。您只能在创建集群时启用这些选项，而不能在创建集群后启用。
+ 如果您想指定 Kubernetes 从中分配服务 ID 地址的 `IPv4` 无类别域间路由（CIDR）块，您必须通过将 `--kubernetes-network-config serviceIpv4Cidr=` 添加到以下命令中来指定它。
指定自己的范围有助于防止 Kubernetes 服务与对等或连接到 VPC 的其他网络之间发生冲突。使用 CIDR 表示法输入范围。例如：`10.2.0.0/16`。
此 CIDR 块必须满足以下要求：
+ 处于以下范围之一：`10.0.0.0/8`、`172.16.0.0/12` 或 `192.168.0.0/16`。
+ 具有最小大小 `/24` 和最大大小 `/12`。
+ 与您的 Amazon EKS 资源的 VPC 范围不重叠。
您只能在使用 `IPv4` 地址系列和创建集群时指定此选项。如果没有指定此选项，Kubernetes 会从 `10.100.0.0/16` 或 `172.20.0.0/16` CIDR 块分配服务 IP 地址。
+ 如果您创建集群并希望集群分配 `IPv6` 地址而不是 `IPv4` 地址给容器组（pod）和服务，请将 `--kubernetes-network-config ipFamily=ipv6` 添加到以下命令。
默认情况下，Kubernetes 会将 `IPv4` 地址分配给容器组（pod）和服务。在决定使用 `IPv6` 系列前，请确保您熟悉 [VPC 要求和注意事项](network-reqs.md#network-requirements-vpc)、[子网要求和注意事项](network-reqs.md#network-requirements-subnets)、[查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)和 [了解如何将 IPv6 地址分配给集群、容器组（pod）和服务](cni-ipv6.md) 主题中的所有注意事项和要求。如果选择 `IPv6` 系列，则不同于可为其指定地址范围的 `IPv4` 系列，您无法指定从中分配 `IPv6` 服务地址的 Kubernetes 的地址范围。Kubernetes 从唯一的本地地址范围 (`fc00::/7`) 分配服务地址。
1. 预置集群需要几分钟时间。可使用以下命令查询集群的状态。
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## 后续步骤
+ [通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)
+ [使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)
+ [为集群启用密钥加密](enable-kms.md)。
+ [为集群配置日志记录](control-plane-logs.md)。
+ [将节点添加到集群](eks-compute.md)。
# 创建一个 Amazon EKS 集群。
**注意**
本主题旨在介绍创建未启用 EKS 自动模式的 EKS 集群。
有关创建 EKS 自动模式集群的详细说明，请参阅[创建 Amazon EKS 自动模式集群](create-cluster-auto.md)。
要学习使用 EKS 自动模式，请参阅[开始使用 Amazon EKS – EKS 自动模式](getting-started-automode.md)。
本主题概述了可用选项，并介绍了创建 Amazon EKS 集群时需要考虑的内容。如果需要创建将本地基础设施作为节点计算的集群，请参阅[创建具有混合节点的 Amazon EKS 集群](hybrid-nodes-cluster-create.md)。如果您是首次创建 Amazon EKS 集群，我们建议您按照 [开始使用 Amazon EKS](getting-started.md) 中的指南之一操作。这些指南可帮助您创建一个简单的默认集群，而无需扩展到所有可用选项。
## 先决条件
+ 满足 [Amazon EKS 要求](network-reqs.md)的现有 VPC 和子网。在部署集群用于生产用途前，我们建议您彻底了解 VPC 和子网要求。如果您没有 VPC 和子网，则可以使用 [Amazon EKS 提供的 AWS CloudFormation 模板](creating-a-vpc.md)创建它们。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》**中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 具有 `create` 和 `describe` Amazon EKS 集群权限的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)。有关更多信息，请参阅[在 Outpost 上创建本地 Kubernetes 集群](security-iam-id-based-policy-examples.md#policy-create-local-cluster)和[列出或描述所有集群](security-iam-id-based-policy-examples.md#policy-example2)。
## 第 1 步：创建集群 IAM 角色
1. 如果您已经拥有集群 IAM 角色，或者您将使用 `eksctl` 创建集群，则可以跳过此步骤。默认情况下，`eksctl` 会为您创建角色。
1. 运行以下命令以创建 IAM 信任策略 JSON 文件。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. 创建 Amazon EKS 集群 IAM 角色。如有必要，使用您在上一步中将文件写入到的计算机上的路径为 *eks-cluster-role-trust-policy.json* 添加前言。该命令将您在上一步中创建的信任策略与角色关联。要创建 IAM 角色，必须为正在创建角色的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)分配 `iam:CreateRole` 操作（权限）。
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. 您可以分配 Amazon EKS 托管策略或创建自己的自定义策略。有关必须在自定义策略中使用的最低权限，请参阅 [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)。
将名为 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) 的 Amazon EKS 托管 IAM 策略附加到角色。要将 IAM 策略附加到某个 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)，必须为附加该策略的主体分配以下 IAM 操作（权限）之一：`iam:AttachUserPolicy` 或 `iam:AttachRolePolicy`。
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### 服务相关角色
Amazon EKS 会自动创建一个名为 `AWSServiceRoleForAmazonEKS` 的服务相关角色。
此角色是集群 IAM 角色的补充。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。该角色允许 Amazon EKS 管理您账户中的集群。有关更多信息，请参阅 [使用 Amazon EKS 集群的角色](using-service-linked-roles-eks.md)。
您用来创建 EKS 集群的 IAM 身份必须具有创建该服务相关角色的权限。这包括 `iam:CreateServiceLinkedRole` 权限。
如果该服务相关角色尚不存在，并且您当前的 IAM 角色没有足够的权限创建该角色，则集群创建操作将会失败。
## 第 2 步：创建集群
您可以使用以下工具来创建集群：
+ [`eksctl`](#step2-eksctl)
+ [AWS 管理控制台](#step2-console)
+ [AWS CLI](#step2-cli)
### 创建集群 – eksctl
1. 您需要在设备或 AWS CloudShell 上安装 `0.215.0` 版或更高版本的 `eksctl` 命令行工具。要安装或更新 `eksctl`，请参阅 `eksctl` 文档中的 [Installation](https://eksctl.io/installation)。
1. 在默认 AWS 区域中，使用 Amazon EKS 默认 Kubernetes 版本创建 Amazon EKS `IPv4` 集群。在运行命令之前，进行以下替换：
1. 将 *region-code* 替换为您要在其中创建集群的 AWS 区域。
1. 将 *my-cluster* 替换为您的集群名称。名称只能包含字母数字字符（区分大小写）和连字符。该名称必须以字母数字字符开头，且不得超过 100 个字符。对于您在其中创建集群的 AWS 区域和 AWS 账户，该名称必须在其内具有唯一性。
1. 将 *1.35* 替换为任何 [Amazon EKS 支持的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。
1. 更改 `vpc-private-subnets` 的值以满足您的要求。您还可以添加其他 ID。您必须指定至少两个子网 ID。如果您想要指定公有子网，您可以将 `--vpc-private-subnets` 更改为 `--vpc-public-subnets`。公有子网有一个与互联网网关的路由相关联的路由，但私有子网没有关联的路由表。我们建议尽可能使用私有子网。
您选择的子网必须符合 [Amazon EKS 子网要求](network-reqs.md#network-requirements-subnets)。在选择子网之前，我们建议您熟悉所有的 [Amazon EKS VPC 以及子网要求和注意事项](network-reqs.md)。
1. 运行如下命令：
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
集群预配置需要几分钟时间。在创建集群时，将显示几行输出。输出的最后一行类似于以下示例行。
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. 继续[第 3 步：更新 kubeconfig](#step3)
#### 可选设置
要查看在使用 `eksctl` 创建集群时可指定的大多数选项，请使用 `eksctl create cluster --help` 命令。要查看所有可用的选项，请使用 `config` 文件。有关更多信息，请参阅 `eksctl` 文档中的[使用配置文件](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files)和[配置文件架构](https://eksctl.io/usage/schema/)。您可以在 GitHub 上查找[配置文件示例](https://github.com/weaveworks/eksctl/tree/master/examples)。
以下是可选设置，如果需要，必须将这些设置添加到上一个命令中。您只能在创建集群时启用这些选项，而不能在创建集群后启用。如果您需要指定这些选项，则必须使用 [eksctl 配置文件](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files)创建集群，然后指定设置，而不是使用上一个命令。
+ 如果您想指定 Amazon EKS 分配给它创建的网络接口的一个或多个安全组，请指定 [securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup) 选项。
无论您是否选择任何安全组，Amazon EKS 都会创建一个安全组，以实现集群和 VPC 之间的通信。Amazon EKS 将此安全组以及您选择的任何安全组与它创建的网络接口关联起来。有关 Amazon EKS 创建的集群安全组的更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。您可以修改 Amazon EKS 创建的集群安全组中的规则。
+ 如果您想指定 Kubernetes 从中分配服务 IP 地址的 `IPv4` 无类别域间路由块（CIDR），请指定 [serviceIPv4CIDR](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR) 选项。
指定自己的范围有助于防止 Kubernetes 服务与对等或连接到 VPC 的其他网络之间发生冲突。使用 CIDR 表示法输入范围。例如：`10.2.0.0/16`。
此 CIDR 块必须满足以下要求：
+ 处于以下范围之一：`10.0.0.0/8`、`172.16.0.0/12` 或 `192.168.0.0/16`。
+ 具有最小大小 `/24` 和最大大小 `/12`。
+ 与您的 Amazon EKS 资源的 VPC 范围不重叠。
您只能在使用 `IPv4` 地址系列和创建集群时指定此选项。如果没有指定此选项，Kubernetes 会从 `10.100.0.0/16` 或 `172.20.0.0/16` CIDR 块分配服务 IP 地址。
+ 如果您要创建集群并希望集群将 `IPv6` 地址（而不是 `IPv4` 地址）分配到容器组（pod）和服务，请指定 [ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily) 选项。
默认情况下，Kubernetes 会将 `IPv4` 地址分配给容器组（pod）和服务。在决定使用 `IPv6` 系列前，请确保您熟悉 [VPC 要求和注意事项](network-reqs.md#network-requirements-vpc)、[子网要求和注意事项](network-reqs.md#network-requirements-subnets)、[查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md) 和 [了解如何将 IPv6 地址分配给集群、容器组（pod）和服务](cni-ipv6.md) 主题中的所有考虑因素和要求。如果选择 `IPv6` 系列，则不同于可为其指定地址范围的 `IPv4` 系列，您无法指定从中分配 `IPv6` 服务地址的 Kubernetes 的地址范围。Kubernetes 从唯一的本地地址范围 (`fc00::/7`) 分配服务地址。
### 创建集群 – AWS 控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 请选择 **Add cluster**（添加集群），然后选择 **Create**（创建）。
1. 在**配置选项**下，选择**自定义配置**
+ 有关快速创建启用 EKS 自动模式的集群的信息，请参阅[使用 AWS 管理控制台创建 EKS 自动模式集群](automode-get-started-console.md)。
1. 在 **EKS 自动模式**下，将**使用 EKS 自动模式**切换为关闭。
+ 有关创建具有自定义配置的 EKS 自动模式集群的信息，请参阅[创建 Amazon EKS 自动模式集群](create-cluster-auto.md)。
1. 在 **Configure cluster**（配置集群）页面上，输入以下字段：
+ **Name**（名称）– 集群的名称。名称只能包含字母数字字符（区分大小写）、连字符和下划线。该名称必须以字母数字字符开头，且不得超过 100 个字符。对于您在其中创建集群的 AWS 区域和 AWS 账户，该名称必须在其内具有唯一性。
+ **集群 IAM 角色** – 选择您创建的 Amazon EKS 集群 IAM 角色，以允许 Kubernetes 控制面板来代表您管理 AWS 资源。
+ **Kubernetes version（Kubernetes 版本）**– 要用于集群的 Kubernetes 的版本。建议选择最新版本，除非您需要早期版本。
+ **支持类型** – 要为集群设置的 Kubernetes 版本策略。如果您希望集群仅根据标准支持版本运行，则可以选择**标准支持**。如果您希望集群在某个版本的标准支持终止时进入扩展支持，则可以选择**扩展支持**。如果您选择的 Kubernetes 版本当前处于延期支持状态，则无法选择标准支持选项。
+ **Secrets encryption**（密钥加密）–（可选）选择此选项以使用 KMS 密钥启用 Kubernetes 密钥的密钥加密。您也可以在创建集群后启用此功能。在启用此功能之前，请确保您熟悉[在现有集群上使用 KMS 加密 Kubernetes 密钥](enable-kms.md)中的信息。
+ **Tags（标签）**– （可选）向集群添加任何标签。有关更多信息，请参阅 [使用标签整理 Amazon EKS 资源](eks-using-tags.md)。
+ **ARC 可用区转移** –（可选）您可以使用 Route53 应用程序恢复控制器来缓解受损的可用区。有关更多信息，请参阅 [了解 Amazon EKS 中的 Amazon 应用程序恢复控制器（ARC）可用区转移](zone-shift.md)。
1. 在“配置集群”页面的**集群访问权限**部分中，输入以下字段：
+ **引导集群管理员访问权限** – 集群创建者自动成为 Kubernetes 管理员。如果要禁用此功能，请选择**不允许集群管理员访问权限**。
+ **集群身份验证模式** – 确定您希望如何向 IAM 用户和角色授予 Kubernetes API 访问权限。有关更多信息，请参阅 [设置集群身份验证模式](grant-k8s-access.md#set-cam)。
完成此页面后，请选择**下一步**。
1. 在 **Specify networking (指定联网)** 页面上，为以下字段选择值：
+ **VPC** – 选择符合 [Amazon EKS VPC 要求](network-reqs.md#network-requirements-vpc)的现有 VPC 以在其中创建集群。在选择 VPC 之前，我们建议您熟悉 [查看 Amazon EKS 对 VPC 和子网的联网要求](network-reqs.md) 中的所有要求和考虑因素。集群创建后，您无法更改要使用的 VPC。如果没有列出任何 VPC，则需要先创建一个。有关更多信息，请参阅 [为您的 Amazon EKS 集群创建 Amazon VPC](creating-a-vpc.md)。
+ **Subnets**（子网）– 预设情况下，已预先选中在之前字段中指定的 VPC 中的所有可用子网。您必须至少选择两个子网。
您选择的子网必须符合 [Amazon EKS 子网要求](network-reqs.md#network-requirements-subnets)。在选择子网之前，我们建议您熟悉所有的 [Amazon EKS VPC 以及子网要求和注意事项](network-reqs.md)。
**Security groups**（安全组）–（可选）指定您希望 Amazon EKS 将之与其创建的网络接口关联的一个或多个安全组。
无论您是否选择任何安全组，Amazon EKS 都会创建一个安全组，以实现集群和 VPC 之间的通信。Amazon EKS 将此安全组以及您选择的任何安全组与它创建的网络接口关联起来。有关 Amazon EKS 创建的集群安全组的更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。您可以修改 Amazon EKS 创建的集群安全组中的规则。
+ **选择集群 IP 地址系列** - 您可以选择 **IPv4** 和 **IPv6**。
默认情况下，Kubernetes 会将 `IPv4` 地址分配给容器组（pod）和服务。在决定使用 `IPv6` 系列前，请确保您熟悉 [VPC 要求和注意事项](network-reqs.md#network-requirements-vpc)、[子网要求和注意事项](network-reqs.md#network-requirements-subnets)、[查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)和 [了解如何将 IPv6 地址分配给集群、容器组（pod）和服务](cni-ipv6.md) 主题中的所有注意事项和要求。如果选择 `IPv6` 系列，则不同于可为其指定地址范围的 `IPv4` 系列，您无法指定从中分配 `IPv6` 服务地址的 Kubernetes 的地址范围。Kubernetes 从唯一的本地地址范围 (`fc00::/7`) 分配服务地址。
+ （可选）选择 **Configure Kubernetes Service IP address range**（配置 Kubernetes 服务 IP 地址范围），然后指定**服务 `IPv4` 范围**。
指定自己的范围有助于防止 Kubernetes 服务与对等或连接到 VPC 的其他网络之间发生冲突。使用 CIDR 表示法输入范围。例如：`10.2.0.0/16`。
此 CIDR 块必须满足以下要求：
+ 处于以下范围之一：`10.0.0.0/8`、`172.16.0.0/12` 或 `192.168.0.0/16`。
+ 具有最小大小 `/24` 和最大大小 `/12`。
+ 与您的 Amazon EKS 资源的 VPC 范围不重叠。
您只能在使用 `IPv4` 地址系列和创建集群时指定此选项。如果没有指定此选项，Kubernetes 会从 `10.100.0.0/16` 或 `172.20.0.0/16` CIDR 块分配服务 IP 地址。
+ 对于**集群端点访问**中，选择一个选项。创建集群后，您可以更改此选项。在选择非默认选项之前，请务必熟悉这些选项及其影响。有关更多信息，请参阅 [集群 API 服务器端点](cluster-endpoint.md)。
完成此页面后，请选择**下一步**。
1. （可选）在**配置可观测性**页面上，选择要开启的**指标**和**控制面板日志记录**选项。默认情况下，每种日志类型都处于关闭状态。
+ 有关 Prometheus 指标选项的更多信息，请参阅[第 1 步：开启 Prometheus 指标](prometheus.md#turn-on-prometheus-metrics)。
+ 有关**控制面板日志记录**选项的更多信息，请参阅 [将控制面板日志发送到 CloudWatch Logs](control-plane-logs.md)。
完成此页面后，请选择**下一步**。
1. 在 **Select add-ons**（选择附加组件）页面上，选择要添加到集群的附加组件。预先选择特定附加组件。您可以根据需要选择任意数量的 **Amazon EKS 附加组件**和 **AWS Marketplace 附加组件**。如果未列出要安装的 **AWS Marketplace 附加组件**，则您可以单击页码编号查看更多页面结果或通过在搜索框中输入文本来搜索可用的 **AWS Marketplace 附加组件**。您也可以按**类别**、**供应商**或**定价模式**进行搜索，然后从搜索结果中选择附加组件。创建集群时，您可以查看、选择和安装任何支持 EKS 容器组身份的附加组件，详情请参阅[了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限](pod-identities.md)。
完成此页面后，请选择**下一步**。
系统会默认安装 Amazon VPC CNI、CoreDNS 和 kube-proxy 等插件。如果您禁用任何默认插件，则可能会影响您运行 Kubernetes 应用程序的能力。
1. 在**配置选定插件设置**页面上，选择要安装的版本。创建集群后，您可以随时更新到更高版本。
对于支持 EKS 容器组身份的附加组件，您可以使用控制台自动生成角色，其中包含专门为该附加组件预先填充的名称、AWS 托管策略和信任策略。您可以重复使用现有角色或为支持的附加组件创建新角色。有关使用控制台为支持 EKS 容器组身份的附加组件创建角色的步骤，请参阅[创建附加组件（AWS 控制台）](creating-an-add-on.md#create_add_on_console)。如果附加组件不支持 EKS 容器组身份，则系统会显示一条消息，说明如何在创建集群后使用向导为服务账户（IRSA）创建 IAM 角色。
创建集群后，您可以更新每个附加组件的配置。有关配置附加组件的更多信息，请参阅[更新 Amazon EKS 附加组件](updating-an-add-on.md)。完成此页面后，请选择**下一步**。
1. 在 **Review and create (审核和创建)** 页面上，审核您在之前页面输入或选择的信息。如果需要进行更改，请选择 **Edit**（编辑）。在您感到满意后，选择**创建**。**Status**（状态）字段在预置集群时显示 **CREATING**（正在创建）。
**注意**
您可能会收到一个错误，指示请求中的可用区之一没有足够容量来创建 Amazon EKS 集群。如果发生这种情况，错误输出将包含可支持新集群的可用区。再次尝试使用至少两个位于您账户中支持的可用区的子网创建集群。有关更多信息，请参阅 [容量不足](troubleshooting.md#ice)。
集群预配置需要几分钟时间。
1. 继续[第 3 步：更新 kubeconfig](#step3)
### 创建集群 – AWS CLI
1. 使用以下命令创建集群。在运行命令之前，进行以下替换：
+ 将 *region-code* 替换为您要在其中创建集群的 AWS 区域。
+ 将 *my-cluster* 替换为您的集群名称。名称只能包含字母数字字符（区分大小写）、连字符和下划线。该名称必须以字母数字字符开头，且不得超过 100 个字符。对于您在其中创建集群的 AWS 区域和 AWS 账户，该名称必须在其内具有唯一性。
+ 将 *1.35* 替换为任何 [Amazon EKS 支持的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。
+ 将 *111122223333* 替换为账户 ID，并将 *myAmazonEKSClusterRole* 替换为您的集群 IAM 角色的名称。
+ 将 `subnetIds` 的值替换为您自己的值。您还可以添加其他 ID。您必须指定至少两个子网 ID。
您选择的子网必须符合 [Amazon EKS 子网要求](network-reqs.md#network-requirements-subnets)。在选择子网之前，我们建议您熟悉所有的 [Amazon EKS VPC 以及子网要求和注意事项](network-reqs.md)。
+ 如果您不想指定安全组 ID，请从命令中删除 `,securityGroupIds=sg-`。如果您想指定一个或多个安全组 ID，请将 `securityGroupIds` 的值替换为您自己的值。您还可以添加其他 ID。
无论您是否选择任何安全组，Amazon EKS 都会创建一个安全组，以实现集群和 VPC 之间的通信。Amazon EKS 将此安全组以及您选择的任何安全组与它创建的网络接口关联起来。有关 Amazon EKS 创建的集群安全组的更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。您可以修改 Amazon EKS 创建的集群安全组中的规则。
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws:iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**注意**
您可能会收到一个错误，指示请求中的可用区之一没有足够容量来创建 Amazon EKS 集群。如果发生这种情况，错误输出将包含可支持新集群的可用区。再次尝试使用至少两个位于您账户中支持的可用区的子网创建集群。有关更多信息，请参阅 [容量不足](troubleshooting.md#ice)。
以下是可选设置，如果需要，必须将这些设置添加到上一个命令中。您只能在创建集群时启用这些选项，而不能在创建集群后启用。
+ 默认情况下，EKS 会在创建集群期间安装多个联网插件。这包括 Amazon VPC CNI、CoreDNS 和 kube-proxy 等。
如果要禁用这些默认联网插件的安装，请使用以下参数。这可以用于 Cilium 等替代 CNI。有关更多信息，请参阅 [EKS API 参考](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html)。
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ 如果您想指定 Kubernetes 从中分配服务 ID 地址的 `IPv4` 无类别域间路由（CIDR）块，您必须通过将 `--kubernetes-network-config serviceIpv4Cidr=` 添加到以下命令中来指定它。
指定自己的范围有助于防止 Kubernetes 服务与对等或连接到 VPC 的其他网络之间发生冲突。使用 CIDR 表示法输入范围。例如：`10.2.0.0/16`。
此 CIDR 块必须满足以下要求：
+ 处于以下范围之一：`10.0.0.0/8`、`172.16.0.0/12` 或 `192.168.0.0/16`。
+ 具有最小大小 `/24` 和最大大小 `/12`。
+ 与您的 Amazon EKS 资源的 VPC 范围不重叠。
您只能在使用 `IPv4` 地址系列和创建集群时指定此选项。如果没有指定此选项，Kubernetes 会从 `10.100.0.0/16` 或 `172.20.0.0/16` CIDR 块分配服务 IP 地址。
+ 如果您创建集群并希望集群分配 `IPv6` 地址而不是 `IPv4` 地址给容器组（pod）和服务，请将 `--kubernetes-network-config ipFamily=ipv6` 添加到以下命令。
默认情况下，Kubernetes 会将 `IPv4` 地址分配给容器组（pod）和服务。在决定使用 `IPv6` 系列前，请确保您熟悉 [VPC 要求和注意事项](network-reqs.md#network-requirements-vpc)、[子网要求和注意事项](network-reqs.md#network-requirements-subnets)、[查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)和 [了解如何将 IPv6 地址分配给集群、容器组（pod）和服务](cni-ipv6.md) 主题中的所有注意事项和要求。如果选择 `IPv6` 系列，则不同于可为其指定地址范围的 `IPv4` 系列，您无法指定从中分配 `IPv6` 服务地址的 Kubernetes 的地址范围。Kubernetes 从唯一的本地地址范围 (`fc00::/7`) 分配服务地址。
1. 预置集群需要几分钟时间。可使用以下命令查询集群的状态。
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
在返回的输出为 `ACTIVE` 之前，请勿继续执行下一步。
1. 继续[第 3 步：更新 kubeconfig](#step3)
## 第 3 步：更新 kubeconfig
1. 如果您使用 `eksctl` 创建了集群，则可以跳过此步骤。这是因为 `eksctl` 已经为您完成了此步骤。通过向 `kubectl` `config` 文件添加新上下文来启用 `kubectl` 与您的集群通信。有关如何创建和更新文件的更多信息，请参阅 [通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)。
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
示例输出如下。
```
Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. 通过运行以下命令以确认与集群的通信。
```
kubectl get svc
```
示例输出如下。
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## 第 4 步：集群设置
1. （推荐）要使用某些 Amazon EKS 附加组件，或启用个别 Kubernetes 工作负载以具有特定 AWS Identity and Access Management（IAM）权限，请为集群[创建一个 IAM OpenID Connect（OIDC）提供者](enable-iam-roles-for-service-accounts.md)。您只需为集群创建一次 IAM OIDC 提供程序。要了解有关 Amazon EKS 附加组件的详情，请参阅 [Amazon EKS 附加组件](eks-add-ons.md)。要了解有关将特定 IAM 权限分配给工作负载的详情，请参阅 [服务账户的 IAM 角色](iam-roles-for-service-accounts.md)。
1. （推荐）在将 Amazon EC2 节点部署到集群之前，为适用于 Kubernetes 的 Amazon VPC CNI 插件配置集群。默认情况下，该插件随集群一起安装。当您将 Amazon EC2 节点添加到集群时，插件将自动部署到您添加的每个 Amazon EC2 节点上。该插件要求您将以下 IAM 策略之一附加到 IAM 角色。如果集群使用 `IPv4` 系列，请使用 [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) 托管 IAM 策略。如果您的集群使用 `IPv6` 系列，请使用[您创建的 IAM 策略](cni-iam-role.md#cni-iam-role-create-ipv6-policy)。
您将策略附加到的 IAM 角色可以是节点 IAM 角色，也可以是仅用于插件的专用角色。我们建议将策略附加到此角色。有关创建角色的更多信息，请参阅[配置 Amazon VPC CNI 插件以使用 IRSA](cni-iam-role.md)或 [Amazon EKS 节点 IAM 角色](create-node-role.md)。
1. 如果您使用 AWS 管理控制台 部署了集群，则可以跳过此步骤。默认情况下，AWS 管理控制台 会部署适用于 Kubernetes 的 Amazon VPC CNI 插件、CoreDNS 和 `kube-proxy` Amazon EKS 附加组件。
如果使用 `eksctl` 或 AWS CLI 部署集群，则系统将部署适用于 Kubernetes 的 Amazon VPC CNI 插件、CoreDNS 和 `kube-proxy` 自主管理型附加组件。您可以将使用集群部署的适用于 Kubernetes 的 Amazon VPC CNI 插件、CoreDNS 和 `kube-proxy` 自主管理型附加组件迁移到 Amazon EKS 附加组件。有关更多信息，请参阅 [Amazon EKS 附加组件](eks-add-ons.md)。
1. （可选）如果您尚未执行此操作，可以为集群启用 Prometheus 指标。有关更多信息，请参阅《Amazon Managed Service for Prometheus 用户指南》**中的[创建抓取程序](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create)。
1. 如果您计划将工作负载部署到使用 Amazon EBS 卷的集群，则在部署工作负载之前，您必须将 [Amazon EBS CSI](ebs-csi.md) 安装到您的集群。
## 后续步骤
+ 创建集群的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)是唯一可以访问集群的主体。[向其它 IAM 主体授予权限](grant-k8s-access.md)，以便它们可以访问您的集群。
+ 如果创建集群的 IAM 主体仅具有先决条件中引用的最低 IAM 权限，则您可能想要为该主体添加额外的 Amazon EKS 权限。有关向 IAM 主体授予 Amazon EKS 权限的更多信息，请参阅[适用于 Amazon EKS 的身份和访问管理](security-iam.md)。
+ 如果您希望创建集群的 IAM 主体或任何其他主体在 Amazon EKS 控制台中查看 Kubernetes 资源，请向实体授予[所需权限](view-kubernetes-resources.md#view-kubernetes-resources-permissions)。
+ 如果您希望节点和 IAM 主体从 VPC 内访问您的集群，请为集群启用私有端点。默认情况下，将启用公有端点。如需要，可以在启用私有端点后禁用公有端点。有关更多信息，请参阅 [集群 API 服务器端点](cluster-endpoint.md)。
+ [为集群启用密钥加密](enable-kms.md)。
+ [为集群配置日志记录](control-plane-logs.md)。
+ [将节点添加到集群](eks-compute.md)。
# Amazon EKS 预置式控制面板
## 概述
Amazon EKS 预置式控制面板是一项功能，集群管理员可通过它从一系列扩展层级中进行选择，并为集群的控制面板指定所选层级，以此实现极高且可预期的性能表现。借助该功能，集群管理员能够确保控制面板始终按照指定的容量完成预置部署。
Amazon EKS 为集群的控制面板提供两种运行模式。默认情况下，Amazon EKS 集群采用**标准模式**。在此模式下，控制面板会根据工作负载需求自动进行纵向扩展与缩减。标准模式可动态分配充足的控制面板容量来满足工作负载需求，是适用于大多数使用案例的推荐方案。但对于部分特殊工作负载，比如无法容忍控制面板因扩缩而产生任何性能波动，或需要超大控制面板容量的场景，您可以选择启用**预置模式**。预置模式支持预先分配控制面板容量，让资源始终处于就绪状态，能够应对高负载的工作负载需求。
**注意**
预置模式是一种附加的控制面板运行模式，与默认的标准模式并行存在。预置模式的推出，不会改变标准模式的原有运行逻辑。
借助 EKS 预置式控制面板功能，集群管理员可以提前预置所需的控制面板容量，让集群控制面板始终保持可用状态，同时实现可预期的高性能表现。EKS 预置式控制面板还支持集群管理员在多环境中预置相同规格的控制面板容量，覆盖从测试环境、生产环境到灾难恢复站点的全场景。这一点至关重要，能够确保多环境下的控制面板性能一致且可预期。此外，EKS 预置式控制面板可提供超高规格的控制面板性能，支持您在 Kubernetes 上运行具备海量扩展能力的人工智能工作负载、高性能计算工作负载以及大规模数据处理工作负载。
所有现存及新建的 Amazon EKS 集群，均默认采用标准模式运行。对于对控制面板有高性能、可预期表现需求的集群，您可以选择启用 EKS 预置式控制面板功能。计费方面，除 EKS 标准支持或扩展支持的小时费外，您还需按所选控制面板扩展层级的小时费率支付费用。有关定价的更多信息，请参阅 [Amazon EKS 定价](https://aws.amazon.com/eks/pricing/)。
![\[Amazon EKS 控制面板模式\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/control-plane-modes.png)
## 使用案例
EKS 预置式控制面板功能专为满足部分特定业务场景而设计，在这些场景中，控制面板的高性能与可预期表现对业务运行至关重要。了解这些使用案例，有助于您判断 EKS 预置式控制面板是否为适配自身工作负载的理想方案。
**性能敏感型工作负载**：对于要求 Kubernetes 控制面板具备极低延迟与极致性能的工作负载，EKS 预置式控制面板可提供充足容量，消除因控制面板扩缩操作引发的性能波动问题。
**海量扩展型工作负载**：若运行的工作负载具备极强的扩展属性（例如人工智能训练与推理、高性能计算、大规模数据处理），且这类负载需要集群内运行大量节点，EKS 预置式控制面板能够提供所需的控制面板容量，以此支撑这些高压力工作负载的运行。
**可预期的高需求事件**：当预判将出现控制面板请求量激增的情况时，例如电商大促活动、新品发布、节假日购物季，或是重大体育赛事、文娱活动期间，预置式控制面板允许提前对控制面板容量进行扩展。这种主动配置方式，可确保控制面板提前就绪，从容应对流量高峰，无需等待自动扩缩机制响应需求变化。
**环境一致性**：预置式控制面板支持您在测试环境与生产环境中配置相同的控制面板容量与性能规格，助力您在业务部署至生产环境前，尽早识别潜在问题。通过在多环境中保持一致的控制面板层级，测试结果能够精准反映生产环境的运行状态，从而降低业务上线时因性能问题引发意外状况的风险。
**灾难恢复与业务连续性**：在灾难恢复场景下，预置式控制面板允许您为失效转移环境配置与主环境同等水平的控制面板容量。这一配置可确保失效转移切换时，业务中断时间降至最低，且恢复速度更快。因为灾难恢复集群从启动的那一刻起，就具备与生产集群完全一致的控制面板性能特征。
## 控制面板扩展层级
EKS 预置式控制面板提供的扩展层级采用 T 恤尺码命名方式（XL、2XL、4XL 和 8XL）。每个层级均通过三项 Kubernetes 核心属性定义自身容量规格，而这三项属性决定了集群控制面板的性能特征。理解这些属性，有助于您根据自身工作负载需求选择合适的扩展层级。
**API 请求并发量**：衡量 Kubernetes 控制面板的 API Server 可同时处理的请求数量，这一指标对于高吞吐量工作负载至关重要。
**容器组（pod）调度速率**：表示默认 Kubernetes 调度器将容器组（pod）调度到节点的速度，单位为每秒调度容器组（pod）数。
**集群数据库容量**：表示为 etcd（存储集群状态/元数据的数据库）分配的存储空间大小。
当您通过预置式控制面板功能，为集群控制面板配置某一扩展层级时，Amazon EKS 会确保该控制控制面板维持与所选层级对应的各项限额。控制面板各扩展层级的限额会随 Kubernetes 版本不同而有所差异，具体信息详见下表。
### EKS v1.28 及 v1.29
| 预置式控制面板扩展层级 | API 请求并发量（席位） | 容器组（pod）调度速率（个/秒） | 集群数据库容量（GB） |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS v1.30 及更高版本
| 预置式控制面板扩展层级 | API 请求并发量（席位） | 容器组（pod）调度速率（个/秒） | 集群数据库容量（GB） |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2XL | 3400 | 283 | 16 |
| 4XL | 6800 | 400 | 16 |
| 8XL | 13600 | 400 | 16 |
### 监控控制面板扩展层级使用率
Amazon EKS 提供多项指标，有助于您监控控制面板的扩展层级使用率。这些指标会以 [Amazon CloudWatch 指标](cloudwatch.md)的形式发布，可通过 CloudWatch 控制台与 EKS 控制台进行查看。此外，您可以从 EKS 集群的 Prometheus 端点中采集这些指标（详见[此处](prometheus.md)）。
| | **Prometheus 指标** | **CloudWatch 指标** |
| --- | --- | --- |
| **API 请求并发数** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **容器组（pod）调度速率** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total、scheduler\$1schedule\$1attempts\$1SCHEDULED、scheduler\$1schedule\$1attempts\$1UNSCHEDULABLE |
| **集群数据库大小** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
您可以在 Amazon EKS 控制台中查看控制面板利用率。在集群的概述页面中，选择**监控集群**以访问可观测性控制面板，然后选择**控制面板监控**选项卡以查看**控制面板扩展**部分下的控制面板利用率。
![\[监控 EKS 集群\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/monitor-cluster.png)
![\[EKS 控制面板监控\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/control-plane-monitoring.png)
### 理解层级容量与实际性能的区别
当您选定某一预置式控制面板扩展层级时，该层级的各项属性代表着 Amazon EKS 为集群控制面板配置的底层参数。但您最终获得的实际性能，取决于自身具体的工作负载模式、配置情况以及对 Kubernetes 最佳实践的遵循程度。例如，4XL 层级会将 API 优先级和公平性（APF）配置为支持 6800 个并发请求席位，但控制面板实际能达到的请求吞吐量，会受当前执行的操作类型影响。例如，Kubernetes 对 list 请求的资源消耗要求高于 get 请求，因此控制面板可并发处理的 list 请求有效数量，会低于 get 请求的并发处理数量（详见[此处](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness)）。同理，虽然 4XL 层级会将默认调度器的每秒查询率（QPS）设置为 400，但实际的容器组（pod）调度速率，还会受节点是否处于就绪、运行状况的可调度状态等因素影响。若要实现最优性能，请确保应用程序遵循 Kubernetes 最佳实践规范（详见[此处](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)），并针对自身工作负载的特征完成合理配置。
## 注意事项
+ **标准模式控制面板容量**：EKS 标准模式控制面板具备出色的性价比，是绝大多数使用案例的推荐方案。但对于两类特殊工作负载，无法容忍控制面板因扩缩产生性能波动的负载，或是需要超大控制面板容量的负载，您可以选择启用预置模式。
+ **需手动启用**：现存集群不会从标准控制面板自动纵向扩展到更高[资费](https://aws.amazon.com/eks/pricing/)的 EKS 预置式控制面板层级。您必须明确启用其中一个全新的 EKS 预置式控制面板扩展层级。
+ **回退限制**：标准模式控制面板支持的集群数据库（etcd）容量上限为 8 GB。若在预置模式下的集群数据库容量超过 8 GB，则必须先将数据库容量降至 8 GB 以下，才能切换回标准模式。例如，若在预置模式下使用了 14 GB 的数据库存储空间，需先将数据库使用率降至 8 GB 以下，方可回退至标准模式。
+ **无自动层级扩缩机制**：EKS 预置式控制面板不支持跨层级自动扩缩。一旦选定某一扩展层级，集群控制面板将固定在该层级运行，以此保障性能的一致性与可预期性。不过，您可灵活搭建自定义的自动扩缩方案：通过监控层级使用率指标，当指标触发设定的阈值时，调用 EKS 预置式控制面板 API 执行纵向扩展或缩减操作，从而完全掌控扩缩策略与成本优化方向。
+ **查看当前层级**：您可通过 Amazon EKS 控制台、AWS 命令行界面（CLI）或 API，查看当前的控制面板扩展层级。在 CLI 中，可执行 `describe-cluster` 命令：`aws eks describe-cluster --name cluster-name`
+ **层级切换耗时**：您可通过 Amazon EKS 控制台、API 或 CLI，执行跨层级切换或退出预置模式的操作。Amazon EKS 新增了一种名为 `ScalingTierConfigUpdate` 的集群更新类型，您可通过查看该更新类型的状态，监控层级切换进度。执行层级变更命令后，可列出集群的更新记录，此时会出现一条类型为 `ScalingTierConfigUpdate`、状态为 `Updating` 的新记录。更新完成后，状态会变为 `Successful`；若出现错误，状态则为 `Failed`。更新记录的 error 字段会注明失败原因。层级切换的操作频率不受限制。控制面板切换过程通常需要数分钟完成。此过程不会出现 API 服务器停机时间，因为 EKS 会在终止旧的 API 服务器之前启动新的 API 服务器。
+ **选择最优层级**：若要为集群选定最优的预置式控制面板扩展层级，可按如下步骤进行压力测试：先将集群预置在最高层级（8XL），再执行压力测试，模拟集群控制面板的峰值负载场景。观察峰值负载下的控制面板层级使用率指标，并以此为依据，选定适合预置模式的扩展层级。
+ **预置式控制面板计费规则**：集群将按预置式控制面板当前所属扩展层级的小时费率计费。该费用在标准支持或扩展支持的小时费基础上叠加收取。有关详细信息，请参阅 [Amazon EKS 定价](https://aws.amazon.com/eks/pricing/)页面。
+ **更大规格扩展层级**：若计划将集群运行在高于 8XL 的扩展层级，请联系亚马逊云科技客户经理，咨询额外的定价信息。
+ **Kubernetes 版本与地域支持**：EKS 预置式控制面板在所有亚马逊云科技商业区域、GovCloud 区域及中国区域均提供支持。预置式控制面板适用于 EKS v1.28 及更高版本。
# Amazon EKS 预置式控制面板入门
本指南将逐步引导您完成借助 AWS CLI 及AWS 管理控制台，搭建并使用 EKS 预置式控制面板的操作流程。
## 先决条件
在开始之前，请确保您满足以下条件：
+ **AWS CLI** – 与 AWS 服务（包括 Amazon EKS）结合使用的命令行工具。有关更多信息，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。在安装 AWS CLI 后，建议您还要对其进行配置。有关更多信息，请参阅《AWS 命令行界面用户指南》**中的[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。请注意，需要 AWS CLI v2 才能使用本页中显示的 **update-kubeconfig** 选项。
+ **所需的 IAM 权限** – 您正在使用的 IAM 安全主体必须具有使用 Amazon EKS IAM 角色、服务相关角色、AWS CloudFormation、VPC 和相关资源的权限。有关更多信息，请参阅*《IAM 用户指南》*中的[操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html)和[使用服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)。您必须以同一用户身份完成本指南中的所有步骤。要查看当前用户，请运行以下命令：
```
aws sts get-caller-identity
```
**注意**
我们建议您在 Bash Shell 中完成本主题中的步骤。如果您没有使用 Bash Shell，则某些脚本命令（例如行延续字符以及变量的设置和使用方式）需要调整 Shell。此外，您的 Shell 的引用和转义规则可能有所不同。有关更多信息，请参阅《AWS 命令行界面用户指南》**中的[在 AWS CLI 中将引号和字符串结合使用](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html)。
## EKS 预置式控制面板：AWS CLI
### 创建搭载 EKS 预置式控制面板扩展层级的集群
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
响应：
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### 查看集群的控制面板扩展层级
```
aws eks describe-cluster --name prod-cluster
```
响应：
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### 更新集群以启用 EKS 预置式控制面板
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
响应：
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### 查看控制面板扩展配置的更新状态
```
aws eks list-updates --name example
```
响应：
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### 从预置式控制面板切换到标准控制面板
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
响应：
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## EKS 预置式控制面板：AWS 管理控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择**创建集群**。
1. 在*配置选项*下，选择**自定义配置**。
1. 向下滚动到**控制面板扩展层级**选项。勾选**启用扩展层级**，以此开启预置式控制面板功能。
1. 从各类扩展层级选项（如 XL、2XL、4XL 和 8XL）中，选择要为集群配置的控制面板扩展层级。
1. 根据需求选择其他集群配置项。在最后一步中，点击**创建集群**。请注意，集群创建过程可能需要数分钟才能完成。
# 利用集群见解为 Kubernetes 版本升级做好准备并对错误配置进行问题排查
Amazon EKS 集群见解提供问题检测和解决问题的建议，以帮助您管理集群。每个 Amazon EKS 集群都会根据 Amazon EKS 精心策划的见解列表进行自动的定期检查。这些*见解检查*完全由 Amazon EKS 管理，并就如何解决任何调查发现提供建议。
## 集群见解类型
+ **配置见解**：识别 EKS 混合节点设置中可能损害集群或工作负载功能的错误配置。
+ **升级见解**：识别可能影响您升级到新版 Kubernetes 能力的问题。
## 注意事项
+ **频率**：Amazon EKS 每 24 小时刷新一次集群见解，您也可以手动刷新以查看最新状态。例如，您可以在解决问题后手动刷新集群见解，以查看问题是否已解决。
+ **权限**：Amazon EKS 会为每个 EKS 集群中的集群见解自动创建集群访问条目。此条目会授予 EKS 查看有关集群的信息的权限。Amazon EKS 会利用这些信息来生成见解。有关更多信息，请参阅 [AmazonEKSClusterInsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy)。
## 使用案例
Amazon EKS 中的集群见解提供自动检查，可帮助维护 Kubernetes 集群的运行状况、可靠性和最佳配置。以下是集群见解的关键使用案例，包括升级准备情况和配置故障排除。
### 升级见解
升级见解是集群见解中的一种特定类型的见解检查。这些检查会返回与 Kubernetes 版本升级就绪情况相关的见解。Amazon EKS 会对每个 EKS 集群运行升级见解检查。
**重要**
Amazon EKS 暂时回滚了一项功能，该功能要求您在遇到某些集群见解问题时使用 `--force` 标志升级集群。有关更多信息，请参阅 GitHub 上的 [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570)。
有关更新集群的更多信息，请参阅[第 3 步：更新集群控制面板](update-cluster.md#update-cluster-control-plane)。
在更新集群 Kubernetes 版本之前，可以使用 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)中可观测性控制面板的**升级见解**选项卡。如果您的集群已发现问题，请查看它们并进行适当的修复。这些问题包括指向 Amazon EKS 和 Kubernetes 文档的链接。修复问题后，按需刷新集群见解以获取最新见解。如果所有问题都已解决，则[请更新您的集群](update-cluster.md)。
Amazon EKS 会返回与 Kubernetes 版本升级就绪情况相关的见解。升级见解可以发现可能影响 Kubernetes 集群升级的可能问题。这样可以最大限度地减少管理员准备升级所需的工作量，并提高新 Kubernetes 版本上应用程序的可靠性。Amazon EKS 会根据可能影响 Kubernetes 版本升级的问题列表自动扫描集群。Amazon EKS 经常根据对每个 Kubernetes 版本中所做更改的审查来更新见解检查列表。
Amazon EKS 升级见解加快了新版本的测试和验证过程。还允许集群管理员和应用程序开发人员通过强调问题和提供补救建议来利用最新 Kubernetes 功能。
### 配置见解
EKS 集群见解会自动扫描带有混合节点的 Amazon EKS 集群，以发现影响 Kubernetes 控制面板到 Webhook 通信、exec 和日志等 kubectl 命令执行及其他方面的配置问题。配置见解可以发现问题并提供补救建议，从而加快实现混合节点设置完全正常运行的时间。
## 开始使用
要查看已执行的见解检查列表以及 Amazon EKS 发现的任何相关问题，您可以使用 AWS 管理控制台、AWS CLI、AWS SDK 和 Amazon EKS `ListInsights` API 操作。要开始使用，请参阅 [查看集群见解](view-cluster-insights.md)。
# 查看集群见解
Amazon EKS 提供两种类型的见解：**配置见解**与**升级见解**。**配置见解**可识别 EKS 混合节点设置中可能损害集群或工作负载功能的错误配置。**升级见解**可识别可能影响您升级到新版 Kubernetes 能力的问题。
要查看已执行的见解检查列表以及 Amazon EKS 发现的任何相关问题，您可以调用 AWS 管理控制台、AWS CLI、AWS SDK 和 Amazon EKS `ListInsights` API 操作进行查看。
## 查看配置见解（控制台）
1. 打开 [Amazon EKS console 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 从集群列表中，选择您希望查看见解的 Amazon EKS 集群的名称。
1. 选择**监控集群**。
1. 选择**集群运行状况**选项卡。
1. 在**配置见解**表中，您将看到以下列：
+ **名称** – Amazon EKS 对集群执行的检查。
+ **见解状态**：状态为 `Error` 的见解表示存在可能影响集群功能的错误配置。状态为 `Warning` 的见解表示配置与记录的方法不匹配，但如果有意配置该集群功能，则可能会起作用。状态为 `Passing` 的见解表示 Amazon EKS 并未在集群中发现与该见解检查相关的任何问题。
+ **版本**：适用的版本。
+ **上次刷新时间**：此集群上次刷新见解状态的时间。
+ **描述** – 来自见解检查的信息，包括警报和建议的补救措施。
## 查看升级见解（控制台）
1. 打开 [Amazon EKS console 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 从集群列表中，选择您希望查看见解的 Amazon EKS 集群的名称。
1. 选择**监控集群**。
1. 选择**升级见解**选项卡。
1. 要查看最新数据，请选择**刷新见解**按钮，然后等待刷新操作完成。
1. 在**升级见解**表中，您将看到以下列：
+ **名称** – Amazon EKS 对集群执行的检查。
+ **见解状态** – 状态为“错误”的见解通常表示受影响的 Kubernetes 版本是当前集群版本的 N\$11，而状态为“警告”的见解表示该见解适用于未来 Kubernetes 版本 N\$12 或更高版本。状态为“通过”的见解表示 Amazon EKS 在您的集群中未发现与该见解检查相关的任何问题。状态为“未知”的见解表示 Amazon EKS 无法确定您的集群是否受到此见解检查的影响。
+ **版本** – 见解检查可能存在问题的 Kubernetes 版本。
+ **上次刷新时间**：此集群上次刷新见解状态的时间。
+ **上次转换时间**：此见解上次更改状态的时间。
+ **描述** – 来自见解检查的信息，包括警报和建议的补救措施。
## 查看集群见解（AWS CLI）
1. 要查看最新数据，请刷新指定集群的见解。根据需要对该命令进行以下修改，然后运行修改后的命令。
+ 将 *region-code* 替换为 AWS 区域的代码。
+ 将 *my-cluster* 替换为您的集群的名称。
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. 要跟踪见解刷新状态，请运行以下命令。将 *my-cluster* 替换为您的集群的名称。
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
示例输出如下。
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. 列出指定集群的见解。根据需要对该命令进行以下修改，然后运行修改后的命令。
+ 将 *region-code* 替换为 AWS 区域的代码。
+ 将 *my-cluster* 替换为您的集群的名称。
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
示例输出如下。
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. 有关见解的描述性信息，请运行以下命令。根据需要对该命令进行以下修改，然后运行修改后的命令。
+ 将 *region-code* 替换为 AWS 区域的代码。
+ 请将 *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222* 替换为从集群见解列表中检索到的见解 ID。
+ 将 *my-cluster* 替换为您的集群的名称。
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
示例输出如下。
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# 将现有集群更新到新的 Kubernetes 版本
**提示**
[注册参加](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 讲习会。
当 Amazon EKS 中有新的 Kubernetes 版本可用时，您可以将 Amazon EKS 集群更新到最新版本。
**重要**
升级集群后，就无法降级到以前的版本。在更新到新的 Kubernetes 版本之前，建议您先查看[了解 EKS 上的 Kubernetes 版本生命周期](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)中的信息，以及本主题中的更新步骤。
新的 Kubernetes 版有时会引入重大更改。因此，我们建议您先针对新的 Kubernetes 版本测试您的应用程序的行为，然后再在生产集群上执行更新。您可以通过构建持续集成工作流来测试应用程序行为，然后再移至新的 Kubernetes 版本来执行此操作。
更新过程包含 Amazon EKS 随 Kubernetes 的更新版本推出新的 API 服务器节点，以取代现有此类节点。Amazon EKS 对这些新节点上的网络流量执行标准基础设施和就绪运行状况检查，以确认它们是否按预期工作。但是，一旦开始集群升级，就不能暂停或停止。如果任意一项检查失败，Amazon EKS 都将恢复基础设施部署，且您的集群保留为先前的 Kubernetes 版本。正在运行的应用程序不会受影响，并且您的集群绝不会处于不确定性或不可恢复的状态。Amazon EKS 会定期备份所有托管的集群，并且具有在必要时恢复集群的机制。我们会不断评估和改进我们的 Kubernetes 基础设施管理流程。
为了升级集群，Amazon EKS 需要您在创建集群时指定的子网中的最多 5 个可用的 IP 地址。Amazon EKS 在您指定的任何子网中创建新的集群弹性网络接口（网络接口）。网络接口可能在不同于现有网络接口所在的子网中创建，因此请确保您的安全组规则允许您对创建集群时指定的任何子网进行[所需的集群通信](sec-group-reqs.md)。如果您在创建集群时指定的任何子网不存在，没有足够的可用 IP 地址，或者没有允许必要的集群通信的安全组规则，则更新可能会失败。
为确保集群的 API 服务器端点始终可访问，Amazon EKS 提供了高度可用的 Kubernetes 控制面板，并且会在更新操作期间执行 API 服务器实例的滚动更新。由于支持 Kubernetes API 服务器端点的 API 服务器实例 IP 地址会持续变化，您必须确保自己的 API 服务器客户端能够有效地管理重新连接。最新版本的 `kubectl` 和 Kubernetes 客户端[库](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)已经获得正式支持，能够透明地执行此重新连接过程。
**注意**
要了解有关集群更新内容的更多信息，请参阅《EKS Best Practices Guide》中的 [Best Practices for Cluster Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)。此资源有助于您规划升级，了解集群升级策略。
## Amazon EKS 自动模式的注意事项
+ Amazon EKS 自动模式的计算能力控制节点的 Kubernetes 版本。升级控制面板后，EKS 自动模式将开始逐步更新托管式节点。EKS 自动模式会遵守容器组中断预算。
+ 您无需手动升级 Amazon EKS 自动模式的功能，包括计算自动扩缩、块存储和负载均衡功能。
## 摘要
下面简要概述了 Amazon EKS 集群升级过程：
1. 确保集群处于支持升级的状态。这包括检查部署到集群中的资源所使用的 Kubernetes API，确保集群没有任何运行状况问题。在评估集群的升级准备情况时，您应使用 Amazon EKS 升级见解。
1. 将控制面板升级到下一个次要版本（例如，从 1.34 升级到 1.35）。
1. 升级数据面板中的节点以匹配控制面板中的节点。
1. 升级集群上运行的所有其他应用程序（例如 `cluster-autoscaler`）。
1. 升级 Amazon EKS 提供的附加组件，例如默认包含的附加组件：
+ [Amazon VPC CNI 推荐版本](managing-vpc-cni.md)
+ [CoreDNS 推荐版本](managing-coredns.md)
+ [`kube-proxy` 推荐版本](managing-kube-proxy.md)
1. 升级与集群通信的所有客户端（例如 `kubectl`）。
## 第 1 步：准备升级
比较集群控制层面的 Kubernetes 版本与节点的 Kubernetes 版本。
+ 获取集群控制面板的 Kubernetes 版本。
```
kubectl version
```
+ 获取您的节点的 Kubernetes 版本。此命令会返回所有自主管理型和托管式 Amazon EC2、Fargate 和混合节点。每个 Fargate 容器组（pod）都作为其自身的节点列出。
```
kubectl get nodes
```
将控制面板升级到新的 Kubernetes 版本之前，确保集群中的托管节点和 Fargate 节点的 Kubernetes 次要版本与控制面板的版本相同。例如，如果您的控制面板正在运行 `1.29` 版本，且其中一个节点正在运行 `1.28` 版本，则您必须将节点更新为 `1.29` 版本，然后将控制面板更新为 1.30。我们还建议在更新控制面板之前，将自主管理型节点和混合节点更新到与控制面板相同的版本。有关更多信息，请参阅 [更新集群的托管式节点组](update-managed-node-group.md)、[更新集群的自行管理型节点](update-workers.md) 和 [升级集群的混合节点](hybrid-nodes-upgrade.md)。如果 Fargate 节点的次要版本低于控制面板版本，请先删除节点所表示的容器组（pod）。然后更新您的控制面板。剩余的容器组（pod）将在重新部署之后更新到新版本。
## 第 2 步：检查升级注意事项
Amazon EKS 集群见解会根据可能影响 Kubernetes 版本升级的问题（例如已弃用的 API 使用问题）列表自动扫描集群。Amazon EKS 会根据对 Kubernetes 项目变更的评估，定期更新待执行的见解检查列表。每当 Amazon EKS 服务引入更改以及新版本后，Amazon EKS 也会更新见解检查列表。有关更多信息，请参阅 [利用集群见解为 Kubernetes 版本升级做好准备并对错误配置进行问题排查](cluster-insights.md)。
查看 Kubernetes 文档中的[已弃用 API 的迁移指南](https://kubernetes.io/docs/reference/using-api/deprecation-guide/)。
### 查看升级见解
使用 Amazon EKS 升级见解来识别问题。有关更多信息，请参阅 [查看升级见解（控制台）](view-cluster-insights.md#view-upgrade-insights-console)。
### 详细注意事项
+ 由于 Amazon EKS 运行高度可用的控制面板，您一次只能更新一个次要版本。有关此要求的更多信息，请参阅 [Kubernetes 版本和版本偏差支持策略](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver)。假设集群的当前版本为版本 `1.28`，而且您想将其更新到版本 `1.30`。您必须先将版本 `1.28` 集群更新为版本 `1.29`，然后将版本 `1.29` 集群更新为版本 `1.30`。
+ 查看节点上 Kubernetes `kube-apiserver` 和 `kubelet` 之间的版本偏差。
+ 从 Kubernetes 版本 `1.28` 开始，`kubelet` 最多可能有三个早于 `kube-apiserver` 的次要版本。请参阅 [Kubernetes 上游版本偏差策略](https://kubernetes.io/releases/version-skew-policy/#kubelet)。
+ 如果您的托管节点和 Fargate 节点上的 `kubelet` 为 Kubernetes 版本 `1.25` 或更新版本，则无需更新 `kubelet` 版本即可将集群最多提前更新三个版本。例如，如果 `kubelet` 为版本 `1.25`，则可以在 `kubelet` 保持版本 `1.25` 的情况下，将您的 Amazon EKS 集群版本从 `1.25` 更新到 `1.27`、`1.26` 和 `1.28`。
+ 作为开始更新之前的最佳实践，请确保节点上的 `kubelet` 与控制面板具有相同的 Kubernetes 版本。
+ 如果集群配置有早于 `1.8.0` 的适用于 Kubernetes 的 Amazon VPC CNI 插件版本，建议将插件更新为最新版本，然后更新集群。要更新插件，请参阅 [使用 Amazon VPC CNI 将 IP 分配给容器组（pod）](managing-vpc-cni.md)。
+ 您可以备份 Amazon EKS 集群，以便在升级过程中出现故障时恢复 Amazon EKS 集群状态和持久性存储。请参阅 [使用 AWS Backup 备份 EKS 集群](integration-backup.md)。
## 第 3 步：更新集群控制面板
**重要**
Amazon EKS 暂时回滚了一项功能，该功能要求您在遇到某些集群见解问题时使用 `--force` 标志升级集群。有关更多信息，请参阅 GitHub 上的 [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570)。
Amazon EKS 会在“上次刷新时间”后 24 小时刷新集群见解。您可以将问题解决时间与集群见解的“上次刷新时间”进行比较。
此外，解决已弃用的 API 使用问题后，见解状态最多需要 30 天才能更新。升级见解始终会在 30 天滚动窗口内查找已弃用的 API 使用问题。
您可以使用以下方式提交升级 EKS 控制面板版本的请求：
+ [eksctl](#step3-eksctl)
+ [AWS 控制台](#step3-console)
+ [AWS CLI](#step3-cli)
### 更新集群 – eksctl
此过程需要 `eksctl` 版本 `0.215.0` 或更高版本。可以使用以下命令来查看您的版本：
```
eksctl version
```
有关安装和更新 `eksctl` 的说明，请参阅 `eksctl` 文档中的 [Installation](https://eksctl.io/installation)。
更新 Amazon EKS 控制面板的 Kubernetes 版本。将 `` 替换为您的集群名称。将 `` 替换为想要将集群更新到的 Amazon EKS 支持的版本号。有关支持的版本号列表，请参阅 [Amazon EKS 支持的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。
```
eksctl upgrade cluster --name --version --approve
```
更新过程可能需要几分钟才能完成。
继续[第 4 步：更新集群组件](#step4)。
### 更新集群 – AWS 控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 对于想要升级的集群，选择**立即升级**。
1. 选择要将集群更新到的版本，然后选择**升级**。
1. 更新过程可能需要几分钟才能完成。继续[第 4 步：更新集群组件](#step4)。
### 更新集群– AWS CLI
1. 确认已安装 AWS CLI 并且您已登录。有关更多信息，请参阅[安装或更新到最新版本的 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。
1. 使用以下 AWS CLI 命令更新 Amazon EKS 集群。替换要升级的集群的 `` 和 ``。将 `` 替换为想要将集群更新到的 Amazon EKS 支持的版本号。有关支持的版本号列表，请参阅 [Amazon EKS 支持的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
示例输出如下。
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. 更新过程可能需要几分钟才能完成。使用以下命令监控集群更新的状态。除了使用相同的 `` 和 `` 之外，还要使用上一条命令返回的 ``。
```
aws eks describe-update --name \
--region --update-id
```
当 `Successful` 状态显示时，更新完成。
1. 继续[第 4 步：更新集群组件](#step4)。
## 第 4 步：更新集群组件
1. 集群更新完成后，将节点更新为与已更新的集群相同的 Kubernetes 版本。有关更多信息，请参阅 [更新集群的自行管理型节点](update-workers.md)、[更新集群的托管式节点组](update-managed-node-group.md) 和 [升级集群的混合节点](hybrid-nodes-upgrade.md)。在 Fargate 上启动的任何新容器组（pod）都具有与您的集群版本匹配的 `kubelet` 版本。现有 Fargate Pod 不会更改。
1. （可选）如果您在更新集群之前将 Kubernetes Cluster Autoscaler 部署到了集群，请将 Cluster Autoscaler 更新为与您升级后的 Kubernetes 主版本和次要版本匹配的最新版本。
1. 在 Web 浏览器中打开 Cluster Autoscaler [版本](https://github.com/kubernetes/autoscaler/releases)页面，查找与您集群的 Kubernetes 主版本和次要版本相匹配的最新 Cluster Autoscaler 版本。例如，如果您集群的 Kubernetes 版本是 `1.30`，则查找以 `1.30` 开头的最新 Cluster Autoscaler 版本。记录该版本的语义版本号（例如 `1.30.n`）以在下一步中使用。
1. 使用以下命令，将 Cluster Autoscaler 映像标签设置为您在上一步中记录的版本。如有必要，将 `X.XX.X` 替换为您自己的值。
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. （仅限具有 GPU 节点的集群）如果您的集群具有支持 GPU 的节点组（例如 `p3.2xlarge`），则您必须在集群上更新[适用于 Kubernetes 的 NVIDIA 设备插件](https://github.com/NVIDIA/k8s-device-plugin) DaemonSet。将 `` 替换为您需要的 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) 版本，然后运行以下命令。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. 更新适用于 Kubernetes 的 Amazon VPC CNI 插件、CoreDNS 和 `kube-proxy` 附加组件。建议将附件组件更新为[服务账户令牌](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions)中列出的最低版本。
+ 如果您正在使用 Amazon EKS 附加组件，请在 Amazon EKS 控制台中选择 **Clusters**（集群），然后在左侧导航窗格中选择您更新的集群的名称。控制台中显示通知。这些通知将告知您有一个新版本可用于每个具有可用更新的附加组件。要更新附加组件，请选择**附加组件**选项卡。在具有可用更新的附加组件的其中一个框中，选择**立即更新**，选择一个可用版本，然后选择**更新**。
+ 此外，您也可以使用 AWS CLI 或 `eksctl` 更新附加组件。有关更多信息，请参阅 [更新 Amazon EKS 附加组件](updating-an-add-on.md)。
1. 如有必要，请更新您的 `kubectl` 版本。您必须使用与 Amazon EKS 集群控制面板不同的次要版本内的 `kubectl` 版本。
## 降级 Amazon EKS 集群的 Kubernetes 版本
无法降级 Amazon EKS 集群的 Kubernetes。而应根据之前的 Amazon EKS 版本创建一个新集群并迁移工作负载。
# 删除集群
使用完 Amazon EKS 集群后，应删除与其关联的资源，这样便不会产生任何不必要的费用。
您可以使用 `eksctl`、AWS 管理控制台或 AWS CLI 删除集群。
## 注意事项
+ 如果您因为已删除集群创建者而收到错误，请参阅[这篇文章](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error)解决。
+ 适用于 Prometheus 的 Amazon 托管服务资源不在集群生命周期内，需要独立于集群进行维护。删除集群时，请务必同时删除所有适用的抓取器以停止适用的费用。有关更多信息，请参阅*《Amazon Managed Service for Prometheus 用户指南》*中的[查找和删除抓取程序](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete)。
+ 要删除连接的集群，请参阅 [从 Amazon EKS 控制台注销 Kubernetes 集群](deregister-connected-cluster.md)
+ 在删除集群之前，请先确保已禁用该集群的删除保护功能。
### EKS 自动模式注意事项
+ 所有 EKS 自动模式节点都将被删除，包括 EC2 托管式实例
+ 所有负载均衡器都将被删除
有关更多信息，请参阅 [禁用 EKS 自动模式](auto-disable.md)。
## 先决条件步骤
以下是在删除集群之前您必须先执行的步骤。无论您采用何种方法来删除集群，这些步骤均适用。
1. 列出集群中运行的所有服务。
```
kubectl get svc --all-namespaces
```
1. 删除具有关联的 `EXTERNAL-IP` 值的任何服务。这些服务的前面配置了一个 Elastic Load Balancing 负载均衡器，您必须从 Kubernetes 中将其删除才能释放负载均衡器和关联资源。请根据描述将 *service-name* 替换为所列每项服务的名称。
```
kubectl delete svc service-name
```
1. 同时删除所有的入口资源。如果您不删除入口资源，则即使您删除了集群，应用程序负载均衡器仍会保留。将 *ingress-name* 替换为入口资源的名称。
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## 删除集群（eksctl）
此过程需要 `eksctl` 版本 `0.215.0` 或更高版本。可以使用以下命令来查看您的版本：
```
eksctl version
```
有关安装或升级 `eksctl` 的说明，请参阅 `eksctl` 文档中的 [Installation](https://eksctl.io/installation)。
1. 完成[先决条件步骤](#prerequisite-steps)。执行此操作后，使用以下命令（将 *prod* 替换为您的集群名称）删除集群及其关联的节点。
```
eksctl delete cluster --name prod
```
输出：
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## 删除集群（AWS 控制台）
1. 完成[先决条件步骤](#prerequisite-steps)。执行此操作后，删除所有节点组和 Fargate 配置文件。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 请在左侧导航窗格中，选择 Amazon EKS **Clusters**（集群），然后在集群的选项卡列表中，选择要删除的集群的名称。
1. 选择 **Compute**（计算）选项卡，然后选择要删除的节点组。选择 **Delete**（删除），输入节点组的名称，然后选择 **Delete**（删除）。删除集群中的所有节点组。
**注意**
只会列出[托管节点组](managed-node-groups.md)。
1. 选择要删除的 **Fargate Profile**（Fargate 配置文件），选择 **Delete**（删除），输入配置文件的名称，然后选择 **Delete**（删除）。删除集群中的所有 Fargate 配置文件。
1. 删除所有[自主管理的节点 AWS CloudFormation 堆栈](https://docs.aws.amazon.com/eks/latest/userguide/worker)。
1. 打开 [AWS CloudFormation 控制台](https://console.aws.amazon.com/cloudformation/)。
1. 请选择要删除的节点堆栈，然后选择 **Delete**（删除）。
1. 在 **Delete stack**（删除堆栈）确认对话框中，请选择 **Delete stack**（删除堆栈）。删除集群中的所有自行管理的节点堆栈。
1. 请删除集群。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择要删除的集群并选择 **Delete**（删除）。
1. 在删除集群确认屏幕上，选择 **Delete (删除)**。
1. （可选）删除 VPC AWS CloudFormation 堆栈。
1. 打开 [AWS CloudFormation 控制台](https://console.aws.amazon.com/cloudformation/)。
1. 请选择要删除的 VPC 堆栈，然后选择 **Delete**（删除）。
1. 在 **Delete stack**（删除堆栈）确认对话框中，请选择 **Delete stack**（删除堆栈）。
## 删除集群（AWS CLI）
1. 完成[先决条件步骤](#prerequisite-steps)。执行此操作后，删除所有节点组和 Fargate 配置文件。
1. 使用以下命令列出集群中的节点组。
```
aws eks list-nodegroups --cluster-name my-cluster
```
**注意**
只会列出[托管节点组](managed-node-groups.md)。
1. 使用以下命令删除每个节点组。删除集群中的所有节点组。
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. 使用以下命令列出集群中的 Fargate 配置文件。
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. 使用以下命令删除每个 Fargate 配置文件。删除集群中的所有 Fargate 配置文件。
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. 删除所有[自主管理的节点 AWS CloudFormation 堆栈](https://docs.aws.amazon.com/eks/latest/userguide/worker)。
1. 使用以下命令列出您的可用 AWS CloudFormation 堆栈。在生成的输出中查找节点模板名称。
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. 使用以下命令（将 *node-stack* 替换为节点堆栈名称）删除每个节点堆栈。删除集群中的所有自行管理的节点堆栈。
```
aws cloudformation delete-stack --stack-name node-stack
```
1. 使用以下命令删除集群，同时将 *my-cluster* 替换为您的集群名称。
```
aws eks delete-cluster --name my-cluster
```
1. （可选）删除 VPC AWS CloudFormation 堆栈。
1. 使用以下命令列出您的可用 AWS CloudFormation 堆栈。在生成的输出中查找 VPC 模板名称。
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. 使用以下命令删除 VPC 堆栈，同时将 *my-vpc-stack* 替换为您的 VPC 堆栈名称。
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# 防止意外删除 EKS 集群
意外删除 EKS 集群可能会影响 Kubernetes 集群的正常运行。
现在，您可以防止意外删除 EKS 集群。如果在集群上启用了删除保护，必须先禁用删除保护，然后才能删除该集群。
删除保护的目的是防止意外操作。您应谨慎限制有权删除集群的人员。
如果您尝试删除已启用删除保护的活动集群，将收到 `InvalidRequestException`。
**重要**
如果您在集群上启用了删除保护，则必须**同时**拥有 UpdateClusterConfig 和 DeleteCluster IAM 权限才能先移除删除保护，并最终删除该集群。
**注意**
如果集群状态为正在创建、失败或正在删除，即使已启用删除保护，您仍可以删除该集群。
## 为现有集群启用删除保护
您只能在处于活动状态的集群上运行此命令。
```
aws eks update-cluster-config --name --region --deletion-protection
```
## 为现有集群禁用删除保护
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# 集群 API 服务器端点
本主题可帮助您为 Amazon EKS 集群的 Kubernetes API 服务器端点启用私有访问，并限制或完全禁用通过互联网进行公有访问。
在创建新集群时，Amazon EKS 将为您用于与集群进行通信的托管 Kubernetes API 服务器（使用 Kubernetes 管理工具，如 `kubectl`）创建端点。默认情况下，此 API 服务器端点对于互联网是公有的，对 API 服务器的访问将使用 AWS Identity and Access Management（IAM）与本机 Kubernetes [基于角色的访问控制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)（RBAC）相结合的方式加以保护。此端点称为*集群公共端点*。还有一个*集群私有端点*。有关集群私有端点的更多信息，请参阅以下部分：[集群私有端点](#cluster-endpoint-private)。
## `IPv6` 集群端点格式
EKS 按以下格式为 2024 年 10 月之后创建的新 `IPv6` 集群创建唯一的双堆栈端点。*IPv6 集群*是您在群集的 IP 系列 (`ipFamily`) 设置中选择了 `IPv6` 的集群。
**Example**
EKS 集群公共/私有端点：`eks-cluster.region.api.aws`
EKS 集群公共/私有端点：`eks-cluster.region.api.aws`
EKS 集群公共/私有端点：`eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**注意**
双堆栈集群端点已于 2024 年 10 月推出。有关 `IPv6` 的更多信息，请参阅 [了解如何将 IPv6 地址分配给集群、容器组（pod）和服务](cni-ipv6.md)。在 2024 年 10 月之前创建的集群，请改用以下端点格式。
## `IPv4` 集群端点格式
EKS 采用以下格式为在集群的 IP 系列（ipFamily）设置中选择了 `IPv4` 的每个集群创建一个唯一的端点：
**Example**
EKS 集群公共/私有端点 `eks-cluster.region.eks.amazonaws.com`
EKS 集群公共/私有端点 `eks-cluster.region.eks.amazonaws.com`
EKS 集群公共/私有端点 `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**注意**
在 2024 年 10 月之前，`IPv6` 集群也使用此端点格式。对于这些集群，公共端点和私有端点都只有从此端点解析的 `IPv4` 地址。
## 集群私有端点
您可以启用对 Kubernetes API 服务器的私有访问，以便节点与 API 服务器之间的所有通信都在 VPC 内。您可以限制从 Internet 访问 API 服务器的 IP 地址，或完全禁用对 API 服务器的 Internet 访问。
**注意**
由于此端点用于 Kubernetes API 服务器，而不是用于与 AWS API 通信的传统 AWS PrivateLink 端点，因而不会在 Amazon VPC 控制台中显示为端点。
当您为集群启用端点私有访问时，Amazon EKS 将代表您创建一个 Route 53 私有托管区域，并将它与您的集群的 VPC 关联。这个私有托管区域由 Amazon EKS 管理，它不会出现在您的账户的 Route 53 资源中。为了使私有托管区域正确地将流量路由到您的 API 服务器，您的 VPC 必须将 `enableDnsHostnames` 和 `enableDnsSupport` 设置为 `true`，而且为 VPC 设置的 DHCP 选项必须在其域名服务器列表中包含 `AmazonProvidedDNS`。有关更多信息，请参阅 *Amazon VPC 用户指南*中的[更新 VPC 的 DNS 支持](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)。
您可以在创建新集群时定义 API 服务器终端节点的访问要求，并且可以随时更新集群的 API 服务器终端节点访问。
## 修改集群终端节点访问
使用本节中的过程来修改现有集群的终端节点访问。下表显示了受支持的 API 服务器终端节点访问组合及其关联的行为。
| 终端节点公有访问 | 终端节点私有访问 | 行为 |
| --- | --- | --- |
| 已启用 | 已禁用 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/cluster-endpoint.html) |
| 已启用 | 已启用 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/cluster-endpoint.html) |
| 已禁用 | 已启用 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/cluster-endpoint.html) |
**端点访问控制**
请注意，以下用于控制端点访问的各个方法都只会影响相应的端点。
*集群安全组*
集群安全组控制两种类型的连接：与 *kubelet API* 的连接和私有端点的连接。与 `kubelet` API 的连接用于 `kubectl attach`、`kubectl cp`、`kubectl exec`、`kubectl logs` 和 `kubectl port-forward` 命令中。集群安全组不会影响公有端点。
*公共访问权限 CIDR*
*公共访问权限 CIDR* 通过 CIDR 数据块列表来控制对公有端点的访问权限。请注意，公共访问权限 CIDR 不会影响私有端点。公共访问权限 CIDR 在 `IPv6` 集群和 `IPv4` 集群上的行为会有所不同，具体取决于它们的创建日期，如下所述：
**公有端点（`IPv6` 集群）中的 CIDR 块**
您可以将 `IPv6` 和 `IPv4` CIDR 块添加到 `IPv6` 集群的公有端点，因为公有端点是双堆栈端点。这仅适用于您在 2024 年 10 月或之后创建的且将 `ipFamily` 设置为 `IPv6` 的新集群。您可以通过新的端点域名 `api.aws` 来识别这些集群。
**公有端点（`IPv4` 集群）中的 CIDR 块**
您可以将 `IPv4` CIDR 块添加到 `IPv4` 集群的公有端点。您无法将 `IPv6` CIDR 块添加到 `IPv4` 集群的公有端点。如果您尝试添加，EKS 将返回以下错误消息：`The following CIDRs are invalid in publicAccessCidrs`
**公有端点中的 CIDR 块（2024 年 10 月之前创建的 `IPv6` 集群）**
您可以将 `IPv4` CIDR 块添加到您在 2024 年 10 月之前创建的旧 `IPv6` 集群的公有端点。您可以通过 `eks.amazonaws.com` 端点识别这些集群。您无法将 `IPv6` CIDR 块添加到您在 2024 年 10 月之前创建的旧 `IPv6` 集群的公有端点。如果您尝试添加，EKS 将返回以下错误消息：`The following CIDRs are invalid in publicAccessCidrs`
## 访问私有 API 服务器
如果已禁用集群的 Kubernetes API 服务器端点的公有访问，则只能从 VPC 或[连接的网络](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)内访问 API 服务器。以下是访问 Kubernetes API 服务器终端节点的部分可行方法：
**连接的网络**
使用 [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 或其它[连接](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html)选项将您的网络连接到 VPC，然后使用连接的网络中的计算机。必须确保 Amazon EKS 控制面板安全组包含允许来自所连接网络的入口流量通过端口 443 的规则。
**Amazon EC2 堡垒主机**
您可以在集群的 VPC 中将 Amazon EC2 实例启动到公共子网中，然后通过 SSH 登录到该实例来运行 `kubectl` 命令。有关更多信息，请参阅[AWS上的 Linux 堡垒主机](https://aws.amazon.com/quickstart/architecture/linux-bastion/)。必须确保 Amazon EKS 控制面板安全组包含允许来自堡垒主机的入口流量通过端口 443 的规则。有关更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。
在为堡垒主机配置 `kubectl` 时，请确保使用已映射到集群的 RBAC 配置的 AWS 凭证，或在移除端点公共访问之前添加您的堡垒机将用于 RBAC 配置的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)。有关更多信息，请参阅[向 IAM 用户和角色授予对 Kubernetes API 的访问权限](grant-k8s-access.md)和[未经授权或访问被拒绝 (`kubectl`)](troubleshooting.md#unauthorized)。
** AWSCloud9 IDE**
AWS Cloud9 是一种基于云的集成式开发环境（IDE），您只需要一个浏览器，即可编写、运行和调试代码。您可以在集群的 VPC 中创建 AWS Cloud9 IDE，然后使用 IDE 来与集群进行通信。有关更多信息，请参阅[在 AWS Cloud9 中创建环境](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html)。必须确保 Amazon EKS 控制面板安全组包含允许来自 IDE 安全组的入口流量通过端口 443 的规则。有关更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。
在为 AWS Cloud9 IDE 配置 `kubectl` 时，请确保使用已映射到集群的 RBAC 配置的 AWS 凭证，或在移除端点公共访问之前添加您的 IDE 将用于 RBAC 配置的 IAM 主体。有关更多信息，请参阅[向 IAM 用户和角色授予对 Kubernetes API 的访问权限](grant-k8s-access.md)和[未经授权或访问被拒绝 (`kubectl`)](troubleshooting.md#unauthorized)。
📝 [在 GitHub 上编辑此页面](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# 配置对集群 API 服务器端点的网络访问权限
您可以在以下部分中使用 AWS 管理控制台或 AWS CLI 修改集群 API 服务器端点访问。
## 配置端点访问 – AWS 控制台
1. 打开 [Amazon EKS console（Amazon EKS 控制台）](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择集群的名称可以显示集群信息。
1. 选择**联网**选项卡，然后选择**管理端点访问**。
1. 对于**私有访问**，选择是启用还是禁用集群的 Kubernetes API 服务器端点的私有访问。如果启用私有访问，源自集群的 VPC 内的 Kubernetes API 请求将使用私有 VPC 端点。您必须启用私有访问以禁用公有访问。
1. 对于**公有访问**，选择是启用还是禁用集群的 Kubernetes API 服务器端点的公有访问。如果禁用公有访问，集群的 Kubernetes API 服务器只能接收来自集群 VPC 内的请求。
1. （可选）如果您已启用**公有访问**，则可以指定互联网中的哪些地址可以与公共端点通信。选择 **Advanced Settings (高级设置)**。输入 CIDR 块，例如 *203.0.113.5/32*。该块不能包含[预留地址](https://en.wikipedia.org/wiki/Reserved_IP_addresses)。您可以通过选择 **Add Source (添加源)** 来输入其他块。您可以指定的 CIDR 块存在最大数量限制。有关更多信息，请参阅 [查看和管理 Amazon EKS 和 Fargate 服务配额](service-quotas.md)。如果未指定任何块，则公有 API 服务器端点将接收来自双堆栈 `IPv6` 集群的所有 `IPv4` (`0.0.0.0/0`) 和 `IPv6` (`::/0`) IP 地址的请求。如果您使用 CIDR 块限制对公有端点的访问，建议您还启用私有端点访问，以便节点和 Fargate Pods（如果您使用它们）可以与集群进行通信。在未启用私有终端节点的情况下，您的公有访问终端节点 CIDR 源必须包含来自 VPC 的出口源。例如，如果您在私有子网中有一个节点，该节点通过 NAT 网关与 Internet 通信，则您需要将 NAT 网关的出站 IP 地址添加作为公有端点上的容许 CIDR 块的一部分。
1. 选择 **Update (更新)** 完成操作。
## 配置端点访问 – AWS CLI
使用 AWS CLI 版本 `1.27.160` 或更高版本完成以下步骤。您可以使用 `aws --version` 检查您的当前版本。要安装或升级 AWS CLI，请参阅[安装 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。
1. 使用下面的 AWS CLI 命令更新集群 API 服务器端点访问。替换您的集群名称和所需的终端节点访问值。如果设置了 `endpointPublicAccess=true`，则可以（可选）输入单个 CIDR 块，或者输入 `publicAccessCidrs` 的用逗号分隔的 CIDR 块列表。块不能包含[预留地址](https://en.wikipedia.org/wiki/Reserved_IP_addresses)。如果您指定 CIDR 块，则公有 API 服务器终端节点将只接收来自列出的块的请求。您可以指定的 CIDR 块存在最大数量限制。有关更多信息，请参阅 [查看和管理 Amazon EKS 和 Fargate 服务配额](service-quotas.md)。如果您使用 CIDR 块限制对公有端点的访问，建议您还启用私有端点访问，以便节点和 Fargate Pods（如果您使用这些 Pod）可以与集群进行通信。在未启用私有终端节点的情况下，您的公有访问终端节点 CIDR 源必须包含来自 VPC 的出口源。例如，如果您在私有子网中有一个节点，该节点通过 NAT 网关与 Internet 通信，则您需要将 NAT 网关的出站 IP 地址添加作为公有端点上的容许 CIDR 块的一部分。如果未指定任何 CIDR 块，则公有 API 服务器端点将接收来自双堆栈 `IPv6` 集群的所有 (0.0.0.0/0) 和 `IPv6` (`::/0`) 的 IP 地址请求。
**注意**
以下命令为 API 服务器终端节点启用来自单个 IP 地址的私有访问和公有访问。将 *203.0.113.5/32* 替换为要限制网络访问的单个 CIDR 块或用逗号分隔的 CIDR 块列表。
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
示例输出如下。
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. 使用以下命令通过上一命令返回的集群名称和更新 ID 监控您的终端节点访问更新的状态。当状态显示为 `Successful` 时，您的更新将完成。
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
示例输出如下。
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [在 GitHub 上编辑此页面](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# 在 EKS 集群上部署 Windows 节点
了解如何为 Amazon EKS 集群启用和管理 Windows 支持，以便同时运行 Windows 容器和 Linux 容器。
## 注意事项
在部署 Windows 节点之前，请注意以下注意事项。
+ EKS 自动模式不支持 Windows 节点
+ 您可以使用 `HostProcess` 容器组（pod）在 Windows 节点上使用主机网络。有关更多信息，请参阅 Kubernetes 文档中的[创建 Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/)。
+ Amazon EKS 集群必须包含一个或多个 Linux 或 Fargate 节点，才能运行仅在 Linux 上运行的核心系统容器组（pod），如 CoreDNS。
+ `kubelet` 和 `kube-proxy` 事件日志将重定向到 `EKS Windows` 事件日志，并设置为 200MB 限制。
+ 您不能对在 Windows 节点上运行的容器组（pod）使用[将安全组分配到单个容器组（pod）](security-groups-for-pods.md)。
+ 您不能对 Windows 节点使用[自定义联网](cni-custom-network.md)。
+ 您不能将 `IPv6` 与 Windows 节点结合使用。
+ Windows 节点支持每个节点一个弹性网络接口。默认情况下，每个 Windows 节点可以运行的容器组（pod）数等于每个弹性网络接口可用于节点实例类型的 IP 地址数减 1。有关更多信息，请参阅《Amazon EC2 用户指南》**中的[每种实例类型的每个网络接口的 IP 地址数](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI)。
+ 在 Amazon EKS 集群中，采用负载均衡器的单个服务最多可支持 1024 个后端容器组（pod）。每个 Pod 都有自己的唯一 IP 地址。对于从 [OS 内部版本 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4) 开始的 [Windows 服务器更新](https://github.com/microsoft/Windows-Containers/issues/93)，之前的 64 个 容器组（pod）限制已经没有了。
+ Fargate 上的 Amazon EKS 容器组（pod）不支持 Windows 容器。
+ 不能使用将 Windows 作为主机操作系统的 Amazon EKS 混合节点。
+ 无法从 `vpc-resource-controller` 容器组（pod）检索日志。以前在将此控制器部署到数据面板时则可以检索。
+ 在将 `IPv4` 地址分配给新容器组（pod）之前，会有一段“冷却”时间。这样可以防止流量因过时的 `kube-proxy` 规则而流向具有相同 `IPv4` 地址的旧容器组（pod）。
+ 控制器的源代码在 GitHub 上进行管理。要为该控制器贡献代码或提交针对该控制器的问题，请访问 GitHub 上的相应[项目](https://github.com/aws/amazon-vpc-resource-controller-k8s)。
+ 为 Windows 托管节点组指定自定义 AMI ID 时，请将 `eks:kube-proxy-windows` 添加到您的 AWS IAM 身份验证器配置映射中。有关更多信息，请参阅 [指定 AMI ID 时的限制和条件](launch-templates.md#mng-ami-id-conditions)。
+ 如果保留可用的 IPv4 地址对您的子网至关重要，请参阅 [EKS Best Practices Guide - Windows Networking IP Address Management](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management) 以获取指导。
+ EKS 访问条目注意事项
+ 用于 Windows 节点的访问条目所需类型为 `EC2_WINDOWS`。有关更多信息，请参阅 [创建访问条目](creating-access-entries.md)。
要为 Windows 节点创建访问条目，请执行以下操作：
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/ --type EC2_Windows
```
## 先决条件
+ 现有集群。
+ 您的集群必须至少有一个（我们建议至少有两个）Linux 节点或 Fargate 容器组（pod）才能运行 CoreDNS。如果您启用旧版 Windows 支持，则必须使用 Linux 节点而非 Fargate 容器组（pod）来运行 CoreDNS。
+ 现有 [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)。
## 启用 Windows 支持
1. 如果集群中没有 Amazon Linux 节点，并且使用容器组（pod）的安全组，请跳至下一步。否则，请确认 `AmazonEKSVPCResourceController` 托管策略是否已附加到您的[集群角色](cluster-iam-role.md)。请将 *eksClusterRole* 替换为集群角色的名称。
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
示例输出如下。
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
如果像前面的输出中那样已经附加了策略，请跳过下一步。
1. 将 **[AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html)** 托管策略附加到您的 [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)。请将 *eksClusterRole* 替换为集群角色的名称。
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. 更新 VPC CNI ConfigMap 以启用 Windows IPAM。请注意，如果使用 Helm 图表或作为 Amazon EKS 附加组件将 VPC CNI 安装在您的集群上，则可能无法直接修改 ConfigMap。有关配置 Amazon EKS 附加组件的信息，请参阅[确定可以为 Amazon EKS 附加组件自定义的字段](kubernetes-field-management.md)。
1. 创建名为 *vpc-resource-controller-configmap.yaml* 的文件，具有以下内容。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. 将 `ConfigMap` 应用于集群。
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. 如果集群已将身份验证模式设置为启用 `aws-auth` Configmap：
+ 验证 `aws-auth` `ConfigMap` 是否包含 Windows 节点的实例角色映射，以包含 `eks:kube-proxy-windows` RBAC 权限组。您可以通过运行以下命令进行验证。
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
示例输出如下。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws:iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
您应该会看到组下面列出的 `eks:kube-proxy-windows`。如果未指定组，则需要更新 `ConfigMap` 或进行创建，以包含所需的组。有关 `aws-auth` `ConfigMap` 的更多信息，请参阅 [将 `aws-auth` `ConfigMap` 应用到集群](auth-configmap.md#aws-auth-configmap)。
1. 如果集群已将身份验证模式设置为禁用 `aws-auth` Configmap，则可使用 EKS 访问条目。创建一个用于 Windows 实例的新节点角色，之后 EKS 将自动创建 `EC2_WINDOWS` 类型的访问条目。
## 部署 Windows 容器组（pod）
将容器组（pod）部署到集群时，如果您运行的是多种不同类型的节点，则需要指定这些容器组（pod）所用的操作系统。
对于 Linux 容器组（pod），请使用清单中的以下节点选择器文本。
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
对于 Windows 容器组（pod），请使用清单中的以下节点选择器文本。
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
可以部署一款[示例应用程序](sample-deployment.md)，以查看正在使用的节点选择器。
## 在 Windows 节点上支持更高的容器组（pod）密度
在 Amazon EKS 中，每个容器组（pod）都会从您的 VPC 分配一个 `IPv4` 地址。因此，即使有足够的资源可以在节点上运行更多容器组（pod），可以部署到该节点的容器组（pod）数量也受到可用 IP 地址的限制。由于 Windows 节点仅支持一个弹性网络接口，因此默认情况下，Windows 节点上可用 IP 地址的最大数量等于：
```
Number of private IPv4 addresses for each interface on the node - 1
```
一个 IP 地址用作网络接口的主要 IP 地址，因此无法将其分配给容器组（pod）。
通过启用 IP 前缀委派，可以在 Windows 节点上启用更高的容器组（pod）密度。此功能使您可以为主网络接口分配 `/28` `IPv4` 前缀，而不是分配辅助 `IPv4` 地址。分配 IP 前缀会将节点上的最大可用 `IPv4` 地址数增加到：
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
由于可用 IP 地址的数量要多得多，可用的 IP 地址不应限制您在节点上扩展容器组（pod）数量的能力。有关更多信息，请参阅 [为带前缀的 Amazon EKS 节点分配更多 IP 地址](cni-increase-ip-addresses.md)。
# 禁用 Windows 支持
1. 如果您的集群包含 Amazon Linux 节点，并且您对这些节点使用[容器组（pod）安全组](security-groups-for-pods.md)，请跳过此步骤。
从您的[集群角色](cluster-iam-role.md)中删除 `AmazonVPCResourceController` 这项托管的 IAM policy。请将 *eksClusterRole* 替换为集群角色的名称。
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. 在 `amazon-vpc-cni` ConfigMap 中禁用 Windows IPAM。
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# 部署具有有限互联网访问权限的私有集群
本主题将介绍如何部署部署在 AWS 云上但没有出站互联网访问权限的 Amazon EKS 集群。如果您在 AWS 上有一个本地集群，请参阅[在 AWS Outpost 上创建 Amazon Linux 节点](eks-outposts-self-managed-nodes.md)而不是本主题。
如果您不熟悉 Amazon EKS 联网，请参阅 [Amazon EKS 工作线程节点的集群联网解密](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes)。如果集群没有出站互联网访问权限，则其必须满足以下要求：
## 集群架构要求
+ 您的集群必须从 VPC 中的容器注册表中拉取映像。您可以在 VPC 中创建 Amazon Elastic Container Registry，并将容器映像复制到其中，以供节点拉取。有关更多信息，请参阅 [将容器镜像从一个存储库复制到另一个存储库](copy-image-to-repository.md)。
+ 集群必须启用端点私有访问权限。需要启用该访问权限，节点才能注册到集群端点。终端节点公有访问权限是可选的。有关更多信息，请参阅 [集群 API 服务器端点](cluster-endpoint.md)。
## 节点要求
+ 自主管理型 Linux 和 Windows 节点必须包含以下引导参数才能启动。这些实际参数绕过 Amazon EKS 自检，且无需从 VPC 内访问 Amazon EKS API。
1. 使用以下命令确定集群端点的值。将 *my-cluster* 替换为您的集群的名称。
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
示例输出如下。
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. 使用以下命令确定集群证书颁发机构的值。将 *my-cluster* 替换为您的集群的名称。
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
返回的输出是一个长字符串。
1. 请将 NodeConfig 对象中的 `apiServerEndpoint` 和 `certificateAuthority` 值替换为以上命令的输出中返回的值。有关在启动 Amazon Linux 2023 自主管理型节点时指定引导参数的更多信息，请参阅[创建自行管理的 Amazon Linux 节点](launch-workers.md)和[创建自主管理型 Microsoft Windows 节点](launch-windows-workers.md)。
+ 对于 Linux 节点：
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
有关更多参数，请参阅 GitHub 上的[引导启动脚本](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)。
+ 对于 Windows 节点：
**注意**
如果您使用自定义服务 CIDR，则需要使用 `-ServiceCIDR` 参数进行指定。否则，集群中的容器组（pod）DNS 解析将失败。
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
有关更多参数，请参阅 [引导脚本配置参数](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)。
+ 必须从 VPC 内创建集群的 `aws-auth` `ConfigMap`。有关在 `aws-auth` `ConfigMap` 中创建和添加条目的更多信息，请在终端中输入 `eksctl create iamidentitymapping --help`。如果您的服务器上不存在 `ConfigMap`，则 `eksctl` 将在您使用命令添加身份映射时创建。
## 容器组（pod）要求
+ **容器组身份**：配置了 EKS 容器组身份的容器组（pod）从 EKS Auth API 获取凭证。如果没有出站互联网访问权限，则必须创建并使用一个用于 EKS Auth API 的 VPC 端点：`com.amazonaws.region-code.eks-auth`。有关 EKS 和 EKS Auth VPC 端点的更多信息，请参阅[使用 AWS PrivateLink 访问 Amazon EKS](vpc-interface-endpoints.md)。
+ **IRSA**：配置了[服务账户的 IAM 角色](iam-roles-for-service-accounts.md)的容器组（pod）通过 AWS Security Token Service（AWS STS）API 调用获取凭证。如果没有出站互联网访问权限，则您必须在 VPC 中创建并使用 AWS STS VPC 端点。默认情况下，大多数 AWS `v1` SDK 均使用全局 AWS STS 端点（`sts.amazonaws.com`），而此端点不使用 AWS STS VPC 端点。要使用 AWS STS VPC 端点，您可能需要将 SDK 配置为使用区域 AWS STS 端点（`sts.region-code.amazonaws.com`）。有关更多信息，请参阅 [为服务账户配置 AWS Security Token Service 端点](configure-sts-endpoint.md)。
+ 集群的 VPC 子网必须具有容器组（pod）需要访问的任何 AWS 服务的 VPC 接口端点。有关更多信息，请参阅[使用接口 VPC 端点访问 AWS 服务](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)。下表列出了一些常用的服务和端点。有关端点的完整列表，请参阅《AWS PrivateLink 指南》[https://docs.aws.amazon.com/vpc/latest/privatelink/](https://docs.aws.amazon.com/vpc/latest/privatelink/)中的[与 AWS PrivateLink 集成的 AWS 服务](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)。
我们建议您为 VPC 端点[启用私有 DNS 名称](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names)，这样工作负载即可继续正常使用公共 AWS 服务端点。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/private-clusters.html)
+ 任何自行管理的节点都必须部署到具有您需要的 VPC 接口端点的子网中。如果您创建托管节点组，则 VPC 接口端点安全组必须允许子网的 CIDR，或者您必须将已创建的节点安全组添加到 VPC 接口端点安全组。
+ **EFS 存储**：如果容器组（pod）使用 Amazon EFS 卷，在部署[使用 Amazon EFS 存储弹性文件系统](efs-csi.md)之前，必须更改驱动程序的 [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) 文件，才能将容器映像设置为使用与 Amazon EKS 集群相同的 AWS 区域。
+ Route53 不支持 AWS PrivateLink。您无法从私有 Amazon EKS 集群管理 Route53 DNS 记录。这会影响 Kubernetes [external-dns](https://github.com/kubernetes-sigs/external-dns)。
+ 如果您使用 EKS 优化版 AMI，则应启用上表中的 `ec2` 端点。您也可以手动设置节点 DNS 名称。优化版 AMI 使用 EC2 API 来自动设置节点 DNS 名称。
+ 您可以使用 [AWS Load Balancer Controller](aws-load-balancer-controller.md) 将 AWS Application Load Balancers（ALB）和 Network Load Balancers 部署到私有集群。部署时，您应该使用[命令行标记](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags)将 `enable-shield`、`enable-waf` 和 `enable-wafv2` 设置为 false。带有来自 Ingress 对象中的主机名的[证书发现](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host)不受支持。这是因为控制器需要访问没有 VPC 接口端点的 AWS Certificate Manager。
该控制器支持带有 IP 目标的网络负载均衡器，结合 Fargate 一起使用时需要网络负载均衡器。有关更多信息，请参阅[使用应用程序负载均衡器路由应用程序和 HTTP 流量](alb-ingress.md)和[创建网络负载均衡器](network-load-balancing.md#network-load-balancer)。
+ 支持 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)。在部署 Cluster Autoscaler 容器组（pod）时，请确保命令行包括 `--aws-use-static-instance-list=true`。有关更多信息，请参阅 GitHub 上的[使用静态实例列表](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list)。Worker 节点 VPC 还必须包括 AWS STS VPC 端点和弹性伸缩 VPC 端点。
+ 一些容器软件产品使用 API 调用来访问监控使用情况的 AWS Marketplace Metering Service。私有集群不允许这些调用，因此您不能在私有集群中使用这些容器类型。
# 使用 Karpenter 和 Cluster Autoscaler 扩展集群计算
Autoscaling 是一项功能，可以自动扩缩资源以满足您不断变化的需求。若没有此项重要的 Kubernetes 功能，则需要耗费大量的人力资源来手动执行这些工作。
## EKS 自动模式
Amazon EKS 自动模式会自动扩展集群计算资源。如果现有节点无法满足容器组的需要，EKS 自动模式会创建一个新节点。EKS 自动模式还会整合工作负载并删除节点。EKS 自动模式是以 Karpenter 为基础构建的。
有关更多信息，请参阅：
+ [使用 EKS 自动模式实现集群基础设施自动化](automode.md)
+ [为 EKS 自动模式创建节点池](create-node-pool.md)
+ [将示例 inflate 工作负载部署到 Amazon EKS 自动模式集群](automode-workload.md)
## 其他解决方案
Amazon EKS 支持另外两个自动扩缩产品：
**Karpenter**
Karpenter 是一款灵活的高性能 Kubernetes 集群自动扩缩器，可帮助提高应用程序可用性和集群效率。Karpenter 只需不到一分钟时间，即可启动适当规模的计算资源（例如 Amazon EC2 实例）来响应不断变化的应用程序负载。通过将 Kubernetes 与 AWS 相集成，Karpenter 可以即时调配精准满足工作负载需求的计算资源。Karpenter 会根据集群工作负载的具体需求来自动调配新的计算资源。这包括计算、存储、加速和调度需求。Amazon EKS 支持使用 Karpenter 的集群，但 Karpenter 可以与任何合规的 Kubernetes 集群配合使用。有关更多信息，请参阅 [Karpenter](https://karpenter.sh/docs/) 文档。
Karpenter 是一种开源软件，AWS 客户负责在其 Kubernetes 集群中安装、配置和管理。AWS 在 Amazon EKS 集群中使用兼容版本运行未经修改的 Karpenter 时提供技术支持。客户在升级 Karpenter 控制器或运行它的 Kubernetes 集群时，必须维护 Karpenter 控制器的可用性和安全性以及适当的测试程序，就像任何其它客户管理的软件一样。Karpenter 没有 AWS 服务水平协议（SLA），客户有责任确保 Karpenter 启动的 EC2 实例满足其业务需求。
**Cluster Autoscaler**
当 Pod 失败或被重新安排到其他节点时，Kubernetes Cluster Autoscaler 会自动调整集群中的节点数。Cluster Autoscaler 使用自动扩缩组。有关更多信息，请参阅 [AWS 上的 Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)。
# 了解 Amazon EKS 中的 Amazon 应用程序恢复控制器（ARC）可用区转移
Kubernetes 具有原生功能，可让您的应用程序对可用区（AZ）运行状况下降或损坏等事件更具弹性。在 Amazon EKS 集群中运行工作负载时，您可以使用 [Amazon 应用程序恢复控制器（ARC）的可用区转移](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html)或[可用区自动转移](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html)，进一步改善应用程序环境的容错能力和应用程序恢复。ARC 可用区转移旨在作为一种临时措施，可让您将资源流量从损坏的可用区转出，直到可用区转移到期或您取消它。如有必要，可以延长可用区转移。
您可以为 EKS 集群启动可用区转移，也可以通过启用可用区自动转移来让 AWS 为您执行可用区转移。这种转移会更新集群中东-西网络流量，使其仅考虑在运行状况良好的可用区中的 Worker 节点上运行的容器组（pod）的网络端点。此外，任何处理 EKS 集群中应用程序入口流量的 ALB 或 NLB 都会自动将流量路由到运行状况良好的可用区中的目标。对于那些寻求最高可用性目标的客户来说，在可用区损坏的情况下，能够将所有流量从损坏的可用区转移出去可能很重要，直到可用区恢复为止。为此，您还可以[https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)。
## 了解容器组（pod）之间的东-西网络流量
下图说明了两个示例工作负载，即“订单”和“产品”。此示例的目的是展示不同可用区中的工作负载和容器组（pod）是如何通信的。
![\[展示网络流量的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[展示网络流量的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. 要使“订单”与“产品”通信，它必须首先解析目标服务的 DNS 名称。“订单”将与 CoreDNS 通信以获取该服务的虚拟 IP 地址（集群 IP）。“订单”解析“产品”服务名称后，它会将流量发送到该目标 IP 地址。
1. kube-proxy 在集群中的每个节点上运行，并持续监视 [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) 的服务。创建服务时，EndpointSlice 控制器将在后台创建和管理 EndpointSlice。每个 EndpointSlice 都有一个端点列表或表格，其中包含容器组（pod）地址的子集以及它们在其中正在运行的节点。kube-proxy 在节点上为每个容器组（pod）端点设置 `iptables` 路由规则。kube-proxy 还负责一种基本的负载均衡，也就是将发往服务集群 IP 地址的流量重定向为直接发送到容器组（pod）的 IP 地址。kube-proxy 通过重写传出连接上的目标 IP 地址来实现此目的。
1. 然后，网络数据包通过相应节点上的 ENI 发送到可用区 2 中的“产品”容器组（pod）（如前面的图表所示）。
### 了解 Amazon EKS 中的 ARC 可用区转移
如果您的环境中存在可用区损坏，则可以为您的 EKS 集群环境启动可用区转移。或者，您可以允许 AWS 使用可用区自动转移来为您管理流量转移。使用可用区自动转移，AWS 可监控整体可用区运行状况，并通过自动将流量从集群环境中损坏的可用区转移出去来应对潜在的可用区损坏。
使用 ARC 启用 Amazon EKS 集群可用区转移后，您可以使用 ARC 控制台、AWS CLI 或可用区转移和可用区自动转移 API，启动可用区转移或启用可用区自动转移。在 EKS 可用区转移期间，将自动执行以下操作：
+ 受影响可用区中的所有节点都被封锁。这将防止 Kubernetes 调度器将新容器组（pod）调度到运行状况不佳的可用区中的节点上。
+ 如果您使用的是[托管节点组](managed-node-groups.md)，则[https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)将被暂停，并且您的自动扩缩组也将更新，以确保新的 EKS 数据面板节点仅在运行状况良好的可用区中启动。
+ 运行状况不佳的可用区中的节点不会被终止，容器组（pod）也不会被逐出这些节点。这可确保当可用区转移到期或被取消时，您的流量可以安全地返回到可用区以获得完整容量。
+ EndpointSlice 控制器将在损坏的可用区中找到所有容器组（pod）端点，并将它们从相关的 EndpointSlices 中移除。这将确保只有运行状况良好的可用区中的容器组（pod）端点才会成为接收网络流量的目标。当可用区转移被取消或到期时，EndpointSlice 控制器将更新 EndpointSlices 以包括已恢复的可用区中的端点。
下图简要概述了 EKS 可用区转移如何确保集群环境中仅针对运行状况良好的容器组（pod）端点。
![\[展示网络流量的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[展示网络流量的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## EKS 可用区转移要求
要在 EKS 中成功进行可用区转移，您必须事先设置集群环境，使其能够抵御可用区损坏。以下是有助于确保韧性的配置选项列表。
+ 跨多个可用区配置集群的 Worker 节点
+ 预调配足够的计算容量，以适应单个可用区的移除
+ 在每个可用区预先扩展容器组（pod）（包括 CoreDNS）
+ 将多个容器组（pod）副本分布在所有可用区中，帮助确保从单个可用区转出后，仍会给您留下足够的容量
+ 将相互依赖或相关的容器组（pod）托管在同一可用区中
+ 通过手动启动从可用区的可用区转移，测试集群环境是否能在没有可用区的情况下按预期运行。或者，您可以启用可用区自动转移并在自动转移练习运行时回复。要在 EKS 中进行可用区转移，手动测试或进行可用区转移并非强制要求，但强烈建议执行此操作。
### 跨多个可用区预调配您的 EKS Worker 节点
AWS 区域有多个独立的地点，其物理数据中心称为可用区（AZ)。可用区在物理上相互隔离，以避免同时影响整个区域的冲击。在预调配 EKS 集群时，建议将 Worker 节点部署到一个区域中的多个可用区。这有助于使您的集群环境更能抵御单个可用区的损坏，并让您能够保持在其它可用区中运行的应用程序的高可用性（HA）。当您开始从受影响的可用区启动可用区转移时，EKS 环境的集群内网络将自动更新为仅使用运行状况良好的可用区，以帮助保持集群的高可用性。
确保为 EKS 环境设置多可用区将提高系统的整体可靠性。但是，多可用区环境会影响应用程序数据的传输和处理方式，这反过来又会影响您环境的网络费用。特别是，频繁的跨可用区出站流量（流量分布在可用区之间）可能会对您的网络相关成本产生重大影响。您可以应用不同的策略来控制 EKS 集群中容器组（pod）之间的跨可用区流量并降低相关成本。有关在运行高可用性 EKS 环境时如何优化网络成本的更多信息，请参阅[https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/)。
下图说明了具有三个运行状况良好的可用区的高可用性 EKS 环境。
![\[展示网络的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-ha-before-failure.png)
下图说明了具有三个可用区的 EKS 环境如何抵御可用区损坏，并且由于剩余两个可用区运行状况良好，因此仍保持高可用性。
![\[展示网络的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-ha-after-failure.png)
### 预调配足够的计算容量，以适应单个可用区的移除
为了优化 EKS 数据面板中计算基础设施的资源利用率和成本，最佳做法是使计算容量与工作负载要求保持一致。但是，**如果您的所有 Worker 节点都已满负荷**，则在调度新的容器组（pod）之前，您只能依赖将新的 Worker 节点添加到 EKS 数据面板中。在运行关键工作负载时，通常最好使用冗余容量在线运行，以应对负载突然增加、节点运行状况问题等意外情况。如果您计划使用可用区转移，则要计划在出现损坏时移除整个可用区的容量。这意味着您必须调整冗余计算容量，使其足以处理负载，即使其中一个可用区处于离线状态也不例外。
扩展计算资源时，向 EKS 数据面板添加新节点的过程需要一些时间。这可能会对应用程序的实时性能和可用性产生影响，尤其是在出现可用区损坏的情况下。您的 EKS 环境应能够承受丢失一个可用区所带来的负载，而不会导致最终用户或客户体验降级。这意味着要最大限度地减少或消除需要新容器组（pod）的时间与实际调度到 Worker 节点上的时间之间的延迟。
此外，如果出现可用区损坏，您应旨在降低遇到计算容量限制的风险，这将阻止在运行状况良好的可用区中将新需要的节点添加到您的 EKS 数据面板中。
为降低这些潜在负面影响的风险，建议您在每个可用区的某些 Worker 节点中过度预调配计算容量。通过执行此操作，Kubernetes 调度器有预先存在的容量可用于放置新容器组（pod），当您在环境中丢失其中一个可用区时，这一点尤为重要。
### 跨可用区运行和分布多个容器组（pod）副本
Kubernetes 允许您通过运行单个应用程序的多个实例（容器组（pod）副本）来预先扩展工作负载。为一个应用程序运行多个容器组（pod）副本可以消除单点故障，并通过减少单个副本的资源紧张来提高其整体性能。但是，为了使应用程序具有高可用性和更好的容错能力，建议在不同的故障域（也称为拓扑域）中运行应用程序的多个副本并将它们分散到不同的故障域。这种情况下的故障域是可用区。通过使用[拓扑分布约束](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)，您可以将应用程序设置为具有预先存在的静态稳定性。然后，当出现可用区损坏情况时，您的环境将在运行状态良好的可用区中具有足够的副本，可立即应对任何流量峰值或激增。
下图展示了当所有可用区都运行状况良好时，具有东-西流量流向的 EKS 环境。
![\[展示网络的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-spread-constraints.png)
下图展示了具有东-西流量流向的 EKS 环境，其中单个可用区出现故障，且您已启动可用区转移。
![\[展示网络的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-spread-constraints-2.png)
以下代码片段是如何在 Kubernetes 中使用多个副本设置工作负载的示例。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
最重要的是，您应该运行 DNS 服务器软件（CoreDNS/kube-dns）的多个副本，如果默认情况下尚未配置这些副本，则应用类似的拓扑分布约束。这有助于确保在出现单个可用区损坏时，您在运行状况良好的可用区中有足够的 DNS 容器组（pod），以便继续处理集群中其他通信容器组（pod）的服务发现请求。[CoreDNS EKS 附加组件](managing-coredns.md)具有 CoreDNS 容器组（pod）默认设置，可确保如果多个可用区中有节点可用，则 CoreDNS 容器组（pod）将分布在集群的可用区域中。您也可以根据需要将这些默认设置替换为自己的自定义配置。
[使用 Helm 安装 CoreDNS](https://github.com/coredns/helm/tree/master) 时，您可以更新 [values.yaml 文件](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml)中的 `replicaCount`，以确保每个可用区中有足够的副本。此外，为确保这些副本分布在集群环境中的不同可用区中，请确保更新同一个 `values.yaml` 文件中的 `topologySpreadConstraints` 属性。以下代码片段说明了如何配置 CoreDNS 来执行此操作。
**CoreDNS Helm values.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
如果出现可用区损坏，您可以使用 CoreDNS 的自动缩放系统来承受 CoreDNS 容器组（pod）上增加的负载。您需要的 DNS 实例数取决于集群中运行的工作负载数量。CoreDNS 受 CPU 约束，允许它使用 [Horizontal Pod Autoscaler（HPA）](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa)基于 CPU 进行扩展。以下是您可以修改以满足需求的示例。
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
另外，EKS 可以在 CoreDNS 的 EKS 附加组件版本中管理 CoreDNS 部署的自动扩缩。此 CoreDNS 自动扩缩器会持续监控集群状态，包括节点数量和 CPU 核心数量。控制器会根据这些信息，动态调整 EKS 集群中 CoreDNS 部署的副本数量。
要在 [CoreDNS EKS 附加组件中启用自动扩缩配置](coredns-autoscaling.md)，请使用以下配置设置：
```
{
"autoScaling": {
"enabled": true
}
}
```
您也可以使用 [NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) 或[集群比例自动扩缩器](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)来扩展 CoreDNS。有关更多信息，请参阅[水平扩展 CoreDNS](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally)。
### 将相互依赖的容器组（pod）托管在同一个可用区中
通常，应用程序有不同的工作负载，这些工作负载需要相互通信才能成功完成端到端流程。如果这些不同的应用程序分布在不同的可用区中，但托管在同一个可用区中，则单个可用区损坏可能会影响端到端流程。例如，如果**应用程序 A** 在可用区 1 和可用区 2 中有多个副本，但**应用程序 B** 的所有副本都在可用区 3 中，则可用区 3 丢失将影响两个工作负载（**应用程序 A** 和**应用程序 B**）之间的端到端流程。如果您将拓扑分布约束与容器组（pod）亲和性相结合，则可以通过将容器组（pod）分布到所有可用区来增强应用程序的韧性。此外，这还配置了某些容器组（pod）之间的关系，确保它们已托管。
借助[容器组（pod）亲和性规则](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)，您可以定义工作负载之间的关系以影响 Kubernetes 调度器的行为，使其将容器组（pod）托管在同一个 Worker 节点或同一个可用区中。您还可以配置调度约束的严格程度。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
下图展示了使用容器组（pod）亲和性规则托管在同一节点上的多个容器组（pod）。
![\[展示网络的插图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### 测试您的集群环境能否应对可用区的丢失
完成之前章节所述的要求后，下一个步骤是测试您是否有足够的计算和工作负载容量来应对可用区的丢失。您可以通过在 EKS 中手动启动可用区转移来实现此目的。或者，您可以启用可用区自动转移并配置练习运行，这种运行还可测试在集群环境中少一个可用区的情况下，您的应用程序是否按预期运行。
## 常见问题
**为什么应该使用此功能？**
通过在 EKS 集群中使用 ARC 可用区转移或可用区自动转移，您可以自动执行将集群内网络流量从损坏的可用区转移出去的快速恢复过程，从而更好地维护 Kubernetes 应用程序的可用性。使用 ARC，您可以避免漫长而复杂的步骤，这些步骤会导致在可用区损坏事件期间延长恢复期。
**此功能如何与其它 AWS 服务结合使用？**
EKS 与 ARC 集成，后者为您提供了在 AWS 中完成恢复操作所需的主要接口。为了确保集群内流量从损坏的可用区适当路由，EKS 对在 Kubernetes 数据面板中运行的容器组（pod）的网络端点列表进行了修改。如果您使用弹性负载均衡将外部流量路由到集群，则可以向 ARC 注册您的负载均衡器，并对其启动可用区转移，以防止流量流入降级的可用区。可用区转移还适用于由 EKS 托管节点组创建的 Amazon EC2 Auto Scaling 组。为了防止损坏的可用区被用于新的 Kubernetes 容器组（pod）或节点启动，EKS 会将损坏的可用区从自动扩缩组中移除。
**此功能与默认的 Kubernetes 保护有何不同？**
此功能与多个 Kubernetes 内置保护结合使用，可帮助客户应用程序保持韧性。您可以配置容器组（pod）就绪性和存活性探测器，以决定容器组（pod）何时应接入流量。当这些探测器失败时，Kubernetes 会移除将这些容器组（pod）作为服务的目标，流量将不再发送到这些容器组（pod）。虽然这很有用，但对于客户来说，配置这些运行状况检查以确保在可用区降级时它们会失败并非易事。ARC 可用区转移功能提供了额外的安全网，可以帮助您在 Kubernetes 的原生保护不足时完全隔离已降级的可用区。可用区转移还为用户提供了一种测试架构的运行就绪性和韧性的简便方法。
**AWS 可以代表我启动可用区转移吗？**
可以。如果您想以一种全自动的方式使用 ARC 可用区转移，则可以启用 ARC 可用区自动转移。借助可用区自动转移，您可以依靠 AWS 来监控 EKS 集群的可用区运行状况，并在检测到可用区损坏时自动启动可用区转移。
**如果我使用此功能，但我的 Worker 节点和工作负载未预先扩展，会发生什么情况？**
如果您没有预先扩展，并且依赖于在可用区转移期间预调配其他节点或容器组（pod），则可能会面临恢复延迟的风险。向 Kubernetes 数据面板添加新节点的过程将需要一些时间，这可能会对应用程序的实时性能和可用性产生影响，尤其是在出现可用区损坏的情况下。此外，如果出现可用区损坏，您可能会遇到潜在的计算容量约束，这会阻止将新需要的节点添加到运行状况良好的可用区。
如果您的工作负载未预先扩展并分布在集群中的所有可用区，则可用区损坏可能会影响仅在受影响可用区的 Worker 节点上运行的应用程序的可用性。为了降低应用程序可用性完全中断的风险，如果工作负载的所有端点都位于运行状况不佳的可用区中，EKS 提供了故障安全功能，可以将流量发送到损坏的可用区中的容器组（pod）端点。但是，强烈建议您预先扩展应用程序并将其分散到所有可用区，以便在出现可用区问题时保持可用性。
**如果我运行的是有状态的应用程序会怎样？**
如果您运行的是有状态的应用程序，则须根据使用案例和架构评测其容错能力。如果您采用主动/备用架构或模式，则可能存在主动服务器位于损坏的可用区中的情况。在应用程序级别，如果未激活备用副本，则您的应用程序可能会遇到问题。在运行状况良好的可用区中启动新的 Kubernetes 容器组（pod）时，您也可能会遇到问题，因为它们将无法附加到损坏的可用区的持久卷。
**此功能适用于 Karpenter 吗？**
在 EKS 中，ARC 可用区转移和可用区自动转移目前不支持 Karpenter。如果可用区损坏，则可以通过移除运行状况不佳的可用区来调整相关的 Karpenter NodePool 配置，这样新的 Worker 节点只能在其他可用区中启动。
**此功能是否可以与 EKS Fargate 结合使用？**
此功能不能与 EKS Fargate 结合使用。默认情况下，当 EKS Fargate 识别出可用区运行状况值事件时，容器组（pod）将更愿意在其它可用区中运行。
**EKS 托管的 Kubernetes 控制面板是否会受到影响？**
不会。默认情况下，Amazon EKS 跨多个可用区运行和扩展 Kubernetes 控制面板以确保高可用性。ARC 可用区转移和可用区自动转移只能在 Kubernetes 数据面板上起作用。
**这项新功能有什么相关费用吗？**
您可以在 EKS 集群中使用 ARC 可用区转移和可用区自动转移，无需额外付费。但是，您将继续为预调配实例付费，因此强烈建议您在使用此功能之前预先扩展 Kubernetes 数据面板。您应该考虑在成本和应用程序可用性之间取得平衡。
## 其他资源
+ [可用区转移的工作原理](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [ARC 中的可用区转移最佳实践](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [可用区转移和可用区自动转移支持的资源和场景](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [在 Amazon EKS 上运行弹性工作负载](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [通过容器组（pod）优先级和超额预置消除 Kubernetes 节点扩展延迟](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [扩展 CoreDNS 容器以获得高 DNS 流量](coredns-autoscaling.md)
# 启用 EKS 可用区转移以避开损坏的可用区
Amazon 应用程序恢复控制器（ARC）可帮助您管理和协调跨可用区（AZ）的应用程序恢复，并可与包括 Amazon EKS 在内的许多服务结合使用。借助对 ARC 可用区转移的 EKS 支持，您可以将集群内的网络流量从损坏的可用区转移出去。您还可以授权 AWS 监控可用区的运行状况，并代表您暂时将网络流量从运行状况不佳的可用区转移出去。
**如何使用 EKS 可用区转移：**
1. 使用 Amazon 应用程序恢复控制器（ARC）启用您的 EKS 集群。此操作通过使用 Amazon EKS 控制台、AWS CLI、CloudFormation 或 eksctl 在集群级别完成。
1. 启用后，您可以使用 ARC 控制台、AWS CLI 或可用区转移和可用区自动转移 API 来管理可用区转移或可用区自动转移。
请注意，向 ARC 注册 EKS 集群后，您仍然需要配置 ARC。例如，您可以使用 ARC 控制台来配置可用区自动转移。
有关 EKS 可用区转移的工作原理以及如何设计工作负载以处理损坏的可用区的更多详细信息，请参阅[了解 Amazon EKS 中的 Amazon 应用程序恢复控制器（ARC）可用区转移](zone-shift.md)。
## 注意事项
+ EKS 自动模式不支持 Amazon 应用程序恢复控制器、可用区转移和可用区自动转移。
+ 我们建议在两次可用区转移操作之间至少等待 60 秒，以确保正确处理每个请求。
尝试快速连续执行可用区转移（彼此相隔在 60 秒以内）时，Amazon EKS 服务可能无法正确处理所有转移请求。这是由于当前的轮询机制会更新集群的可用区状态。如果您需要执行多次可用区转移，则请确保两次操作之间有足够的时间让系统处理每次变更。
## 什么是 Amazon 应用程序恢复控制器？
Amazon 应用程序恢复控制器（ARC）可帮助您为在 AWS 上运行的应用程序做好恢复准备并更快地完成恢复。可用区转移通过暂时将支持的资源的流量从可用区（AZ）转移到 AWS 区域中的运行状况良好的可用区，从而可帮助您从可用区损坏中快速恢复。
[了解有关 Amazon 应用程序恢复控制器（ARC）的更多信息](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## 什么是可用区转移？
可用区转移是 ARC 中的一项功能，它允许您将资源（例如 EKS 集群或 Elastic Load Balancer）的流量从某个 AWS 区域的可用区移走，从而快速缓解问题并快速恢复应用程序。由于部署不当导致延迟问题或者由于可用区损坏等原因，您可能会选择转移流量。可用区转移不需要高级配置步骤。
[详细了解 ARC 可用区转移](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## 什么是可用区自动转移？
可用区自动转移是 ARC 中的一项功能，您可以启用该功能，以授权 AWS 代表您将流量从受支持资源的可用区转移到 AWS 区域中运行状况良好的可用区。当内部遥测功能指示区域中的可用区存在可能会影响客户的损坏时，AWS 会开始自动转移。内部遥测纳入了多个来源的指标，包括 AWS 网络、Amazon EC2 和 Elastic Load Balancing 服务。
当指示器显示不再存在问题或潜在问题时，AWS 将结束自动转移。
[详细了解 ARC 区域自动转移](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## EKS 在自动转移期间会做什么？
EKS 更新网络配置以避免将流量定向到损坏的可用区。此外，如果您使用的是托管节点组，EKS 将仅在可用区转移期间在运行状况良好的可用区中启动新节点。当转移到期或被取消时，联网配置将恢复为包括先前检测为运行状况不佳的可用区。
[详细了解 EKS 可用区转移](zone-shift.md)。
## 向 Amazon 应用程序恢复控制器（ARC）（AWS 控制台）注册 EKS 集群
1. 找到您要向 ARC 注册的 EKS 集群的名称和区域。
1. 导航到该区域的 [EKS 控制台](https://console.aws.amazon.com/eks)，然后选择您的集群。
1. 在**集群信息**页面上，选择**概述**选项卡。
1. 在**可用区转移**标题下，选择**管理**按钮。
1. 为 *EKS 可用区转移*选择**启用**或**禁用**。
现在，您的 EKS 集群已向 ARC 注册。
如果您希望 AWS 检测并避开损坏的可用区，则需要配置 ARC 可用区自动转移。例如，您可以在 ARC 控制台中执行此操作。
## 后续步骤
+ 了解如何[启用可用区自动转移](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html)。
+ 了解如何手动[启动可用区转移](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html)。