

 **協助改進此頁面** 

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 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 執行個體的建立、刪除與修補。您則需負責管理部署在執行個體上的容器與 Pod。

由 EKS 自動模式建立的 EC2 執行個體不同於其他 EC2 執行個體，這類執行個體屬於「受管執行個體」。此類受管執行個體歸 EKS 所有，且存取權限更為嚴格。您無法直接存取 EKS 自動模式管理的執行個體，也無法在其上安裝軟體。

 AWS 建議執行 EKS Auto Mode 或自我管理 Karpenter。您可在移轉期間或進階組態中同時安裝兩者。若已同時安裝，請設定節點集區，使工作負載僅與 Karpenter 或 EKS 自動模式其一相關聯。

如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的 [Amazon EC2 受管執行個體](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 執行個體。  |  您可將 Pod 與容器部署至受管執行個體。  | 
|  由您決定作業系統與映像 (AMI)。  |   AWS 會決定作業系統和映像。  | 
|  您可部署依賴 Windows 或 Ubuntu 功能的工作負載。  |  您可部署基於 Linux 的容器，但不能有特定作業系統相依性。  | 
|  由您決定要啟動的執行個體類型與系列。  |   AWS 決定要啟動的執行個體類型和系列。您可透過節點集區限制 EKS 自動模式可選取的執行個體類型。  | 

下列功能同時適用於受管執行個體與標準 EC2 執行個體：
+ 您可以在 AWS 主控台中檢視執行個體。
+ 您可將執行個體儲存空間作為工作負載的臨時儲存。

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

使用 EKS Auto Mode 時， AWS 會決定運算節點所使用的映像 (AMI)。 AWS 會監控新 EKS Auto Mode AMI 版本的推出。若您遇到與 AMI 版本相關的工作負載問題，請建立支援案例。如需詳細資訊，請參閱《[支援使用者指南》中的建立支援案例和案例管理](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)。 AWS 

通常情況下，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、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 執行個體：
+ CPU 數量大於 1
+ 執行個體尺寸並非 nano、micro 或 small

如需詳細資訊，請參閱 [Amazon EC2 執行個體類型命名慣例](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)。

## 執行個體中繼資料服務
<a name="_instance_metadata_service"></a>
+ EKS Auto Mode 預設會強制執行 IMDSv2，跳轉限制為 1，並遵循 AWS 安全最佳實務。
+ 此預設組態在 Auto Mode 中無法修改。
+ 對於通常需要 IMDS 存取的附加元件，請在安裝期間提供參數 （例如 AWS 區域），以避免 IMDS 查詢。如需詳細資訊，請參閱[確定您可為 Amazon EKS 附加元件自訂的欄位](kubernetes-field-management.md)。
+ 若 Pod 在 Auto Mode 中執行時絕對需要存取 IMDS，必須將 Pod 設定為搭配 `hostNetwork: true` 執行。如此 Pod 才能直接存取執行個體中繼資料服務。
+ 在授予 Pods 存取執行個體中繼資料的權限時，請務必考量安全性影響。

如需有關 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 容量，則會發生下列動作：
  + Auto Mode 跳過小型 EBS 磁碟區。
  + NVMe 磁碟機會直接開放給您的工作負載使用。
+ Amazon EKS Auto Mode 不支援下列 Fault Injection Service AWS 動作：
  +  `ec2:RebootInstances` 
  +  `ec2:SendSpotInstanceInterruptions` 
  +  `ec2:StartInstances` 
  +  `ec2:StopInstances` 
  +  `ec2:TerminateInstances` 
  +  `ec2:PauseVolumeIO` 
+ Amazon EKS Auto Mode AWS 支援 Fault Injection Service EKS Pod 動作。如需詳細資訊，請參閱 AWS 《Resilience Hub 使用者指南》中的[管理故障注入服務實驗](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html)和[使用 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 裝置外掛程式不在 Auto Mode 節點上執行。如需詳細資訊，請參閱[控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)。

# 了解 EKS 自動模式中的身分和存取
<a name="auto-learn-iam"></a>

本主題描述使用 EKS 自動模式所需的 Identity and Access Management (IAM) 角色與許可。EKS 自動模式使用兩個主要 IAM 角色：叢集 IAM 角色和節點 IAM 角色。這些角色與 EKS Pod 身分識別和 EKS 存取項目協同工作，為您的 EKS 叢集提供全面的存取管理。

當您設定 EKS Auto Mode 時，您將需要設定這些具有特定許可的 IAM 角色，以允許 AWS 服務與您的叢集資源互動。這包括用於管理運算資源、儲存磁碟區、負載平衡器和聯網元件的許可。了解這些角色組態對於正確的叢集操作與安全性至關重要。

在 EKS Auto 模式中， 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 Auto 模式時， AWS 建議為每個 AWS 帳戶建立單一叢集 IAM 角色。
+  AWS 建議將此角色命名為 `AmazonEKSAutoClusterRole`。
+ 此角色需要多個 AWS 服務的許可，才能管理 資源，包括 EBS 磁碟區、Elastic Load Balancer 和 EC2 執行個體。
+ 此角色的建議組態包含多個 AWS 受管 IAM 政策，與 EKS Auto Mode 的不同功能相關。
  +  `AmazonEKSComputePolicy` 
  +  `AmazonEKSBlockStoragePolicy` 
  +  `AmazonEKSLoadBalancingPolicy` 
  +  `AmazonEKSNetworkingPolicy` 
  +  `AmazonEKSClusterPolicy` 

如需叢集 IAM 角色和 AWS 受管 IAM 政策的詳細資訊，請參閱：
+  [AWS Amazon Elastic Kubernetes Service 的 受管政策](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 叢集中工作者節點許可的 AWS Identity and Access Management (IAM) 角色。此角色會授予以 Kubernetes 節點身分執行的 EC2 執行個體與 AWS 服務和資源互動的必要許可，並使用 EKS 存取項目自動設定 Kubernetes RBAC 許可。
+ 您必須將 AWS IAM 政策連接至此角色。
+ EKS 自動模式會使用 EKS 存取項目自動將 Kubernetes RBAC 許可附加到此角色。
+  AWS 建議將此角色命名為 `AmazonEKSAutoNodeRole`。
+ 使用 EKS Auto Mode， AWS 建議為每個 AWS 帳戶建立單一節點 IAM 角色。
+ 此角色具有有限的許可。關鍵許可包括擔任 Pod 身分識別角色，以及從 ECR 提取映像。
+  AWS 建議下列 AWS 受管 IAM 政策：
  +  `AmazonEKSWorkerNodeMinimalPolicy` 
  +  `AmazonEC2ContainerRegistryPullOnly` 

如需叢集 IAM 角色和 AWS 受管 IAM 政策的詳細資訊，請參閱：
+  [AWS Amazon Elastic Kubernetes Service 的 受管政策](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)。服務連結角色是直接連結至 Amazon EKS 的一種特殊 IAM 角色類型。服務連結角色由 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 Auto 資源的自訂 AWS 標籤
<a name="tag-prop"></a>

根據預設，與 EKS Auto Mode 相關的受管政策不允許將使用者定義的標籤套用至 Auto Mode 佈建 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 Auto Mode 時， 會 AWS 管理叢集的 VPC 容器網路界面 (CNI) 組態和負載平衡器佈建。您可透過定義 `NodeClass` 物件，以及將特定注釋套用至服務與傳入資源來影響聯網行為，同時維持 EKS 自動模式提供的自動化營運模式。

## 聯網功能
<a name="_networking_capability"></a>

EKS 自動模式具有一個處理節點和 Pod 聯網的新聯網功能。您可以透過建立一個 `NodeClass` Kubernetes 物件進行設定。

先前 AWS VPC CNI 的組態選項不適用於 EKS Auto 模式。

### 使用 `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 NodeClass](create-node-class.md)。

### 考量事項
<a name="_considerations"></a>

EKS 自動模式支援：
+ EKS 網路政策。
+ Kubernetes Pod 的 `HostPort` 與 `HostNetwork` 選項。
+ 位於公有或私有子網路中的節點和 Pod。
+ 在節點上快取 DNS 查詢。

EKS 自動模式**不支援**下列功能：
+ 每個 Pod 的安全群組 (SGPP)。若要在自動模式下將個別安全群組套用至 Pod 流量，請`NodeClass`改為在 `podSecurityGroupSelectorTerms`中使用 。如需詳細資訊，請參閱[Pod 的個別子網路和安全群組](create-node-class.md#pod-subnet-selector)。
+ `ENIConfig` 中的自訂聯網。您可以使用 [Pod 的個別子網路和安全群組](create-node-class.md#pod-subnet-selector) 將 Pod 放入多個子網路中，或將其與節點流量完全隔離。
+ 預熱 IP、預熱前綴和預熱 ENI 組態。
+ 最小 IP 目標組態。
+ 開放原始碼 AWS VPC CNI 支援的其他組態。
+ 網路政策組態，如連線追蹤計時器自訂 (預設為 300 秒)。
+ 將網路事件日誌匯出至 CloudWatch。

### 網路資源管理
<a name="_network_resource_management"></a>

EKS 自動模式透過監控聯網組態的 NodeClass 資源來處理字首、IP 定址和聯網介面管理。該服務會自動執行多項關鍵操作：

 **字首委派** 

EKS Auto Mode 預設為使用字首委派 (/28 個字首） 進行 Pod 聯網，並維護預先定義的 IP 資源暖集區，該集區會根據排程的 Pod 數量進行擴展。偵測到 Pod 子網路分段時，自動模式會佈建次要 IP 地址 (/32)。由於此預設 Pod 網路演算法，自動模式會根據每個執行個體類型支援的 ENIs 和 IPs 數目 （假設片段的最壞情況），計算每個節點的最大 Pod。如需每個執行個體類型的最大 ENIs IPs 的詳細資訊，請參閱 EC2 使用者指南中的[每個網路界面的最大 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)。較新一代 (Nitro v6 及更高版本） 執行個體系列通常會增加每個執行個體類型的 ENIs 和 IPs，而自動模式會相應地調整最大 Pod 計算。

對於 IPv6 叢集，只會使用字首委派，而自動模式一律使用每個節點最多 110 個 Pod。

 **冷卻時間管理** 

該服務為不再使用的字首或次要 IPv4 位址實作冷卻集區。在冷卻時間到期後，這些資源將被釋出回 VPC。但是，如果 Pod 在冷卻時間內重複使用這些資源，則會從冷卻集區還原這些資源。

 **IPv6 支援** 

對於 IPv6 叢集，EKS 自動模式會在主要網路介面上為每個節點佈建 `/80` IPv6 前綴。使用 時`podSubnetSelectorTerms`，字首會改為配置在 Pod 子網路中的次要網路界面上。

該服務還確保所有網路介面的正確管理和垃圾回收。

## Load balancing
<a name="auto-lb-consider"></a>

您可以在服務和輸入資源上使用註釋來設定 EKS Auto Mode 佈建的 AWS Elastic Load Balancer。

如需詳細資訊，請參閱 [建立 IngressClass 以設定 Application Load Balancer](auto-configure-alb.md) 或 [使用服務注釋設定 Network Load Balancer](auto-configure-nlb.md) 。

### 使用 EKS 自動模式進行負載平衡的考量事項
<a name="_considerations_for_load_balancing_with_eks_auto_mode"></a>
+ 預設目標模式是 IP 模式，而非執行個體模式。
+ EKS 自動模式僅支援 Network Load Balancer 的安全群組模式。
+  AWS 不支援將負載平衡器從自我管理 AWS 負載平衡器控制器遷移至 EKS Auto Mode 管理。
+ 不支援 `TargetGroupBinding` 規格中的 `networking.ingress.ipBlock` 欄位。
+ 如果您的工作節點使用自訂安全群組 (而非 `eks-cluster-sg- ` 命名模式)，則您的叢集角色需要額外的 IAM 許可。預設的 EKS 受管政策僅允許 EKS 修改名為 `eks-cluster-sg-` 的安全群組。如果沒有修改您自訂安全群組的許可，EKS 將無法新增所需的輸入規則，以允許 ALB/NLB 流量到達您的 Pod。

#### CoreDNS 考量事項
<a name="dns-consider"></a>

EKS Auto Mode 不會使用傳統 CoreDNS 部署在叢集內提供 DNS 解析。反之，自動模式節點會利用 CoreDNS，直接在每個節點上執行做為系統服務。如果將傳統叢集轉換為自動模式，您可以將工作負載移至自動模式節點後，從叢集中移除 CoreDNS 部署。

**重要**  
如果您計劃維護具有自動模式和非自動模式節點的叢集，則必須保留 CoreDNS 部署。非自動模式節點依賴傳統的 CoreDNS Pod 進行 DNS 解析，因為它們無法存取自動模式提供的節點層級 DNS 服務。