**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 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 建立叢集，並提供兩種方法的step-by-step指引。
對於尋求較簡單設定程序的使用者，請參閱以下簡化叢集建立步驟：
+ [使用 eksctl CLI 建立 EKS 自動模式叢集](automode-get-started-eksctl.md)
+ [使用 CLI AWS 建立 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)。
## 先決條件
+ 現有 VPC 和子網符合 [Amazon EKS 要求](network-reqs.md)。部署叢集以供生產使用之前，建議您先徹底了解 VPC 和子網要求。如果您沒有 VPC 和子網路，您可以使用 [Amazon EKS provided AWS CloudFormation 範本](creating-a-vpc.md)建立它們。
+ `kubectl` 命令列工具安裝在您的裝置或 AWS CloudShell 上。版本可以與您的叢集 Kubernetes 版本相同，或是為最多比該版本更舊一版或更新一版的次要版本。例如，如果您的叢集版本為 `1.29`，則可以搭配使用 `kubectl` `1.28`、`1.29` 或 `1.30` 版。若要安裝或升級 `kubectl`，請參閱 [設定 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 在您的裝置或 AWS CloudShell 上安裝和設定的 AWS 命令列界面 (AWS CLI) 版本 `1.27.160` `2.12.3`或更新版本。若要檢查您目前的版本，請使用 `aws --version`。若要安裝最新版本，請參閱《 * AWS 命令列界面使用者指南*》中的使用 aws 設定[安裝](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 和快速組態。 [https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config](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. 在設定叢集頁面的**自動模式運算**區段，輸入以下欄位：
+ **節點集區**：決定是否要使用內建節點集區。如需詳細資訊，請參閱[啟用或停用內建的 NodePool](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 之前，建議您先熟悉 [檢視 VPC 和子網路的 Amazon EKS 聯網需求](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)。
**安全群組**:(選用) 指定一或多個您希望 Amazon EKS 與其建立的網路介面相關聯的安全群組。
無論您是否選擇任何安全群組，Amazon EKS 都會建立一個安全群組，以支援您的叢集和 VPC 之間的通訊。Amazon EKS 將此安全群組及您選擇的任何群組與其建立的網路介面相關聯。如需有關 Amazon EKS 建立的叢集安全群組的詳細資訊，請參閱 [檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md)。您可以修改 Amazon EKS 建立的叢集安全群組中的規則。
+ **選擇叢集 IP 地址系列**：您可以選擇 **IPv4** 或 **IPv6**。
預設情況下，Kubernetes 會為 Pod 和服務指派 `IPv4` 位址。在決定使用 `IPv6` 系列之前，請確認您已熟悉 [VPC 要求和考量事項](network-reqs.md#network-requirements-vpc)、[子網需求和注意事項](network-reqs.md#network-requirements-subnets)、[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md) 和 [了解叢集、Pod 與服務的 IPv6 位址](cni-ipv6.md) 主題中的所有考量事項和要求。如果您選擇 `IPv6` 系列，則無法像對 `IPv4` 系列那樣，指定 Kubernetes 從中分配 `IPv6` 服務位址的位址範圍。Kubernetes 從唯一的本地位址範圍指派服務位址 (`fc00::/7`)。
+ (選用) 選擇**設定 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 位址。
+ 針對 **Cluster endpoint access** (叢集端點存取)，選取一個選項。建立叢集後，您可以變更此選項。在選取非預設選項之前，請務必熟悉這些選項及其含義。如需詳細資訊，請參閱[叢集 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 Pod 身分識別的任何附加元件，詳見 [了解 EKS Pod 身分識別如何授予 AWS 服務的 Pod 存取權](pod-identities.md)。
+ EKS 自動模式會自動化某些附加元件的功能。如果您計劃將 EKS 受管節點群組部署到 EKS 自動模式叢集，選取**其他 Amazon EKS 附加元件**並檢閱選項。您可能需要安裝 CoreDNS 和 kube-proxy 等附加元件。EKS 僅會在自我管理節點與節點群組上安裝本節中的附加元件。
+ 完成此頁面後，請選擇**下一步**。
1. 在**設定選取的附加元件設定**頁面上，選取您要安裝的版本。建立叢集後，您隨時皆可更新至更新版本。
對於支援 EKS Pod 身分的附加元件，您可以使用 主控台自動產生角色，其中包含專為附加元件預先填入的名稱、 AWS 受管政策和信任政策。您可以重複使用現有角色或為支援的附加元件建立新角色。有關使用主控台為支援 EKS Pod 身分識別的附加元件建立角色的步驟，請參閱 [建立附加元件AWS （主控台）](creating-an-add-on.md#create_add_on_console)。如果附加元件不支援 EKS Pod 身分識別，則會顯示一則訊息，指示在叢集建立後使用精靈建立服務帳戶的 IAM 角色 (IRSA)。
您可以在建立叢集後更新每個附加元件的組態。如需有關設定附加元件的詳細資訊，請參閱[更新 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)。
+ 使用您的帳戶 ID 取代 *111122223333*
+ 如果您為叢集和節點角色建立了不同名稱的 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 要從哪個 `IPv4` 無類別域間路由 (CIDR) 區塊中指派服務 IP 地址，您必須將 `--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 會為 Pod 和服務指派 `IPv4` 位址。在決定使用 `IPv6` 系列之前，請確認您已熟悉 [VPC 要求和考量事項](network-reqs.md#network-requirements-vpc)、[子網需求和注意事項](network-reqs.md#network-requirements-subnets)、[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md) 和 [了解叢集、Pod 與服務的 IPv6 位址](cni-ipv6.md) 主題中的所有考量事項和要求。如果您選擇 `IPv6` 系列，則無法像對 `IPv4` 系列那樣，指定 Kubernetes 從中分配 `IPv6` 服務位址的位址範圍。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 Auto 模式的情況下建立 Amazon 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) 中一個指南的步驟進行。這些指南可協助您建立一個簡單的預設叢集，而無需擴展到所有可用選項。
## 先決條件
+ 現有 VPC 和子網符合 [Amazon EKS 要求](network-reqs.md)。部署叢集以供生產使用之前，建議您先徹底了解 VPC 和子網要求。如果您沒有 VPC 和子網路，您可以使用 [Amazon EKS provided AWS CloudFormation 範本](creating-a-vpc.md)建立它們。
+ `kubectl` 命令列工具安裝在您的裝置或 AWS CloudShell 上。版本可以與您的叢集 Kubernetes 版本相同，或是為最多比該版本更舊一版或更新一版的次要版本。若要安裝或升級 `kubectl`，請參閱 [設定 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 在您的裝置或 AWS CloudShell 上安裝和設定的 AWS 命令列界面 (AWS CLI) 版本 `1.27.160` `2.12.3`或更新版本。若要檢查您目前的版本，請使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。適用於 macOS 的 `yum`、 `apt-get`或 Homebrew 等套件管理員通常是最新版本 CLI AWS 後面的幾個版本。若要安裝最新版本，請參閱《 * AWS 命令列界面使用者指南*》中的使用 aws 設定[安裝](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 和快速組態。 [https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)在 AWS CloudShell 中安裝的 AWS CLI 版本也可能是最新版本後面的幾個版本。若要更新它，請參閱《CloudShell [AWS 使用者指南》中的將 CLI 安裝到您的主目錄](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。 * AWS CloudShell *
+ 具有對 Amazon EKS 叢集 `create` 和 `describe` 的許可的 [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 動作之一 (許可)：`iam:AttachUserPolicy` 或 `iam:AttachRolePolicy`。
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### 服務連結角色
Amazon EKS 會自動建立名為 `AWSServiceRoleForAmazonEKS` 的服務。
這是叢集 IAM 角色之外的額外角色。服務連結角色是直接連結至 Amazon EKS 的一種特殊 IAM 角色類型。該角色可讓 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. 您需要在裝置`0.215.0`或 AWS CloudShell 上安裝版本 或更新版本的`eksctl`命令列工具。如需有關安裝或更新 `eksctl` 的指示，請參閱 `eksctl` 文件中的[安裝](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 要從哪個 `IPv4` 無類別域間路由 (CIDR) 區塊中指派服務 IP 位址，請指定 [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 會為 Pod 和服務指派 `IPv4` 位址。在決定使用 `IPv6` 系列之前，請確認您已熟悉 [VPC 要求和注意事項](network-reqs.md#network-requirements-vpc)、[子網需求和注意事項](network-reqs.md#network-requirements-subnets)、[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md) 和 [了解叢集、Pod 與服務的 IPv6 位址](cni-ipv6.md) 主題中的所有考量事項和要求。如果您選擇 `IPv6` 系列，則無法像對 `IPv4` 系列那樣，指定 Kubernetes 從中分配 `IPv6` 服務位址的位址範圍。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 Application Recovery Controller 來緩解受損的可用區域。如需詳細資訊，請參閱[了解 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 之前，建議您先熟悉 [檢視 VPC 和子網路的 Amazon EKS 聯網需求](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)。
**安全群組**:(選用) 指定一或多個您希望 Amazon EKS 與其建立的網路介面相關聯的安全群組。
無論您是否選擇任何安全群組，Amazon EKS 都會建立一個安全群組，以支援您的叢集和 VPC 之間的通訊。Amazon EKS 將此安全群組及您選擇的任何群組與其建立的網路介面相關聯。如需有關 Amazon EKS 建立的叢集安全群組的詳細資訊，請參閱 [檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md)。您可以修改 Amazon EKS 建立的叢集安全群組中的規則。
+ **選擇叢集 IP 地址系列**：您可以選擇 **IPv4** 或 **IPv6**。
預設情況下，Kubernetes 會為 Pod 和服務指派 `IPv4` 位址。在決定使用 `IPv6` 系列之前，請確認您已熟悉 [VPC 要求和考量事項](network-reqs.md#network-requirements-vpc)、[子網需求和注意事項](network-reqs.md#network-requirements-subnets)、[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md) 和 [了解叢集、Pod 與服務的 IPv6 位址](cni-ipv6.md) 主題中的所有考量事項和要求。如果您選擇 `IPv6` 系列，則無法像對 `IPv4` 系列那樣，指定 Kubernetes 從中分配 `IPv6` 服務位址的位址範圍。Kubernetes 從唯一的本地位址範圍指派服務位址 (`fc00::/7`)。
+ (選用) 選擇**設定 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 位址。
+ 針對 **Cluster endpoint access** (叢集端點存取)，選取一個選項。建立叢集後，您可以變更此選項。在選取非預設選項之前，請務必熟悉這些選項及其含義。如需詳細資訊，請參閱[叢集 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 Pod 身分識別的任何附加元件，詳見 [了解 EKS Pod 身分識別如何授予 AWS 服務的 Pod 存取權](pod-identities.md)。
完成此頁面後，請選擇**下一步**。
一些附加元件，例如 Amazon VPC CNI、CoreDNS 和 kube-proxy，是預設安裝的。如果停用任何預設附加元件，可能會影響您執行 Kubernetes 應用程式的能力。
1. 在**設定選取的附加元件設定**頁面上，選取您要安裝的版本。建立叢集後，您隨時皆可更新至更新版本。
對於支援 EKS Pod 身分的附加元件，您可以使用 主控台自動產生角色，其中包含專為附加元件預先填入的名稱、 AWS 受管政策和信任政策。您可以重複使用現有角色或為支援的附加元件建立新角色。有關使用主控台為支援 EKS Pod 身分識別的附加元件建立角色的步驟，請參閱 [建立附加元件AWS （主控台）](creating-an-add-on.md#create_add_on_console)。如果附加元件不支援 EKS Pod 身分識別，則會顯示一則訊息，指示在叢集建立後使用精靈建立服務帳戶的 IAM 角色 (IRSA)。
您可以在建立叢集後更新每個附加元件的組態。如需有關設定附加元件的詳細資訊，請參閱[更新 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)。
+ 使用帳戶 ID 取代 *111122223333*，並使用叢集 IAM 角色名稱取代 *myAmazonEKSClusterRole*。
+ 以您自己的值取代 `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。
如果您想要停用這些預設聯網附加元件的安裝，請使用以下參數。這可能用於替代 CNI，例如 Cilium。如需詳細資訊，請參閱 [EKS API 參考](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html)。
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ 如果您想指定 Kubernetes 要從哪個 `IPv4` 無類別域間路由 (CIDR) 區塊中指派服務 IP 地址，您必須將 `--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 會為 Pod 和服務指派 `IPv4` 位址。在決定使用 `IPv6` 系列之前，請確認您已熟悉 [VPC 要求和考量事項](network-reqs.md#network-requirements-vpc)、[子網需求和注意事項](network-reqs.md#network-requirements-subnets)、[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md) 和 [了解叢集、Pod 與服務的 IPv6 位址](cni-ipv6.md) 主題中的所有考量事項和要求。如果您選擇 `IPv6` 系列，則無法像對 `IPv4` 系列那樣，指定 Kubernetes 從中分配 `IPv6` 服務位址的位址範圍。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. (建議) 將叢集設定為 Kubernetes 專用 Amazon VPC CNI 外掛程式，然後再將 Amazon EC2 節點部署到叢集。預設情況下，外掛程式已隨叢集一起安裝。將 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、CoreDNS 和 Amazon EKS 附加元件`kube-proxy`的 Amazon VPC CNI 外掛程式。
如果您使用 `eksctl`或 AWS CLI 部署叢集，則會部署適用於 Kubernetes、CoreDNS 和`kube-proxy`自我管理附加元件的 Amazon VPC CNI 外掛程式。您可以將隨叢集一起部署的 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 主體。[將許可授予其他 IAM 主體](grant-k8s-access.md)，這樣他們就可以存取您的叢集。
+ 如果建立叢集的 IAM 主體僅具有先決條件中所參考的最低 IAM 許可，那麼您可能需要為該主體新增其他 Amazon EKS 許可。如需將 Amazon EKS 許可授予 IAM 主體的詳細資訊，請參閱 [Amazon EKS 的 Identity and Access Management](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 上執行大規模可擴展的 AI 工作負載、高效能運算和大規模資料處理工作負載。
根據預設，所有現有和新的 Amazon EKS 叢集都會以標準模式運作。對於需要控制平面高、可預測效能的叢集，您可以選擇使用 EKS 佈建控制平面功能。除了標準或延長支援 EKS 的每小時費用之外，還會按特定控制平面擴展方案的每小時費率向您收費。如需定價的詳細資訊，請參閱 [Amazon EKS 定價](https://aws.amazon.com/eks/pricing/)。
![\[Amazon EKS 控制平面模式\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/control-plane-modes.png)
## 使用案例
EKS 佈建控制平面旨在解決特定案例，其中高且可預測的控制平面效能對您的操作至關重要。了解這些使用案例可協助您判斷 EKS 佈建控制平面是否為適合您工作負載的解決方案。
**效能關鍵工作負載** – 對於需要 Kubernetes 控制平面最低延遲和最高效能的工作負載，EKS 佈建控制平面提供容量，可消除控制平面擴展的效能變化。
**大規模可擴展的工作負載** – 如果您執行高度可擴展的工作負載，例如 AI 訓練和推論、高效能運算，或需要大量節點在叢集中執行的大規模資料處理，佈建控制平面會提供必要的控制平面容量，以支援這些嚴苛的工作負載。
**預期的高需求事件** – 當您預期由於電子商務銷售或促銷、產品推出、假日購物季節或主要運動或娛樂活動等近期事件，控制平面請求突然激增時，佈建控制平面可讓您事先擴展控制平面容量。這種主動方法可確保您的控制平面已準備好處理增加的負載，而無需等待自動擴展來回應需求。
**環境一致性** – 佈建的控制平面可讓您在預備環境和生產環境中比對控制平面容量和效能，協助您在部署至生產環境之前及早識別潛在問題。透過跨環境維護相同的控制平面層，您可以確保測試結果準確反映生產行為，從而降低在推出期間與效能相關的意外風險。
**災難復原和業務持續性** – 對於災難復原案例，佈建的控制平面可讓您佈建與主要環境具有相同容量層級的容錯移轉環境。這可確保在容錯移轉事件期間盡可能減少中斷和快速復原，因為您的災難復原叢集在啟動時將具有與生產叢集相同的控制平面效能特性。
## 控制平面擴展層
EKS 佈建控制平面提供使用 T-shirt 大小 (XL、2XL, 4XL 和 8XL) 命名的擴展層。每個層透過三個關鍵 Kubernetes 屬性來定義其容量，這些屬性會決定叢集控制平面的效能特性。了解這些屬性可協助您為工作負載需求選取適當的層。
**API 請求並行**測量 Kubernetes 控制平面 API 伺服器可以同時處理的請求數量，這對高輸送量工作負載至關重要。
**Pod 排程率**指出預設 Kubernetes 排程器在節點上排程 Pod 的速度，以每秒 Pod 為單位。
**叢集資料庫大小**表示配置給 etcd 的儲存空間，即保留叢集狀態/中繼資料的資料庫。
當您使用佈建控制平面在特定擴展層上佈建叢集的控制平面時，EKS 可確保叢集的控制平面維持與該層對應的限制。控制平面擴展層的限制因 Kubernetes 版本而異，如下表所示。
### EKS 1.28 版和 1.29 版
| 佈建的控制平面擴展層 | API 請求並行 （座位） | Pod 排程速率 (Pod/秒） | 叢集資料庫大小 (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS 1.30 版及更新版本
| 佈建的控制平面擴展層 | API 請求並行 （座位） | Pod 排程速率 (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_tw/eks/latest/userguide/images/monitor-cluster.png)
![\[EKS 控制平面監控\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/control-plane-monitoring.png)
### 了解層容量與實際效能
當您選取佈建控制平面擴展層時，層屬性代表 Amazon EKS 套用至控制平面的基礎組態。不過，您達到的實際效能取決於您的特定工作負載模式、組態，以及對 Kubernetes 最佳實務的遵循。例如，當 4XL 層設定具有 6，800 個並行請求座位的 API Priority and Fairness (APF) 時，您從控制平面取得的實際請求輸送量取決於正在執行的操作類型。例如，Kubernetes 會對清單請求進行超過取得的懲罰，因此控制平面同時處理的清單請求有效數量低於取得請求 （請參閱[此處](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 佈建控制平面擴展層。
+ **結束限制** – 標準控制平面模式支援高達 8 GB 的叢集資料庫 （等） 大小。如果您在使用佈建模式時叢集的資料庫大小超過 8 GB，則在將資料庫大小降至低於 8 GB 之前，您無法切換回標準模式。例如，如果您在佈建模式下使用 14 GB 的資料庫儲存體，您必須先將資料庫使用率降低到低於 8GB，才能返回標準模式。
+ **無自動層擴展** – EKS 佈建控制平面不會在層之間自動擴展。選取擴展層後，叢集的控制平面仍會固定到該層，以確保一致且可預測的效能。不過，您可以透過監控層使用率指標和使用 EKS 佈建控制平面 APIs 來彈性實作自己的自動擴展解決方案，以便在您定義的指標跨越閾值時擴展或縮減規模，讓您完全控制擴展策略和成本最佳化。
+ **檢視目前層** – 您可以使用 Amazon EKS 主控台、Amazon Web Services CLI 或 API 來檢視目前的控制平面擴展層。在 CLI 中，您可以執行 `describe-cluster`命令： `aws eks describe-cluster --name cluster-name`
+ **層轉換時間** – 您可以使用 Amazon EKS 主控台、Amazon EKS APIs 或 CLI 在擴展層之間結束或移動。Amazon EKS 已推出名為 的新叢集更新類型`ScalingTierConfigUpdate`，您可以檢查以監控轉換的進度。執行層變更命令後，您可以列出叢集上的更新，以查看狀態`ScalingTierConfigUpdate`為 的 類型新更新`Updating`。狀態會在更新完成`Successful`時變更為 ，或在發生錯誤`Failed`時變更為 。更新中的錯誤欄位指出失敗的原因。您可以切換層的頻率沒有限制。變更控制平面層需要幾分鐘的時間才能完成。在此過程中不會停機 API 伺服器，因為 EKS 會在終止舊伺服器之前啟動新的 API 伺服器。
+ **選取最佳方案** – 若要判斷叢集的最佳佈建控制平面擴展方案，您可以透過在最高方案 (8XL) 上佈建叢集來執行負載測試。然後執行負載測試來模擬叢集控制平面上的尖峰需求。在尖峰負載時觀察控制平面層使用率指標，並使用這些觀察做為引導因素，為佈建模式選取適當的層。
+ **佈建控制平面定價** – 將按您叢集所在的佈建控制平面擴展方案的每小時費率向您收費。這是標準或延長支援每小時費用以外的費用。如需詳細資訊，請參閱 Amazon EKS 定價[頁面](https://aws.amazon.com/eks/pricing/)。
+ **較大的擴展層** – 如果您想要在大於 8XL 的擴展層上執行叢集，請聯絡您的 Amazon Web Services 帳戶團隊以取得其他定價資訊。
+ **Kubernetes 版本和區域支援** – 所有 Amazon Web Services 商業、 GovCloud 和中國區域都支援 EKS 佈建控制平面。佈建的控制平面適用於 EKS v1.28 及更高版本。
# Amazon EKS 佈建控制平面入門
本指南會逐步解說使用 AWS CLI 和 設定和使用 EKS 佈建控制平面的步驟 AWS 管理主控台。
## 先決條件
開始前，請確保您具備以下條件：
+ ** AWS CLI** – 用於使用 AWS 服務的命令列工具，包括 Amazon EKS。如需詳細資訊，請參閱《 * AWS 命令列界面使用者指南*》中的[安裝](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。安裝 CLI AWS 之後，建議您也進行設定。如需詳細資訊，請參閱《 * AWS 命令列界面使用者指南*》中的[具有 aws 設定的快速組態](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。請注意，使用此頁面中顯示的 **update-kubeconfig** 選項需要 AWS CLI v2。
+ **所需的 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. 選擇 **Create Cluster** (建立叢集)。
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 上對更新叢集版本強制執行升級洞察的臨時復原](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 通訊、kubectl 命令 (如 exec 和 logs) 等的組態問題。組態洞見會發現問題並提供修復建議，從而加速實現功能完整的混合節點設定。
## 開始使用
如需查看 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 SDKs和 Amazon EKS `ListInsights` API 操作。
## 檢視組態洞察 (主控台)
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 從叢集清單中，選擇您想要查看其相關洞察之 Amazon EKS 叢集的名稱。
1. 選擇**監控叢集**。
1. 選擇**叢集運作狀態**索引標籤。
1. 在**組態洞察**資料表中，您將看到以下各欄：
+ **名稱**：Amazon EKS 對叢集執行的檢查。
+ **洞察狀態** – 洞察狀態為 `Error`，意味著組態錯誤很可能會影響叢集功能。洞察狀態為 `Warning`，意味著組態與記錄的方法不相符，但若您有意設定，則叢集功能可能會運作。洞察狀態為 `Passing`，意味著 Amazon EKS 在此洞察檢查中未發現叢集中存在任何問題。
+ **版本** – 適用的版本。
+ **上次重新整理時間** – 上次重新整理此叢集的洞察狀態的時間。
+ **描述**：來自洞察檢查的資訊，其中包括提醒和建議的補救措施。
## 檢視升級洞察 (主控台)
1. 開啟 [Amazon EKS 主控台](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. 如需檢視最新資料，重新整理指定叢集的洞察。視需要對命令進行下列修改，然後執行修改後的命令。
+ 使用您區域的程式碼取代 AWS *region-code*。
+ 使用您叢集的名稱取代 *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. 列示指定叢集的洞察。視需要對命令進行下列修改，然後執行修改後的命令。
+ 使用您區域的程式碼取代 AWS *region-code*。
+ 使用您叢集的名稱取代 *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. 如需洞察的描述性資訊，執行以下命令。視需要對命令進行下列修改，然後執行修改後的命令。
+ 使用您區域的程式碼取代 AWS *region-code*。
+ 使用從列示叢集洞察的清單中擷取的洞察 ID 來取代 *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222*。
+ 使用您叢集的名稱取代 *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 叢集更新至最新版本。
**重要**
一旦升級叢集，您就無法降級至先前的版本。建議您先檢閱[了解 EKS 上的 Kubernetes 版本生命週期](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)中的資訊，以及本主題中的更新步驟，再更新至全新 Kubernetes 版本。
新的 Kubernetes 版本有時會加入重大變更。新的 Kubernetes 版本加入了重大變更，因此推薦您在生產叢集執行更新之前，先針對新的 Kubernetes 版本測試您應用程式的行為。若要達成此目標，您可以在移至新的 Kubernetes 版本之前，先建置持續的整合工作流程來測試應用程式行為。
更新程序包括 Amazon EKS 啟動新的 API 伺服器節點，並使用更新的 Kubernetes 版本取代現有的節點。Amazon EKS 會針對這些新節點的網路流量執行標準的基礎結構和整備運作狀態檢查，以確認新節點如同預期順利運作。然而，一旦開始叢集升級，您就無法暫停或停止升級。如果檢查有失敗，Amazon EKS 會還原基礎設施部署，之前的 Kubernetes 版本仍然保留您的叢集。執行中的應用程式不會受到影響，您的叢集絕對不會處於非確定性或無法恢復狀態。Amazon EKS 會定期備份所有受管叢集，並且具備在必要時復原叢集的機制。我們會持續評估和改善 Kubernetes 基礎結構管理程序。
若要更新叢集，Amazon EKS 最多需要五個來自子網的可用 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 最佳實務指南》中的[叢集升級最佳實務](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)。此資源可協助您規劃升級，以及了解升級叢集的策略。
## Amazon EKS 自動模式的考量事項
+ Amazon EKS 自動模式的運算功能可控制節點的 Kubernetes 版本。在升級控制平面之後，EKS 自動模式將開始逐步更新受管節點。EKS 自動模式遵守 Pod 中斷預算。
+ 您無須手動升級 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 版本升級清單來自動掃描叢集，例如棄用 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 Version and Version Skew Support Policy](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver) (Kubernetes 版本和 版本差異支援政策)。假設您目前的叢集版本是版本 `1.28`，並且您想要將其更新為版本 `1.30`。您必須先將您的版本 `1.28` 叢集更新為版本 `1.29`，再將版本 `1.29` 叢集更新為版本 `1.30`。
+ 請檢閱節點上 Kubernetes `kube-apiserver` 和 `kubelet` 之間的版本差異。
+ 從 Kubernetes `1.28` 版開始，`kubelet` 最多可能比 `kube-apiserver` 低三個次要版本。請參閱 [Kubernetes upstream version skew policy](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.26`、`1.27` 或 `1.28`
+ 作為最佳實務，在開始更新之前，請確認節點上的 `kubelet` 與控制平面的 Kubernetes 版本相同。
+ 如果您的叢集設定的適用於 Kubernetes 的 Amazon VPC CNI 外掛程式版本比 `1.8.0` 還舊，則建議您將外掛程式更新至最新版本，然後再更新您的叢集。若要更新外掛程式，請參閱 [使用 Amazon VPC CNI 將 IP 指派給 Pod](managing-vpc-cni.md)。
+ 您可以備份 Amazon EKS 叢集，以便在升級程序失敗時還原 Amazon EKS 叢集狀態和持久性儲存。請參閱 [使用 Backup AWS 備份 EKS 叢集](integration-backup.md)
## 步驟 3：更新叢集控制平面
**重要**
Amazon EKS 已臨時復原一項功能，若發生特定叢集洞察問題，會要求您使用 `--force` 標誌來升級叢集。如需詳細資訊，請參閱 [GitHub 上對更新叢集版本強制執行升級洞察的臨時復原](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. 使用以下 CLI 命令更新您的 Amazon EKS AWS 叢集。取代您想要升級的叢集的 `` 及 ``。使用您要更新叢集的 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. 在網頁瀏覽器中開啟 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、CoreDNS 及 `kube-proxy` 附加元件的 Amazon VPC CNI 外掛程式。建議您將附加元件更新為[服務帳戶字符](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions)中列出的最低版本。
+ 如果您正在使用 Amazon EKS 附加元件，請在 Amazon EKS 主控台中選取 **Clusters** (叢集)，然後在左導覽窗格中選取您已更新的叢集名稱。通知會顯示在主控台。它們會通知您每個有可用更新的附加元件有新的可用版本。若要更新附加元件，請選擇 **Add-ons** (附加元件) 標籤。在具有可用更新之附加元件的其中一個方塊中，選取 **Update now** (立即更新)，選取可用的版本，然後選取 **Update** (更新)。
+ 或者，您可以使用 AWS CLI 或 `eksctl` 來更新附加元件。如需詳細資訊，請參閱[更新 Amazon EKS 附加元件](updating-an-add-on.md)。
1. 如有必要，請更新您的 `kubectl` 版本。您所使用的 `kubectl` 版本，必須與 Amazon EKS 叢集控制平面的版本差距在一個版本以內。
## 升級適用於 Amazon EKS 叢集的 Kubernetes 版本
您無法對 Amazon EKS 叢集的 Kubernetes 降級。取而代之的是，在之前的 Amazon EKS 版本上建立新的叢集，然後移轉工作負載。
# 刪除叢集
當您完成使用 Amazon EKS 叢集後，應刪除與之相關聯的資源，才不會產生任何不必要的成本。
您可以使用 `eksctl`、 AWS 管理主控台或 CLI AWS 刪除叢集。
## 考量事項
+ 如果由於已移除叢集建立者而收到錯誤，請參閱[此篇文章](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error)來解決問題。
+ 叢集生命週期不包括適用於 Prometheus 的 Amazon Managed Service 資源，需要獨立於叢集進行維護。刪除叢集後，確認亦同時刪除任何適用的湊集器，以免產生適用的費用。如需詳細資訊，請參閱 *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. 同時刪除任何輸入資源。如果您不刪除傳入資源，即使您刪除叢集，應用程式負載平衡器仍會保留。將 *inress-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. 刪除所有[自我管理的 node 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** (s刪除堆疊) 確認對話方塊中，選擇 **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. 刪除所有[自我管理的 node 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. 使用以下命令，將 *my-vpc-stack* 替換為您的 VPC 堆疊名稱以刪除 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 伺服器端點對網際網路是公有的，並且會使用 AWS Identity and Access Management (IAM) 和原生 Kubernetes [角色型存取控制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) 的組合來保護對 API 伺服器的存取。此端點稱為*叢集公有端點*。此外還有一個*叢集私有端點*。有關叢集私有端點的更多資訊，請參閱以下章節 [叢集私有端點](#cluster-endpoint-private)。
## `IPv6` 叢集端點格式
對於 2024 年 10 月之後建立的新 `IPv6` 叢集，EKS 會以下列格式建立唯一的雙堆疊端點。*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` 叢集的詳細資訊，請參閱 [了解叢集、Pod 與服務的 IPv6 位址](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。您可以限制可以從網際網路存取 API 伺服器的 IP 地址，或完全停用對 API 伺服器的網際網路存取。
**注意**
由於此端點適用於 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 伺服器端點存取組合及其相關的行為。
| 端點公有存取 | 端點私有存取 | Behavior (行為) |
| --- | --- | --- |
| 已啟用 | Disabled | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/cluster-endpoint.html) |
| 已啟用 | 已啟用 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/cluster-endpoint.html) |
| Disabled | 已啟用 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/cluster-endpoint.html) |
**端點存取控制**
請注意，下列每個控制端點存取的方法只會影響個別的端點。
*叢集安全群組*
叢集安全群組控制兩種類型的連線：連線至 *kubelet API* 和私有端點。API 的連線`kubelet`用於 `kubectl attach`、`kubectl cp`、`kubectl logs`、 `kubectl exec`和 `kubectl port-forward`命令。叢集安全群組不會影響公有端點。
*公開存取 CIDRs*
*公有存取 CIDRs* 會依 CIDR 區塊清單控制對公有端點的存取。請注意，公有存取 CIDRs不會影響私有端點。公有存取 CIDRs 在`IPv6`叢集和`IPv4`叢集上的行為，取決於其建立日期，以下說明：
**公有端點中的 CIDR 區塊 (`IPv6` 叢集) **
您可以將 `IPv6` 和 `IPv4` CIDR 區塊新增至 `IPv6` 叢集的公有端點，因為該公有端點是雙重堆疊的。這僅適用於 2024 年 10 月或之後建立的、`ipFamily` 設定為 `IPv6` 的新叢集。您可以透過新的端點網域名稱 `api.aws` 來識別這些叢集。
**公有端點中的 CIDR 區塊 (`IPv4` 叢集) **
您可以將 `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 傳輸閘道](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 登入資料，或在移除端點公開存取之前，將堡壘將使用的 [IAM 主體](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)新增至 RBAC 組態。如需詳細資訊，請參閱[授予 IAM 使用者和角色對 Kubernetes APIs存取權](grant-k8s-access.md)及[未經授權或存取遭拒 (`kubectl`)](troubleshooting.md#unauthorized)。
** AWS Cloud9 IDE**
AWS Cloud9 是以雲端為基礎的整合式開發環境 (IDE)，可讓您使用瀏覽器撰寫、執行和偵錯程式碼。您可以在叢集的 VPC 中建立 an AWS Cloud9 IDE，並使用 IDE 與叢集通訊。如需詳細資訊，請參閱[在 AWS Cloud9 中建立環境](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html)。您必須確認 Amazon EKS 控制平面安全群組包含的規則允許連接埠 443 上來自 IDE 安全群組的傳入流量。如需詳細資訊，請參閱[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md)。
當您`kubectl`為 AWS Cloud9 IDE 設定 時，請務必使用已映射至叢集 RBAC 組態的 AWS 登入資料，或在移除端點公開存取之前，將 IDE 將使用的 IAM 主體新增至 RBAC 組態。如需詳細資訊，請參閱[授予 IAM 使用者和角色對 Kubernetes APIs存取權](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 管理主控台 或 CLI AWS 修改叢集 API 伺服器端點存取。
## 設定端點存取 - AWS 主控台
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇叢集名稱以顯示您叢集的資訊。
1. 選擇**聯網**索引標籤，然後選擇**管理端點存取**。
1. 對於 **Private access** (私有存取)，選擇是否啟用或停用您叢集的 Kubernetes API 伺服器端點的私有存取。如果您啟用私有存取，源自於您叢集的 VPC 的 Kubernetes API 將使用私有 VPC 端點。您必須啟用私有存取，才能停用公有存取。
1. 對於 **Public access** (公有存取)，選擇是否啟用或停用您叢集的 Kubernetes API 伺服器端點的公有存取。若您停用公有存取，您叢集的 Kubernetes API 伺服器僅可接收來自叢集 VPC 內的請求。
1. (選用) 如果您已啟用 **Public access** (公開存取)，則可指定網際網路可用來與公有端點通訊的位址。選取 **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 伺服器端點會接收來自所有 `IPv4` (`0.0.0.0/0`) IP 位址的要求，此外對於雙重堆疊 `IPv6` 叢集，還會接受來自 `IPv6` (`::/0`) 的要求。如果您使用 CIDR 區塊限制對公有端點的存取，則建議您也啟用私有端點存取，以便節點和 Fargate Pods (如果您使用它們) 可與叢集通訊。若不啟用私有端點，您的公有存取端點 CIDR 來源必須包含來自 VPC 的輸出來源。例如，如果您的私有子網路中有節點，透過 NAT 閘道與網際網路通訊，則您必須將 NAT 閘道的對外 IP 地址新增至公有端點上的白名單 CIDR 區塊。
1. 選擇 **Update (更新)** 以完成操作。
## 設定端點存取 - AWS CLI
使用 CLI AWS 版本 `1.27.160` 或更新版本完成下列步驟。您可以使用 `aws --version` 來檢查您的目前版本。若要安裝或升級 AWS CLI，請參閱[安裝 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。
1. 使用以下 CLI AWS 命令更新您的叢集 API 伺服器端點存取權。替換叢集名稱和所需的端點存取值。如果您設定了 `endpointPublicAccess=true`，則可以 (選擇性地) 為 `publicAccessCidrs` 輸入單一 CIDR 區塊或以逗號分隔的 CIDR 區塊清單。區塊不能包含[預留地址](https://en.wikipedia.org/wiki/Reserved_IP_addresses)。如果您指定 CIDR 區塊，則公有 API 伺服器端點只會接收來自所列出區塊的要求。您可以指定的 CIDR 區塊有數量上限。如需詳細資訊，請參閱[檢視與管理 Amazon EKS 和 Fargate 服務配額](service-quotas.md)。如果您使用 CIDR 區塊限制對公有端點的存取，則建議您也啟用私有端點存取，以便節點和 Fargate Pods (如果您使用它們) 可以與叢集通訊。若不啟用私有端點，您的公有存取端點 CIDR 來源必須包含來自 VPC 的輸出來源。例如，如果您的私有子網路中有節點，透過 NAT 閘道與網際網路通訊，則您必須將 NAT 閘道的對外 IP 地址新增至公有端點上的白名單 CIDR 區塊。如果不指定 CIDR 區塊，則公有 API 伺服器端點會接收來自所有 (0.0.0.0/0) IP 位址的要求，此外對於雙重堆疊 `IPv6` 叢集，還會接受來自 `IPv6` (`::/0`) 的請求。
**注意**
下列命令會啟用 API 伺服器端點的私有存取以及來自單一 IP 地址的公有存取。使用單一 CIDR 區塊或您想要限制網路存取的 CIDR 區塊清單取代 *203.0.113.5/32*。
```
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 支援，以便同時執行 Linux 容器與 Windows 容器。
## 考量事項
部署 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` 事件日誌，且其限制會設定為 200 MB。
+ 您不能對在 Windows 節點上執行 Pod 使用[指派安全群組給個別 Pod](security-groups-for-pods.md)。
+ 您不能將[自訂聯網](cni-custom-network.md)與 Windows 節點搭配使用。
+ 您不能將 `IPv6` 與 Windows 節點搭配使用。
+ Windows 節點支援每個節點一個彈性網路介面。依預設，每個 Windows 節點可以執行的 Pod 數量，等於節點執行個體類型的每個彈性網路介面可用的 IP 位址數量減去一。如需詳細資訊，請參閱 *Amazon EC2 使用者指南*中的[每個執行個體類型每個網路介面的 IP 位址](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI)。
+ 在 Amazon EKS 叢集中，具有負載平衡器的單一服務最多可支援 1024 個後端 Pod。每個 Pod 都有自己的唯一 IP 地址。自 [OS Build 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4) 起的 [Windows Server 更新](https://github.com/microsoft/Windows-Containers/issues/93)後，過去的 64 個 Pod 限制已不存在。
+ Windows 容器不支援 Fargate 上的 Amazon EKS Pod。
+ 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 Authenticator 組態映射。如需詳細資訊，請參閱[指定 AMI ID 時的限制和條件](launch-templates.md#mng-ami-id-conditions)。
+ 若保留您的可用 IPv4 位址對於子網路非常重要，請參閱 [EKS 最佳實務指南 - Windows 網路 IP 位址管理](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 Chart 在叢集上安裝 VPC CNI，或作為 Amazon EKS 附加元件，可能無法直接修改 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 部署到叢集時，您需要指定在執行混合節點類型時所使用的作業系統。
對於 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 數量的能力。如需詳細資訊，請參閱[將更多 IP 位址指派給具有字首的 Amazon EKS 節點](cni-increase-ip-addresses.md)。
# 停用 Windows 支援
1. 如果叢集包含 Amazon Linux 節點，並且使用 [Pod 的安全群組](security-groups-for-pods.md)，則請跳過這個步驟。
從[叢集角色](cluster-iam-role.md)中移除 `AmazonVPCResourceController` 受管 IAM 政策。使用叢集角色名稱取代 *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 Outposts 上有本機叢集，請參閱 [在 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 物件`certificateAuthority`中 `apiServerEndpoint`和 的值取代為先前命令輸出中傳回的值。如需在啟動自我管理 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 上的 [Bootstrap 指令碼](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)。
+ 您的叢集 `aws-auth` `ConfigMap` 必須從 VPC 建立。若要進一步了解如何建立項目並將項目新增至 `aws-auth` `ConfigMap`，請在終端機中輸入 `eksctl create iamidentitymapping --help`。如果您的伺服器上不存在 `ConfigMap`，則 `eksctl` 會在您使用命令新增身分映射時建立它。
## Pod 要求
+ **Pod 身分識別** - 透過 EKS Pod 身分識別設定的 Pod 會從 EKS 驗證 API 獲取憑證。如果沒有傳出網際網路存取權，則必須針對 EKS 驗證 API 建立並使用 VPC 端點：`com.amazonaws.region-code.eks-auth`。若要了解 EKS 與 EKS 驗證 VPC 端點的相關詳細資訊，請參閱 [使用 AWS PrivateLink 存取 Amazon EKS](vpc-interface-endpoints.md)。
+ **IRSA** - 為[服務帳戶設定 IAM 角色的](iam-roles-for-service-accounts.md) Pod 會從 AWS 安全字符服務 (AWS STS) API 呼叫取得憑證。如果沒有傳出網際網路存取，您必須在 VPC 中建立和使用 AWS STS VPC 端點。大多數 AWS `v1` SDKs 預設使用全域 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)。
+ 對於 Pod 需要存取的任何 AWS 服務，叢集的 VPC 子網路必須具有 VPC 介面端點。如需詳細資訊，請參閱[使用介面 VPC 端點存取 AWS 服務](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)。下表列出了一些常用的服務和端點。如需端點的完整清單，請參閱《 [AWSAWS PrivateLink 指南》中的與PrivateLink 整合的 服務](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)。 [AWS PrivateLink ](https://docs.aws.amazon.com/vpc/latest/privatelink/)
我們建議您為 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_tw/eks/latest/userguide/private-clusters.html)
+ 任何自我管理節點都必須部署至具有您所需 VPC 介面端點的子網路。如果您建立受管節點群組，VPC 介面端點安全群組必須允許子網路的 CIDR，或者您必須將建立的節點安全群組新增至 VPC 介面端點安全群組。
+ **EFS 儲存** - 如果您的 Pod 使用 Amazon EFS 磁碟區，則必須先變更[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控制器](aws-load-balancer-controller.md)，將 AWS Application Load Balancer (ALB) 和 Network Load Balancer 部署到您的私有叢集。部署時，您應使用[命令列旗標](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags)將 `enable-shield`、`enable-waf` 和 `enable-wafv2` 設定為 false。不支援透過傳入物件的主機名稱進行[憑證探索](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host)。這是因為控制器需要連線到沒有 VPC 介面端點的 AWS Certificate Manager。
控制器支援具有 IP 目標的 Network Load Balancer，這些目標與 Fargate 一起使用。如需詳細資訊，請參閱[透過 Application Load Balancer 路由應用程式與 HTTP 流量](alb-ingress.md)及[建立 Network Load Balancer](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)。工作者節點 VPC 也必須包含 AWS STS VPC 端點和自動擴展 VPC 端點。
+ 有些容器軟體產品會使用 API 呼叫來存取 AWS Marketplace Metering Service 來監控用量。私有叢集不允許這些呼叫，因此您無法將這些容器類型用於私有叢集。
# 透過 Karpenter 與 Cluster Autoscaler 擴展叢集運算資源
自動擴展功能可自動將您的資源向內外擴展，滿足不斷變化的需求。這是 Kubernetes 的主要功能，否則需要大量人力資源才能手動執行。
## EKS 自動模式
Amazon EKS 自動模式會自動擴展叢集運算資源。若現有節點無法容納 Pod，EKS 自動模式會建立新節點。另外，EKS 自動模式也會合併工作負載，並刪除多餘節點。EKS 自動模式的實現基礎是 Karpenter。
如需詳細資訊，請參閱：
+ [利用 EKS 自動模式自動運作叢集基礎設施](automode.md)
+ [為 EKS 自動模式建立節點集區](create-node-pool.md)
+ [在 Amazon EKS 自動模式叢集中部署範例 inflate 工作負載](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 叢集中安裝、設定與管理。若在 Amazon EKS 叢集中執行未經修改的相容版本 Karpenter，AWS 將提供技術支援。與其他客戶管理的軟體相同，客戶必須確保 Karpenter 控制器的可用性與安全性，並在升級 Karpenter 或其執行所在的 Kubernetes 叢集時，執行適當的測試程序。此外，AWS 未針對 Karpenter 提供服務水準協議 (SLA)，客戶需自行確保 Karpenter 啟動的 EC2 執行個體符合其業務需求。
**Cluster Autoscaler**
當 Pod 故障或重新排程到其他節點時，Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) 會自動調整叢集中的節點數量。Cluster Autoscaler 使用 Auto Scaling 群組。如需詳細資訊，請參閱 [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 區域轉移旨在作為一項臨時措施，讓您將資源的流量遠離受損的 AZ，直到區域轉移到期或您將它取消為止。您可在必要時擴充區域轉移。
您可以為 EKS 叢集啟動區域轉移，也可以透過啟用區域自動轉移 AWS 來允許 為您轉移流量。藉助此區域轉移，可將叢集中的東向西網路流量更新為只考慮正常運作 AZ 中工作節點上執行之 Pod 的網路端點。另外，任何 ALB 或 NLB 在處理 EKS 叢集中應用程式的輸入流量時，都會將流量路由自動至運作狀態良好的可用區域中的目標。若客戶尋求實現最高可用性目標，在可用區域受損時，能夠在復原之前將所有流量從受損的可用區域移出非常重要。因此，您亦可[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_tw/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[網路流量圖解\]](http://docs.aws.amazon.com/zh_tw/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 可在節點上，使用 `iptables` 為這些 Pod 端點的每一個設定路由規則。此外，kube-proxy 還負責基本形式的負載平衡，以便重新引導目的地為服務叢集 IP 位址的流量，轉而直接傳送至 Pod 的 IP 位址。kube-proxy 可在傳出連線上重寫目的地 IP 位址，藉此來執行此操作。
1. 如先前圖表所示，隨後藉助各自節點上的 ENI，將網路封包傳送至可用區域 2 中的產品 Pod。
### 了解 Amazon EKS 中的 ARC 區域轉移
若您的環境中有可用區域受損，您可針對 EKS 叢集環境起始區域轉移。或者，您可以允許 使用區域自動轉移來 AWS 管理轉移流量。使用區域自動轉移， AWS 可監控整體 AZ 運作狀態，並透過自動將流量從叢集環境中受損的 AZ 轉移來回應潛在的 AZ 損害。
Amazon EKS 叢集使用 ARC 啟用區域轉移後，您可以使用 ARC 主控台、CLI 或區域轉移和區域自動轉移 APIs AWS 來啟動區域轉移或啟用區域自動轉移。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)則會暫停，且 Auto Scaling 群組會更新，進而確保新的 EKS 資料平面節點僅在運作狀態良好的可用區域啟動。
+ 不會終止運作狀態不佳可用區域中的節點，亦不會從節點中移出 Pod。這可確保區域轉移到期或取消時，流量可安全地返回可用區域，以便獲取完整容量。
+ EndpointSlice 控制器可在受損的可用區域中尋找全部 Pod 端點，然後從相關的 EndpointSlices 中將其移除。此操作可確保僅鎖定運作狀態良好可用區域中的 Pod 端點，來接收網路流量。若區域轉移取消或到期，EndpointSlice 控制器將更新 EndpointSlices，以便在還原的可用區域中納入這些端點。
下面的圖表提供了一個高階概觀，闡述 EKS 區域轉移如何確保叢集環境中僅鎖定運作狀態良好的 Pod 端點。
![\[網路流量圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[網路流量圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## EKS 區域轉移要求
為了將區域轉移與 EKS 成功地配合使用，必須事先設定叢集環境，以便具備復原能力應對可用區域受損。下面的清單列示了可協助確保復原能力的組態選項。
+ 跨多個可用區域佈建叢集的工作節點
+ 佈建足夠的運算容量來適應單一可用區域移除
+ 在每個可用區域預先擴展包括 CoreDNS 在內的 Pod
+ 將多個 Pod 複本分佈到所有可用區域，有助於確保從單一可用區域移出時，您仍有充足的容量
+ 在相同的可用區域主機代管相依或相關的 Pod
+ 手動啟動從可用區域區域移出，藉此測試在沒有一個可用區域的情況下，您的叢集環境是否如預期運作。或者，您可啟用區域自動轉移，以及依賴於自動轉移實際執行。手動或實際區域轉移測試，無須在 EKS 中運作區域轉移，但強烈建議這樣做。
### 跨多個可用區域佈建 EKS 工作節點
AWS 區域具有多個不同的位置，具有實體資料中心，稱為可用區域 (AZs)。設置可用區域旨在彼此進行實體隔離，以避免可能同時影響整個區域。佈建 EKS 叢集後，建議您將工作節點部署至區域中的多個可用區域。此操作有助於讓叢集環境具備更強的復原能力來應對單一可用區域受損，還可確保在其他可用區域執行的應用程式具有高可用性。開始從受影響的可用區域移出時，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_tw/eks/latest/userguide/images/zs-ha-before-failure.png)
下面的圖表闡述三個可用區域的 EKS 環境如何具備復原能力來應對可用區域受損，以及確保高可用性，因為還有兩個運作狀態良好的可用區域。
![\[網路圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/zs-ha-after-failure.png)
### 佈建足夠的運算容量來應對單一可用區域移除
如需最佳化 EKS 資料平面中運算基礎結構的資源使用率與成本，最佳實務是使運算容量符合工作負載需求。然而，**若您的所有工作節點容量已滿**，則您需要在排程新的 Pod 之前，將新的工作節點新增至 EKS 資料平面。若執行關鍵工作負載，最佳實務一般是在線上使用備援容量來執行，以便處理負載突增及節點運作狀態問題等情境。若您打算使用區域轉移，需要規劃在發生受損情況時移除整個可用區域的容量。這意味著必須調整備援運算容量，即使其中一個可用區域離線，也足以處理負載。
擴展運算資源後，需要一些時間來處理將新的節點新增至 EKS 資料平面的程序。這可能會影響應用程式的即時效能與可用性，在區域受損的情況下尤其如此。EKS 環境應能在缺少一個可用區域的情況下吸收負載，而不會導致最終使用者或用戶端的體驗降級。這意味著，需要新 Pod 與在工作節點實際排程的間隔時間，需要最大限度地減少或消除延遲。
另外，若出現區域受損，您應竭力緩解在運算容量約束條件中執行的風險，以阻止將新的必要節點新增至運作狀態良好可用區域中的 EKS 資料平面。
若要實現降低這些潛在負面影響的風險，建議您在每個可用區域的某些工作節點中過度佈建運算容量。執行此操作，Kubernetes 排程器就預先有容量可用於新 Pod 置放，在環境中缺少其中一個可用區域時尤其重要。
### 跨可用區域執行及分佈多個 Pod 複本
Kubernetes 藉由執行單一應用程式的多個執行個體 (Pod 複本)，可讓您預先擴展您的工作負載。針對應用程式執行多個 Pod 複本，能夠消除單一故障點，以及減少單一複本上的資源壓力來提高整體效能。然而，若要讓應用程式同時具備高可用性與更佳容錯能力，建議您執行應用程式的多個複本，然後將複本分佈到不同的故障網域，亦稱為拓撲網域。此情境中的故障網域為可用區域。藉助[拓撲分佈約束條件](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)，您可設定應用程式，使其具備預先存在的靜態穩定性。之後，若可用區域受損，您的環境將會在運作狀態良好的可用區域擁有足夠的複本，以便立即處理任何流量尖峰或激增。
下面的圖表闡述了 EKS 環境，在所有可用區域運作狀態良好時，該環境具有東西向流量。
![\[網路圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/zs-spread-constraints.png)
下面的圖表闡述了具有東西向流量的 EKS 環境，其中單一可用區域發生故障，並且您已開始區域轉移。
![\[網路圖解\]](http://docs.aws.amazon.com/zh_tw/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 的預設設定，若多個可用區域有可用的節點，可確保這些節點將分佈到叢集的各個可用區域。您可依據意願，使用您自己的自訂組態來取代預設設定。
若您[透過 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 繫結，可使用[水平 Pod 自動擴展器 (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 在同一工作節點或同一可用區域進行主機代管。您亦可設定排程約束條件的嚴格度。
```
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_tw/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### 測試叢集環境是否可應對可用區域缺失
在完成前面章節所述的要求之後，下一步是測試是否有充足的運算和工作負載容量來應對可用區域缺失。您可在 EKS 中，手動啟動區域轉移來執行此動作。或者，您可啟用區域自動轉移及設定實際執行，這亦會測試在叢集環境缺少一個可用區域的情況下，應用程式是否如預期運作。
## 常見問答集
**這項功能有什麼用？**
藉由在您的 EKS 叢集中使用 ARC 區域轉移或區域自動轉移，您可自動執行從受損的可用區域移出叢集內網路流量的快速復原程序，以便更好地確保 Kubernetes 應用程式可用性。藉助 ARC，在發生受損可用區域事件期間，您可避免可能引起延長復原時段的冗長且複雜的步驟。
**此功能如何與其他 AWS 服務搭配使用？**
EKS 與 ARC 整合，可提供您完成復原操作的主要界面 AWS。若要確保叢集內流量從受損的可用區域適當移出，EKS 會對執行於 Kubernetes 資料平面的 Pod 的網路端點清單做出修改。若您使用 Elastic Load Balancing，將外部流量路由至叢集，可在 ARC 註冊負載平衡器，然後在這些負載平衡器上開始區域轉移，來阻止流量流入降級的可用區域。此外，區域轉移還適用於 EKS 受管節點群組建立的 Amazon EC2 Auto Scaling 群組。若要阻止受損的可用區域用於新的 Kubernetes Pod 或節點啟動，EKS 會從 Auto Scaling 群組中移除受損的可用區域。
**此功能與預設 Kubernetes 防護有何差異？**
此功能可與若干 Kubernetes 內建防護功能配合使用，可協助客戶確保應用程式的復原能力。您可設定 Pod 整備與存活探查，來決定 Pod 應接收流量的時間。若這些探查失敗，Kubernetes 會將這些 Pod 作為服務目標進行移除，並且不再將流量傳送至 Pod。雖然這很實用，但客戶設定這些運作狀態檢查並不容易，因此若可用區域降級，需要保證這些探查會失敗。ARC 區域轉移功能提供了額外的安全網路，若 Kubernetes 的原生保護不足，它能協助您完全隔離降級的可用區域。此外，區域轉移還為您提供了一種簡便的方式，來測試架構的運作整備與復原能力。
**可以代表我 AWS 開始區域轉移嗎？**
是，若您需要以全自動化方式使用 ARC 區域轉移，您可啟用 ARC 區域自動轉移。透過區域自動轉移，您可以依賴 AWS 來監控 EKS 叢集的AZs運作狀態，並在偵測到可用區域受損時自動啟動區域轉移。
**若我使用此功能，並且工作節點與工作負載未預先擴展，會發生什麼？**
若您未預先調整擴展，並且在區域轉移期間依賴於佈建額外的節點或 Pod，則有延遲復原的風險。新增節點至 Kubernetes 資料平面的程序需要一些時間，這可能會影響應用程式的即時效能與可用性，在區域受損時尤其如此。另外，若發生區域受損，您可能會遇到運算容量約束，這可能會阻止新的必要節點新增至運作狀態良好的可用區域。
若工作負載未預先擴展，並且分佈到叢集中的所有可用區域，對於僅執行於受影響可用區域中工作節點的應用程式，區域受損可能會影響其可用性。當工作負載在運作狀態不佳的可用區域擁有全部端點的情況下，若要緩解應用程式可用性完全中斷的風險，EKS 設置有失效安全機制，來將流量傳送至受損區域的 Pod 端點。然而，強烈建議您預先擴展應用程式，然後將其分佈到所有可用區域，以便在發生區域問題時確保可用性。
**若我執行具狀態應用程式，會如何運作？**
若您正在執行具狀態應用程式，必須依據您的使用案例和架構來評估其容錯能力。若您有作用中/待命架構或模式，可能會有作用中執行個體位於受損的可用區域。若在應用程式層級未啟用待命，執行時可能會遇到應用程式問題。若在運作狀態良好的可用區域啟動新的 Kubernetes Pod，可能會遇到問題，因為這些 Pod 無法連接至已繫結受損可用區域的持續性磁碟區。
**此功能是否可與 Karpenter 配合使用？**
EKS 中的 ARC 區域轉移與區域自動轉移目前不提供 Karpenter 支援。若可用區域受損，您可移除運作狀態不佳的可用區域，藉此來調整相關的 Karpenter NodePool 組態，以便僅在其他可用區域啟動新的工作節點。
**此功能是否可與 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)
+ [為高 DNS 流量擴展 CoreDNS Pod](coredns-autoscaling.md)
# 啟用 EKS 區域轉移來避免可用區域受損
Amazon 應用程式復原控制器 (ARC) 可協助您管理及協調跨可用區域 (AZ) 進行應用程式復原，並且可搭配包括 Amazon EKS 在內的多項服務一起使用。憑藉 ARC 區域轉移的 EKS 支援，您可從受損的可用區域轉移叢集內的網路流量。您也可以授權 AWS 監控 AZs 的運作狀態，並代表您暫時將網路流量移離運作狀態不佳的 AZ。
**EKS 區域轉移運作方式：**
1. 透過 Amazon 應用程式復原控制器 (ARC) 啟用 EKS 叢集。這會在叢集層級使用 Amazon EKS 主控台、CLI、CloudFormation AWS 或 eksctl 完成。
1. 啟用後，您可以使用 ARC 主控台、 AWS CLI 或區域轉移和區域自動轉移 APIs 來管理區域轉移或區域自動轉移。
請注意，在 ARC 註冊 EKS 叢集之後，您仍需設定 ARC。舉例來說，您可藉助 ARC 主控台來設定區域自動轉移。
若要了解 EKS 區域轉移運作方式，以及如何設計工作負載來處理受損可用區域的相關詳細資訊，請參閱 [了解 Amazon EKS 中的 Amazon 應用程式復原控制器 (ARC) 區域轉移](zone-shift.md)。
## 考量事項
+ EKS 自動模式不支援 Amazon 應用程式復原控制器、區域轉移和區域自動轉移。
+ 建議在各項區域轉移操作間等候至少 60 秒，以確認每項請求均得到適當處理。
嘗試以快速、連續的方式執行區域轉移時 (相隔 60 秒內)，Amazon EKS 服務可能無法適當處理所有請求輪次。這是由於目前更新叢集區域狀態的輪詢機制所致。若您需要執行多次區域轉移，確認系統在各項操作間留有充足的時間來處理每項變更。
## 什麼是 Amazon 應用程式復原控制器？
Amazon 應用程式復原控制器 (ARC) 可協助您針對執行於 AWS的應用程式做好準備，以及加速完成復原。區域轉移可讓您從可用區域 (AZ) 受損快速復原，方法是暫時將支援資源的流量從可用區域移出至 AWS 區域中運作狀態良好的AZs。
[進一步了解 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 將流量從 AZ 轉移到 AWS 區域中運作狀態良好的 AZs。當內部遙測顯示 區域中的一個 AZ 受損，而可能影響客戶時， 會 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 Application Recovery Controller (ARC) 註冊 EKS 叢集AWS （主控台）
1. 找到在 ARC 註冊的 EKS 叢集名稱與區域。
1. 導覽至該區域的 [EKS 主控台](https://console.aws.amazon.com/eks)，然後選取您的叢集。
1. 在**叢集資訊**頁面上，選取**概觀**索引標籤。
1. 在**區域轉移**標題項下，選取**管理**按鈕。
1. 針對 *EKS 區域轉移*，選取**啟用**或**停用**。
現在即可在 ARC 註冊 EKS 叢集。
如果您想要 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)。