

 **帮助改进此页面** 

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。

# 了解 EKS 自动模式的工作原理
<a name="auto-reference"></a>

通过本章了解 Amazon EKS 自动模式集群的组件的工作原理。

**Topics**
+ [了解 Amazon EKS 自动模式的托管式实例](automode-learn-instances.md)
+ [了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)
+ [了解 EKS 自动模式下的 VPC 联网和负载均衡](auto-networking.md)

# 了解 Amazon EKS 自动模式的托管式实例
<a name="automode-learn-instances"></a>

本主题介绍了 Amazon EKS 自动模式如何管理 EKS 集群中的 Amazon EC2 实例。启用 EKS 自动模式后，集群的计算资源将由 EKS 自动预置和管理，从而改变您与作为集群中节点的 EC2 实例的交互方式。

了解 Amazon EKS 自动模式会如何管理实例，对于规划工作负载部署策略和操作程序至关重要。与传统的 EC2 实例或托管式节点组不同，此类实例遵循不同的生命周期模式，EKS 负责许多操作任务，同时限制某些类型的访问和自定义。

Amazon EKS 自动模式可自动执行创建新 EC2 实例的例行任务，并将其作为节点挂载到 EKS 集群。EKS 自动模式会检测现有节点何时不能满足工作负载的需要，并创建新的 EC2 实例。

Amazon EKS 自动模式负责创建、删除和修补 EC2 实例。您负责实例上部署的容器和容器组。

EKS 自动模式创建的 EC2 实例属于托管式实例，这与其他 EC2 实例不同。此类托管式实例由 EKS 所有，并且受到更多限制。您不能直接访问由 EKS 自动模式管理的实例或在此类实例上安装软件。

 AWS 建议运行 EKS 自动模式或自主管理型 Karpenter。您可以在迁移过程中或在高级配置中同时安装这两者。如果您同时安装了这两者，请配置节点池，以将工作负载关联到 Karpenter 或 EKS 自动模式。

有关更多信息，请参阅《Amazon EC2 用户指南》中的 [Amazon EC2 managed instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)。

## 比较表
<a name="_comparison_table"></a>


| 标准 EC2 实例 | EKS 自动模式托管式实例 | 
| --- | --- | 
|  您负责修补和更新实例。  |   AWS 会自动修补和更新实例。  | 
|  EKS 对实例上的软件不承担任何责任。  |  EKS 对实例上的某些软件负责，例如 `kubelet`、容器运行时和操作系统。  | 
|  您可以使用 EC2 API 来删除 EC2 实例。  |  EKS 负责决定将在您账户中部署的实例数量。如果您删除工作负载，EKS 将会减少您账户中的实例数量。  | 
|  您可以使用 SSH 访问 EC2 实例。  |  您可以将容器组和容器部署到托管式实例。  | 
|  您负责决定操作系统和映像（AMI）。  |   AWS 负责决定操作系统和映像。  | 
|  您可以部署依赖 Windows 或 Ubuntu 功能的工作负载。  |  您可以部署基于 Linux 但无特定操作系统依赖项的容器。  | 
|  您负责决定要启动的实例类型和系列。  |   AWS 负责决定要启动的实例类型和系列。您可以使用节点池来限制 EKS 自动模式可选择的实例类型。  | 

以下功能对托管式实例和标准 EC2 实例均适用：
+ 您可以在 AWS 控制台中查看实例。
+ 您可以将实例存储用作工作负载的临时存储。

### AMI 支持
<a name="_ami_support"></a>

通过 EKS 自动模式，AWS 可确定用于计算节点的映像（AMI）。AWS 还会监控新的 EKS 自动模式 AMI 版本的推出。如果遇到与 AMI 版本相关的工作负载问题，请创建支持案例。有关更多信息，请参阅《AWS Support User Guide》中的 [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)。

通常，EKS 每周都会发布一个包含 CVE 和安全修复的新 AMI。

## EKS 自动模式支持的实例参考
<a name="auto-supported-instances"></a>

EKS 自动模式仅创建属于受支持类型且符合最小大小要求的实例。

EKS 自动模式支持以下实例类型：


| 系列 | 实例类型 | 
| --- | --- | 
|  计算优化型（C）  |  c8i、c8i-flex、c8gd、c8gn、c8g、c7a、c7g、c7gn、c7gd、c7i、c7i-flex、c6a、c6g、c6i、c6gn、c6id、c6in、c6gd、c5、c5a、c5d、c5ad、c5n、c4  | 
|  通用型（M）  |  m8i、m8i-flex、m8a、m8gn、m8gb、m8gd、m8g、m7i、m7a、m7g、m7gd、m7i-flex、m6a、m6i、m6in、m6g、m6idn、m6id、m6gd、m5、m5a、m5ad、m5n、m5dn、m5d、m5zn、m4  | 
|  内存优化型（R）  |  r8i、r8i-flex、r8gn、r8gb、r8gd、r8g、r7a、r7iz、r7gd、r7i、r7g、r6a、r6i、r6id、r6in、r6idn、r6g、r6gd、r5、r5n、r5a、r5dn、r5b、r5ad、r5d、r4  | 
|  突增型（T）  |  t4g、t3、t3a、t2  | 
|  内存增强型（Z/X）  |  z1d、x8g、x2gd  | 
|  存储优化型（I/D）  |  i8ge、i7i、i8g、i7ie、i4g、i4i、i3、i3en、is4gen、d3、d3en、im4gn  | 
|  加速计算型（P/G/Inf/Trn）  |  p5、p4d、p4de、p3、p3dn、gr6、g6、g6e、g5g、g5、g4dn、inf2、inf1、trn1、trn1n  | 
|  高性能计算型（X2）  |  x2iezn、x2iedn、x2idn  | 

此外，EKS 自动模式将仅创建满足以下要求的 EC2 实例：
+ 超过 1 个 CPU
+ 实例大小并非纳米型、微型或小型

有关更多信息，请参阅 [Amazon EC2 实例类型命名约定](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)。

## 实例元数据服务
<a name="_instance_metadata_service"></a>
+ 默认情况下，EKS 自动模式会遵循 AWS 安全最佳实践，强制执行 IMDSv2（跃点限制为 1）。
+ 此默认配置在自动模式下无法修改。
+ 对于通常需要 IMDS 访问权限的附加组件，请在安装过程中提供参数（例如 AWS 区域），以避免 IMDS 查找。有关更多信息，请参阅 [确定可以为 Amazon EKS 附加组件自定义的字段](kubernetes-field-management.md)。
+ 如果容器组在自动模式下运行时确实需要 IMDS 访问权限，则必须将该容器组配置为可以使用 `hostNetwork: true` 运行。这将允许容器组直接访问实例元数据服务。
+ 授予容器组实例元数据访问权限时，应考虑安全影响。

有关 Amazon EC2 实例元数据服务（IMDS）的更多信息，请参阅《Amazon EC2 用户指南》**中的[配置实例元数据服务选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)。

## 注意事项
<a name="_considerations"></a>
+ 如果 NodeClass 中配置的临时存储小于实例的 NVMe 本地存储，则 EKS 自动模式会自动执行以下操作，无需手动配置：
  + 使用较小（20 GiB）的 Amazon EBS 数据量来降低成本。
  + 格式化并配置 NVMe 本地存储以供临时数据使用。这包括在具有多个 NVMe 驱动器的情况下设置 RAID 0 阵列。
+ 当 `ephemeralStorage.size` 等于或超过本地 NVMe 容量时，会发生以下操作：
  + 自动模式会跳过小型 EBS 卷。
  + NVMe 驱动器将直接公开给工作负载。
+ Amazon EKS 自动模式不支持下列 AWS 故障注入服务操作：
  +  `ec2:RebootInstances` 
  +  `ec2:SendSpotInstanceInterruptions` 
  +  `ec2:StartInstances` 
  +  `ec2:StopInstances` 
  +  `ec2:TerminateInstances` 
  +  `ec2:PauseVolumeIO` 
+ Amazon EKS 自动模式支持 AWS 故障注入服务 EKS 容器组（pod）操作。有关更多信息，请参阅[管理故障注入服务试验](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html)和《AWS 韧性监测中心用户指南》中的[执行 AWS FIS aws:eks:pod 操作](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account)。
+ 不需要在 EKS 自动模式节点上安装 `Neuron Device Plugin`。

  如果集群中有其他类型的节点，则需要将 Neuron Device 插件配置为不在自动模式节点上运行。有关更多信息，请参阅 [控制工作负载是否部署在 EKS 自动模式节点上](associate-workload.md)。

# 了解 EKS 自动模式中的身份和访问权限
<a name="auto-learn-iam"></a>

本主题介绍使用 EKS 自动模式所需的 Identity and Access Management（IAM）角色和权限。EKS 自动模式使用两个主要 IAM 角色：一个集群 IAM 角色和一个节点 IAM 角色。这两个角色与 EKS 容器组身份和 EKS 访问条目配合使用，从而为 EKS 集群提供全面的访问管理。

配置 EKS 自动模式时，您需要设置这两个 IAM 角色，为其授予允许 AWS 服务与集群资源交互所需的特定权限，包括管理计算资源、存储卷、负载均衡器和网络组件的权限。了解这些角色配置对于确保集群的正常运行和安全至关重要。

在 EKS 自动模式下，AWS IAM 角色会自动通过 EKS 访问条目映射到 Kubernetes 权限，无需手动配置 `aws-auth` ConfigMaps 或自定义绑定。创建新的自动模式集群时，EKS 会使用访问条目自动创建相应的 Kubernetes 权限，从而确保 AWS 服务和集群组件在 AWS 和 Kubernetes 授权系统中都具有适当的访问权限级别。这种自动集成可减少配置的复杂性，有助于防止在管理 EKS 集群时常见的权限相关问题。

## 集群 IAM 角色
<a name="auto-learn-cluster-iam-role"></a>

集群 IAM 角色是 Amazon EKS 用来管理 Kubernetes 集群权限的 AWS Identity and Access Management（IAM）角色。此角色向 Amazon EKS 授予代表集群与其他 AWS 服务进行交互的必要权限，并且使用 EKS 访问条目自动配置了 Kubernetes 权限。
+ 您必须将 AWS IAM 策略附加到此角色。
+ EKS 自动模式使用 EKS 访问条目自动为此角色附加 Kubernetes 权限。
+ 使用 EKS 自动模式时，AWS 建议为每个 AWS 账户创建一个集群 IAM 角色。
+  AWS 建议将此角色命名为 `AmazonEKSAutoClusterRole`。
+ 此角色需要具有允许多个 AWS 服务管理资源的权限，包括 EBS 卷、弹性负载均衡器和 EC2 实例等。
+ 此角色的建议配置包括与 EKS 自动模式的不同功能相关的多个 AWS 托管式 IAM 策略。
  +  `AmazonEKSComputePolicy` 
  +  `AmazonEKSBlockStoragePolicy` 
  +  `AmazonEKSLoadBalancingPolicy` 
  +  `AmazonEKSNetworkingPolicy` 
  +  `AmazonEKSClusterPolicy` 

有关集群 IAM 角色和 AWS 托管式 IAM 策略的更多信息，请参阅：
+  [Amazon Elastic Kubernetes Service 的AWS托管策略](security-iam-awsmanpol.md) 
+  [Amazon EKS 集群 IAM 角色](cluster-iam-role.md) 

有关 Kubernetes 访问权限的更多信息，请参阅：
+  [检查访问策略权限](access-policy-permissions.md) 

## 节点 IAM 角色
<a name="auto-learn-node-iam-role"></a>

节点 IAM 角色是 Amazon EKS 用来管理 Kubernetes 集群中 Worker 节点权限的 AWS Identity and Access Management（IAM）角色。此角色向作为 Kubernetes 节点运行的 EC2 实例授予与 AWS 服务和资源进行交互所需的必要权限，并使用 EKS 访问条目自动配置 Kubernetes RBAC 权限。
+ 您必须将 AWS IAM 策略附加到此角色。
+ EKS 自动模式使用 EKS 访问条目自动为此角色附加 Kubernetes RBAC 权限。
+  AWS 建议将此角色命名为 `AmazonEKSAutoNodeRole`。
+ 使用 EKS 自动模式时，AWS 建议为每个 AWS 账户创建一个节点 IAM 角色。
+ 此角色具有的权限较为有限。主要权限包括代入容器组身份角色以及从 ECR 中拉取映像的权限。
+  AWS 建议使用以下 AWS 托管式 IAM 策略：
  +  `AmazonEKSWorkerNodeMinimalPolicy` 
  +  `AmazonEC2ContainerRegistryPullOnly` 

有关集群 IAM 角色和 AWS 托管式 IAM 策略的更多信息，请参阅：
+  [Amazon Elastic Kubernetes Service 的AWS托管策略](security-iam-awsmanpol.md) 
+  [Amazon EKS 节点 IAM 角色](create-node-role.md) 

有关 Kubernetes 访问权限的更多信息，请参阅：
+  [检查访问策略权限](access-policy-permissions.md) 

## 服务相关角色
<a name="_service_linked_role"></a>

Amazon EKS 会使用一个服务相关角色（SLR）来执行某些操作。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。

 AWS 会自动创建和配置此 SLR。只有首先删除 SLR 的相关资源后才能将其删除。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。

SLR 策略会向 Amazon EKS 授予观察和删除核心基础设施组件的权限：EC2 资源（实例、网络接口、安全组）、ELB 资源（负载均衡器、目标组）、CloudWatch 功能（日志记录和指标）以及带有“eks”前缀的 IAM 角色。此策略还支持通过 VPC/托管区关联来实现私有端点联网，并且包括 EventBridge 监控和清理带有 EKS 标签的资源的权限。

有关更多信息，请参阅：
+  [AWS托管策略：AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) 
+  [Amazon EKS 的服务相关角色权限](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 

## EKS 自动模式资源的自定义 AWS 标签
<a name="tag-prop"></a>

默认情况下，与 EKS 自动模式相关的托管式策略不允许将用户定义的标签应用于自动模式预置的 AWS 资源。如果要将用户定义的标签应用于 AWS 资源，则必须为集群 IAM 角色附加额外的权限，以提供在 AWS 资源上创建和修改标签的充分权限。以下示例策略将允许不受限制的标记访问权限：

### 查看自定义标签策略示例
<a name="auto-tag-policy"></a>

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Compute",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateFleet",
                "ec2:RunInstances",
                "ec2:CreateLaunchTemplate"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
                },
                "StringLike": {
                    "aws:RequestTag/eks:kubernetes-node-class-name": "*",
                    "aws:RequestTag/eks:kubernetes-node-pool-name": "*"
                }
            }
        },
        {
            "Sid": "Storage",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVolume",
                "ec2:CreateSnapshot"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:snapshot/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
                }
            }
        },
        {
            "Sid": "Networking",
            "Effect": "Allow",
            "Action": "ec2:CreateNetworkInterface",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
                },
                "StringLike": {
                    "aws:RequestTag/eks:kubernetes-cni-node-name": "*"
                }
            }
        },
        {
            "Sid": "LoadBalancer",
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:CreateTargetGroup",
                "elasticloadbalancing:CreateListener",
                "elasticloadbalancing:CreateRule",
                "ec2:CreateSecurityGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
                }
            }
        },
        {
            "Sid": "ShieldProtection",
            "Effect": "Allow",
            "Action": [
                "shield:CreateProtection"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
                }
            }
        },
        {
            "Sid": "ShieldTagResource",
            "Effect": "Allow",
            "Action": [
                "shield:TagResource"
            ],
            "Resource": "arn:aws:shield::*:protection/*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
                }
            }
        }
    ]
}
```

## 访问策略参考
<a name="_access_policy_reference"></a>

要详细了解 EKS 自动模式使用的 Kubernetes 权限，请参阅[检查访问策略权限](access-policy-permissions.md)。

# 了解 EKS 自动模式下的 VPC 联网和负载均衡
<a name="auto-networking"></a>

本主题介绍如何在 EKS 自动模式下配置虚拟私有云（VPC）联网和负载均衡功能。虽然 EKS 自动模式会自动管理大多数联网组件，但您仍然可以通过 `NodeClass` 资源和负载均衡器注释来自定义集群联网配置的某些方面。

使用 EKS 自动模式时，AWS 会管理集群的 VPC 容器网络接口（CNI）配置和负载均衡器预置。您可以通过定义 `NodeClass` 对象并对服务和 Ingress 资源应用特定的注释来影响联网行为，同时保持 EKS 自动模式提供的自动运行模式优势。

## 联网功能
<a name="_networking_capability"></a>

EKS 自动模式具有一个能够处理节点和容器组（pod）联网的新联网功能。您可以通过创建 `NodeClass` Kubernetes 对象来对其进行配置。

以前的 AWS VPC CNI 配置选项不适用于 EKS 自动模式。

### 使用 `NodeClass` 配置联网
<a name="_configure_networking_with_a_nodeclass"></a>

借助 EKS 自动模式中的 `NodeClass` 资源，您可以自定义联网功能的某些方面。通过 `NodeClass`，您可以指定安全组选择，控制 VPC 子网中的节点放置，设置 SNAT 策略，配置网络策略以及启用网络事件日志记录。这种方法既可保持 EKS 自动模式的自动化运行模式，同时又可灵活自定义网络。

您可以使用 `NodeClass` 来：
+ 选择节点的安全组
+ 控制节点在 VPC 子网上的放置方式
+ 将节点 SNAT 策略设置为 `random` 或 `disabled` 
+ 启用 Kubernetes *网络策略*，包括：
  + 将网络策略设置为“默认拒绝”或“默认允许”
  + 启用将网络事件日志记录到文件。
+ 通过将容器组（pod）连接到不同的子网，将容器组（pod）流量与节点流量隔离开来。

了解如何[创建 Amazon EKS 节点类](create-node-class.md)。

### 注意事项
<a name="_considerations"></a>

EKS 自动模式支持下列功能：
+ EKS 网络策略。
+ Kubernetes 容器组的 `HostPort` 和 `HostNetwork` 选项。
+ 公有子网或私有子网中的节点和容器组（pod）。
+ 在节点上缓存 DNS 查询。

EKS 自动模式**不**支持下列功能：
+ 每容器组的安全组（SGPP）。要在自动模式下将不同的安全组应用于容器组（pod）流量，请改用 `NodeClass` 中的 `podSecurityGroupSelectorTerms`。有关更多信息，请参阅 [为容器组（pod）配置独立的子网和安全组](create-node-class.md#pod-subnet-selector)。
+ `ENIConfig` 中的自定义联网。您可以将容器组（pod）放在多个子网中，也可以使用 [为容器组（pod）配置独立的子网和安全组](create-node-class.md#pod-subnet-selector) 专门将它们与节点流量隔离开来。
+ 暖 IP、暖前缀和暖 ENI 配置。
+ 最低 IP 目标配置。
+ 开源 AWS VPC CNI 支持的其他配置。
+ 网络策略配置，例如 conntrack 计时器自定义（默认为 300 秒）。
+ 将网络事件日志导出到 CloudWatch。

### 网络资源管理
<a name="_network_resource_management"></a>

EKS 自动模式通过监控用于网络配置的节点类资源来处理前缀、IP 寻址及网络接口管理。该服务会自动执行多项关键操作：

 **前缀委派** 

EKS 自动模式会默认使用前缀委托（/28 前缀）进行容器组（pod）联网，并维护可根据调度的容器组（pod）数量进行扩展的预定义 IP 热池。检测到容器组（pod）子网碎片时，自动模式会预置辅助 IP 地址（/32）。由于这种默认的容器组（pod）联网算法，自动模式会根据每种实例类型支持的 ENI 和 IP 数量来计算每个节点的最大容器组（pod）数（假设是最坏的碎片化情况）。有关每个实例类型的最大 ENI 和 IP 数量的更多信息，请参阅《EC2 用户指南》中的[每个网络接口的最大 IP 地址数](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)。新一代（Nitro v6 及更高版本）实例系列通常会增加每种实例类型的 ENI 和 IP，自动模式会相应地调整最大容器组（pod）计算。

对于 IPv6 集群，仅使用前缀委派，自动模式始终使用每个节点 110 个容器组（pod）的最大容器组（pod）限制。

 **冷却管理** 

该服务为不再使用的前缀或辅助 IPv4 地址设置了冷却池。冷却时间到期后，这些资源将释放回 VPC。但是，如果容器组（pod）在冷却时间内重复使用这些资源，它们将从冷却池中恢复。

 **IPv6 支持** 

对于 IPv6 集群，EKS 自动模式会在主网络接口上为每个节点预置 `/80` IPv6 前缀。使用时 `podSubnetSelectorTerms`，前缀将在容器组（pod）子网的辅助网络接口上分配。

该服务还可确保对所有网络接口进行适当管理和垃圾回收。

## 负载均衡
<a name="auto-lb-consider"></a>

您可以使用服务和 Ingress 资源上的注释来配置由 EKS 自动模式预置的 AWS 弹性负载均衡器。

有关更多信息，请参阅 [创建 IngressClass 以配置应用程序负载均衡器](auto-configure-alb.md) 或 [使用服务注释配置网络负载均衡器](auto-configure-nlb.md)。

### EKS 自动模式负载均衡的注意事项
<a name="_considerations_for_load_balancing_with_eks_auto_mode"></a>
+ 默认目标模式是 IP 模式，而不是实例模式。
+ EKS 自动模式仅支持网络负载均衡器的安全组模式。
+  AWS 不支持将负载均衡器从自主管理型 AWS 负载均衡器控制器迁移到由 EKS 自动模式管理。
+ 不支持 `TargetGroupBinding` 规范中的 `networking.ingress.ipBlock` 字段。
+ 如果 Worker 节点使用自定义安全组（非 `eks-cluster-sg- ` 命名模式），则集群角色需要额外的 IAM 权限。默认 EKS 托管式策略仅允许 EKS 修改名为 `eks-cluster-sg-` 的安全组。如果没有修改自定义安全组的权限，EKS 将无法添加允许 ALB/NLB 流量到达容器组所需的 Ingress 规则。

#### CoreDNS 注意事项
<a name="dns-consider"></a>

EKS 自动模式不使用传统的 CoreDNS 部署在集群内提供 DNS 解析。相反，自动模式节点利用 CoreDNS 作为系统服务直接在每个节点上运行。如果将传统集群过渡到自动模式，则可以在工作负载移至自动模式节点后，从集群中移除 CoreDNS 部署。

**重要**  
如果您计划维护同时包含自动模式和非自动模式节点的集群，则必须保留 CoreDNS 部署。非自动模式节点依赖传统的 CoreDNS 容器组（pod）进行 DNS 解析，因为它们无法访问自动模式提供的节点级 DNS 服务。