**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 利用 EKS 自動模式自動運作叢集基礎設施
**提示**
[註冊](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)即將舉行的 Amazon EKS Auto Mode 研討會。
EKS Auto Mode 會將 Kubernetes 叢集的 AWS 管理延伸到叢集本身之外， AWS 以允許 也設定和管理基礎設施，讓工作負載能夠順暢地運作。您可以委派關鍵基礎設施決策，並利用 的專業知識 AWS 進行day-to-day操作。管理的叢集基礎設施 AWS 包含許多 Kubernetes 功能作為核心元件，而不是附加元件，例如運算自動擴展、Pod 和服務聯網、應用程式負載平衡、叢集 DNS、區塊儲存和 GPU 支援。
若要開始使用，您可部署新的 EKS 自動模式叢集，也可在現有叢集上啟用 EKS Auto Mode。您可以使用 eksctl、 AWS CLI、、EKS APIs 或您偏好的基礎設施即程式碼工具來部署、升級或修改 AWS 管理主控台 EKS Auto Mode 叢集。 infrastructure-as-code
在 EKS 自動模式中，您仍可繼續使用偏好的 Kubernetes 相容工具。EKS Auto Mode 會與 Amazon EC2、Amazon EBS 和 ELB 等 AWS 服務整合，利用遵循最佳實務的 AWS 雲端資源。這些資源會自動擴展、最佳化成本，並定期更新，協助最大限度降低營運成本與負荷。
## 功能
EKS 自動模式提供以下進階功能：
**簡化 Kubernetes 叢集管理**：EKS 自動模式提供可直接用於生產環境的叢集，並將營運負荷降至最低，藉此簡化 EKS 管理流程。透過 EKS 自動模式，即使缺乏深厚的 EKS 專業知識，您也能安心執行高需求、動態的工作負載。
**應用程式可用性**：EKS 自動模式依據 Kubernetes 應用程式的需求，動態新增或移除 EKS 叢集中的節點。這能減少手動容量規劃的需求，並確保應用程式的可用性。
**效率優化**：EKS 自動模式的設計目標是在符合您的 NodePool 與工作負載需求所定義的彈性範圍內，最佳化運算成本。它還會終止未使用的執行個體，並將工作負載整合到其他節點，以提升成本效率。
**安全性強化**：EKS 自動模式使用被視為不可變的 AMI 來供您的節點使用。這類 AMI 會強制執行鎖定的軟體設定、啟用 SELinux 強制存取控制，並提供唯讀的根檔案系統。此外，由 EKS 自動模式啟動的節點有最長 21 天的生命週期 (您可縮短此期限)，期滿後會自動被新節點取代。此機制透過定期更換節點增強安全狀態，與許多客戶已採用的最佳實務一致。
**自動化升級**：EKS 自動模式會確保您的 Kubernetes 叢集、節點及相關元件保持最新修補程式版本，同時尊重您設定的 Pod 中斷預算 (PDB) 和 NodePool 中斷預算 (NDB)。在最長 21 天的生命週期內，若有阻斷性的 PDB 或其他設定妨礙更新，可能需要手動介入。
**受管元件**：EKS Auto Mode 包含 Kubernetes 和 AWS 雲端功能作為核心元件，否則必須作為附加元件進行管理。其中包括對 Pod IP 位址指派、Pod 網路政策、本機 DNS 服務、GPU 外掛程式、運作狀態檢查程式及 EBS CSI 儲存的內建支援。
**可自訂的 NodePool 與 NodeClass**：若您的工作負載需要變更儲存、運算或聯網設定，可透過 EKS 自動模式建立自訂的 NodePool 與 NodeClass。雖然不建議編輯預設的 NodePool 與 NodeClass，但您可在預設設定之外新增自訂的 NodePool 或 NodeClass，以符合特定需求。
## 自動化元件
EKS 自動模式透過自動化關鍵基礎結構元件，簡化 Amazon EKS 叢集的操作。啟用 EKS 自動模式後，管理 EKS 叢集的任務將進一步減少。
下列是已實現自動化的資料平面元件清單：
+ **運算**：對於多數工作負載，透過 EKS 自動模式，您無需關注 EKS 叢集運算層面的許多細節。其中包含：
+ **節點**：EKS 自動模式節點的設計理念是將其視為專用設備來處理。EKS 自動模式會執行下列作業：
+ 選擇合適的 AMI，該 AMI 已預先設定執行工作負載所需的多項服務，無需介入。
+ 透過 SELinux 強制模式與唯讀根檔案系統，鎖定 AMI 上的檔案存取權；
+ 禁止 SSH 或 SSM 存取，防止直接存取節點；
+ 包含 GPU 支援，提供適用於 NVIDIA 與 Neuron GPU 的獨立核心驅動程式與外掛程式，支援高效能工作負載；
+ 自動處理 [EC2 Spot 執行個體中斷通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)與 EC2 執行個體運作狀態事件
+ **自動擴展**：EKS 自動模式依賴 [Karpenter](https://karpenter.sh/docs/) 自動擴展功能，監控無法排程的 Pod，並部署新節點來執行這些 Pod。當工作負載終止時，EKS 自動模式會在節點不再需要時動態中斷並終止節點，最佳化資源使用率。
+ **升級**：透過掌控節點，EKS 自動模式能更順暢地提供安全性修補程式，以及必要的作業系統與元件升級。這些升級的設計旨在將工作負載的中斷降至最低。EKS 自動模式會強制執行最長 21 天的節點生命週期，確保軟體與 API 保持最新。
+ **負載平衡**：EKS 自動模式透過與 Amazon Elastic Load Balancing 服務整合，簡化負載平衡流程，自動為 Kubernetes Service 與 Ingress 資源佈建並設定負載平衡器。它支援 Application 與 Network Load Balancer 的進階功能、管理其生命週期，並根據叢集需求進行擴展。此整合提供符合 AWS 最佳實務的生產就緒負載平衡解決方案，可讓您專注於應用程式，而非基礎設施管理。
+ **儲存**：EKS 自動模式會為您設定暫時性儲存，包括設定磁碟區類型、磁碟區大小、加密政策，以及節點終止時的刪除原則。
+ **聯網**：EKS 自動模式會自動化 Pod 與服務連線所需的關鍵聯網作業。其中包括支援 IPv4/IPv6 協定，以及使用次要 CIDR 區塊來擴展 IP 位址空間。
+ **Identity and Access Management**：您無需在 EKS 自動模式叢集上安裝 EKS Pod 身分識別代理程式。
有關這些元件的更多資訊，請參閱 [了解 EKS 自動模式的運作方式](auto-reference.md)。
## Configuration
儘管 EKS 自動模式能在無需您介入的情況下，有效管理大部分資料平面服務，但有時您可能需要調整部分服務的運作行為。您可透過下列方式修改 EKS 自動模式叢集的組態：
+ **Kubernetes DaemonSets**：無需修改安裝在節點上的服務，您可改用 Kubernetes DaemonSet。DaemonSet 專為由 Kubernetes 管理而設計，但會在叢集中的每個節點上執行。過這種方式，您可新增用於監控或其他節點管理場景的專用服務。
+ **自訂 NodePool 與 NodeClass**：預設 NodePool 和 NodeClass 由 EKS 自動模式設定，不建議自行編輯。要自訂節點行為，可針對以下使用案例建立額外的 NodePool 或 NodeClass，例如：
+ 選取特定執行個體類型 (例如，加速處理器或 EC2 Spot 執行個體)。
+ 隔離工作負載，以達成安全性或成本追蹤目的。
+ 設定暫時性儲存設定，如 IOPS、大小和輸送量。
+ **負載平衡**：EKS 自動模式會將部分服務 (如負載平衡) 作為 Kubernetes 物件執行，這類服務可直接在 EKS 自動模式叢集上進行設定。
如需設定 EKS 自動模式的詳細資訊，請參閱 [進行 EKS 自動模式設定](settings-auto.md)。
## 共同責任模型
AWS 共同責任模型定義 AWS 和 客戶之間的安全與合規責任。以下影像和文字會比較和對比 EKS Auto Mode AWS 和 EKS 標準模式之間的客戶和責任差異。
![\[EKS 自動模式與標準模式的共用責任模型\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/eksautosrm.png)
EKS 自動模式將 Kubernetes 基礎結構的大部分共用責任從客戶轉移至 AWS。透過 EKS Auto Mode， AWS 承擔更多雲端安全的責任，這曾經是客戶的責任，現在已共同承擔。客戶現在可以更專注於其應用程式，同時 AWS 管理基礎基礎設施。
**客戶責任**
在 EKS 自動模式下，客戶仍需負責應用程式容器的相關事務，包括容器的可用性、安全性與監控。此外，客戶也需掌控 VPC 基礎結構與 EKS 叢集組態的核心設定。此模型可讓客戶在委派叢集基礎設施管理給 時，專注於應用程式特定的考量 AWS。每個節點的選用功能可以透過 AWS 附加元件包含在叢集中。
** AWS 責任**
使用 EKS Auto Mode 時， AWS 擴展其責任，包括與已在未使用 Auto Mode 的 EKS 叢集中管理的元件相比，管理幾個額外的關鍵元件。具體而言，EKS 自動模式會接管以下事務：由其啟動的 EC2 執行個體之設定、管理、安全性與擴展，以及叢集在負載平衡、IP 位址管理、聯網原則與區塊儲存方面的功能。下列元件由 AWS 以 EKS Auto 模式管理：
+ **自動模式啟動的 EC2 執行個體**：利用 Amazon EC2 受管執行個體 AWS 來處理節點的完整生命週期。EC2 受管執行個體負責作業系統組態、修補、監控與運作狀態維護。在此模型中，執行個體本身及其上執行的來賓作業系統均由 AWS負責。這些節點使用專為執行容器而最佳化的 [Bottlerocket](https://aws.amazon.com/bottlerocket) AMI 變體。Bottlerocket AMI 具備軟體鎖定、不可變根檔案系統，以及安全網路存取 (防止透過 SSH 或 SSM 直接連線) 等特性。
+ **Cluster Capabilities**： AWS 管理運算自動擴展、具有網路政策強制執行的 Pod 聯網、Elastic Load Balancing 整合和儲存驅動程式組態。
+ **叢集控制平面**： AWS 繼續管理 Kubernetes API 伺服器、跨帳戶 ENIs 和 等資料庫，如同標準 EKS。
+ **Foundation Services 和全球基礎設施**： AWS 負責基礎運算、儲存、聯網和監控服務，以及區域、本機區域和節點的全球基礎設施。
# 使用 Amazon EKS 自動模式建立叢集
本章節闡釋如何使用各種工具和介面建立已啟用自動模式的 Amazon EKS 叢集。自動模式透過自動設定與管理叢集的運算、聯網及儲存基礎結構，簡化了叢集建立過程。您將了解如何使用 AWS CLI、AWS 管理主控台 或 eksctl 命令列工具來建立自動模式叢集。
**注意**
EKS 自動模式需要 Kubernetes 版本 1.29 或以上。
請根據您的需求選擇合適的工具：AWS 管理主控台 提供視覺化介面，非常適合了解 EKS 自動模式功能和建立單獨叢集。AWS CLI 最適合用於指令碼編寫和自動化任務，特別是將叢集建立整合到現有工作流程或 CI/CD 管道時。eksctl CLI 提供了 Kubernetes 原生的體驗，推薦給熟悉 Kubernetes 工具並希望使用合理的預設值來簡化命令列操作的使用者。
開始之前，請確定您已安裝並設定必要先決條件，包括建立 EKS 叢集的適當 IAM 許可。要了解如何安裝 CLI 工具，例如 `kubectl`、`aws` 和 `eksctl`，請參閱 [設定以使用 Amazon EKS](setting-up.md)。
您可以使用 AWS CLI、AWS 管理主控台 或 eksctl CLI 來建立具有 Amazon EKS 自動模式的叢集。
**Topics**
+ [使用 eksctl CLI 建立 EKS 自動模式叢集](automode-get-started-eksctl.md)
+ [使用 CLI AWS 建立 EKS 自動模式叢集](automode-get-started-cli.md)
+ [使用 建立 EKS 自動模式叢集 AWS 管理主控台](automode-get-started-console.md)
# 使用 eksctl CLI 建立 EKS 自動模式叢集
本主題展示如何使用 eksctl 命令列介面 (CLI) 建立 Amazon EKS 自動模式叢集。您可以透過執行單一 CLI 命令或套用 YAML 組態檔案來建立自動模式叢集。兩種方法提供相同的功能，其中 YAML 方法能對叢集設定提供更細緻的控制。
eksctl CLI 透過處理基礎 AWS 資源建立和組態，簡化建立和管理 EKS Auto Mode 叢集的程序。在繼續之前，請確定您已在本機電腦上設定必要的 AWS 登入資料和許可。本指南假設您熟悉基本的 Amazon EKS 概念，並且已安裝必要的 CLI 工具。
**注意**
您必須安裝 `0.195.0` 或更高版本的 eksctl。如需詳細資訊，請參閱 GitHub 上的 [eksctl 版本](https://github.com/eksctl-io/eksctl/releases)。
## 使用 CLI 命令建立 EKS 自動模式叢集
您必須已安裝 `aws` 和 `eksctl` 工具。您必須以足夠的許可登入 AWS CLI，才能管理 AWS 資源，包括：EC2 執行個體、EC2 聯網、EKS 叢集和 IAM 角色。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
執行下列命令，建立新的 EKS 自動模式叢集
```
eksctl create cluster --name= --enable-auto-mode
```
## 使用 YAML 檔案建立 EKS 自動模式叢集
您必須已安裝 `aws` 和 `eksctl` 工具。您必須以足夠的許可登入 AWS CLI，才能管理 AWS 資源，包括：EC2 執行個體、EC2 聯網、EKS 叢集和 IAM 角色。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
檢閱以下範例 ClusterConfig 資源中的 EKS 自動模式組態選項。有關完整的 ClusterConfig 規格，請參閱 [eksctl 文件](https://eksctl.io/usage/creating-and-managing-clusters/)。
AWS 建議啟用 EKS 自動模式。如果這是您第一次建立 EKS 自動模式叢集，請不要指定 `nodeRoleARN`，以便為 EKS 自動模式建立節點 IAM 角色。如果您的 AWS 帳戶中已有節點 IAM 角色， AWS 建議重複使用它。
AWS 建議不要為 指定任何值`nodePools`。EKS 自動模式會建立預設節點集區。您可使用 Kubernetes API 來建立其他節點集區。
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
將 `ClusterConfig` 檔案儲存為 `cluster.yaml`，並使用下列命令來建立叢集：
```
eksctl create cluster -f cluster.yaml
```
# 使用 CLI AWS 建立 EKS 自動模式叢集
EKS 自動模式叢集可自動執行運算、儲存和聯網的常規叢集管理任務。例如，EKS 自動模式叢集會自動檢測何時需要額外節點，並佈建新的 EC2 執行個體以滿足工作負載需求。
本主題會引導您使用 CLI 建立新的 EKS AWS 自動模式叢集，並選擇性地部署範例工作負載。
## 先決條件
+ 在您裝置上安裝和設定的最新版本 AWS 命令列界面 (AWS CLI)。若要檢查您目前的版本，請使用 `aws --version`。若要安裝最新版本，請參閱《 AWS 命令列界面使用者指南》中的使用 aws 設定[安裝](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 和[快速組態](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)。
+ 使用足夠的 IAM 許可登入 CLI，以建立 AWS 資源，包括 IAM 政策、IAM 角色和 EKS 叢集。
+ 裝置上安裝的 kubectl 命令列工具。 AWS 建議您使用與 EKS 叢集 Kubernetes 版本相同的 kubectl 版本。若要安裝或升級 kubectl，請參閱 [設定 `kubectl` 和 `eksctl`](install-kubectl.md)。
## 指定 VPC 子網路
Amazon EKS 自動模式會將節點部署到 VPC 子網路。建立 EKS 叢集時，您必須指定將部署節點的 VPC 子網路。您可以使用 AWS 帳戶中的預設 VPC 子網路，或為關鍵工作負載建立專用 VPC。
+ AWS 建議為您的叢集建立專用 VPC。了解如何 [為您的 Amazon EKS 叢集建立 Amazon VPC](creating-a-vpc.md)。
+ EKS 主控台可協助建立新 VPC。了解如何 [使用 建立 EKS 自動模式叢集 AWS 管理主控台](automode-get-started-console.md)。
+ 或者，您可以使用 AWS 您帳戶的預設 VPC。使用下列說明來尋找子網路 ID。
### 尋找預設 VPC 的子網路 ID
**使用 AWS CLI：**
1. 執行以下命令以列出預設 VPC 及其子網路：
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. 儲存輸出並記下**子網路 ID**。
輸出範例：
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## EKS 自動模式叢集的 IAM 角色
### 叢集 IAM 角色
EKS Auto Mode 需要叢集 IAM 角色才能在 AWS 帳戶中執行動作，例如佈建新的 EC2 執行個體。您必須建立此角色，才能授予 EKS 必要的許可。 AWS 建議將下列 AWS 受管政策連接至叢集 IAM 角色：
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### 節點 IAM 角色
當您建立 EKS 自動模式叢集時，需要指定一個節點 IAM 角色。當 EKS 自動模式建立節點以處理待處理的工作負載時，每個新的 EC2 執行個體節點都會指派節點 IAM 角色。此角色允許節點與 EKS 通訊，但通常不會由在節點上執行的工作負載存取。
如果您想要將許可授予節點上執行的工作負載，請使用 EKS Pod 身分識別。如需詳細資訊，請參閱[了解 EKS Pod 身分識別如何授予 AWS 服務的 Pod 存取權](pod-identities.md)。
您必須建立此角色並連接下列 AWS 受管政策：
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
EKS 自動模式還需要一個服務連結角色，該角色由 AWS自動建立與設定。更多資訊請參閱 [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md)。
## 建立 EKS 自動模式叢集 IAM 角色
### 步驟 1：建立信任政策
建立信任政策，允許 Amazon EKS 服務擔任該角色。將政策儲存為 `trust-policy.json`：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### 步驟 2：建立 IAM 角色
使用信任政策建立叢集 IAM 角色：
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### 步驟 3：記下角色 ARN
擷取並儲存新角色的 ARN，供後續步驟使用：
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### 步驟 4：附加所需政策
將下列 AWS 受管政策連接至叢集 IAM 角色，以授予必要的許可：
**AmazonEKSClusterPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSComputePolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSBlockStoragePolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSLoadBalancingPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
## 建立 EKS 自動模式節點 IAM 角色
### 步驟 1：建立信任政策
建立信任政策，允許 Amazon EKS 服務擔任該角色。將政策儲存為 `node-trust-policy.json`：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### 步驟 2：建立節點 IAM 角色
使用上一步中的 **node-trust-policy.json** 檔案來定義哪些實體可擔任該角色。執行下列命令以建立節點 IAM 角色：
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### 步驟 3：記下角色 ARN
建立角色後，擷取並儲存節點 IAM 角色的 ARN。您在後續步驟中將需要此 ARN。使用以下命令來取得 ARN：
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### 步驟 4：附加所需政策
將下列 AWS 受管政策連接至節點 IAM 角色，以提供必要的許可：
**AmazonEKSWorkerNodeMinimalPolicy**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**AmazonEC2ContainerRegistryPullOnly**：
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## 建立 EKS 自動模式叢集
### 概觀
若要使用 CLI AWS 建立 EKS 自動模式叢集，您將需要下列參數：
+ `cluster-name`：叢集的名稱。
+ `k8s-version`：Kubernetes 版本 (如 1.31)。
+ `subnet-ids`：先前步驟中識別的子網路 ID。
+ `cluster-role-arn`：叢集 IAM 角色的 ARN。
+ `node-role-arn`：節點 IAM 角色的 ARN。
#### 預設叢集組態
在建立叢集之前，檢閱這些預設值與功能：
+ `nodePools`：EKS 自動模式包含通用與系統預設節點集區。進一步了解[節點集區](create-node-pool.md)。
**注意：**EKS 自動模式中的節點集區與 Amazon EKS 受管節點群組不同，但可以在同一叢集中共存。
+ `computeConfig.enabled`：自動化常規運算任務，例如建立與刪除 EC2 執行個體。
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`：自動化負載平衡任務，包括建立與刪除 Elastic Load Balancer。
+ `storageConfig.blockStorage.enabled`：自動化儲存任務，如建立與刪除 Amazon EBS 磁碟區。
+ `accessConfig.authenticationMode`：需要 EKS 存取項目。深入了解 [EKS 身分驗證模式](grant-k8s-access.md)。
#### 執行命令
使用下列命令建立叢集：
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### 檢查叢集狀態
#### 步驟 1：確認叢集建立
執行下列命令，以檢查您的叢集狀態。建立叢集通常需要約 15 分鐘的時間：
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### 步驟 2：更新 kubeconfig
叢集準備就緒後，請更新本機 kubeconfig 檔案，以使 `kubectl` 與叢集通訊。此組態使用 AWS CLI 進行身分驗證。
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### 步驟 3：確認節點集區
使用以下命令列出叢集中的節點集區：
```
kubectl get nodepools
```
## 後續步驟
+ 了解如何將[範例工作負載部署](automode-workload.md)至新的 EKS 自動模式叢集。
# 使用 建立 EKS 自動模式叢集 AWS 管理主控台
在 中建立 EKS Auto Mode 叢集 AWS 管理主控台 所需的組態比其他選項少。EKS 與 AWS IAM 和 VPC 網路整合，協助您建立與 EKS 叢集相關聯的資源。
您在主控台中有兩個建立叢集的選項：
+ 快速組態 (使用 EKS 自動模式)
+ 自訂組態
在本主題中，您將了解如何使用快速組態選項建立 EKS 自動模式叢集。
## 使用快速組態選項建立 EKS 自動模式
您必須 AWS 管理主控台 以足夠的許可登入 來管理 AWS 資源，包括：EC2 執行個體、EC2 聯網、EKS 叢集和 IAM 角色。
1. 導覽至 EKS 主控台
1. 按一下**建立叢集**
1. 確認已選取**快速組態**選項
1. 確定以下值，或使用測試叢集的預設值。
+ 叢集**名稱**
+ Kubernetes 版本
1. 選取叢集 IAM 角色。如果這是您第一次建立 EKS 自動模式叢集，請使用**建立建議的角色**選項。
+ 或者，您可以為所有 EKS Auto Mode 叢集重複使用 AWS 帳戶中的單一叢集 IAM 角色。
+ 叢集 IAM 角色包含 EKS 自動模式管理資源 (包括 EC2 執行個體、EBS 磁碟區和 EC2 負載平衡器) 所需的許可。
+ **建立建議角色**選項會以建議值預先填入所有欄位。選取**下一步**，再選取**建立**。角色將使用建議 `AmazonEKSAutoClusterRole` 名稱。
+ 如果您最近建立了新角色，請使用**重新整理**圖示，重新載入角色選取下拉式清單。
1. 選取節點 IAM 角色。如果這是您第一次建立 EKS 自動模式叢集，請使用**建立建議的角色**選項。
+ 或者，您可以為所有 EKS Auto Mode 叢集重複使用 AWS 帳戶中的單一節點 IAM 角色。
+ 節點 IAM 角色包含自動模式節點連線叢集所需的許可。節點 IAM 角色必須包含為容器擷取 ECR 映像的許可。
+ **建立建議角色**選項會以建議值預先填入所有欄位。選取**下一步**，再選取**建立**。角色將使用建議 `AmazonEKSAutoNodeRole` 名稱。
+ 如果您最近建立了新角色，請使用**重新整理**圖示，重新載入角色選取下拉式清單。
1. 選取您的 EKS 自動模式叢集的 VPC。選擇**建立 VPC**，為 EKS 建立新的 VPC，或選擇您先前為 EKS 建立的 VPC。
+ 如果您使用 VPC 主控台建立新的 VPC， AWS 建議您為每個可用區域建立至少一個 NAT 閘道。否則，您可使用所有其他預設值。
+ 如需 IPv6 叢集需求的更多資訊和詳細資訊，請參閱 [為您的 Amazon EKS 叢集建立 Amazon VPC](creating-a-vpc.md)。
1. (選用) EKS 自動模式會自動為您選擇的 VPC 填入私有子網路。您可移除不需要的子網路。
+ EKS 會遵循最佳實務，自動從 VPC 中選取私有子網路。您可選擇從 VPC 中選取其他子網路，例如公有子網路。
1. (選用) 選取**檢視快速組態預設值**，以檢閱新叢集的所有組態值。資料表指出，在建立叢集之後，某些值無法編輯。
1. 選取 **Create cluster** (建立叢集)。請注意，建立叢集可能需要 15 分鐘時間才能完成。
## 後續步驟
+ 了解如何[將範例工作負載部署到您的 EKS 自動模式叢集](sample-storage-workload.md)
# 在現有的 EKS 叢集上啟用 EKS 自動模式
您可以在現有的 EKS 叢集上啟用 EKS 自動模式。
** AWS 支援下列移轉：**
+ 從 Karpenter 移轉至 EKS 自動模式節點。如需詳細資訊，請參閱[使用 kubectl 從 Karpenter 移轉至 EKS 自動模式](auto-migrate-karpenter.md)。
+ 從 EKS 受管節點群組移轉至 EKS 自動模式節點。如需詳細資訊，請參閱[從 EKS 受管節點群組移轉至 EKS 自動模式](auto-migrate-mng.md)。
+ 從 EKS Fargate 移轉至 EKS 自動模式。如需詳細資訊，請參閱[從 EKS Fargate 移轉至 EKS 自動模式](auto-migrate-fargate.md)。
** AWS 不支援下列移轉：**
+ 將磁碟區從 EBS CSI 控制器 (使用 Amazon EKS 附加元件) 移轉至 EKS 自動模式 EBS CSI 控制器 (由 EKS 自動模式管理)。使用其中一個製作的 PVC 無法由另一個掛載，因為它們使用的是兩個不同的 Kubernetes 磁碟區佈建程式。
+ [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (AWS Labs 專案） 可在標準 EBS CSI StorageClass (`ebs.csi.aws.com`) 和 EKS Auto EBS CSI StorageClass () 之間進行遷移`ebs.csi.eks.amazonaws.com`。請注意，移轉需要刪除並重新建立現有的 PersistentVolumeClaim/PersistentVolume 資源，因此在實作之前，請務必在非生產環境中進行驗證。
+ 將負載平衡器從 AWS Load Balancer控制器遷移至 EKS Auto 模式
您可以在 Amazon EKS Auto Mode 叢集上安裝 AWS Load Balancer控制器。使用 `IngressClass` 或 `loadBalancerClass` 選項，將服務和傳入資源與 Load Balancer 控制器或 EKS 自動模式建立關聯。如需規範性指引，請參閱 [https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html)
+ 使用替代 CNI 或其他不支援的網路組態移轉 EKS 叢集
## 移轉參考
使用下列移轉參考，將 Kubernetes 資源設定為由自我管理控制器或 EKS 自動模式擁有。
| 功能 | 資源 | 欄位 | 自我管理 | EKS 自動模式 |
| --- | --- | --- | --- | --- |
| 區塊儲存 | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Load balancing | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Load balancing | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Load balancing | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Load balancing | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 運算 | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## 移轉 EBS 磁碟區
將工作負載移轉至 EKS 自動模式時，由於 CSI 驅動程式佈建程式不同，您需要處理 EBS 磁碟區移轉：
+ EKS 自動模式佈建程式：`ebs.csi.eks.amazonaws.com`
+ 開放原始碼 EBS CSI 佈建程式：`ebs.csi.aws.com`
請遵循下列步驟，移轉您的持久性磁碟區：
1. **修改磁碟區保留政策**：將現有平台版本的 (PV) `persistentVolumeReclaimPolicy` 變更為 `Retain`，以確保不會刪除基礎 EBS 磁碟區。
1. **從 Kubernetes 移除 PV**：刪除舊 PV 資源，同時保持實際 EBS 磁碟區原封不動。
1. **使用靜態佈建建立新的 PV**：建立參考相同 EBS 磁碟區且可與目標 CSI 驅動程式搭配使用的新 PV。
1. **繫結至新的 PVC**：使用 `volumeName` 欄位建立專門參考 PV 的新 PVC。
### 考量事項
+ 在開始此移轉之前，請確保您的應用程式已停止。
+ 在開始移轉程序之前，備份您的資料。
+ 每個持久性磁碟區皆需執行此程序。
+ 工作負載必須更新，才能使用新的 PVC。
## 移轉負載平衡器
您無法將現有的負載平衡器從自我管理 AWS 負載平衡器控制器直接轉移到 EKS Auto 模式。相反地，您必須實作藍綠部署策略。這包括在受管控制器下建立新的負載平衡器時，維護現有的負載平衡器組態。
若要最大限度地減少服務中斷，我們建議採用 DNS 型流量轉移方法。首先，使用 EKS 自動模式建立新的負載平衡器，同時保持現有組態正常運作。然後，使用 DNS 路由 (例如 Route 53)，逐步將流量從舊負載平衡器轉移至新的負載平衡器。成功移轉流量並驗證新組態後，您即可停用舊負載平衡器和自我管理控制器。
# 在現有叢集上啟用 EKS 自動模式
本主題描述如何在現有的 Amazon EKS 叢集上啟用 Amazon EKS Auto Mode。在現有叢集上啟用自動模式需要更新 IAM 許可，並設定 EKS 自動模式核心設定。一旦啟用，您可以開始移轉現有的運算工作負載，以利用自動模式的簡化操作和自動化基礎結構管理。
**重要**
在啟用 EKS 自動模式之前，請確認您已安裝特定 Amazon EKS 附加元件的最低所需版本。如需詳細資訊，請參閱[所需的附加元件版本](#auto-addons-required)。
開始之前，請確認您擁有 Amazon EKS 叢集的管理員存取權限及修改 IAM 角色的許可。本主題中的步驟會引導您使用 AWS 管理主控台 或 CLI AWS 來啟用自動模式。
## AWS 管理主控台
您必須使用管理 IAM、EKS 和 EC2 資源的許可登入 AWS 主控台。
**注意**
EKS 叢集的叢集 IAM 角色在叢集建立後無法變更。EKS 自動模式需要此角色的額外許可。您必須在目前角色上附加其他政策。
### 更新叢集 IAM 角色
1. 在 AWS 管理主控台中開啟您的叢集概觀頁面。
1. 在**叢集 IAM 角色 ARN** 下，選取在 **IAM 中檢視**。
1. 從**新增許可**下拉式清單中，選取**連接政策**。
1. 使用**搜尋**方塊，尋找並選取以下政策：
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. 選取**新增許可**
1. 從**信任關係**索引標籤，選取**編輯信任政策**
1. 插入下列叢集 IAM 角色信任政策，並選取**更新政策**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### 啟用 EKS 自動模式
1. 在 AWS 管理主控台中開啟您的叢集概觀頁面。
1. 在 **EKS 自動模式**下，選取**管理**
1. 將 **EKS 自動模式**切換為開啟。
1. 從 **EKS 節點集區**下拉式清單中，選取要建立的預設節點集區。
+ 進一步了解 EKS 自動模式的節點集區。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
1. 如果您先前已建立此 AWS 帳戶的 EKS 自動模式節點 IAM 角色，請在**節點 IAM 角色**下拉式清單中選取該角色。如果您之前尚未建立此角色，請選取**建立建議的角色**，並依步驟操作。
## AWS CLI
### 先決條件
+ 現有 EKS 叢集的叢集 IAM 角色必須包含 EKS Auto Mode 的足夠許可，例如下列政策：
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ 叢集 IAM 角色必須具有更新的信任政策，包括 `sts:TagSession` 動作。如需有關建立 IAM 角色的詳細資訊，請參閱 [使用 CLI AWS 建立 EKS 自動模式叢集](automode-get-started-cli.md)。
+ `aws` 已安裝、登入的 CLI 和足夠的版本。您必須具有管理 IAM、EKS 和 EC2 資源的許可。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
### 程序
使用以下命令，在現有叢集上啟用 EKS 自動模式。
**注意**
運算、區塊儲存和負載平衡功能必須在同一請求中全部啟用或停用。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## 所需的附加元件版本
如果您計劃在現有叢集上啟用 EKS 自動模式，您可能需要更新特定附加元件。版本備註：
+ 這僅適用於轉換為 EKS 自動模式的現有叢集。
+ 啟用 EKS 自動模式時建立的新叢集無需這些更新。
如果您安裝了以下任何附加元件，請確保其至少為指定的最低版本：
| 附加元件名稱 | 所需的最低版本 |
| --- | --- |
| Kubernetes 專用 Amazon VPC CNI 外掛程式 | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/auto-enable-existing.html) |
| Amazon EBS CSI 驅動程式 | v1.37.0-eksbuild.1 |
| CSI 快照控制器 | v8.1.0-eksbuild.2 |
| EKS Pod 身分識別代理程式 | v1.3.4-eksbuild.1 |
如需詳細資訊，請參閱[更新 Amazon EKS 附加元件](updating-an-add-on.md)。
## 後續步驟
+ 要移轉管理節點群組工作負載，請參閱 [從 EKS 受管節點群組移轉至 EKS 自動模式](auto-migrate-mng.md)。
+ 要從自我管理 Karpenter 移轉，請參閱 [使用 kubectl 從 Karpenter 移轉至 EKS 自動模式](auto-migrate-karpenter.md)。
# 使用 kubectl 從 Karpenter 移轉至 EKS 自動模式
本主題將逐步引導您使用 kubectl 將工作負載從 Karpenter 移轉至 Amazon EKS 自動模式。移轉可以逐步進行，讓您能夠按照自己的步調移動工作負載，同時在整個轉換期間保持叢集穩定性和應用程式可用性。
下面概述的逐步方法使您能夠在移轉期間同時執行 Karpenter 和 EKS 自動模式。這種雙重操作策略有助於確保平穩轉換，讓您可以在完全停用 Karpenter 之前，驗證工作負載在 EKS 自動模式上的行為。您可以單獨或分組移轉應用程式，提供靈活性以適應您的特定運營要求與風險承受能力。
## 先決條件
開始移轉之前，請確保您已具備下列項目：
+ 在叢集上安裝了 Karpenter v1.1 或以上版本。如需詳細資訊，請參閱 Karpenter 文件中的[升級至版本 1.1.0 及以上](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110)。
+ 已安裝並將 `kubectl` 連接到您的叢集。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
本主題假設您熟悉 Karpenter 及 NodePools。如需詳細資訊，請參閱 [Karpenter](https://karpenter.sh/) 文件。
## 步驟 1：在叢集上啟用 EKS 自動模式
使用 CLI 或 管理主控台在現有叢集上啟用 AWS EKS 自動模式。如需詳細資訊，請參閱[在現有叢集上啟用 EKS 自動模式](auto-enable-existing.md)。
**注意**
啟用 EKS 自動模式時，切勿在轉換期間的此階段啟用 `general purpose` nodepool。此節點集區不具選擇性。
如需詳細資訊，請參閱[啟用或停用內建的 NodePool](set-builtin-node-pools.md)。
## 步驟 2：建立帶有污點的 EKS 自動模式 NodePool
為 EKS 自動模式建立帶有污點的新 NodePool。這確保了現有的 Pod 不會自動排程到新的 EKS 自動模式節點上。此節點集區使用 EKS 自動模式內建的 `default` `NodeClass`。如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。
帶有污點的節點集區範例：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
更新節點集區的需求，以符合您要從中移轉的 Karpenter 組態。您至少需要一個需求。
## 步驟 3：更新工作負載以進行移轉
識別並更新您想要移轉至 EKS 自動模式的工作負載。向這些工作負載新增容差和節點選取器：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
此變更可讓工作負載排程至新的 EKS 自動模式節點。
EKS 自動模式使用與 Karpenter 不同的標籤。與 EC2 受管執行個體相關的標籤以 `eks.amazonaws.com` 開頭。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
## 步驟 4：逐步移轉工作負載
針對要移轉的每個工作負載重複步驟 3。這使您可根據需求和風險承受能力，單獨或分組移動工作負載。
## 步驟 5：移除原始 Karpenter NodePool
所有工作負載移轉完成後，即可移除原始的 Karpenter NodePool：
```
kubectl delete nodepool
```
## 步驟 6：從 EKS 自動模式 NodePool 移除污點 (選用)
如果您希望 EKS 自動模式成為新工作負載的預設值，可以從 EKS 自動模式 NodePool 中移除污點：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## 步驟 7：從工作負載移除節點選取器 (選用)
如果您已從 EKS 自動模式 NodePool 移除污點，可以選擇從工作負載移除節點選取器，因為 EKS 自動模式現在是預設值：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## 步驟 8：從叢集解除安裝 Karpenter
移除 Karpenter 的步驟取決於您的安裝方式。如需詳細資訊，請參閱 [Karpenter 安裝說明](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter)。
# 從 EKS 受管節點群組移轉至 EKS 自動模式
當您將 Amazon EKS 叢集轉換為使用 EKS 自動模式時，可以使用 eksctl CLI 工具從受管節點群組順暢地移轉現有工作負載。此程序能確保應用程式持續可用，同時 EKS 自動模式會最佳化您的運算資源。移轉可以在對執行中應用程式造成最小干擾的情況下進行。
本主題將引導您完成從現有受管節點群組耗盡 Pod，並讓 EKS 自動模式在新佈建的執行個體上重新排程它們的步驟。透過遵循此程序，您可在整個移轉過程中保持應用程式可用性的同時，利用 EKS 自動模式的智慧型工作負載整合功能。
## 先決條件
+ 已啟用 EKS 自動模式的叢集
+ 已安裝並將 `eksctl` CLI 連接到您的叢集。如需詳細資訊，請參閱 [設定以使用 Amazon EKS](setting-up.md)。
+ 叢集上未安裝 Karpenter。
## 程序
使用以下 `eksctl` CLI 命令來開始從現有受管節點群組執行個體排空 Pod。EKS 自動模式將建立新節點，以支援被取代的 Pod。
```
eksctl delete nodegroup --cluster= --name=
```
您需要為叢集中的每個受管節點群組執行此命令。
有關此命令的更多資訊，請參閱 eksctl 文件中的[刪除和耗盡節點群組](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)。
# 從 EKS Fargate 移轉至 EKS 自動模式
本主題將引導您使用 `kubectl` 將工作負載從 EKS Fargate 移轉至 Amazon EKS 自動模式的程序。移轉可以逐步進行，讓您能夠按照自己的步調移動工作負載，同時在整個轉換期間保持叢集穩定性和應用程式可用性。
下面概述的逐步方法使您能夠在移轉期間同時執行 EKS Fargate 和 EKS 自動模式。這種雙重操作策略有助於確保平穩轉換，讓您可以在完全停用 EKS Fargate 之前，驗證工作負載在 EKS 自動模式上的行為。您可以單獨或分組移轉應用程式，提供靈活性以適應您的特定運營要求與風險承受能力。
## 使用 AWS Fargate 比較 Amazon EKS Auto 模式和 EKS
對於想要執行 EKS 的客戶而言，Amazon EKS 搭配 AWS Fargate 仍然是選項，但 Amazon EKS Auto Mode 是建議的方法。EKS 自動模式完全符合 Kubernetes 規範，支援所有上游 Kubernetes 基本元件與 Istio 等平台工具，而這些是 Fargate 無法支援的。EKS 自動模式還完全支援所有 EC2 執行時期購買選項，包括 GPU 和 Spot 執行個體，使客戶能夠利用協商後的 EC2 折扣和其他節省機制。這些功能在使用帶有 Fargate 的 EKS 時不可用。
此外，EKS 自動模式允許客戶實現與 Fargate 相同的隔離模型，使用標準的 Kubernetes 排程功能來確保每個 EC2 執行個體運行單個應用程式容器。透過採用 Amazon EKS Auto Mode，客戶可以釋放在 上執行 Kubernetes 的完整優點 AWS ：完全符合 Kubernetes 的平台，提供彈性以利用整個 EC2 的廣度和購買選項，同時保留 Fargate 提供的基礎設施管理的易用性和抽象性。
### 在 EKS Auto 模式下實現類似 Fargate 的隔離
若要複寫 Fargate 的 Pod 隔離模型，其中每個 Pod 在自己的專用執行個體上執行，您可以使用 Kubernetes 拓撲分散限制條件。這是控制跨節點 Pod 分佈的建議方法：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
在此組態中：
+ `maxSkew: 1` 確保任何兩個節點之間的 Pod 計數差異最多為 1，每個節點可有效分配一個 Pod
+ `topologyKey: kubernetes.io/hostname` 將節點定義為拓撲網域
+ `whenUnsatisfiable: DoNotSchedule` 如果無法滿足限制條件， 會阻止排程
+ `minDomains: 1` 確保在排程之前至少有一個網域 （節點）
EKS Auto Mode 將視需要自動佈建新的 EC2 執行個體，以滿足此限制，提供與 Fargate 相同的隔離模型，同時讓您存取完整的 EC2 執行個體類型和購買選項。
或者，您可以使用 Pod 反親和性規則進行更嚴格的隔離：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
使用 的`podAntiAffinity`規則`requiredDuringSchedulingIgnoredDuringExecution`可確保在相同節點上`app: isolated-app`無法排程具有標籤的兩個 Pod。此方法提供與 Fargate 類似的硬隔離保證。
## 先決條件
開始移轉之前，請確保您已具備下列項目
+ 使用 Fargate 設定叢集。如需詳細資訊，請參閱[為您的叢集開始使用 AWS Fargate](fargate-getting-started.md)。
+ 已安裝並將 `kubectl` 連接到您的叢集。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
## 步驟 1：檢查 Fargate 叢集
1. 檢查帶有 Fargate 的 EKS 叢集是否正在執行：
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. 檢查執行中的 Pod：
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. 在名為 `deployment_fargate.yaml` 的檔案中建立部署：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 套用部署：
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. 檢查 Pod 與部署狀態：
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. 檢查節點：
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## 步驟 2：在叢集上啟用 EKS 自動模式
1. 使用 CLI 或 管理主控台在現有叢集上啟用 AWS EKS 自動模式。如需詳細資訊，請參閱[在現有叢集上啟用 EKS 自動模式](auto-enable-existing.md)。
1. 檢查 nodepool：
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## 步驟 3：更新工作負載以進行移轉
識別並更新您想要移轉至 EKS 自動模式的工作負載。
要將工作負載從 Fargate 移轉至 EKS 自動模式，請套用註釋 `eks.amazonaws.com/compute-type: ec2`。這能確保即使存在 Fargate 設定檔，該工作負載也不會由 Fargate 排程，而是由 EKS 自動模式 NodePool 接管。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
1. 修改您的部署 (例如 `deployment_fargate.yaml` 檔案)，將運算類型變更為 `ec2`：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 套用部署。此變更可讓工作負載排程至新的 EKS 自動模式節點：
```
kubectl apply -f deployment_fargate.yaml
```
1. 檢查部署是否在 EKS 自動模式叢集中執行：
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. 確認沒有 Fargate 節點在執行，且部署正在 EKS 自動模式受管節點上執行：
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## 步驟 4：逐步移轉工作負載
針對要移轉的每個工作負載重複步驟 3。這使您可根據需求和風險承受能力，單獨或分組移動工作負載。
## 步驟 5：移除原始的 Fargate 設定檔
所有工作負載移轉完成後，即可移除原始的 `fargate` 設定檔。將 ** 取代為您的 Fargate 設定檔名稱：
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## 步驟 6：縮減 CoreDNS 規模
由於 EKS 自動模式會處理 CoreDNS，您可將 `coredns` 部署縮減到 0：
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# 在 EKS 自動模式叢集中執行範例工作負載
本章節提供如何將不同類型的工作負載部署到在自動模式下執行的 Amazon EKS 叢集的範例。這些範例展示了關鍵的工作負載模式，包括範例應用程式、負載平衡的 Web 應用程式、使用持久性儲存的具狀態工作負載，以及具有特定節點放置要求的工作負載。每個範例都包含完整的資訊清單和逐步部署說明，您可以將其用作自己應用程式的範本。
繼續進行範例之前，請確定您已在自動模式下執行 EKS 叢集，且已安裝 AWS CLI 和 kubectl。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。這些範例假設您基本熟悉 Kubernetes 概念與 kubectl 命令。
您可以使用這些基於使用案例的範例在 EKS 自動模式叢集中執行工作負載。
[在 Amazon EKS 自動模式叢集中部署範例 inflate 工作負載](automode-workload.md)
展示如何使用 `kubectl` 命令將範例工作負載部署到 EKS 自動模式叢集。
[將範例負載平衡器工作負載部署至 EKS 自動模式](auto-elb-example.md)
展示如何在 Amazon EKS 上部署容器化版本的 2048 遊戲。
[部署具狀態工作負載範例至 EKS 自動模式](sample-storage-workload.md)
展示如何將範例具狀態應用程式部署到 EKS 自動模式叢集。
[部署加速工作負載](auto-accelerated.md)
說明如何將硬體加速工作負載部署至 EKS Auto Mode 管理的節點。
[控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)
展示如何使用注釋來控制工作負載是否部署到由 EKS 自動模式管理的節點。
# 在 Amazon EKS 自動模式叢集中部署範例 inflate 工作負載
在本教學中，您將學習如何將範例工作負載部署至 EKS 自動模式叢集，並觀察其如何自動佈建所需的運算資源。您將使用 `kubectl` 命令來監看叢集的行為，並親自了解自動模式如何簡化 Kubernetes 操作 AWS。完成本教學後，您將了解 EKS 自動模式如何透過自動管理底層運算資源來回應工作負載部署，無需手動設定節點群組。
## 先決條件
+ 一個 Amazon EKS 自動模式叢集。請記下叢集的名稱和 AWS 區域。
+ IAM 主體，例如使用者或角色，具有足夠的許可來管理聯網、運算和 EKS 資源。
+ 若需詳細資訊，請參閱《IAM 使用者指南》中的[建立角色和附加政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)。
+ 已安裝 `aws` CLI 並以 IAM 身分進行設定。
+ 已安裝 `kubectl` CLI 並連接至叢集。
+ 如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
## 步驟 1：檢閱現有運算資源 (選用)
第一，使用 `kubectl` 列出叢集上的節點集區。
```
kubectl get nodepools
```
輸出範例：
```
general-purpose
```
在本教學中，我們將部署設定為使用 `general-purpose` 節點集區的工作負載。此節點集區內建於 EKS Auto Mode，包含適用於一般工作負載，如微服務和 Web 應用程式的合理預設值。您也可建立自己的節點集區。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
第二，使用 `kubectl` 列出連接到叢集的節點。
```
kubectl get nodes
```
若您剛建立 EKS 自動模式叢集，一開始不會有任何節點。
在本教學中，您將部署一個範例工作負載。若沒有節點，或現有節點無法容納工作負載，EKS 自動模式將會佈建新節點。
## 步驟 2：將範例應用程式部署至叢集
請檢閱下列 Kubernetes 部署，將其儲存為 `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
請注意，`eks.amazonaws.com/compute-type: auto` 選擇器要求工作負載必須部署在 Amazon EKS 自動模式節點上。
將部署套用至叢集。
```
kubectl apply -f inflate.yaml
```
## 步驟 3：監看 Kubernetes 事件
使用下列命令以監看 Kubernetes 事件，包括建立新節點。使用 `ctrl+c` 以停止監看事件。
```
kubectl get events -w --sort-by '.lastTimestamp'
```
再次使用 `kubectl` 以列出連接到叢集的節點。請記下新建立的節點。
```
kubectl get nodes
```
## 步驟 4：在 AWS 主控台中檢視節點和執行個體
您可在 EKS 主控台中檢視 EKS 自動模式節點，並且在 EC2 主控台中檢視相關聯的 EC2 執行個體。
由 EKS 自動模式部署的 EC2 執行個體有存取限制。您將無法在 EKS 自動模式節點上執行任意命令。
## 步驟 5：刪除部署
使用 `kubectl` 刪除範例部署
```
kubectl delete -f inflate.yaml
```
若您沒有部署至叢集的其他工作負載，由 EKS 自動模式建立的節點將處於空閒狀態。
在預設組態中，EKS 自動模式會偵測到已空閒達 30 秒的節點，並終止這些節點。
使用 `kubectl` 或 EC2 主控台確認相關聯的執行個體已被刪除。
# 將範例負載平衡器工作負載部署至 EKS 自動模式
本指南將引導您在 Amazon EKS 上部署容器化版本的 2048 遊戲，並包含負載平衡和網際網路可存取性。
## 先決條件
+ EKS 自動模式叢集
+ `kubectl` 已設定為與叢集互動
+ 建立 ALB 資源的適當 IAM 許可
## 步驟 1：建立命名空間
首先，為 2048 遊戲應用程式建立專用命名空間。
建立名為 `01-namespace.yaml` 的檔案：
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
套用命名空間組態：
```
kubectl apply -f 01-namespace.yaml
```
## 步驟 2：部署應用程式
應用程式會執行多個 2048 遊戲容器的複本。
建立名為 `02-deployment.yaml` 的檔案：
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**注意**
如果您收到載入映像 的錯誤`public.ecr.aws/l6m2t8p7/docker-2048:latest`，請確認您的節點 IAM 角色具有從 ECR 提取映像的足夠許可。如需詳細資訊，請參閱[節點 IAM 角色](auto-learn-iam.md#auto-learn-node-iam-role)。此外，範例中的 `docker-2048` 映像是 `x86_64` 映像，並且不會在其他架構執行。
**關鍵元件：**
+ 部署 5 個應用程式複本
+ 使用公有 ECR 映像
+ 每個 Pod 請求 0.5 個 CPU 核心
+ 公開 HTTP 流量的連接埠 80
套用部署：
```
kubectl apply -f 02-deployment.yaml
```
## 步驟 3：建立服務
服務會將部署公開至叢集網路。
建立名為 `03-service.yaml` 的檔案：
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**關鍵元件：**
+ 建立 NodePort 服務
+ 將連接埠 80 映射至容器的連接埠 80
+ 使用標籤選擇器來尋找 Pod
套用服務：
```
kubectl apply -f 03-service.yaml
```
## 步驟 4：設定負載平衡
您將設定傳入，以將應用程式公開至網際網路。
首先，建立 `IngressClass`。建立名為 `04-ingressclass.yaml` 的檔案：
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**注意**
EKS 自動模式需要子網路標籤來識別公有和私有子網路。
若您使用 `eksctl` 建立叢集，則您已具備這些標籤。
了解如何 [標記 EKS 自動模式的子網路](tag-subnets-auto.md)。
然後建立傳入資源。建立名為 `05-ingress.yaml` 的檔案：
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**關鍵元件：**
+ 建立面向網際網路的 ALB
+ 使用 IP 目標類型來進行直接 Pod 路由
+ 將所有流量 (/) 路由到遊戲服務
套用傳入組態：
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## 步驟 5：確認部署
1. 檢查所有 Pod 是否處於執行狀態：
```
kubectl get pods -n game-2048
```
1. 確認服務是否已建立：
```
kubectl get svc -n game-2048
```
1. 取得 ALB 端點：
```
kubectl get ingress -n game-2048
```
傳入輸出中的 ADDRESS 欄位將顯示您的 ALB 端點。等待 2-3 分鐘，讓 ALB 完成佈建並註冊所有目標。
## 步驟 6：存取遊戲
開啟網頁瀏覽器，瀏覽至先前步驟中取得的 ALB 端點 URL。您應會看到 2048 遊戲介面。
## 步驟 7：清除
要移除在本教學課程中建立的全部資源：
```
kubectl delete namespace game-2048
```
這將刪除命名空間中的所有資源，包括部署、服務和傳入資源。
## 幕後情況
1. 部署會建立 5 個執行 2048 遊戲的 Pod
1. 服務為這些 Pod 提供穩定的網路存取
1. EKS 自動模式：
+ 在 中建立 Application Load Balancer AWS
+ 為 Pod 設定目標群組
+ 設定路由規則，以將流量導向服務
## 疑難排解
如果遊戲無法載入：
+ 確保所有 Pod 均在執行：`kubectl get pods -n game-2048`
+ 檢查傳入狀態：`kubectl describe ingress -n game-2048`
+ 驗證 ALB 運作狀態檢查：在 AWS 主控台中檢查目標群組運作狀態
# 部署具狀態工作負載範例至 EKS 自動模式
這項教學課程將引導您部署具狀態範例應用程式至 EKS 自動模式叢集。應用程式可將時間戳記寫入持續性磁碟區，從而示範 EKS 自動模式的自動 EBS 磁碟區佈建與持續保留功能。
## 先決條件
+ EKS 自動模式叢集
+ AWS CLI 已設定適當許可
+ `kubectl` 已安裝並已設定
+ 如需詳細資訊，請參閱 [設定以使用 Amazon EKS](setting-up.md)。
## 步驟 1：設定您的環境
1. 設定環境變數：
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. 更新 kubeconfig：
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## 步驟 2：建立儲存類別
`StorageClass` 定義 EKS 自動模式佈建 EBS 磁碟區的方式。
EKS 自動模式不會為您建立 `StorageClass`。您必須建立 `StorageClass` 參考 `ebs.csi.eks.amazonaws.com`，以使用 EKS 自動模式的儲存功能。
1. 建立名為 `storage-class.yaml` 的檔案：
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. 套用 `StorageClass`：
```
kubectl apply -f storage-class.yaml
```
**關鍵元件：**
+ `provisioner: ebs.csi.eks.amazonaws.com` - 使用 EKS 自動模式
+ `volumeBindingMode: WaitForFirstConsumer` - 延遲建立磁碟區，直至 Pod 需要磁碟區
+ `type: gp3` - 指定 EBS 磁碟區類型
+ `encrypted: "true"` - EBS 將使用預設 `aws/ebs` 金鑰，來加密使用此類別建立的磁碟區。此為選用操作，但建議您採用。
+ `storageclass.kubernetes.io/is-default-class: "true"` - 依預設，Kubernetes 將使用此儲存類別，除非您在持續性磁碟區宣告上指定了不同的磁碟區類別。若要從其他儲存控制器移轉，則在設定該值時要謹慎對待。(選用)
## 步驟 3：建立持續性磁碟區宣告
PVC 可從 `StorageClass` 請求儲存。
1. 建立名為 `pvc.yaml` 的檔案：
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. 套用 PVC：
```
kubectl apply -f pvc.yaml
```
**關鍵元件：**
+ `accessModes: ReadWriteOnce` - 磁碟區可一次由一個節點掛載
+ `storage: 8Gi` - 請求 8 GiB 磁碟區
+ `storageClassName: auto-ebs-sc` - 參考我們建立的 `StorageClass`
## 步驟 4：部署應用程式
部署將執行一個容器，這會將時間戳記寫入持續性磁碟區。
1. 建立名為 `deployment.yaml` 的檔案：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. 套用部署：
```
kubectl apply -f deployment.yaml
```
**關鍵元件：**
+ 寫入時間戳記至檔案的簡易 bash 容器
+ 在 `/data` 掛載 PVC
+ 請求 1 個 CPU 核心
+ 針對 EKS 受管節點使用節點選擇器
## 步驟 5：驗證設定
1. 檢查 Pod 是否在執行中：
```
kubectl get pods -l app=inflate-stateful
```
1. 確認 PVC 是否已繫結：
```
kubectl get pvc auto-ebs-claim
```
1. 檢查 EBS 磁碟區：
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. 驗證是否正在寫入資料：
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## 步驟 6：清除
若要移除在本教學課程中建立的全部資源，請執行以下命令：
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## 幕後情況
1. PVC 可從 `StorageClass` 請求儲存
1. 排程 Pod 時：
1. EKS 自動模式可佈建 EBS 磁碟區
1. 建立 PersistentVolume
1. 連接磁碟區至節點
1. Pod 會掛載磁碟區及開始撰寫時間戳記
## 快照控制器
EKS 自動模式與 Kubernetes CSI 快照器相容，亦稱為快照控制器。然而，EKS 自動模式不包括快照控制器。您將負責安裝及設定快照控制器。如需詳細資訊，請參閱 [啟用 CSI 磁碟區的快照功能](csi-snapshot-controller.md)。
請檢閱下列參考 EKS 自動模式儲存功能的 `VolumeSnapshotClass`。
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[了解 Kubernetes CSI 快照器的相關詳細資訊。](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 部署加速工作負載
本教學課程示範 Amazon EKS Auto Mode 如何簡化硬體加速工作負載的啟動。Amazon EKS 自動模式不僅限於叢集本身，還透過自動化關鍵基礎結構元件來簡化操作，這些元件預設提供運算、聯網、負載平衡、儲存和身分存取管理功能。
Amazon EKS Auto Mode 包含特定執行個體類型所需的驅動程式和裝置外掛程式，例如 NVIDIA 和 AWS Neuron 驅動程式。您無需安裝或更新這些元件。
EKS 自動模式會自動管理這些加速器的驅動程式：
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [Amazon EC2 加速執行個體上的 NVIDIA GPU](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**注意**
EKS 自動模式包含 Kubernetes 專用 NVIDIA 裝置外掛程式。此外掛程式會自動執行，且在您的叢集中不會顯示為常駐程式集。
其他聯網支援：
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
Amazon EKS 自動模式消除了加速器驅動程式和裝置外掛程式管理的繁瑣工作。
您還可以透過將叢集縮減至零來節省成本。您可以設定 EKS 自動模式，在沒有工作負載執行時終止執行個體。這對基於批次的推斷工作負載很有用。
以下提供一個範例，說明如何使用 Amazon EKS 自動模式啟動加速工作負載。
## 先決條件
+ 一個已設定 Amazon EKS 自動模式的 Kubernetes 叢集。
+ 當啟用 `general-purpose` 或 `system` 受管節點集區時，所建立的預設 `default` EKS 節點類別。
## 步驟 1：部署 GPU 工作負載
在此範例中，您將為需要 45GB GPU 記憶體的 NVIDIA 基礎工作負載建立一個 NodePool。透過 EKS 自動模式，您可使用 Kubernetes 排程限制來定義您的執行個體需求。
要部署 Amazon EKS 自動模式的 `NodePool` 和範例 `workload`，請檢閱以下的 NodePool 和 Pod 定義，並分別儲存為 `nodepool-gpu.yaml` 和 `pod.yaml`：
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
請注意，`eks.amazonaws.com/compute-type: auto` 選擇器要求工作負載必須部署在 Amazon EKS 自動模式節點上。NodePool 還設定了一個污點，只允許排程具有 NVIDIA GPU 容忍度的 Pod。
將 NodePool 和工作負載套用至您的叢集。
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
您應該會看到下列輸出：
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
等待幾秒鐘，並檢查叢集中的節點。您現在應該會看到在 Amazon EKS 自動叢集中佈建了一個新節點：
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## 步驟 2：驗證
您會看見 Amazon EKS 自動模式啟動了一個 `g6e.2xlarge` 而非 `g6.2xlarge`，這是因為根據以下的 Kubernetes 排程限制，工作負載需要一個配備 l40s `GPU` 的執行個體：
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
現在，執行以下命令查看容器日誌：
```
kubectl logs nvidia-smi
```
輸出範例：
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
您會看到容器已偵測到其正在具有 `NVIDIA` GPU 的執行個體上執行，且您無需安裝任何裝置驅動程式，因為這由 Amazon EKS 自動模式管理。
## 步驟 3：清理
若要移除所有建立的物件，請使用 `kubectl` 刪除範例部署和 NodePool，以便終止節點：
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## NodePools 範例參考
### 建立 NVIDIA NodePool
以下 NodePool 定義：
+ 只啟動 `g6e` 和 `g6` 系列的執行個體
+ 節點閒置 1 小時後進行合併
+ `consolidateAfter` 1 小時的值可支援突增的工作負載，並減少節點波動。您可根據工作負載需求調整 `consolidateAfter`。
**具有 GPU 執行個體系列和合併功能的範例 NodePool**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
您可使用 `eks.amazonaws.com/instance-family` 來指定執行個體系列，而非設定 `eks.amazonaws.com/instance-gpu-name`。如需其他影響排程的知名標籤，請參閱 [EKS 自動模式支援的標籤](create-node-pool.md#auto-supported-labels)。
若您有特定的儲存需求，可以透過建立自己的 [NodeClass](create-node-class.md) 並在 NodePool 中參考，來調整節點的臨時儲存 `iops`、`size` 和 `throughput`。深入了解[可設定的 NodeClass 選項](create-node-class.md)。
**NodeClass 的儲存組態範例**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### 定義 AWS Trainium 和 AWS Inferentia NodePool
以下 NodePool 設定了 `eks.amazonaws.com/instance-category`，表示僅啟動 Inferentia 與 Trainium 系列的執行個體：
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# 進行 EKS 自動模式設定
本章內容介紹如何設定 Amazon Elastic Kubernetes Service (EKS) 自動模式叢集的特定層面。儘管 EKS 自動模式可自動管理大多數基礎結構元件，但您可自訂某些功能來滿足工作負載需求。
藉助本主題中所述的組態選項，您可修改聯網設定、運算資源及負載平衡行為，同時確保自動化管理基礎結構的優勢。做出任何組態變更之前，檢閱以下章節中所述的可用選項，確定哪種方法最能滿足您的需求。
| 您想要設定的功能有哪些？ | 組態選項 |
| --- | --- |
| **節點聯網及儲存** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [建立 Amazon EKS 的節點類別](create-node-class.md) |
| **節點運算資源** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [為 EKS 自動模式建立節點集區](create-node-pool.md) |
| **靜態容量節點集區** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [EKS Auto 模式的靜態容量節點集區](auto-static-capacity.md) |
| **Application Load Balancer 設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [建立 IngressClass 以設定 Application Load Balancer](auto-configure-alb.md) |
| **Network Load Balancer 設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [使用服務注釋設定 Network Load Balancer](auto-configure-nlb.md) |
| **儲存類別設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [建立儲存類別](create-storage-class.md) |
| **控制 ODCR 用量** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [使用 EKS 自動模式控制工作負載部署至容量保留](auto-odcr.md) |
| **節點進階安全性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [設定節點的進階安全設定](auto-advanced-security.md) |
# 建立 Amazon EKS 的節點類別
Amazon EKS 節點類別是範本，可讓您精細控制 EKS 自動模式受管節點的組態。節點類別定義套用至 EKS 叢集中節點群組的基礎結構層級設定，包括網路組態、儲存設定和資源標記。本主題闡釋如何建立和設定節點類別，以滿足您的特定操作需求。
當您需要自訂 EKS 自動模式在預設設定之外，佈建和設定 EC2 執行個體的方式時，建立節點類別可讓您精確控制關鍵基礎結構參數。例如，您可以指定私有子網路放置以增強安全性，為效能敏感的工作負載設定執行個體暫時性儲存，或套用自訂標記以進行成本分配。
## 建立節點類別
要建立 `NodeClass`，請執行下列步驟：
1. 使用節點類別組態建立 YAML 檔案 (例如 `nodeclass.yaml`)
1. 使用 `kubectl` 將組態套用至您的叢集
1. 在節點集區組態中參考節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
您需要已安裝並設定 `kubectl`。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
### 基本節點類別範例
以下是一個節點類別範例：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
此 NodeClass 會增加節點上的暫時性儲存量。
透過以下方式套用此組態：
```
kubectl apply -f nodeclass.yaml
```
接下來，在節點集區組態中參考節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
## 建立節點類別存取項目
如果您建立了自訂節點類別，則需要建立 EKS 存取項目以允許節點加入叢集。在當您使用內建節點類別和節點集區時，EKS 會自動建立存取項目。
如需項目存取方法的相關資訊，請參閱 [使用 EKS 存取項目授予 IAM 使用者 Kubernetes 的存取權](access-entries.md)。
為 EKS 自動模式節點類別建立存取項目時，您需要使用 `EC2` 存取項目類型。
### 使用 CLI 建立存取項目
**要建立 EC2 節點的存取項目，並關聯 EKS Auto Node 政策：**
使用您的叢集名稱和節點角色 ARN 更新以下 CLI 命令。節點角色 ARN 在節點類別 YAML 中指定。
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### 使用 CloudFormation 建立存取項目
**要建立 EC2 節點的存取項目，並關聯 EKS Auto Node 政策：**
使用您的叢集名稱和節點角色 ARN 更新以下 CloudFormation。節點角色 ARN 在節點類別 YAML 中指定。
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
有關部署 CloudFormation 堆疊的資訊，請參閱 [CloudFormation 入門](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## 節點類別規格
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws: kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## 考量事項
+ 如果您想要確認執行個體有多少本機儲存，可以描述節點以查看暫時性儲存資源。
+ **磁碟區加密** - EKS 使用設定的自訂 KMS 金鑰來加密執行個體的唯讀根磁碟區及讀取/寫入資料磁碟區。
+ **取代節點 IAM 角色** - 如果您變更與 `NodeClass` 相關聯的節點 IAM 角色，則需要建立新的存取項目。EKS 在叢集建立期間會自動為節點 IAM 角色建立存取項目。節點 IAM 角色需要 `AmazonEKSAutoNodePolicy` EKS 存取政策。如需詳細資訊，請參閱[使用 EKS 存取項目授予 IAM 使用者 Kubernetes 的存取權](access-entries.md)。
+ **最大 Pod 密度** - EKS 會將節點上的最大 Pod 數量限制為 110。此限制是在現有的最大 Pod 計算之後套用的。如需詳細資訊，請參閱[選擇最佳的 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。
+ **標籤** - 如果您想要將標籤從 Kubernetes 傳播到 EC2，需要設定其他 IAM 許可。如需詳細資訊，請參閱[了解 EKS 自動模式中的身分和存取](auto-learn-iam.md)。
+ **預設節點類別** - 請勿將您的自訂節點類別命名為 `default`。這是因為 EKS 自動模式包含一個名為 `default` 的 `NodePool`，當您啟用至少一個內建 `NodeClass` 時會自動佈建該類別。如需啟用內建 `NodePools` 的詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。
+ **具有多個子網路的 `subnetSelectorTerms` 行為** - 如果有多個子網路符合 `subnetSelectorTerms` 條件或您按 ID 提供的子網路，EKS 自動模式會建立分佈於各個子網路中的節點。
+ 如果子網路位於不同的可用區域 (AZ)，您可以使用 Kubernetes 功能，例如 [Pod 拓撲分散限制](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints)條件和[拓撲感知路由](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)，分別將 Pod 和流量分散到各個區域。
+ 如果*同一個 AZ 中*有多個子網路符合 `subnetSelectorTerms`，則 EKS 自動模式會在該可用區域中分散在各個子網路的每個節點上建立 Pod。EKS 自動模式會在相同 AZ 中其他子網路中的每個節點建立次要網路介面。它根據每個子網路中可用 IP 位址的數量進行選擇，以更高效地使用子網路。但是，您無法指定 EKS 自動模式為每個 Pod 使用的子網路；如果您需要 Pod 在特定子網路中執行，請改用 [Pod 的個別子網路和安全群組](#pod-subnet-selector)。
## Pod 的個別子網路和安全群組
`podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms` 欄位允許 Pod 使用與其節點不同的子網路和安全群組，以啟用進階聯網組態。兩個欄位必須一起指定。這種分離可增強對網路流量路由與安全政策的控制。
**注意**
此功能不同於 AWS VPC CNI 用於非EKS Auto Mode 運算的 [Pod 安全群組](security-groups-for-pods.md) (SGPP) 功能。EKS Auto 模式不支援 SGPP。反之，請在 `podSecurityGroupSelectorTerms`中使用 `NodeClass`，將個別的安全群組套用至 Pod 流量。安全群組適用於 `NodeClass`層級，這表示使用 `NodeClass`共用相同 Pod 安全群組之節點上的所有 Pod。
### 運作方式
當您設定 `podSubnetSelectorTerms`和 時`podSecurityGroupSelectorTerms`：
1. 節點的主要 ENI 使用來自 和 的子網路`subnetSelectorTerms`和安全群組`securityGroupSelectorTerms`。只有節點自己的 IP 地址才會指派給此界面。
1. EKS Auto Mode 會在符合 的子網路中建立次要 ENIs`podSubnetSelectorTerms`，並`podSecurityGroupSelectorTerms`連接來自 的安全群組。根據預設，Pod IP 地址會使用 /28 字首從這些次要 ENIs 配置，並在連續字首區塊無法使用時自動回復到次要 IPs (/32)。如果在 `"32"`中`ipv4PrefixSize`將 設定為 `advancedNetworking`，則只會使用次要 IPs。
1. 中指定的安全群組`podSecurityGroupSelectorTerms`適用於 VPC 內的 Pod 流量。對於目的地為 VPC 之外的流量，Pod 會使用節點的主要 ENI （及其安全群組），因為來源網路位址轉譯 (SNAT) 會將 Pod IP 轉譯為節點 IP。您可以使用 中的 `snatPolicy` 欄位修改此行為`NodeClass`。
### 使用案例
當您需要`podSecurityGroupSelectorTerms`時，請使用 `podSubnetSelectorTerms`和 ：
+ 套用不同的安全群組，分別控制節點和 Pod 的流量。
+ 將基礎設施流量 node-to-node通訊） 與應用程式流量 (Pod-to-Pod通訊） 分開。
+ 對節點子網路和 Pod 子網套用不同的聯網組態。
+ 專門為節點流量設定反向代理或網路篩選, 而不影響 Pod 流量。使用 `advancedNetworking` 和 `certificateBundles` 來定義您的反向代理，以及代理的任何自簽署或私有憑證。
### 範例組態
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### 個別 Pod 子網路和安全群組的考量事項
+ **安全群組範圍**： 的安全群組`podSecurityGroupSelectorTerms`會連接至次要 ENIs，並套用至 VPC 內的 Pod 流量。啟用 SNAT 時 （預設 `snatPolicy: Random`)，離開 VPC 的流量會轉譯為節點的主要 ENI IP 地址，因此節點的安全群組`securityGroupSelectorTerms`會套用至該流量。如果您設定 `snatPolicy: Disabled`，Pod 會針對所有流量使用自己的 IP 地址，而且您必須確保相應地設定路由和安全群組。
+ **NodeClass 層級精細程度**：Pod 安全群組適用於使用 排程在節點上的所有 Pod`NodeClass`。若要將不同的安全群組套用至不同的工作負載，請建立個別 `NodeClass` 和 `NodePool` 資源，並使用污點、容錯或節點選擇器，將工作負載排程到適當的節點。
+ **降低 Pod 密度**：每個節點上執行的 Pod 較少，因為節點的主要網路介面預留給節點 IP，且無法用於 Pod。
+ **子網路選擇器限制**：標準`subnetSelectorTerms`和`securityGroupSelectorTerms`組態不適用於 Pod 子網路或安全群組選擇。
+ **網路規劃**：確保節點和 Pod 子網路中有足夠的 IP 位址空間，以支援您的工作負載需求。
+ **路由組態**：確認 Pod 子網路的路由表和網路存取控制清單 (ACL) 已正確設定，以便在節點和 Pod 子網路之間進行通訊。
+ **可用區域**：確認您已在多個 AZ 中建立 Pod 子網路。如果您使用的是特定的 Pod 子網路，它必須與節點子網路 AZ 位於相同的 AZ 中。
## Pod 的次要 IP 模式
`ipv4PrefixSize` 欄位透過僅將次要 IP 地址配置給節點來啟用進階聯網組態。此功能不會將字首 (/28) 配置給節點，而且只會維護一個次要 IP 做為 MinimalIPTarget。
### 使用案例
當您需要以下功能時，可使用 `ipv4PrefixSize`：
+ **降低 IP 使用率**：每個節點只會暖機一個 IP 地址。
+ **較低的 Pod 追逐率**：Pod 建立速度不是主要問題。
+ **無字首分割**：字首導致的分割是使用自動模式的主要考量或封鎖程式。
### 範例組態
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### 次要 IP 模式的考量事項
+ **降低 Pod 建立速度**：由於只有一個次要 IP 已暖機，因此在建立更多 Pod 時，IPAM 服務需要更多時間來佈建 IPs。
## 在 IPv4IPv6 叢集中停用 IPv6 Pod 的 IPv6 輸出。
`enableV4Egress` 欄位`true`預設為 。對於自動模式 IPv6 叢集，此功能可以停用，因此自動模式不會為 IPv6 Pod 建立僅輸出 IPv4 界面。這很重要，因為 IPv4 輸出界面不受網路政策強制執行的約束。網路政策僅在 Pod 的主要界面 (eth0) 上強制執行。
### 使用案例
當您需要以下功能時，可使用 `enableV4Egress`：
+ **使用 IPv6 叢集**：預設允許 IPv4 輸出流量。
+ **使用網路政策**：目前 EKS 網路政策不支援雙堆疊。停用`enableV4Egress`可防止 Pod 流量意外透過 IPv4 輸出。
### 範例組態
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### 停用 enableV4Egress 的考量事項
+ **IPv6 叢集中的網路政策**：IPv6 叢集預設允許 IPv4 流量。設定 會`enableV4Egress: false`封鎖 IPv4 輸出流量，提供增強的安全性，特別是在與網路政策搭配使用時。
# 為 EKS 自動模式建立節點集區
Amazon EKS 節點集區提供了彈性的方式來管理 Kubernetes 叢集中的運算資源。本主題示範如何使用 Karpenter 建立和設定節點集區，這是一種有助於最佳化叢集擴展與資源使用率的節點佈建工具。透過 Karpenter 的 NodePool 資源，您可以為運算資源定義特定要求，包括執行個體類型、可用區域、架構和容量類型。
您無法修改內建 `system` 和 `general-purpose` 節點集區。您僅可以啟用或停用它們。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。
NodePool 規格透過各種支援的標籤和要求，允許對 EKS 叢集的運算資源進行精細控制。這些選項包括指定 EC2 執行個體類別、CPU 組態、可用區域、架構 (ARM64/AMD64) 及容量類型 (Spot 或隨需)。您還可以為 CPU 和記憶體用量設定資源限制，確保您的叢集保持在所需的操作範圍內。
EKS 自動模式利用眾所周知的 Kubernetes 標籤，提供一致且標準化的方式來識別節點特性。這些標籤遵循既定的 Kubernetes 慣例，例如用於可用區域的 `topology.kubernetes.io/zone` 和用於 CPU 架構的 `kubernetes.io/arch`。此外，EKS 特定標籤 (字首為 `eks.amazonaws.com/`) 使用 AWS 特定屬性延伸此功能，例如執行個體類型、CPU 製造商、GPU 功能和聯網規格。這種標準化的標籤系統可讓您與現有的 Kubernetes 工具無縫整合，同時提供深度 AWS 基礎結構整合。
## 建立 NodePool
請遵循以下步驟為您的 Amazon EKS 叢集建立 NodePool：
1. 使用所需的 NodePool 組態建立名為 `nodepool.yaml` 的 YAML 檔案。您可以使用以下範例組態。
1. 將 NodePool 套用至您的叢集：
```
kubectl apply -f nodepool.yaml
```
1. 確認已成功建立 NodePool：
```
kubectl get nodepools
```
1. (選用) 監控 NodePool 狀態：
```
kubectl describe nodepool default
```
確保您的 NodePool 參照了叢集中存在的有效 NodeClass。NodeClass 為您的運算資源定義了特定於 AWS 的組態。如需詳細資訊，請參閱 [建立 Amazon EKS 的節點類別](create-node-class.md)。
## 範例 NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## EKS 自動模式支援的標籤
EKS 自動模式支援下列眾所周知的標籤。
**注意**
EKS 自動模式使用與 Karpenter 不同的標籤。與 EC2 受管執行個體相關的標籤以 `eks.amazonaws.com` 開頭。
| 標籤 | 範例 | 描述 |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS 區域 |
| node.kubernetes.io/instance-type | g4dn.8xlarge | AWS 執行個體類型 |
| kubernetes.io/arch | amd64 | 架構由執行個體上的 [GOARCH 值](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)定義 |
| karpenter.sh/capacity-type | spot | 容量類型包括 `spot`、`on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | 使用特定 Hypervisor 的執行個體類型 |
| eks.amazonaws.com/compute-type | auto | 識別 EKS 自動模式受管節點 |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | 支援 (或不支援) 傳輸中加密的執行個體類型 |
| eks.amazonaws.com/instance-category | g | 相同類別的執行個體類型，通常為產生編號之前的字串 |
| eks.amazonaws.com/instance-generation | 4 | 執行個體類別內的執行個體類型產生編號 |
| eks.amazonaws.com/instance-family | g4dn | 屬性類似，但資源數量不同的執行個體類型 |
| eks.amazonaws.com/instance-size | 8xlarge | 資源數量類似，但屬性不同的執行個體類型 |
| eks.amazonaws.com/instance-cpu | 32 | 執行個體上的 CPU 數量 |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU 製造商的名稱 |
| eks.amazonaws.com/instance-memory | 131072 | 執行個體上的記憶體 MiB 數 |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | 執行個體上可用 EBS 的[最大 MiB ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance)數 |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | 執行個體上可用的[基準兆位](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)數 |
| eks.amazonaws.com/instance-gpu-name | t4 | 執行個體上的 GPU 名稱 (如有) |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | GPU 製造商的名稱 |
| eks.amazonaws.com/instance-gpu-count | 1 | 執行個體上的 GPU 數 |
| eks.amazonaws.com/instance-gpu-memory | 16384 | GPU 上的記憶體 MiB 數 |
| eks.amazonaws.com/instance-local-nvme | 900 | 執行個體上本機 nvme 儲存體的 GiB 數 |
**注意**
EKS 自動模式僅支援特定執行個體，且具有最小大小需求。如需詳細資訊，請參閱 [EKS 自動模式支援的執行個體參考](automode-learn-instances.md#auto-supported-instances)。
## EKS 自動模式不支援的標籤
EKS 自動模式不支援以下標籤。
+ EKS 自動模式僅支援 Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## 停用內建節點集區
如果您建立了自訂節點集區，可以停用內建節點集區。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。
## 沒有內建節點集區的叢集
您可建立沒有內建節點集區的叢集。當您的組織已建立自訂節點集區時，這會很有幫助。
**注意**
當您建立沒有內建節點集區的叢集時，`default` NodeClass 不會自動佈建。您需要建立自訂的 NodeClass。如需詳細資訊，請參閱 [建立 Amazon EKS 的節點類別](create-node-class.md)。
**概觀**
1. 建立 EKS 叢集，其 `nodePools` 和 `nodeRoleArn` 值均為空。
+ 範例 eksctl `autoModeConfig`：
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
如需詳細資訊，請參閱[使用 eksctl CLI 建立 EKS 自動模式叢集](automode-get-started-eksctl.md)
1. 使用節點角色 ARN 建立自訂節點類別
+ 如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)
1. 為自訂節點類別建立存取項目
+ 如需詳細資訊，請參閱[建立節點類別存取項目](create-node-class.md#auto-node-access-entry)
1. 如上所述，建立自訂節點集區。
## 中斷
您可透過多種方式設定 EKS 自動模式，以透過您的 NodePool 來中斷節點。您可以使用 `spec.disruption.consolidationPolicy`、`spec.disruption.consolidateAfter` 或 `spec.template.spec.expireAfter`。您還可以透過 NodePool 的 `spec.disruption.budgets` 來限制 EKS 自動模式的中斷速率。您還可以控制時間範圍和同時中斷的節點數量。有關設定此行為的說明，請參閱 Karpenter 文件中的[中斷](https://karpenter.sh/docs/concepts/disruption/)。
您可將節點集區的中斷設定為：
+ 識別執行個體未得到充分利用的時間，並合併工作負載。
+ 建立節點集區中斷預算，以限制因偏離、空置和合併而導致的節點終止速率。
根據預設，EKS 自動模式：
+ 合併未充分利用的執行個體。
+ 在 336 小時後終止執行個體。
+ 設定單一中斷預算為節點的 10%。
+ 當新的自動模式 AMI 發布時，允許因偏離而取代節點，這大約每週發生一次。
## 終止寬限期
當 `terminationGracePeriod` 未在 EKS Auto NodePool 上明確定義時，系統會自動將預設的 24 小時終止寬限期套用到關聯的 NodeClaim。雖然 EKS Auto 不會在其自訂 NodePool 組態中看到預設的 `terminationGracePeriod`，但他們會在 NodeClaim 上觀察到此預設值。無論寬限期是在 NodePool 上明確設定，還是在 NodeClaim 上預設，功能都保持一致，確保了叢集中可預測的節點終止行為。
# EKS Auto 模式的靜態容量節點集區
Amazon EKS Auto Mode 支援靜態容量節點集區，無論 Pod 需求為何，都能維持固定數量的節點。靜態容量節點集區適用於需要可預測容量、預留執行個體或特定合規需求的工作負載，而您需要維持一致的基礎設施使用量。
與根據 Pod 排程需求擴展的動態節點集區不同，靜態容量節點集區會維持您已設定的節點數量。
## 設定靜態容量節點集區
若要建立靜態容量節點集區，請在 NodePool 規格中設定 `replicas` 欄位。`replicas` 欄位定義節點集區將維護的確切節點數量。如需如何設定 [範例](#static-capacity-examples)，請參閱 `replicas`。
## 靜態容量節點集區考量事項
靜態容量節點集區有幾項重要的限制條件和行為：
**組態限制：**
+ **無法切換模式**：在節點集區`replicas`上設定後，就無法將其移除。節點集區無法在靜態和動態模式之間切換。
+ **資源限制**：限制區段僅支援 `limits.nodes` 欄位。CPU 和記憶體限制不適用。
+ **無權重欄位**：由於節點選擇不是根據優先順序，因此無法在靜態容量節點集區上設定 `weight` 欄位。
**操作行為：**
+ **無合併**：靜態容量集區中的節點不會考慮合併。
+ **擴展操作**：擴展操作會略過節點中斷預算，但仍遵守 PodDisruptionBudgets。
+ **節點替換**：節點仍會根據您的組態替換成偏離 （例如 AMI 更新） 和過期。
## 最佳實務
**容量規劃：**
+ 設定`limits.nodes`高於 `replicas` 以允許在節點取代操作期間暫時擴展。
+ 設定限制時，請考慮節點偏離或 AMI 更新期間所需的最大容量。
**執行個體選擇：**
+ 當您有預留執行個體或特定硬體需求時，請使用特定執行個體類型。
+ 避免在擴展期間限制執行個體可用性的過度限制需求。
**中斷管理：**
+ 設定適當的中斷預算，以平衡可用性與維護操作。
+ 設定預算百分比時，請考慮您應用程式的節點替換公差。
**監控：**
+ 定期監控 `status.nodes` 欄位，以確保維持所需的容量。
+ 設定實際節點計數偏離所需複本時的提醒。
**區域分佈：**
+ 為了實現高可用性，請將靜態容量分散到多個可用區域。
+ 當您建立跨越多個可用區域的靜態容量節點集區時，EKS Auto Mode 會將節點分散到指定區域，但不保證分佈均勻。
+ 若要跨可用區域進行可預測且均勻的分佈，請建立個別的靜態容量節點集區，每個集區都會使用 `topology.kubernetes.io/zone`需求固定到特定的可用區域。
+ 如果您需要將 12 個節點平均分散到三個區域，請建立三個節點集區，每個節點集區各有 4 個複本，而不是一個節點集區，在三個區域各有 12 個複本。
## 擴展靜態容量節點集區
您可以使用 `kubectl scale`命令變更靜態容量節點集區中的複本數量：
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
縮減規模時，EKS Auto Mode 會正常終止節點，遵守 PodDisruptionBudgets，並允許將執行中的 Pod 重新排程到剩餘的節點。
## 監控靜態容量節點集區
使用下列命令來監控靜態容量節點集區：
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes` 欄位顯示節點集區管理的目前節點數量，在正常情況下應符合您所需的`replicas`計數。
## 疑難排解
**未到達所需複本的節點：**
+ 檢查`limits.nodes`值是否足夠
+ 確認您的需求不會過度限制執行個體選取
+ 檢閱您正在使用的執行個體類型和區域的 AWS 服務配額
**節點替換耗時太長：**
+ 調整中斷預算以允許更多並行取代
+ 檢查 PodDisruptionBudgets 是否阻止節點終止
**非預期的節點終止：**
+ 檢閱 `expireAfter`和 `terminationGracePeriod`設定
+ 檢查手動節點終止或 AWS 維護事件
## 範例
### 基本靜態容量節點集區
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### 具有特定執行個體類型的靜態容量
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### 多區域靜態容量節點集區
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### 具有容量保留的靜態容量
下列範例示範如何搭配 EC2 容量保留使用靜態容量節點集區。如需搭配 EKS Auto 模式使用 EC2 容量預留的詳細資訊，請參閱 [使用 EKS 自動模式控制工作負載部署至容量保留](auto-odcr.md)。
`NodeClass` 定義 `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool` 使用 參考上述 `NodeClass`和 `karpenter.sh/capacity-type: reserved`。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# 建立 IngressClass 以設定 Application Load Balancer
EKS 自動模式會自動執行負載平衡的常規任務，包括將叢集應用程式公開至網際網路。
AWS 建議使用 Application Load Balancer (ALB) 來提供 HTTP 和 HTTPS 流量。Application Load Balancer 可根據請求的內容路由請求。如需 Application Load Balancer 的詳細資訊，請參閱[什麼是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
EKS 自動模式會建立與設定 Application Load Balancer (ALB)。例如，當您建立一個 `Ingress` Kubernetes 物件時，EKS 自動模式會建立一個負載平衡器，並將其設定為將流量路由至叢集工作負載。
**概觀**
1. 建立您想要公開到網際網路的工作負載。
1. 建立 `IngressClassParams` 資源，指定 AWS 特定組態值，例如用於 SSL/TLS 和 VPC 子網路的憑證。
1. 建立 `IngressClass` 資源，指定 EKS 自動模式將作為該資源的控制器。
1. 建立 `Ingress` 資源，將 HTTP 路徑和連接埠與叢集工作負載關聯起來。
EKS 自動模式將建立 Application Load Balancer，指向 `Ingress` 資源中指定的工作負載，並使用在 `IngressClassParams` 資源中指定的負載平衡器配置。
## 先決條件
+ Amazon EKS 叢集上已啟用 EKS 自動模式
+ Kubectl 已設定為連接到您的叢集
+ 您可使用 `kubectl apply -f `，將以下範例組態 YAML 檔案套用至您的叢集。
**注意**
EKS 自動模式需要子網路標籤來識別公有和私有子網路。
若您使用 `eksctl` 建立叢集，則您已具備這些標籤。
了解如何 [標記 EKS 自動模式的子網路](tag-subnets-auto.md)。
## 步驟 1：建立工作負載
首先，建立您想要公開到網際網路的工作負載。此工作負載可為任何處理 HTTP 流量的 Kubernetes 資源，例如部署或服務。
此範例使用名為 `service-2048` 的簡單 HTTP 服務，其接聽連接埠 `80`。透過套用下列資訊清單 `2048-deployment-service.yaml`，建立此服務及其部署：
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
將組態套用至您的叢集：
```
kubectl apply -f 2048-deployment-service.yaml
```
上面列出的資源將在預設命名空間中建立。您可以透過執行以下命令來進行確認：
```
kubectl get all -n default
```
## 步驟 2：建立 IngressClassParams
建立 `IngressClassParams` 物件以指定 Application Load Balancer AWS 的特定組態選項。在本範例中，我們在名為 `alb-ingressclassparams.yaml` 的檔案中，建立名為 `alb` 的 `IngressClassParams` 資源 (您將在下一步中使用)，並指定負載平衡器方案為 `internet-facing`。
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
將組態套用至您的叢集：
```
kubectl apply -f alb-ingressclassparams.yaml
```
## 步驟 3：建立 IngressClass
建立 `IngressClass`，參考名為 的檔案中`IngressClassParams`資源中設定 AWS 的特定組態值`alb-ingressclass.yaml`。請記下 `IngressClass` 的名稱。在此範例中，`IngressClass` 和 `IngressClassParams` 都命名為 `alb`。
使用 `is-default-class` 註釋來控制 `Ingress` 資源是否預設使用此類別。
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
關於設定選項的詳細資訊，請參閱 [IngressClassParams 參考](#ingress-reference)。
將組態套用至您的叢集：
```
kubectl apply -f alb-ingressclass.yaml
```
## 步驟 4：建立傳入
在名為 `alb-ingress.yaml` 的檔案中建立 `Ingress` 資源。此資源的用途是將 Application Load Balancer 上的路徑與連接埠，與您叢集中的工作負載相關聯。在此範例中，我們建立名為 `Ingress` 的資源 `2048-ingress`，將其流量路由到連接埠 80 上名為 `service-2048` 的服務。
如需關於設定資源的詳細資訊，請參閱 Kubernetes 文件中的[傳入](https://kubernetes.io/docs/concepts/services-networking/ingress/)。
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
將組態套用至您的叢集：
```
kubectl apply -f alb-ingress.yaml
```
## 步驟 5：檢查狀態
使用 `kubectl` 尋找 `Ingress` 的狀態。負載平衡器可能需要幾分鐘才能就緒。
使用您在上一步中設定的 `Ingress` 資源名稱。例如：
```
kubectl get ingress 2048-ingress
```
資源就緒後，擷取負載平衡器的網域名稱。
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
要在 Web 瀏覽器中檢視服務，請檢閱 `Ingress` 救援中指定的連接埠與路徑。
## 步驟 6：清除
要清理負載平衡器，請使用以下命令：
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS Auto Mode 會自動刪除您 AWS 帳戶中相關聯的負載平衡器。
## IngressClassParams 參考
下表屬於常用組態選項的快速參考。
| 欄位 | Description | 範例值 |
| --- | --- | --- |
| `scheme` | 定義 ALB 是內部，還是可面向網際網路 | `internet-facing` |
| `namespaceSelector` | 限制哪些命名空間可使用此 IngressClass | `environment: prod` |
| `group.name` | 將多個傳入分組，以共用單一 ALB | `retail-apps` |
| `ipAddressType` | 設定 ALB 的 IP 位址類型 | `dualstack` |
| `subnets.ids` | 用於 ALB 部署的子網路 ID 清單 | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | 用於選擇 ALB 子網路的標籤篩選器 | `Environment: prod` |
| `certificateARNs` | 要使用的 SSL 憑證 ARN | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | AWS 資源的自訂標籤 | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | 負載平衡器特定屬性 | `idle_timeout.timeout_seconds: 60` |
## 考量事項
+ 您無法使用 IngressClass 上的註釋來設定 EKS 自動模式的負載平衡器。IngressClass 組態應該透過 IngressClassParams 完成。不過，您可以在個別輸入資源上使用註釋來設定負載平衡器行為 （例如 `alb.ingress.kubernetes.io/security-group-prefix-lists`或 `alb.ingress.kubernetes.io/conditions.*`)。
+ 您無法使用 EKS 自動模式來設定 [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)。
+ 您必須更新叢集 IAM 角色，才能啟用從 Kubernetes 到 AWS Load Balancer資源的標籤傳播。如需詳細資訊，請參閱[EKS Auto 資源的自訂 AWS 標籤](auto-cluster-iam-role.md#tag-prop)。
+ 如需將資源與 EKS Auto Mode 或 self-managed AWS Load Balancer Controller 建立關聯的資訊，請參閱 [移轉參考](migrate-auto.md#migration-reference)。
+ 有關修復負載平衡器問題的資訊，請參閱 [EKS 自動模式疑難排解](auto-troubleshoot.md)。
+ 有關使用 EKS 自動模式負載平衡功能的更多考量，請參閱 [Load balancing](auto-networking.md#auto-lb-consider)。
以下表格詳細比較了 EKS 自動模式中 IngressClassParams、傳入註釋和 TargetGroupBinding 組態的變更。這些資料表突顯了 EKS 自動模式的負載平衡功能與開放原始碼負載平衡器控制器之間的主要差異，包括 API 版本變更、已棄用的功能及更新的參數名稱。
### IngressClassParams
| 先前的 | 新增 | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本變更 |
| `spec.certificateArn` | `spec.certificateARNs` | 支援多個憑證 ARN |
| `spec.subnets.tags` | `spec.subnets.matchTags` | 變更子網路相符的結構描述 |
| `spec.listeners.listenerAttributes` | 不支援 | EKS 自動模式尚不支援 |
### 傳入註釋
| 先前的 | 新增 | Description |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | 不支援 | 在傳入物件上使用 `spec.ingressClassName` |
| `alb.ingress.kubernetes.io/group.name` | 不支援 | 僅在 IngressClass 中指定群組 |
| `alb.ingress.kubernetes.io/waf-acl-id` | 不支援 | 請改用 WAF v2 |
| `alb.ingress.kubernetes.io/web-acl-id` | 不支援 | 請改用 WAF v2 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | 不支援 | Shield 整合已停用 |
| `alb.ingress.kubernetes.io/auth-type: oidc` | 不支援 | 目前不支援 OIDC 驗證類型 |
### TargetGroupBinding
| 先前的 | 新增 | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本變更 |
| `spec.targetType` 選用 | `spec.targetType` 必要 | 明確的目標類型規格 |
| `spec.networking.ingress.from` | 不支援 | 不再支援沒有安全群組的 NLB |
若要使用自訂 TargetGroupBinding 功能，您必須使用叢集名稱的 eks：eks-cluster-name 標籤來標記目標群組，以授予控制器必要的 IAM 許可。請注意，刪除 TargetGroupBinding 資源或叢集時，控制器會刪除目標群組。
# 使用服務注釋設定 Network Load Balancer
了解如何使用 Kubernetes 服務註釋，在 Amazon EKS 中設定 Network Load Balancer (NLB)。本主題解釋了 EKS 自動模式支援用於自訂 NLB 行為的註釋，包括網際網路可存取性、運作狀態檢查、SSL/TLS 終止及 IP 目標模式。
當您在 EKS Auto Mode `LoadBalancer`中建立 類型的 Kubernetes 服務時，EKS 會根據您指定的註釋自動佈建和設定 AWS Network Load Balancer。這種宣告式方法允許您直接透過 Kubernetes 資訊清單來管理負載平衡器組態，維持基礎結構即程式碼的實踐。
EKS 自動模式預設為處理所有 LoadBalancer 類型服務的 Network Load Balancer 佈建 - 無需安裝或設定額外的控制器。`loadBalancerClass: eks.amazonaws.com/nlb` 規格被自動設定為叢集預設值，簡化了部署程序，同時保持了與現有 Kubernetes 工作負載的相容性。
**注意**
EKS 自動模式需要子網路標籤來識別公有和私有子網路。
若您使用 `eksctl` 建立叢集，則您已具備這些標籤。
了解如何 [標記 EKS 自動模式的子網路](tag-subnets-auto.md)。
## 範例服務
如需有關 Kubernetes `Service` 資源的詳細資訊，請參閱 [Kubernetes 文件中](https://kubernetes.io/docs/concepts/services-networking/service/)。
請檢閱下面的範例 `Service` 資源：
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## 常用註釋
下表列出 EKS 自動模式支援的常用註釋。請注意，EKS 自動模式可能不支援所有註釋。
**提示**
下列所有註釋都需要加上字首 `service.beta.kubernetes.io/`
| 欄位 | Description | 範例 |
| --- | --- | --- |
| `aws-load-balancer-type` | 指定負載平衡器類型。將 `external` 用於新的部署。 | `external` |
| `aws-load-balancer-nlb-target-type` | 指定是將流量路由到節點執行個體，還是直接路由到 Pod IP。將 `instance` 用於標準部署，或將 `ip` 用於直接 Pod 路由。 | `instance` |
| `aws-load-balancer-scheme` | 控制負載平衡器是內部或是面向網際網路。 | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | 目標群組的運作狀態檢查通訊協定。常見選項是 `TCP` (預設) 或 `HTTP`。 | `HTTP` |
| `aws-load-balancer-healthcheck-path` | 使用 HTTP/HTTPS 通訊協定時，用於運作狀態檢查的 HTTP 路徑。 | `/healthz` |
| `aws-load-balancer-healthcheck-port` | 用於運作狀態檢查的連接埠。可以是特定連接埠號碼或 `traffic-port`。 | `traffic-port` |
| `aws-load-balancer-subnets` | 指定要在哪些子網路中建立負載平衡器。可使用子網路 ID 或名稱。 | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | 來自 AWS Certificate Manager for HTTPS/TLS 的 SSL 憑證 ARN。 | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | 指定哪些連接埠應使用 SSL/TLS。 | `443, 8443` |
| `load-balancer-source-ranges` | 允許存取負載平衡器的 CIDR 範圍。 | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | 要套用至負載平衡器和相關資源的其他 AWS 標籤。 | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | 指定負載平衡器是使用 IPv4，還是雙堆疊 (IPv4 \$1 IPv6)。 | `ipv4` 或 `dualstack` |
## 考量事項
+ 您必須更新叢集 IAM 角色，才能啟用從 Kubernetes 到 AWS Load Balancer資源的標籤傳播。如需詳細資訊，請參閱[EKS Auto 資源的自訂 AWS 標籤](auto-cluster-iam-role.md#tag-prop)。
+ 如需將資源與 EKS Auto Mode 或 self-managed AWS Load Balancer Controller 建立關聯的資訊，請參閱 [移轉參考](migrate-auto.md#migration-reference)。
+ 有關修復負載平衡器問題的資訊，請參閱 [EKS 自動模式疑難排解](auto-troubleshoot.md)。
+ 有關使用 EKS 自動模式負載平衡功能的更多考量，請參閱 [Load balancing](auto-networking.md#auto-lb-consider)。
當移轉至 EKS 自動模式進行負載平衡時，服務註釋與資源組態中需要進行多項變更。以下表格概述了先前與新實作之間的關鍵差異，包括不支援的選項和推薦的替代方案。
### 服務註釋
| 先前的 | 新增 | Description |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | 不支援 | 在服務上使用 `spec.loadBalancerSourceRanges` |
| `service.beta.kubernetes.io/aws-load-balancer-type` | 不支援 | 在服務上使用 `spec.loadBalancerClass` |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | 不支援 | 使用 `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` |
| 各種負載平衡器屬性 | 不支援 | 使用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` |
要從已棄用的負載平衡器屬性註釋移轉，請將這些設定合併至 `service.beta.kubernetes.io/aws-load-balancer-attributes` 註釋中。此註釋接受逗號分隔的鍵值對清單，用於各種負載平衡器屬性。例如，若要指定存取記錄和跨區域負載平衡，請使用下列格式：
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
這種合併格式提供了一種更一致、更靈活的方式來設定負載平衡器屬性，同時減少了所需單獨注釋的數量。請檢閱您現有的服務組態，並將其更新為使用此合併格式。
### TargetGroupBinding
| 先前的 | 新增 | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本變更 |
| `spec.targetType` 選用 | `spec.targetType` 必要 | 明確的目標類型規格 |
| `spec.networking.ingress.from` | 不支援 | 不再支援沒有安全群組的 NLB |
注意：若要使用自訂 TargetGroupBinding 功能，您必須使用叢集名稱的`eks:eks-cluster-name`標籤來標記目標群組，以授予控制器必要的 IAM 許可。請注意，刪除 TargetGroupBinding 資源或叢集時，控制器會刪除目標群組。
# 建立儲存類別
在 Amazon EKS 自動模式中，`StorageClass` 定義了當應用程式請求持久性儲存時，如何自動佈建 Amazon EBS 磁碟區。本頁面闡釋了如何建立和設定與 Amazon EKS 自動模式協同工作的 `StorageClass`，以佈建 EBS 磁碟區。
透過設定 `StorageClass`，您可為 EBS 磁碟區指定預設設定，包括磁碟區類型、加密、IOPS 和其他儲存參數。您也可以`StorageClass`將 設定為使用 AWS KMS 金鑰進行加密管理。
EKS 自動模式不會為您建立 `StorageClass`。您必須建立 `StorageClass` 參考 `ebs.csi.eks.amazonaws.com`，以使用 EKS 自動模式的儲存功能。
首先，建立名為 `storage-class.yaml` 的檔案：
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
接著，將儲存體方案套用至您的叢集。
```
kubectl apply -f storage-class.yaml
```
**關鍵元件：**
+ `provisioner: ebs.csi.eks.amazonaws.com` - 使用 EKS 自動模式
+ `allowedTopologies` - 指定 `eks.amazonaws.com/compute-type:auto` 來匹配 `matchLabelExpressions`，將確保如果您的 Pod 需要使用自動模式自動佈建磁碟區，則這些 Pod 不會被排程到非自動節點上。
+ `volumeBindingMode: WaitForFirstConsumer` - 延遲建立磁碟區，直至 Pod 需要磁碟區
+ `type: gp3` - 指定 EBS 磁碟區類型
+ `encrypted: "true"` - EBS 將加密使用此 `StorageClass` 建立的所有磁碟區。EBS 將使用預設的 `aws/ebs` 金鑰別名。如需詳細資訊，請參閱《Amazon EBS 使用者指南》中的 [Amazon EBS 加密運作方式](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html)。此值可選用的，但建議設定。
+ `storageclass.kubernetes.io/is-default-class: "true"` - 依預設，Kubernetes 將使用此儲存類別，除非您在持續性磁碟區宣告上指定了不同的磁碟區類別。此值是選用的。若要從其他儲存控制器移轉，則在設定該值時要謹慎對待。
## 使用自我管理的 KMS 金鑰加密 EBS 磁碟區
要使用自我管理的 KMS 金鑰來加密由 EKS 自動模式自動佈建的 EBS 磁碟區，您需要：
1. 建立自我管理的 KMS 金鑰。
+ 如需詳細資訊，請參閱《KMS 使用者指南》中的[建立對稱加密 KMS 金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html)或 [Amazon Elastic Block Store (Amazon EBS) 如何使用 KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)。
1. 建立一個允許存取 KMS 金鑰的新政策。
+ 使用下面的範例 IAM 政策來建立該政策。插入新的自我管理 KMS 金鑰的 ARN。如需詳細資訊，請參閱《IAM 使用者指南》中的[建立角色和連接政策 （主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)。 AWS
1. 將政策附加到 EKS 叢集角色。
+ 使用 AWS 主控台尋找 EKS 叢集角色的 ARN。角色資訊在**概覽**區段中可見。如需詳細資訊，請參閱[Amazon EKS 叢集 IAM 角色](cluster-iam-role.md)。
1. 更新 `StorageClass`，以參考 `parameters.kmsKeyId` 欄位的 KMS 金鑰 ID。
### 自我管理 KMS IAM 政策範例
更新下方政策中的以下值：
+ `` – AWS 您的帳戶 ID，例如 `111122223333`
+ `` – 叢集 AWS 的區域，例如 `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### 自我管理的 KMS `StorageClass` 範例
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass` 參數參考
有關 Kubernetes `StorageClass` 資源的一般資訊，請參閱 Kubernetes 文件中的[儲存類別](https://kubernetes.io/docs/concepts/storage/storage-classes/)。
`StorageClass` 資源的 THe `parameters`區段是特定的 AWS。請使用下列資料表檢閱可用的選項。
| Parameters | 值 | 預設 | Description |
| --- | --- | --- | --- |
| "csi.storage.k8s.io/fstype" | xfs、ext2、ext3、ext4 | ext4 | 在磁碟區建立期間將被格式化的檔案系統類型。此參數有大小寫之分！ |
| "type" | io1、io2、gp2、gp3、sc1、st1、Standard、sbp1、sbg1 | gp3 | EBS 磁碟區類型。 |
| "iopsPerGB" | | | 每 GiB 的每秒 I/O 操作次數。可為 IO1、IO2 和 GP3 磁碟區指定。 |
| "allowAutoIOPSPerGBIncrease" | true、false | false | 當 時`"true"`，當 `iopsPerGB * ` 太低而無法符合 支援的 IOPS 範圍時，CSI 驅動程式會增加磁碟區的 IOPS AWS。這可讓動態佈建總是成功，即使使用者指定的 PVC 容量或 `iopsPerGB` 值太小。另一方面，這可能會帶來額外成本，因為此類磁碟區的 IOPS 比 `iopsPerGB` 中請求的要高。 |
| "iops" | | | 每秒 I/O 操作。可為 IO1、IO2 和 GP3 磁碟區指定。 |
| "throughput" | | 125 | 輸送量以 MiB/秒為單位。僅在指定了 gp3 磁碟區類型時有效。 |
| "encrypted" | true、false | false | 指示是否加密磁碟區。有效值為 "true" 或 "false"。 |
| "blockExpress" | true、false | false | 啟用 io2 Block Express 磁碟區的建立。 |
| "kmsKeyId" | | | 加密磁碟區時要使用的金鑰的完整 ARN。如果未指定， AWS 將針對磁碟區所在的區域使用預設 KMS 金鑰。如果未變更，這將是一個自動產生的金鑰，稱為 `/aws/ebs`。 |
| "blockSize" | | | 格式化底層檔案系統時使用的區塊大小。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 或 `xfs` 時支援。 |
| "inodeSize" | | | 格式化底層檔案系統時使用的 inode 大小。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 或 `xfs` 時支援。 |
| "bytesPerInode" | | | 格式化底層檔案系統時使用的 `bytes-per-inode`。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 時支援。 |
| "numberOfInodes" | | | 格式化底層檔案系統時使用的 `number-of-inodes`。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 時支援。 |
| "ext4BigAlloc" | true、false | false | 透過啟用 `bigalloc` 格式化選項，將 `ext4` 檔案系統變更為使用叢集區塊配置。警告：您的節點 Linux 核心可能不完全支援 `bigalloc`。 |
| "ext4ClusterSize" | | | 當啟用 `bigalloc` 功能時，格式化 `ext4` 檔案系統所使用的叢集大小。請注意：`ext4BigAlloc` 參數必須設為 true。 |
如需詳細資訊，請參閱 GitHub 上的 [AWS EBS CSI 驅動程式](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)。
## 考量事項
**注意**
您只能在 EKS 自動模式節點上，部署依賴於 EKS 自動模式 StorageClass 的工作負載。如果您有一個混合類型節點的叢集，需要設定您的工作負載僅在 EKS 自動模式節點上執行。如需詳細資訊，請參閱[控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)。
EKS 自動模式的區塊儲存功能與 EBS CSI 驅動程式不同。
+ 靜態佈建
+ 如果您想要搭配 EKS Auto 模式使用外部建立的 EBS 磁碟區，則需要手動新增具有 金鑰`eks:eks-cluster-name`和叢集名稱值的 AWS 標籤。
+ 節點啟動污點
+ 您無法使用節點啟動污點功能，以在儲存功能準備就緒之前防止 Pod 排程
+ 動態佈建磁碟區上的自訂標籤
+ 您無法使用 extra-tag CLI 標誌來設定動態佈建 EBS 磁碟區上的自訂標籤
+ 您可使用 `StorageClass` 標記來新增自訂標籤。EKS Auto Mode 會將標籤新增至相關聯的 AWS 資源。您需要更新叢集 IAM 角色以用於自訂標籤。如需詳細資訊，請參閱[EKS Auto 資源的自訂 AWS 標籤](auto-cluster-iam-role.md#tag-prop)。
+ EBS 詳細效能指標
+ 您無法存取 EBS 詳細效能的 Prometheus 指標
## 安裝 CSI 快照控制器附加元件
EKS 自動模式與 CSI 快照控制器 Amazon EKS 附加元件相容。
AWS 建議您將此附加元件設定為在內建`system`節點集區上執行。
如需詳細資訊，請參閱：
+ [在專用執行個體上執行關鍵附加元件](critical-workload.md)
+ [啟用或停用內建的 NodePool](set-builtin-node-pools.md)
+ [啟用 CSI 磁碟區的快照功能](csi-snapshot-controller.md)
### 在系統節點集區中安裝快照控制器
1. 在 AWS 主控台中開啟您的 EKS 叢集
1. 從**附加元件**索引標籤中，選取**取得更多附加元件**
1. 選取 **CSI 快照控制器**，然後選擇**下一步**
1. 在**設定選取的附加元件設定**頁面上，選取**選用組態設定**，以檢視**附加元件組態結構描述**
1. 插入以下 yaml 以將快照控制器與 `system` 節點集區關聯。快照控制器包含對 `CriticalAddonsOnly` 污點的容錯。
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. 選取**下一步**
1. 檢閱附加元件組態，然後選取**建立**
# 停用 EKS 自動模式
您可以在現有的 EKS 叢集上停用 EKS 自動模式。這是破壞性的操作。
+ EKS 將終止由 EKS 自動模式操作的所有 EC2 執行個體。
+ EKS 將刪除由 EKS 自動模式操作的所有負載平衡器。
+ EKS **不會**刪除由 EKS 自動模式佈建的 EBS 磁碟區。
EKS 自動模式旨在完整管理其所建立的資源。手動介入可能導致 EKS 自動模式在停用時無法完全清除這些資源。例如，如果您從外部安全群組規則中參照了受管安全群組，並且在為叢集停用 EKS Auto Mode 之前忘記移除該參照，則受管安全群組將洩漏 (不會被刪除)。以下步驟說明若發生此情形，如何移除遺漏的安全群組。
## 停用 EKS 自動模式AWS （主控台）
1. 在 AWS 管理主控台中開啟您的叢集概觀頁面。
1. 在 **EKS 自動模式**下，選取**管理**
1. 將 **EKS 自動模式**切換為 `off`。
如果在此程序結束時有任何受管安全群組未被刪除，您可使用[刪除安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html)中的說明手動將其刪除。
## 停用 EKS 自動模式 (AWS CLI)
使用以下命令在現有叢集上停用 EKS 自動模式。
您需要安裝 `aws` CLI，並使用足夠的許可來登入以管理 EKS 叢集。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
**注意**
運算、區塊儲存和負載平衡功能必須在同一請求中全部啟用或停用。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
您可按照以下方式檢查在停用 EKS 自動模式後，是否有遺漏的 EKS 自動模式安全群組未能被刪除：
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
然後刪除安全群組：
```
aws ec2 delete-security-group --group-name=
```
# 更新 EKS 自動模式叢集的 Kubernetes 版本
本主題闡釋如何更新自動模式叢集的 Kubernetes 版本。自動模式透過處理控制平面更新與節點取代的協調來簡化版本更新程序，同時透過 Pod 中斷預算維持工作負載可用性。
升級自動模式叢集時，許多傳統上需要手動更新的元件現在作為服務的一部分進行管理。了解升級程序的自動化層面與您的責任，有助於確保叢集的版本順利轉換。
## 了解 EKS 自動模式的更新
在您啟動控制平面升級後，EKS 自動模式會升級叢集中的節點。當節點到期時，EKS 自動模式會用新節點取代。新節點具有相應的新 Kubernetes 版本。升級節點時，EKS 自動模式會遵守 Pod 中斷預算。
此外，您不再需要更新下列元件：
+ Amazon VPC CNI
+ AWS Load Balancer 控制器
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS EBS CSI 驅動程式
EKS 自動模式會以服務功能取代這些元件。
您仍然負責更新：
+ 部署到您的叢集的應用程式與工作負載
+ 自我管理的附加元件與控制器
+ Amazon EKS 附加元件
+ 了解如何 [更新 Amazon EKS 附加元件](updating-an-add-on.md)
了解[叢集升級的最佳實務](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## 啟動叢集更新
要開始叢集更新，請參閱 [將現有叢集更新至全新 Kubernetes 版本](update-cluster.md)。
# 啟用或停用內建的 NodePool
EKS 自動模式具有兩個內建的 NodePool。您可以使用 AWS 主控台、CLI 或 API 啟用或停用這些 NodePools。
## 內建的 NodePool 參考
+ `system`
+ 此 NodePool 具有 `CriticalAddonsOnly` 污點。CoreDNS 等眾多 EKS 附加元件皆可容忍此污點。藉助此系統節點集區，來分隔叢集關鍵型應用程式。
+ 支援 `amd64` 與 `arm64` 架構。
+ `general-purpose`
+ 針對叢集中的一般用途工作負載，此 NodePool 提供啟動節點相關支援。
+ 只能使用 `amd64` 架構。
兩個內建的 NodePool：
+ 使用預設的 EKS NodeClass
+ 只能使用隨需 EC2 容量
+ 使用 C、M 及 R EC2 執行個體系列
+ 要求使用第 5 代或更新版本的 EC2 執行個體
**注意**
EKS 需要啟用至少一個內建的 NodePool，才能佈建「預設」NodeClass。若停用全部內建的 NodePool，需要建立自訂 NodeClass 及設定 NodePool 才能使用。若要了解 NodeClass 的相關資訊，請參閱 [建立 Amazon EKS 的節點類別](create-node-class.md)。
## 程序
### 先決條件
+ 在您裝置上安裝和設定的最新版本 AWS 命令列界面 (AWS CLI)。若要檢查您目前的版本，請使用 `aws --version`。若要安裝最新版本，請參閱《 AWS 命令列界面使用者指南》中的使用 aws 設定[安裝](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 和[快速組態](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)。
+ 使用足夠的 IAM 許可登入 CLI，以建立 AWS 資源，包括 IAM 政策、IAM 角色和 EKS 叢集。
### 使用 CLI AWS 啟用
使用以下命令，啟用兩個內建的 NodePool：
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
您可修改命令，選擇性地啟用 NodePools。
### 使用 AWS CLI 停用
使用以下命令，停用兩個內建的 NodePool：
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# 控制工作負載是否部署在 EKS 自動模式節點上
在包含 EKS 自動模式的 EKS 叢集中執行工作負載時，您可能需要控制特定工作負載是否應在 EKS 自動模式節點，還是其他運算類型上執行。本主題描述如何使用節點選擇器與親和性，以確保您的工作負載被排程到預期的運算基礎結構上。
本主題中的範例示範如何使用 `eks.amazonaws.com/compute-type` 標籤，以要求或阻止工作負載部署到 EKS 自動模式節點上。這在混合模式叢集中特別有用，例如您同時執行了 EKS 自動模式和其他運算類型 (例如自我管理的 Karpenter 佈建程式或 EKS 受管節點群組) 的環境。
EKS 自動模式節點已將標籤 `eks.amazonaws.com/compute-type` 的值設定為 `auto`。您可使用此標籤來控制工作負載是否要部署到由 EKS 自動模式管理的節點。
## 要求工作負載部署至 EKS 自動模式節點
**注意**
此 `nodeSelector` 值對於 EKS 自動模式並非必要。此 `nodeSelector` 僅在您於混合模式中執行叢集時 (即叢集中包含非 EKS 自動模式管理的節點類型時) 才相關。例如，您可能已透過 EKS 受管節點群組將靜態運算容量部署到叢集中，同時也擁有由 EKS 自動模式管理的動態運算容量。
您可將此 `nodeSelector` 新增至部署或其他工作負載中，以要求 Kubernetes 將其排程到 EKS 自動模式節點上。
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## 要求工作負載不部署至 EKS 自動模式節點
您可將此 `nodeAffinity` 新增至部署或其他工作負載中，以要求 Kubernetes **不要**將其排程到 EKS 自動模式節點上。
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# 在專用執行個體上執行關鍵附加元件
在本主題中，您將了解如何部署具有 `CriticalAddonsOnly` 容差的工作負載，以便 EKS 自動模式將其排程到 `system` 節點集區上。
EKS 自動模式的內建 `system` 節點集區專為在專用執行個體上執行關鍵附加元件而設計。這種隔離確保了關鍵元件擁有專用資源，並與一般工作負載隔離開，從而提升了叢集的整體穩定性與效能。
本指南示範如何透過使用 `CriticalAddonsOnly` 容差和適當的節點選擇器，將附加元件部署到 `system` 節點集區。遵循這些步驟，您可以確保您的關鍵應用程式被排程到專用的 `system` 節點上，充分利用 EKS 自動模式的專用節點集區結構所帶來的隔離與資源分配優勢。
EKS 自動模式有兩個內建節點集區：`general-purpose` 和 `system`。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。
`system` 節點集區的用途是將關鍵附加元件隔離到不同的節點上。節點集區佈建的 `system` 節點帶有 `CriticalAddonsOnly` Kubernetes 污點。Kubernetes 只會將具有相應容差的 Pod 排程到這些節點上。如需詳細資訊，請參閱 Kubernetes 文件中的[污點和容差](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。
## 先決條件
+ 已啟用內建 `system` 節點集區的 EKS 自動模式叢集。如需詳細資訊，請參閱[啟用或停用內建的 NodePool](set-builtin-node-pools.md)
+ `kubectl` 已安裝並已設定。如需詳細資訊，請參閱 [設定以使用 Amazon EKS](setting-up.md)。
## 程序
請檢閱以下的範例 yaml。記下下列組態：
+ `nodeSelector`：這會將工作負載與內建的 `system` 節點集區建立關聯。此節點集區必須透過 AWS API 啟用。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。
+ `tolerations`：此容差用於克服 `system` 節點集區中節點上的 `CriticalAddonsOnly` 污點。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
要更新工作負載使其在 `system` 節點集區上執行，您需要：
1. 更新現有工作負載，以新增上述的下列組態：
+ `nodeSelector`
+ `tolerations`
1. 使用 `kubectl apply` 將更新後的工作負載部署到您的叢集
更新工作負載之後，它將在專用節點上執行。
# 在 EKS 自動模式中使用網路政策
## 概觀
隨著客戶使用 EKS 擴展其應用程式環境，網路流量隔離變得越來越基本，以防止未經授權存取叢集內外的資源。這在多租用戶環境中特別重要，其中多個不相關的工作負載在叢集中並排執行。Kubernetes 網路政策可讓您增強 Kubernetes 工作負載的網路安全狀態，以及其與叢集外部端點的整合。EKS Auto Mode 支援不同類型的網路政策。
### 第 3 層和第 4 層隔離
標準 Kubernetes 網路政策會在 OSI 網路模型的第 3 層和第 4 層運作，可讓您控制 Amazon EKS 叢集內 IP 地址或連接埠層級的流量流程。
#### 使用案例
+ 分割工作負載之間的網路流量，以確保只有相關的應用程式可以互相通訊。
+ 使用 政策在命名空間層級隔離租用戶，以強制執行網路分離。
### DNS 型強制執行
客戶通常會在 EKS 中部署屬於更廣泛分散式環境的工作負載，其中一些工作負載必須與叢集外部的系統和服務 （北向流量） 通訊。這些系統和服務可以 AWS 位於 AWS 雲端或外部。以網域名稱系統 (DNS) 為基礎的政策可讓您採用更穩定且可預測的方法來加強安全狀態，以防止未經授權的 Pod 存取叢集外部資源或端點。此機制不需要手動追蹤和允許列出特定 IP 地址。透過以 DNS 為基礎的方法保護資源，您還可以更靈活地更新外部基礎設施，而無需在上游伺服器和主機變更時放寬安全狀態或修改網路政策。您可以使用完整網域名稱 (FQDN) 或 DNS 網域名稱的相符模式，篩選外部端點的輸出流量。這可讓您靈活地擴展對與特定叢集外部端點相關聯的多個子網域的存取。
#### 使用案例
+ 標準化以 DNS 為基礎的方法，以篩選從 Kubernetes 環境到叢集外部端點的存取。
+ 安全存取多租戶環境中 AWS 的服務。
+ 管理混合雲端環境中從 Pod 到內部部署工作負載的網路存取。
### 管理員 （或叢集範圍） 規則
在某些情況下，如同多租戶案例，客戶可能需要強制執行適用於整個叢集的網路安全標準。您可以使用單一政策來集中管理叢集中不同工作負載的網路存取控制，而不重複定義和維護每個命名空間的不同政策，無論其命名空間為何。這些類型的政策可讓您擴展在第 3 層、第 4 層和使用 DNS 規則時套用之網路篩選規則的強制執行範圍。
#### 使用案例
+ 集中管理 EKS 叢集中所有 （或一部分） 工作負載的網路存取控制。
+ 定義整個叢集的預設網路安全狀態。
+ 以更具營運效率的方式，將組織安全標準擴展到叢集的範圍。
## 開始使用
### 先決條件
+ 已啟用 EKS 自動模式的 Amazon EKS 叢集
+ kubectl 已設定為連接到您的叢集
### 步驟 1：啟用網路政策控制器
要在 EKS 自動模式中使用網路政策，您首先需要透過將 ConfigMap 套用到您的叢集，以啟用網路政策控制器。
1. 建立名為 `enable-network-policy.yaml` 且具有下列內容的檔案：
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. 將 ConfigMap 套用至您的叢集：
```
kubectl apply -f enable-network-policy.yaml
```
### 步驟 2：建立和測試網路政策
您的 EKS 自動模式叢集現已設定為支援 Kubernetes 網路政策。您可利用 [Amazon EKS 的網路政策的星示範](network-policy-stars-demo.md) 來測試此功能。
### 步驟 3：調整節點類別中的網路政策代理程式組態 （選用）
您可以選擇性地建立新的節點類別，以變更節點上網路政策代理程式的預設行為，或啟用網路政策事件的記錄。若要這麼做，請依照下列步驟進行：
1. 建立或編輯節點類別 YAML 檔案 (例如 `nodeclass-network-policy.yaml`)，內容如下：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. 將節點類別組態套用至您的叢集：
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. 確認節點類別是否已建立：
```
kubectl get nodeclass network-policy-config
```
1. 更新您的節點集區，使其使用此節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
## 其運作方式？
### DNS 型網路政策
![\[在 EKS Auto 中套用 DNS 型政策時的工作流程圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[在 EKS Auto 中套用 DNS 型政策時的工作流程圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/apply-dns-policy-2.png)
1. 平台團隊會將 DNS 型政策套用至 EKS 叢集。
1. 網路政策控制器負責監控叢集內政策的建立，然後協調政策端點。在此使用案例中，網路政策控制器會指示節點代理程式，根據所建立政策中允許列出的網域來篩選 DNS 請求。允許使用 FQDN 或符合 Kubernetes 資源組態中定義模式的網域名稱來列出網域名稱。
1. 工作負載 嘗試解析叢集外部端點的 IP。DNS 請求會先經過代理，根據透過網路政策套用的允許清單來篩選這類請求。
1. 一旦 DNS 請求通過 DNS 篩選條件允許清單，它會代理至 CoreDNS，
1. CoreDNS 會接著將請求傳送至外部 DNS 解析程式 (Amazon Route 53 Resolver)，以取得網域名稱後方的 IP 地址清單。
1. 回應 DNS 請求時，會傳回具有 TTL 的已解析 IPs。然後，這些 IPs會寫入 eBPF 映射中，用於執行 IP 層的下一個步驟。
1. 然後，連接至 Pod 實物界面的 eBPF 探查會根據適當的規則，篩選從工作負載 A 到叢集外部端點的輸出流量。這可確保 Pod 只能將叢集外部流量傳送到允許所列網域IPs。這些 IPs 的有效性是以從外部 DNS 解析程式 (Amazon Route 53 Resolver) 擷取的 TTL 為基礎。
#### 使用應用程式網路政策
`ApplicationNetworkPolicy` 結合了標準 Kubernetes 網路政策的功能，以及使用單一自訂資源定義 (CRD) 在命名空間層級進行 DNS 型篩選。因此， `ApplicationNetworkPolicy`可用於：
1. 使用 IP 區塊和連接埠號碼，定義網路堆疊第 3 層和第 4 層的限制。
1. 定義在網路堆疊第 7 層操作的規則，並讓您根據 FQDNs篩選流量。
**重要**
使用 定義的 DNS 型規則`ApplicationNetworkPolicy`僅適用於在 EKS Auto Mode 啟動的 EC2 執行個體中執行的工作負載。 `ApplicationNetworkPolicy`支援標準 Kubernetes 的所有欄位`NetworkPolicy`，以及用於輸出規則的額外 FQDN 篩選條件。
**警告**
請勿將相同的名稱用於相同命名空間`NetworkPolicy`內的 `ApplicationNetworkPolicy`和 。如果名稱衝突，產生的`PolicyEndpoints`物件可能無法正確反映任一政策。接受這兩個資源不會發生錯誤，導致此問題難以診斷。
若要解決命名衝突，請重新命名 `ApplicationNetworkPolicy`或 ，`NetworkPolicy`使其在命名空間中是唯一的，然後驗證對應的`PolicyEndpoints`物件是否已正確更新。
#### 範例
EKS Auto Mode 叢集中有工作負載，需要與具有 DNS 名稱的負載平衡器後方的應用程式內部部署通訊。您可以使用下列網路政策來達成此目的：
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
在 Kubernetes 網路層級，這將允許從標記為 的「galaxy」命名空間中的任何 Pod 輸出`role: backend`，以連接到 TCP 連接埠 8080 上的網域名稱 **myapp.mydomain.com**。此外，您需要為從 VPC 到公司資料中心的輸出流量設定網路連線。
![\[EKS Auto 中工作負載與內部部署應用程式通訊的圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### 管理員 （或叢集） 網路政策
![\[EKS 網路政策的評估順序圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/evaluation-order.png)
#### 使用叢集網路政策
使用 時`ClusterNetworkPolicy`，會先評估管理員層政策，且無法覆寫。評估管理員層政策後，會使用標準命名空間範圍政策來執行套用的網路分割規則。這可以透過使用 `ApplicationNetworkPolicy`或 來完成`NetworkPolicy`。最後，將強制執行定義叢集工作負載預設網路限制的基準層規則。如有需要，命名空間範圍政策**可以**覆寫這些基準層規則。
#### 範例
叢集中有您要隔離其他租用戶工作負載的應用程式。您可以明確封鎖來自其他命名空間的叢集流量，以防止網路存取敏感工作負載命名空間。
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## 考量事項
### 了解政策評估順序
EKS 中支援的網路政策功能會以特定順序評估，以確保可預測且安全的流量管理。因此，請務必了解評估流程，為您的環境設計有效的網路安全狀態。
1. **管理員層政策 （先評估）**：所有管理員層 ClusterNetworkPolicies 都會在任何其他政策之前進行評估。在管理員層中，政策會依優先順序處理 （優先順序最低的數字優先）。動作類型會決定接下來會發生的情況。
+ **拒絕動作 （最高優先順序）**：當具有拒絕動作的管理員政策符合流量時，無論任何其他政策為何，都會立即封鎖該流量。不會處理其他 ClusterNetworkPolicy 或 NetworkPolicy 規則。這可確保命名空間層級政策不會覆寫整個組織的安全控制。
+ **允許動作**：評估拒絕規則之後，具有允許動作的管理員政策會依優先順序 （優先順序最低的數字優先） 處理。當允許動作相符時，系統會接受流量，而不會進行進一步的政策評估。這些政策可以根據標籤選擇器授予多個命名空間的存取權，從而集中控制哪些工作負載可以存取特定資源。
+ **傳遞動作**：在管理員層政策中傳遞動作，將決策委派給較低的層。當流量符合通過規則時，評估會略過該流量的所有剩餘管理員層規則，並直接進入 NetworkPolicy 層。這可讓管理員將特定流量模式的控制明確委派給應用程式團隊。例如，您可以使用傳遞規則將命名空間內流量管理委派給命名空間管理員，同時對外部存取維持嚴格的控制。
1. **網路政策層**：如果沒有管理員層政策與拒絕或允許相符，或者傳遞動作相符，則會接著評估命名空間範圍的 ApplicationNetworkPolicy 和傳統 NetworkPolicy 資源。這些政策可在個別命名空間內提供精細的控制，並由應用程式團隊管理。命名空間範圍政策只能比管理員政策更嚴格。他們無法覆寫管理員政策的拒絕決策，但可以進一步限制管理員政策允許或傳遞的流量。
1. **基準層管理員政策**：如果沒有管理員或命名空間範圍的政策符合流量，則會評估基準層 ClusterNetworkPolicies。這些提供可由命名空間範圍政策覆寫的預設安全狀態，允許管理員設定整個組織的預設值，同時為團隊提供視需要自訂的彈性。基準政策會依優先順序 （優先順序最低的數字優先） 進行評估。
1. **預設拒絕 （如果沒有政策相符）**：此deny-by-default行為可確保只允許明確允許的連線，並維持強大的安全狀態。
### 套用最低權限原則
+ **從限制性政策開始，並視需要逐步新增許可** - 首先在叢集層級實作deny-by-default政策，然後在驗證合法連線需求時逐步新增允許規則。這種方法會強制團隊明確地證明每個外部連線，建立更安全且可稽核的環境。
+ **定期稽核並移除未使用的政策規則** - 網路政策會隨著應用程式演進而隨著時間累積，留下過時規則，不必要的擴展攻擊面。實作定期審查程序，以識別和移除不再需要的政策規則，確保您的安全狀態保持緊密且可維護。
+ **盡可能使用特定的網域名稱，而不是廣泛的模式** - 雖然萬用字元模式`*.amazonaws.com`可提供便利性，但它們也會授予對各種服務的存取權。可行時，請指定 之類的確切網域名稱`s3.us-west-2.amazonaws.com`，以限制僅存取應用程式所需的特定服務，降低工作負載受損時橫向移動的風險。
### 在 EKS 中使用 DNS 型政策
+ 使用 定義的 DNS 型規則`ApplicationNetworkPolicy`僅適用於在 EKS Auto Mode 啟動 EC2 執行個體中執行的工作負載。如果您執行混合模式叢集 （包含 EKS Auto 和非 EKS Auto 工作者節點），您的 DNS 型規則僅在 EKS Auto 模式工作者節點 (EC2 受管執行個體） 中有效。
### 驗證您的 DNS 政策
+ **使用模擬生產網路拓撲的預備叢集進行測試** - 您的預備環境應該複寫生產的網路架構、外部相依性和連線模式，以確保準確的政策測試。這包括相符的 VPC 組態、DNS 解析行為，以及對生產工作負載所需的相同外部服務的存取。
+ **實作關鍵網路路徑的自動化測試** - 建置自動化測試，以驗證 CI/CD 管道中必要外部服務的連線能力。這些測試應驗證在封鎖未經授權的連線時是否允許合法流量流程，提供持續驗證，讓您的網路政策隨著基礎設施發展維持正確的安全狀態。
+ 在**政策變更後監控應用程式行為** - 在將新的或修改的網路政策部署至生產環境之後，請密切監控應用程式日誌、錯誤率和效能指標，以快速識別任何連線問題。建立明確的轉返程序，以便在政策變更造成非預期的應用程式行為或服務中斷時，快速還原政策變更。
### 與 Amazon Route 53 DNS 防火牆的互動
啟動流量時，EKS Admin 和 Network 政策會先在 Pod 層級進行評估。如果 EKS 網路政策允許輸出至特定網域，則 Pod 會執行到達 Route 53 Resolver 的 DNS 查詢。此時會評估 Route 53 DNS 防火牆規則。如果 DNS 防火牆封鎖網域查詢，DNS 解析會失敗，而且即使 EKS 網路政策允許，也無法建立連線。這會建立互補的安全層：EKS DNS 型網路政策為應用程式特定的存取要求和多租用戶安全界限提供 Pod 層級的輸出控制，而 DNS 防火牆為已知惡意網域提供 VPC 整體保護，並強制執行整個組織的封鎖清單。
# 標記 EKS 自動模式的子網路
如果您使用 EKS Auto Mode 的負載平衡功能，則需要將 AWS 標籤新增至 VPC 子網路。
## 背景介紹
這些標籤可辨識與叢集關聯的子網路，且更重要的是辨識子網路為公有還是私有。
公有子網路可透過網際網路閘道直接存取網際網路。其適用於負載平衡器等需要公開存取的資源。
私有子網路不可直接存取網際網路，且針對傳出流量會使用 NAT 閘道。其適用於不需要公有 IP 的 EKS 節點等內部資源。
如需了解 NAT 閘道及網際網路閘道的相關詳細資訊，請參閱《Amazon Virtual Private Cloud (VPC) 使用者指南》中的[連線 VPC 與其他網路](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)。
## 需求
目前，EKS 自動模式用於負載平衡的子網路，需要具有以下其中一個標籤。
### 公有子網路
公有子網路適用於面向網際網路的負載平衡器。這些子網路必須具有以下標籤：
| 金鑰 | 值 |
| --- | --- |
| `kubernetes.io/role/elb` | `1` 或 `` |
### 私有子網路
私有子網路適用於內部負載平衡器。這些子網路必須具有以下標籤：
| 金鑰 | 值 |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` 或 `` |
## 程序
開始操作之前，辨識哪些子網路為公有 (透過網際網路閘道存取) 及哪些為私有 (使用 NAT 閘道)。修改 VPC 資源需要許可。
### AWS 管理主控台
1. 開啟 Amazon VPC 主控台並導覽至**子網路**。
1. 選取要標記的子網路。
1. 選擇**標籤**索引標籤，然後選取**新增標籤**。
1. 新增適當的標籤：
+ 針對公有子網路：Key=`kubernetes.io/role/elb`
+ 針對私有子網路：Key=`kubernetes.io/role/internal-elb`
1. 將**值**設定為 `1`或保持空白。
1. 儲存並重複其餘子網路。
### AWS CLI
針對公有子網路：
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
針對私有子網路：
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
使用實際的子網路 ID 取代 `subnet-ID`。
# 透過 kubectl debug 從 Kubernetes 節點產生 CIS 合規報告
本主題說明如何使用 `kubectl debug` 命令，為 Amazon EKS 節點產生 CIS (Center for Internet Security) 合規報告。此命令可讓您在 Kubernetes 節點上暫時建立偵錯容器，並透過 `apiclient` 工具執行 CIS 合規檢查。`apiclient` 工具是 Bottlerocket OS 的一部分，而 Bottlerocket OS 是 EKS 自動模式節點所使用的作業系統。
## 先決條件
開始前，請確保您具備以下條件：
+ 可存取 Amazon EKS 叢集，且已設定 `kubectl` (版本必須至少為 v1.32.0；可輸入 `kubectl version` 進行檢查)。
+ 具備適當的 IAM 許可以進行節點偵錯。
+ 有效的設定檔，可允許執行偵錯作業 (如 `sysadmin`)。
如需有關搭配 `kubectl` 使用偵錯設定檔的詳細資訊，請參閱 Kubernetes 文件中的[套用設定檔時對 Pod 或節點進行偵錯](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)。
## 程序
1. 決定您要執行報告的節點 AWS 執行個體 ID。使用下列命令列出叢集中的節點。執行個體 ID 可在名稱欄位中找到，且開頭為 `i-`：
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. 執行下列命令，並將 `` 取代為您要查詢的節點的執行個體 ID：
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
此命令的組成部分包括：
+ `kubectl debug node/`：在指定的 EC2 執行個體 ID 上建立偵錯工作階段。
+ `-it`：配置 TTY (命令列 Shell)，並保持 stdin 開啟以支援互動式使用。
+ `--profile=sysadmin`：使用具備適當許可的指定 `kubectl` 設定檔。
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`：使用 `amazonlinux:2023` 作為偵錯的容器映像。
+ `bash -c "…"`：在 bash shell 中執行下列命令：
+ `yum install -q -y util-linux-core`：以安靜模式安裝所需的公用程式套件。
+ `nsenter -t 1 -m`：執行 `nsenter` 以輸入主機程序 (PID 1) 的命名空間。
+ `apiclient report cis --level 1 --format text`：執行等級 1 的 CIS 合規報告，並以文字格式輸出結果。
1. 檢閱報告的文字輸出。
## 解譯輸出
此命令會產生文字格式的報告，顯示各項 CIS 控制項的合規狀態。輸出內容包括：
+ 個別的 CIS 控制項 ID
+ 每個控制項的描述
+ 每項檢查的通過、失敗或略過狀態
+ 解釋任何合規問題的詳細資訊
以下是在 Bottlerocket 執行個體上執行報告後的輸出範例：
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
如需關於基準的資訊，請參閱 Center for Internet Security (CIS) 的 [Kubernetes 基準](https://www.cisecurity.org/benchmark/kubernetes/)。
## 相關資源
+ [Bottlerocket 作業系統文件中的 Bottlerocket CIS 基準](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/)。
+ Kubernetes 文件中的[偵錯執行中的 Pod](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)。
+ Center for Internet Security (CIS) 的 [Kubernetes 基準](https://www.cisecurity.org/benchmark/kubernetes/)。
# 為 EKS 自動模式啟用含客戶自管 KMS 金鑰的 EBS 磁碟區加密
您可使用客戶管理的 KMS 金鑰來加密 EKS 自動模式執行個體的暫時性根磁碟區。
Amazon EKS Auto Mode 使用服務連結角色，在管理 Kubernetes 叢集的加密 EBS 磁碟區 AWS 時，將許可委派給其他服務。本主題描述在為 EKS 自動模式指定客戶管理金鑰以進行 Amazon EBS 加密時，所需設定的金鑰政策。
考量：
+ EKS Auto Mode 不需要額外的授權，即可使用預設 AWS 受管金鑰來保護您帳戶中的加密磁碟區。
+ 本主題涵蓋加密暫時性磁碟區，即 EC2 執行個體的根磁碟區。有關加密用於工作負載的資料磁碟區的更多資訊，請參閱 [建立儲存類別](create-storage-class.md)。
## 概觀
當 EKS Auto Mode 啟動執行個體時，下列 AWS KMS 金鑰可用於 Amazon EBS 根磁碟區加密：
+ ** AWS 受管金鑰** – 在您的帳戶中由 Amazon EBS 建立、擁有和管理的加密金鑰。這是新帳戶的預設加密金鑰。
+ **客戶受管金鑰** – 您所建立、擁有和管理的自訂加密金鑰。
**注意**
金鑰必須為對稱金鑰。Amazon EBS 不支援非對稱客戶受管金鑰。
## 步驟 1：設定金鑰政策
您的 KMS 金鑰必須具有金鑰政策，允許 EKS 自動模式使用透過客戶受管金鑰加密的 Amazon EBS 磁碟區來啟動執行個體。
使用下列結構設定您的金鑰政策：
**注意**
此政策僅包含 EKS 自動模式所需的許可。如果其他身分需要使用金鑰或管理授予，金鑰政策可能需要額外授權。
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
請務必將 取代``為您實際 AWS 的帳戶 ID。
在設定金鑰政策時：
+ `ClusterServiceRole` 必須擁有必要的 IAM 許可，才能使用 KMS 金鑰進行加密操作
+ `kms:GrantIsForAWSResource` 條件可確保只能為 AWS 服務建立授予
## 步驟 2：使用您的客戶管理金鑰設定 NodeClass
設定金鑰政策後，在 EKS 自動模式 NodeClass 組態中參考 KMS 金鑰：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
使用您的實際值取代預留位置的值：
+ `` 您的 AWS 區域
+ `` 使用 AWS 您的帳戶 ID
+ 將 `` 取代為您的 KMS 金鑰 ID
您可使用下列任何格式指定 KMS 金鑰：
+ KMS 金鑰 ID：`1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS 金鑰 ARN：` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ 金鑰別名名稱：`alias/eks-auto-mode-key`
+ 金鑰別名 ARN：` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
使用 kubectl 套用 NodeClass 組態：
```
kubectl apply -f nodeclass.yaml
```
## 相關資源
+ [建立 Amazon EKS 的節點類別](create-node-class.md)
+ 在 AWS Key Management Service 開發人員指南中檢視詳細資訊
+ [金鑰政策中 AWS 服務的許可](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [變更金鑰政策](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [AWS KMS 中的授予](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# 更新 EKS 自動模式的組織控制
某些組織控制項可能會阻止 EKS 自動模式正常運作。如果是這種情況，您必須更新這些控制項，以允許 EKS 自動模式擁有代表您管理 EC2 執行個體所需的許可。
EKS 自動模式使用服務角色來啟動恢復 EKS 自動模式節點的 EC2 執行個體。服務角色是在您帳戶中建立的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)，服務會擔任此角色以代表您執行操作。[服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) 始終適用於使用服務角色執行的操作。這能讓 SCP 限制自動模式的操作。最常見的情況是利用 SCP 來限制可以啟動的 Amazon Machine Image (AMI)。為了讓 EKS 自動模式能夠運作，請修改 SCP 以允許從 EKS 自動模式帳戶啟動 AMI。
您也可使用 [EC2 允許的 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 功能來限制其他帳戶中 AMI 的可見性。若您使用此功能，必須擴展映像標準，以同時包含感興趣區域中的 EKS 自動模式 AMI 帳戶。
## 僅允許 EKS 自動模式 AMI 而封鎖所有其他 AMI 的範例 SCP
下面的 SCP 會阻止呼叫 `ec2:RunInstances`，除非 AMI 屬於 us-west-2 或 us-east-1 區域的 EKS 自動模式 AMI 帳戶。
**注意**
請**勿**使用 `ec2:Owner` 內容索引鍵。Amazon 擁有 EKS 自動模式 AMI 帳戶，此索引鍵的值一律為 `amazon`。若構建的 SCP 允許在 `ec2:Owner` 為 `amazon` 時啟動 AMI，將會允許啟動任何 Amazon 擁有的 AMI，而非僅限 EKS 自動模式專用的 AMI。\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## EKS 自動模式 AMI 帳戶
AWS 帳戶因區域主機 EKS Auto Mode 公有 AMIs 而異。
| | |
| --- |--- |
| AWS 區域 | 帳戶 |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## 關聯公有 IP 位址
當呼叫 `ec2:RunInstances` 時，執行個體啟動的 `AssociatePublicIpAddress` 欄位是由啟動該執行個體的子網路類型自動決定的。SCP 可能被用來強制要求此值必須明確設定為 false，不論所啟動至的子網路類型為何。在這種情況下，可以將 NodeClass 欄位 `spec.advancedNetworking.associatePublicIPAddress` 也設定為 false，以滿足 SCP 的要求。
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# 使用 EKS 自動模式控制工作負載部署至容量保留
您可以控制工作負載部署至[容量保留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)的方式。EKS 自動模式支援 EC2 隨需容量保留 (ODCR) 和適用於 ML 的 EC2 容量區塊。
**提示**
根據預設，EKS Auto Mode 可以透過開放比對在開放 ODCRs 中啟動，但不會排定它們的優先順序。透過開放比對啟動的執行個體會標記為 `karpenter.sh/capacity-type: on-demand`，而不是 `reserved`。若要排定 ODCR 用量的優先順序，並讓執行個體標記為 `karpenter.sh/capacity-type: reserved`，請在 NodeClass 定義`capacityReservationSelectorTerms`中設定 。ML 的容量區塊一律需要`capacityReservationSelectorTerms`且不會自動使用。
## EC2 隨需容量保留 (ODCR)
EC2 隨需容量保留 (ODCR) 可讓您在特定可用區域中，為 Amazon EC2 執行個體保留任何期限的運算容量。使用 EKS 自動模式時，您可能希望控制您的 Kubernetes 工作負載是否部署到這些保留執行個體上，以最大化預購容量的利用率，或確保關鍵工作負載能夠存取保證的資源。
預設情況下，EKS 自動模式會自動啟動到開放的 ODCR 中。但是，透過在 NodeClass 上設定 `capacityReservationSelectorTerms`，您可以明確控制您的工作負載使用哪些 ODCR。透過已設定 ODCR 佈建的節點會帶有 `karpenter.sh/capacity-type: reserved` 標籤，且其優先順序高於隨需與 Spot 執行個體。啟用此功能後，EKS 自動模式將不再自動使用開放的 ODCR，必須透過 NodeClass 明確選取這些 ODCR，讓您能精確控制叢集中容量保留的使用情況。
**警告**
若您在叢集中的某個 NodeClass 上設定 `capacityReservationSelectorTerms`，則 EKS 自動模式將不再為叢集中*任何* NodeClass 自動使用開放的 ODCR。
### 範例 NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
此範例 NodeClass 示範了兩種選取 ODCR 的方式。第一種方式透過 ODCR 的 ID (`cr-56fac701cc1951b03`) 直接參考特定 ODCR。第二種方式使用基於標籤的選取邏輯，目標為帶有 `Name: "targeted-odcr"` 標籤的 ODCR。您也可以選擇性地依擁有保留 AWS 的帳戶進行篩選，這在跨帳戶案例或處理共用容量保留時特別有用。
## ML 的 EC2 容量區塊
ML 的容量區塊可讓您為日後預留基於 GPU 的加速運算執行個體，以支援短時間的機器學習 (ML) 工作負載。容量區塊內執行的執行個體會在 Amazon EC2 UltraCluster 內自動放置於鄰近位置，以實現低延遲、Pb 級的非阻塞式聯網。
有關支援的平台和執行個體類型的詳細資訊，請參閱 EC2 使用者指南中的 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)。
您可以建立使用 ML 的容量區塊的 EKS 自動模式 NodeClass，類似於 ODCR (先前說明)。
以下範例定義會建立了三個資源：
1. 一個引用您的容量區塊保留的 NodeClass
1. 一個使用該 NodeClass 並套用污點的 NodePool
1. 一個容忍該污點並請求 GPU 資源的 Pod 規格
### 範例 NodeClass
此 NodeClass 透過其保留 ID 引用特定 ML 的容量區塊。您可從 EC2 主控台取得此 ID。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。
### NodePool 範例
此 NodePool 引用了 `gpu` NodeClass 並指定了重要組態：
+ 它透過設定 `karpenter.sh/capacity-type: reserved` **僅**使用預留容量
+ 它請求適合 ML 工作負載的特定 GPU 執行個體系列
+ 它會套用 `nvidia.com/gpu` 污點，確保僅 GPU 工作負載會排程至這些節點
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
### 範例 Pod
此範例 Pod 示範了如何設定要在容量區塊節點上執行的工作負載：
+ 它使用 **nodeSelector**，以特定 GPU 類型為目標 (此處為 H200 GPU)
+ 它包含對 NodePool 所套用 `nvidia.com/gpu` 污點的**容差**
+ 它使用 `nvidia.com/gpu` 資源類型明確**請求 GPU 資源**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
如需詳細資訊，請參閱 Kubernetes 文件中的 [Pod](https://kubernetes.io/docs/concepts/workloads/pods/)。
### 相關資源
+ 《Amazon EC2 使用者指南》中的 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)
+ 《Amazon EC2 使用者指南》中的[尋找和購買容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html)
+ [管理 Amazon EKS 上 AI/ML 工作負載的運算資源](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ 《EKS 最佳實務指南》中的 [GPU 資源最佳化和成本管理](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management)
# 將 EKS Auto Mode 節點部署至 Local Zones
EKS Auto Mode 透過自動節點佈建提供簡化的叢集管理。 AWS 本機區域可將 AWS 基礎設施擴展到更接近最終使用者的地理位置，從而減少延遲敏感應用程式的延遲。本指南會逐步解說將 EKS Auto Mode 節點部署至 AWS Local Zones 的程序，讓您針對特定地理區域的使用者執行具有較低延遲的容器化應用程式。
本指南也示範如何使用 Kubernetes 污點和容錯，以確保只有特定工作負載會在 Local Zone 節點上執行，協助您控制成本並最佳化資源用量。
## 先決條件
開始將 EKS Auto Mode 節點部署到 Local Zones 之前，請確定您已備妥下列先決條件：
+ [現有的 EKS 自動模式叢集](create-auto.md)
+ [選擇加入您 AWS 帳戶中的本機區域](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## 步驟 1：建立本機區域子網路
將 EKS Auto Mode 節點部署到 Local Zone 的第一步是在該 Local Zone 中建立子網路。此子網路為您的節點提供網路基礎設施，並允許它們與您的其餘 VPC 通訊。遵循[建立本機區域子網路](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet)指示 （在 AWS 本機區域使用者指南中），在您選擇的本機區域中建立子網路。
**提示**
請記下本機區域子網路的名稱。
## 步驟 2：為本機區域子網路建立 NodeClass
建立本機區域子網路之後，您需要定義參考此子網路的 NodeClass。NodeClass 是一種 Kubernetes 自訂資源，可指定節點的基礎設施屬性，包括要使用的子網路、安全群組和儲存組態。在下面的範例中，我們建立名為 "local-zone" 的 NodeClass，根據其名稱以本機區域子網路為目標。您也可以使用子網路 ID。您需要調整此組態以鎖定您的 Local Zone 子網路。
如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## 步驟 3：使用 NodeClass 和 Taint 建立 NodePool
設定 NodeClass 後，您現在需要建立使用此 NodeClass 的 NodePool。NodePool 會定義節點的運算特性，包括執行個體類型。NodePool 使用 NodeClass 做為參考，以判斷在何處啟動執行個體。
在以下範例中，我們會建立參考 "local-zone" NodeClass 的 NodePool。我們也會將污點新增至節點，以確保只有具有相符公差的 Pod 才能排程在這些 Local Zone 節點上。這對 Local Zone 節點特別重要，這通常具有較高的成本，並且只能由特別受益於降低延遲的工作負載使用。
如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
具有金鑰`aws.amazon.com/local-zone`和效果的污點`NoSchedule`可確保在這些節點上不會排程沒有相符公差的 Pod。這可防止定期工作負載意外在 Local Zone 中執行，這可能會導致意外的成本。
## 步驟 4：部署具有公差和節點親和性的工作負載
若要最佳控制本機區域節點上的工作負載置放，請同時使用污點/容錯和節點親和性。此合併方法提供下列優點：
1. **成本控制**：污點可確保只有具有明確公差的 Pod 可以使用可能昂貴的 Local Zone 資源。
1. **保證配置**：節點親和性可確保對延遲敏感的應用程式僅在本機區域執行，而不是在一般叢集節點上執行。
以下是設定為在 Local Zone 節點上特別執行的部署範例：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
此部署有兩個金鑰排程組態：
1. **容錯允許**在具有`aws.amazon.com/local-zone`污點的節點上排程 Pod。
1. **節點親和性**要求可確保這些 Pod 只會在標籤為 的節點上執行`node-type: local-zone`。
這些共同確保您的延遲敏感應用程式僅在 Local Zone 節點上執行，且一般應用程式不會使用 Local Zone 資源，除非明確設定這樣做。
## 步驟 5：使用 AWS 主控台驗證
設定 NodeClass、NodePool 和 部署之後，您應該驗證節點是否如預期佈建在 Local Zone，以及工作負載是否在其上執行。您可以使用 AWS 管理主控台來驗證 EC2 執行個體是否在正確的本機區域子網路中啟動。
此外，您可以使用 檢查 Kubernetes 節點清單`kubectl get nodes -o wide`，以確認節點使用正確的標籤和污點來加入您的叢集：
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
您也可以確認您的工作負載 Pod 已排程在 Local Zone 節點上：
```
kubectl get pods -o wide
```
此方法可確保只會在這些節點上排定特別容忍 Local Zone 污點的工作負載，協助您控制成本並最有效地使用 Local Zone 資源。
# 設定節點的進階安全設定
本主題說明如何使用節點類別中的`advancedSecurity`規格來設定 Amazon EKS Auto Mode 節點的進階安全設定。
## 先決條件
開始前，請確保您具備以下條件：
+ 一個 Amazon EKS 自動模式叢集。如需詳細資訊，請參閱[使用 Amazon EKS 自動模式建立叢集](create-auto.md)。
+ `kubectl` 已安裝並已設定。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
+ 了解節點類別組態。如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。
## 設定進階安全設定
若要設定節點的進階安全設定，請在節點類別規格中設定`advancedSecurity`欄位：
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
套用此組態：
```
kubectl apply -f nodeclass.yaml
```
在您的節點集區組態中參考此節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
## 欄位描述
+ `fips` （布林值，選用）：設為 時`true`， 會使用具有 FIPS 140-2 驗證密碼編譯模組的 AMIs 佈建節點。此設定會選取符合 FIPS 標準的 AMIs；客戶負責管理其合規要求。如需詳細資訊，請參閱 [AWS FIPS 合規](https://aws.amazon.com/compliance/fips/)。預設：`false`。
+ `kernelLockdown` （字串，選用）：控制核心鎖定安全模組模式。接受的值：
+ `integrity`：封鎖覆寫核心記憶體或修改核心程式碼的方法。防止未簽署的核心模組載入。
+ `none`：停用核心鎖定保護。
如需詳細資訊，請參閱 [Linux 核心鎖定文件](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)。
## 考量事項
+ FIPS 相容的 AMIs 適用於 AWS 美國東部/西部、 AWS GovCloud (US) 和 AWS 加拿大 （中部/西部） 區域。如需詳細資訊，請參閱 [AWS FIPS 合規](https://aws.amazon.com/compliance/fips/)。
+ 使用 時`kernelLockdown: "integrity"`，請確保您的工作負載不需要載入未簽署的核心模組或修改核心記憶體。
## 相關資源
+ [建立 Amazon EKS 的節點類別](create-node-class.md) - 完成節點類別組態指南
+ [為 EKS 自動模式建立節點集區](create-node-pool.md) - 節點集區組態
# 了解 EKS 自動模式的運作方式
使用本章節來了解 Amazon EKS 自動模式叢集的元件如何運作。
**Topics**
+ [了解 Amazon EKS 自動模式受管執行個體](automode-learn-instances.md)
+ [了解 EKS 自動模式中的身分和存取](auto-learn-iam.md)
+ [了解 EKS 自動模式中的 VPC 聯網與負載平衡](auto-networking.md)
# 了解 Amazon EKS 自動模式受管執行個體
本主題說明 Amazon EKS 自動模式如何管理您 EKS 叢集中的 Amazon EC2 執行個體。當您啟用 EKS 自動模式後，叢集的運算資源將由 EKS 自動佈建與管理，這會改變您與作為叢集節點的 EC2 執行個體之間的互動方式。
了解 Amazon EKS 自動模式管理執行個體的機制，對於規劃工作負載部署策略與操作程序至關重要。不同於傳統 EC2 執行個體或受管節點群組，此類執行個體採用不同的生命週期模型：EKS 會負責多數操作環節，同時限制特定類型的存取與自訂功能。
Amazon EKS 自動模式會自動執行建立新 EC2 執行個體的常規工作，並將這些執行個體作為節點附加至您的 EKS 叢集。在 EKS 自動模式偵測到現有節點無法容納工作負載時，便會建立新的 EC2 執行個體。
Amazon EKS 自動模式負責 EC2 執行個體的建立、刪除與修補。您則需負責管理部署在執行個體上的容器與 Pod。
由 EKS 自動模式建立的 EC2 執行個體不同於其他 EC2 執行個體，這類執行個體屬於「受管執行個體」。此類受管執行個體歸 EKS 所有，且存取權限更為嚴格。您無法直接存取 EKS 自動模式管理的執行個體，也無法在其上安裝軟體。
AWS 建議執行 EKS Auto Mode 或自我管理 Karpenter。您可在移轉期間或進階組態中同時安裝兩者。若已同時安裝，請設定節點集區，使工作負載僅與 Karpenter 或 EKS 自動模式其一相關聯。
如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的 [Amazon EC2 受管執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)。
## 比較表格
| 標準 EC2 執行個體 | EKS 自動模式受管執行個體 |
| --- | --- |
| 由您負責執行個體的修補與更新作業。 | AWS 會自動修補和更新執行個體。 |
| EKS 不負責執行個體上的軟體。 | EKS 負責執行個體上的特定軟體，如 `kubelet`、容器執行時期及作業系統。 |
| 您可使用 EC2 API 刪除 EC2 執行個體。 | EKS 決定您帳戶中部署的執行個體數量。在刪除工作負載時，EKS 會減少帳戶中的執行個體數量。 |
| 您可透過 SSH 存取 EC2 執行個體。 | 您可將 Pod 與容器部署至受管執行個體。 |
| 由您決定作業系統與映像 (AMI)。 | AWS 會決定作業系統和映像。 |
| 您可部署依賴 Windows 或 Ubuntu 功能的工作負載。 | 您可部署基於 Linux 的容器，但不能有特定作業系統相依性。 |
| 由您決定要啟動的執行個體類型與系列。 | AWS 決定要啟動的執行個體類型和系列。您可透過節點集區限制 EKS 自動模式可選取的執行個體類型。 |
下列功能同時適用於受管執行個體與標準 EC2 執行個體：
+ 您可以在 AWS 主控台中檢視執行個體。
+ 您可將執行個體儲存空間作為工作負載的臨時儲存。
### AMI 支援
使用 EKS Auto Mode 時， AWS 會決定運算節點所使用的映像 (AMI)。 AWS 會監控新 EKS Auto Mode AMI 版本的推出。若您遇到與 AMI 版本相關的工作負載問題，請建立支援案例。如需詳細資訊，請參閱《[支援使用者指南》中的建立支援案例和案例管理](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)。 AWS
通常情況下，EKS 每週都會發布包含 CVE 與安全性修補的新 AMI。
## EKS 自動模式支援的執行個體參考
EKS 自動模式僅會建立「支援類型」且「符合最小規模需求」的執行個體。
EKS 自動模式支援下列執行個體類型：
| 系列 | 執行個體類型 |
| --- | --- |
| 運算最佳化 © | c8id、c8i、c8i-flex、c8gd、c8gn、c8g、c8a、c8gb、c7a、c7g、c7gn、c7gd、c7i、c7i-flex、c6a、c6g、c6i、c6gn、c6id、c6in、c6gd、c5、c5a、c5d、c5ad、c5n、c4 |
| 一般用途 (M) | m8id、m8i、m8i-flex、m8a、m8azn、m8gn、m8gb、m8gd、m8g、m7i、m7a、m7g、m7gd、m7i-flex、m6a、m6i、m6in、m6g、m6idn、m6id、m6gd、m5、m5a、m5ad、m5n、m5dn、m5dn、m5d、m5zn、m4 |
| 記憶體最佳化 ® | r8id、r8i、r8i-flex、r8gn、r8gb、r8gd、r8g、r8a、r7a、r7iz、r7gd、r7i、r7g、r6a、r6i、r6id、r6in、r6idn、r6g、r6gd、r5、r5n、r5a、r5dn、r5b、r5ad、r5d、r4d |
| 爆量 (T) | t4g、t3、t3a、t2 |
| 記憶體密集型 (Z/X) | z1d、x8aedz、x8g、x8i、x2gd |
| 儲存最佳化 (I/D) | i8ge、i7i、i8g、i7ie、i4g、i4i、i3、i3en、is4gen、d3、d3en、im4gn |
| 加速運算 (P/G/Inf/Trn) | p6-b200、p6-b300、p5、p5e、p5en、p4d、p4de、p3、p3dn、g7e、g6、gr6、g6e、g5g、g5、g4dn、g4ad、inf2、inf1、trn1、trn1n、trn2 |
| 高效能運算 (HPC/X2) | hpc8a、x2iezn、x2iedn、x2idn |
此外，EKS 自動模式僅會建立符合下列要求的 EC2 執行個體：
+ CPU 數量大於 1
+ 執行個體尺寸並非 nano、micro 或 small
如需詳細資訊，請參閱 [Amazon EC2 執行個體類型命名慣例](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)。
## 執行個體中繼資料服務
+ EKS Auto Mode 預設會強制執行 IMDSv2，跳轉限制為 1，並遵循 AWS 安全最佳實務。
+ 此預設組態在 Auto Mode 中無法修改。
+ 對於通常需要 IMDS 存取的附加元件，請在安裝期間提供參數 （例如 AWS 區域），以避免 IMDS 查詢。如需詳細資訊，請參閱[確定您可為 Amazon EKS 附加元件自訂的欄位](kubernetes-field-management.md)。
+ 若 Pod 在 Auto Mode 中執行時絕對需要存取 IMDS，必須將 Pod 設定為搭配 `hostNetwork: true` 執行。如此 Pod 才能直接存取執行個體中繼資料服務。
+ 在授予 Pods 存取執行個體中繼資料的權限時，請務必考量安全性影響。
如需有關 Amazon EC2 執行個體中繼資料服務 (IMDS) 的詳細資訊，請參閱*《Amazon EC2 使用者指南》*中的[設定執行個體中繼資料服務選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)。
## 考量事項
+ 若 NodeClass 中設定的臨時儲存空間小於執行個體的 NVMe 本機儲存空間，EKS 自動模式會自動執行下列動作，無需手動設定：
+ 使用較小 (20 GiB) 的 Amazon EBS 資料磁碟區以降低成本。
+ 格式化並設定 NVMe 本機儲存空間，用於儲存臨時資料。這包括在有多個 NVMe 磁碟機時設定 RAID 0 陣列。
+ 若 `ephemeralStorage.size` 等於或超過本機 NVMe 容量，則會發生下列動作：
+ Auto Mode 跳過小型 EBS 磁碟區。
+ NVMe 磁碟機會直接開放給您的工作負載使用。
+ Amazon EKS Auto Mode 不支援下列 Fault Injection Service AWS 動作：
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS Auto Mode AWS 支援 Fault Injection Service EKS Pod 動作。如需詳細資訊，請參閱 AWS 《Resilience Hub 使用者指南》中的[管理故障注入服務實驗](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html)和[使用 AWS FIS aws：eks：pod 動作](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account)。
+ 無需在 EKS 自動模式節點上安裝 `Neuron Device Plugin`。
若您的叢集中有其他類型的節點，需設定 Neuron 裝置外掛程式不在 Auto Mode 節點上執行。如需詳細資訊，請參閱[控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)。
# 了解 EKS 自動模式中的身分和存取
本主題描述使用 EKS 自動模式所需的 Identity and Access Management (IAM) 角色與許可。EKS 自動模式使用兩個主要 IAM 角色：叢集 IAM 角色和節點 IAM 角色。這些角色與 EKS Pod 身分識別和 EKS 存取項目協同工作，為您的 EKS 叢集提供全面的存取管理。
當您設定 EKS Auto Mode 時，您將需要設定這些具有特定許可的 IAM 角色，以允許 AWS 服務與您的叢集資源互動。這包括用於管理運算資源、儲存磁碟區、負載平衡器和聯網元件的許可。了解這些角色組態對於正確的叢集操作與安全性至關重要。
在 EKS Auto 模式中， AWS IAM 角色會透過 EKS 存取項目自動映射至 Kubernetes 許可，無需手動設定 `aws-auth` ConfigMaps 或自訂繫結。當您建立新的自動模式叢集時，EKS 會使用存取項目自動建立對應的 Kubernetes 許可，確保 AWS 服務和叢集元件在 AWS 和 Kubernetes 授權系統中都具有適當的存取層級。這種自動化整合降低了設定複雜性，並有助於預防管理 EKS 叢集時常見的許可相關問題。
## 叢集 IAM 角色
叢集 IAM 角色是 Amazon EKS 用來管理 Kubernetes 叢集許可的 AWS Identity and Access Management (IAM) 角色。此角色會授予 Amazon EKS 必要的許可，以代表您叢集與其他 AWS 服務互動，並使用 EKS 存取項目自動設定 Kubernetes 許可。
+ 您必須將 AWS IAM 政策連接至此角色。
+ EKS 自動模式會使用 EKS 存取項目自動將 Kubernetes 許可附加到此角色。
+ 使用 EKS Auto 模式時， AWS 建議為每個 AWS 帳戶建立單一叢集 IAM 角色。
+ AWS 建議將此角色命名為 `AmazonEKSAutoClusterRole`。
+ 此角色需要多個 AWS 服務的許可，才能管理 資源，包括 EBS 磁碟區、Elastic Load Balancer 和 EC2 執行個體。
+ 此角色的建議組態包含多個 AWS 受管 IAM 政策，與 EKS Auto Mode 的不同功能相關。
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
如需叢集 IAM 角色和 AWS 受管 IAM 政策的詳細資訊，請參閱：
+ [AWS Amazon Elastic Kubernetes Service 的 受管政策](security-iam-awsmanpol.md)
+ [Amazon EKS 叢集 IAM 角色](cluster-iam-role.md)
如需有關 Kubernetes 存取的詳細資訊，請參閱：
+ [檢閱存取政策許可](access-policy-permissions.md)
## 節點 IAM 角色
節點 IAM 角色是 Amazon EKS 用來管理 Kubernetes 叢集中工作者節點許可的 AWS Identity and Access Management (IAM) 角色。此角色會授予以 Kubernetes 節點身分執行的 EC2 執行個體與 AWS 服務和資源互動的必要許可，並使用 EKS 存取項目自動設定 Kubernetes RBAC 許可。
+ 您必須將 AWS IAM 政策連接至此角色。
+ EKS 自動模式會使用 EKS 存取項目自動將 Kubernetes RBAC 許可附加到此角色。
+ AWS 建議將此角色命名為 `AmazonEKSAutoNodeRole`。
+ 使用 EKS Auto Mode， AWS 建議為每個 AWS 帳戶建立單一節點 IAM 角色。
+ 此角色具有有限的許可。關鍵許可包括擔任 Pod 身分識別角色，以及從 ECR 提取映像。
+ AWS 建議下列 AWS 受管 IAM 政策：
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
如需叢集 IAM 角色和 AWS 受管 IAM 政策的詳細資訊，請參閱：
+ [AWS Amazon Elastic Kubernetes Service 的 受管政策](security-iam-awsmanpol.md)
+ [Amazon EKS 節點 IAM 角色](create-node-role.md)
如需有關 Kubernetes 存取的詳細資訊，請參閱：
+ [檢閱存取政策許可](access-policy-permissions.md)
## 服務連結角色
Amazon EKS 針對某些操作使用服務連結角色 (SLR)。服務連結角色是直接連結至 Amazon EKS 的一種特殊 IAM 角色類型。服務連結角色是由 Amazon EKS 預先定義，並包含該服務代表您呼叫其他 AWS 服務所需的所有許可。
AWS 會自動建立和設定 SLR。您必須先刪除 SLR 的相關資源，才能刪除角色。如此可保護您的 Amazon EKS 資源，避免您不小心移除資源的存取許可。
SLR 政策授予 Amazon EKS 觀察和刪除核心基礎結構元件的許可：EC2 資源 (執行個體、網路介面、安全群組)、ELB 資源 (負載平衡器、目標群組)、CloudWatch 功能 (記錄和指標)，以及具有「eks」字首的 IAM 角色。它還透過 VPC/託管區域關聯啟用私有端點聯網，並包含用於 EventBridge 監控和清理帶有 EKS 標籤之資源的許可。
如需詳細資訊，請參閱：
+ [AWS 受管政策：AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Amazon EKS 的服務連結角色許可](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## 存取政策參考
如需 EKS 自動模式使用的 Kubernetes 許可的詳細資訊，請參閱 [檢閱存取政策許可](access-policy-permissions.md)。
# 了解 EKS 自動模式中的 VPC 聯網與負載平衡
本主題闡釋如何在 EKS 自動模式中設定虛擬私有雲端 (VPC) 聯網與負載平衡功能。雖然 EKS 自動模式會自動管理大多數聯網元件，但您仍然可以透過 `NodeClass` 資源和負載平衡器注釋來自訂叢集聯網組態的某些方面。
當您使用 EKS Auto Mode 時， 會 AWS 管理叢集的 VPC 容器網路界面 (CNI) 組態和負載平衡器佈建。您可透過定義 `NodeClass` 物件，以及將特定注釋套用至服務與傳入資源來影響聯網行為，同時維持 EKS 自動模式提供的自動化營運模式。
## 聯網功能
EKS 自動模式具有一個處理節點和 Pod 聯網的新聯網功能。您可以透過建立一個 `NodeClass` Kubernetes 物件進行設定。
先前 AWS VPC CNI 的組態選項不適用於 EKS Auto 模式。
### 使用 `NodeClass` 設定聯網
EKS 自動模式中的 `NodeClass` 資源讓您能自訂聯網功能的特定層面。透過 `NodeClass`，您可以指定安全群組選擇、控制節點在 VPC 子網路上的放置、設定 SNAT 政策、配置網路政策以及啟用網路事件記錄。這種方法在提供聯網自訂彈性的同時，保持了 EKS 自動模式的自動化操作模型。
您可以使用 `NodeClass` 來：
+ 選取節點的安全群組
+ 控制節點在 VPC 子網路上的放置方式
+ 將節點 SNAT 政策設定為 `random` 或 `disabled`
+ 啟用 Kubernetes *網路政策*，包括：
+ 將網路政策設定為預設拒絕或預設允許
+ 啟用網路事件記錄至檔案。
+ 透過將 Pod 附加至不同的子網路，將 Pod 流量與節點流量隔離。
了解如何[建立 Amazon EKS NodeClass](create-node-class.md)。
### 考量事項
EKS 自動模式支援：
+ EKS 網路政策。
+ Kubernetes Pod 的 `HostPort` 與 `HostNetwork` 選項。
+ 位於公有或私有子網路中的節點和 Pod。
+ 在節點上快取 DNS 查詢。
EKS 自動模式**不支援**下列功能：
+ 每個 Pod 的安全群組 (SGPP)。若要在自動模式下將個別安全群組套用至 Pod 流量，請`NodeClass`改為在 `podSecurityGroupSelectorTerms`中使用 。如需詳細資訊，請參閱[Pod 的個別子網路和安全群組](create-node-class.md#pod-subnet-selector)。
+ `ENIConfig` 中的自訂聯網。您可以使用 [Pod 的個別子網路和安全群組](create-node-class.md#pod-subnet-selector) 將 Pod 放入多個子網路中，或將其與節點流量完全隔離。
+ 預熱 IP、預熱前綴和預熱 ENI 組態。
+ 最小 IP 目標組態。
+ 開放原始碼 AWS VPC CNI 支援的其他組態。
+ 網路政策組態，如連線追蹤計時器自訂 (預設為 300 秒)。
+ 將網路事件日誌匯出至 CloudWatch。
### 網路資源管理
EKS 自動模式透過監控聯網組態的 NodeClass 資源來處理字首、IP 定址和聯網介面管理。該服務會自動執行多項關鍵操作：
**字首委派**
EKS Auto Mode 預設為使用字首委派 (/28 個字首） 進行 Pod 聯網，並維護預先定義的 IP 資源暖集區，該集區會根據排程的 Pod 數量進行擴展。偵測到 Pod 子網路分段時，自動模式會佈建次要 IP 地址 (/32)。由於此預設 Pod 網路演算法，自動模式會根據每個執行個體類型支援的 ENIs 和 IPs 數目 （假設片段的最壞情況），計算每個節點的最大 Pod。如需每個執行個體類型的最大 ENIs IPs 的詳細資訊，請參閱 EC2 使用者指南中的[每個網路界面的最大 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)。較新一代 (Nitro v6 及更高版本） 執行個體系列通常會增加每個執行個體類型的 ENIs 和 IPs，而自動模式會相應地調整最大 Pod 計算。
對於 IPv6 叢集，只會使用字首委派，而自動模式一律使用每個節點最多 110 個 Pod。
**冷卻時間管理**
該服務為不再使用的字首或次要 IPv4 位址實作冷卻集區。在冷卻時間到期後，這些資源將被釋出回 VPC。但是，如果 Pod 在冷卻時間內重複使用這些資源，則會從冷卻集區還原這些資源。
**IPv6 支援**
對於 IPv6 叢集，EKS 自動模式會在主要網路介面上為每個節點佈建 `/80` IPv6 前綴。使用 時`podSubnetSelectorTerms`，字首會改為配置在 Pod 子網路中的次要網路界面上。
該服務還確保所有網路介面的正確管理和垃圾回收。
## Load balancing
您可以在服務和輸入資源上使用註釋來設定 EKS Auto Mode 佈建的 AWS Elastic Load Balancer。
如需詳細資訊，請參閱 [建立 IngressClass 以設定 Application Load Balancer](auto-configure-alb.md) 或 [使用服務注釋設定 Network Load Balancer](auto-configure-nlb.md) 。
### 使用 EKS 自動模式進行負載平衡的考量事項
+ 預設目標模式是 IP 模式，而非執行個體模式。
+ EKS 自動模式僅支援 Network Load Balancer 的安全群組模式。
+ AWS 不支援將負載平衡器從自我管理 AWS 負載平衡器控制器遷移至 EKS Auto Mode 管理。
+ 不支援 `TargetGroupBinding` 規格中的 `networking.ingress.ipBlock` 欄位。
+ 如果您的工作節點使用自訂安全群組 (而非 `eks-cluster-sg- ` 命名模式)，則您的叢集角色需要額外的 IAM 許可。預設的 EKS 受管政策僅允許 EKS 修改名為 `eks-cluster-sg-` 的安全群組。如果沒有修改您自訂安全群組的許可，EKS 將無法新增所需的輸入規則，以允許 ALB/NLB 流量到達您的 Pod。
#### CoreDNS 考量事項
EKS Auto Mode 不會使用傳統 CoreDNS 部署在叢集內提供 DNS 解析。反之，自動模式節點會利用 CoreDNS，直接在每個節點上執行做為系統服務。如果將傳統叢集轉換為自動模式，您可以將工作負載移至自動模式節點後，從叢集中移除 CoreDNS 部署。
**重要**
如果您計劃維護具有自動模式和非自動模式節點的叢集，則必須保留 CoreDNS 部署。非自動模式節點依賴傳統的 CoreDNS Pod 進行 DNS 解析，因為它們無法存取自動模式提供的節點層級 DNS 服務。
# EKS Auto 模式的可觀測性
使用本章來了解 Amazon EKS Auto Mode 叢集的可觀測性選項。
**Topics**
+ [EKS Auto 的存取 AWS受管元件日誌](auto-managed-component-logs.md)
# EKS Auto 的存取 AWS受管元件日誌
您可以從 AWS EKS Auto Mode 存取受管元件日誌，以更深入地觀察叢集操作。EKS Auto Mode 支援下列來源的日誌：
+ 運算自動擴展 - Karpenter
+ 區塊儲存 - EBS CSI
+ 負載平衡 - AWS Load Balancer控制器
+ Pod 聯網 - VPC CNI IP 地址管理
日誌可以交付到您選擇的[交付目的地](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)。
建立 EKS Auto 叢集時，您可以選擇啟用控制平面記錄 (API 伺服器、稽核、驗證器、控制器管理員、排程器）。EKS Auto 受管元件日誌 （例如運算、區塊儲存、負載平衡和 IPAM) 需要透過日誌交付進行個別組態。
## 設定日誌交付
若要設定 EKS Auto Mode 叢集的 AWS受管元件日誌交付，請使用 Amazon CloudWatch Logs API。如需詳細設定指示，請參閱《Amazon CloudWatch Logs 使用者指南》中的[啟用來自 AWS 服務的日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html)記錄。每個自動模式功能都可以設定為個別的 CloudWatch Vended Logs 交付來源，讓您選取要存取的日誌。
EKS Auto Mode 支援下列日誌類型：
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### 使用 Amazon CloudWatch APIs
設定記錄需要三個步驟：
1. 使用 CloudWatch PutDeliverySource API 建立 功能的交付來源
1. 使用 PutDeliveryDestination 建立交付目的地
1. 使用 CreateDelivery 建立交付以連接來源和目的地
您可以使用 CloudWatch PutDeliveryDestination API 中的 deliveryDestinationConfiguration 物件，為自動模式日誌設定目的地的詳細資訊。它接受 CloudWatch 日誌群組、S3 儲存貯體或 Amazon Data Firehose 交付串流的 ARN。
您可以設定單一自動模式功能 （交付來源），透過建立多個交付將日誌傳送至多個目的地。您也可以建立多個交付，以設定多個交付來源，將日誌傳送至相同的交付目的地。
### IAM 許可
根據選取的目的地，您可能需要為 CloudWatch 日誌群組、S3 儲存貯體和 Amazon Data Firehose 設定 IAM 政策或角色，以確保日誌成功交付。此外，如果您跨 AWS 帳戶傳送日誌，則需要使用 PutDeliveryDestinationPolicy API 來設定允許交付至目的地的 IAM 政策。如需其他資訊，請參閱 [CloudWatch Vended Logs 許可文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)。
## 檢視您的日誌
設定日誌交付後，日誌將交付至您指定的目的地。存取日誌的方法取決於您選擇的目的地類型：
+ **CloudWatch Logs** - 在 CloudWatch Logs 主控台中檢視日誌、使用 AWS CLI 命令，或搭配 CloudWatch Logs Insights 進行查詢
+ **Amazon S3** - 透過 S3 主控台、 AWS CLI 或 Amazon Athena 等分析工具，將日誌作為 S3 儲存貯體中的物件存取
+ **Amazon Data Firehose** - 日誌會串流到您設定的 Firehose 目標 （例如 S3、OpenSearch Service、Redshift 等）
## 定價
根據您選擇的交付目的地，CloudWatch Vended Logs 會收取日誌交付和儲存的費用。與標準 CloudWatch Logs 相比，CloudWatch Vended Logs 能以較低的價格使用內建 AWS 身分驗證和授權來實現可靠、安全的日誌交付。如需詳細資訊[，請參閱 CloudWatch 定價頁面的已修訂日誌一節](https://aws.amazon.com/cloudwatch/pricing/)。
### 相關資源
+ [Amazon EKS 控制平面記錄](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ CloudWatch Logs [API 參考中的 PutDeliverySource ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) API
+ CloudWatch Logs [API 參考中的 PutDeliveryDestination ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) API
+ CloudWatch Logs API 參考中的 [CreateDelivery ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) API
# EKS 自動模式疑難排解
使用 EKS Auto Mode， 會 AWS 對您 AWS 帳戶中的 EC2 執行個體承擔更多責任。EKS 負責節點上的容器執行時期、節點上的作業系統，以及某些控制器。這包括區塊儲存控制器、負載平衡控制器及運算控制器。
您必須使用 AWS 和 Kubernetes APIs 對節點進行故障診斷。您可以：
+ 使用 Kubernetes `NodeDiagnostic` 資源，透過 [節點監控代理程式](#auto-node-monitoring-agent) 來擷取節點日誌。如需更多步驟，請參閱 [使用 kubectl 及 S3 擷取受管節點的節點日誌](auto-get-logs.md)。
+ 使用 Kubernetes `NodeDiagnostic` 資源擷取節點上的網路流量。如需更多步驟，請參閱 [使用 kubectl 和 S3 擷取受管節點上的網路流量](auto-get-tcpdump.md)。
+ 使用 AWS EC2 CLI 命令從節點`get-console-output`擷取主控台輸出。如需更多步驟，請參閱 [使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出](#auto-node-console)。
+ 使用 Kubernetes *偵錯容器*來擷取節點日誌。如需更多步驟，請參閱 [使用*偵錯容器*和 `kubectl` CLI 取得節點日誌](#auto-node-debug-logs)。
**注意**
EKS 自動模式使用 EC2 受管執行個體。您無法直接存取 EC2 受管執行個體，包括透過 SSH。
您可能會遇到以下特定於 EKS 自動模式元件的問題及解決方案：
+ Pod 卡在 `Pending` 狀態，無法排程到自動模式節點上。解決方案請參閱 [對 Pod 無法排程到自動模式節點進行疑難排解](#auto-troubleshoot-schedule)。
+ EC2 受管執行個體無法以 Kubernetes 節點身分加入叢集。解決方案請參閱 [對未加入叢集的節點進行疑難排解](#auto-troubleshoot-join)。
+ 使用 EKS 自動模式中包含的控制器的 `NodePools`、`PersistentVolumes` 和 `Services` 出現錯誤和問題。解決方案請參閱 [對自動模式中包含的控制器進行疑難排解](#auto-troubleshoot-controllers)。
+ 增強的 Pod 安全性阻止了跨 Pod 共用磁碟區。解決方案請參閱 [跨 Pod 共用磁碟區](#auto-troubleshoot-share-pod-volumes)。
您可使用以下方法對 EKS 自動模式元件進行疑難排解：
+ [使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出](#auto-node-console)
+ [使用*偵錯容器*和 `kubectl` CLI 取得節點日誌](#auto-node-debug-logs)
+ [在 AWS 主控台中檢視與 EKS Auto Mode 相關聯的資源](#auto-node-ec2-web)
+ [檢視您 AWS 帳戶中的 IAM 錯誤](#auto-node-iam)
+ [使用 `VPC Reachability Analyzer` 檢測節點連線問題](#auto-node-reachability)
## 節點監控代理程式
EKS 自動模式包含 Amazon EKS 節點監控代理程式。您可使用此代理程式來檢視有關節點的疑難排解和偵錯資訊。節點監控代理程式會發布 Kubernetes `events` 與節點 `conditions` 狀況。如需詳細資訊，請參閱[偵測節點運作狀態問題並啟用自動節點修復](node-health.md)。
## 使用 EC2 CLI 從 AWS EC2 受管執行個體取得主控台輸出
此程序有助於對開機時或核心層級的問題進行疑難排解。
首先，您需要確定與您工作負載關聯的執行個體的 EC2 執行個體 ID。其次，使用 AWS CLI 擷取主控台輸出。
1. 確認您已安裝 `kubectl` 並連接到您的叢集
1. (選用) 使用 Kubernetes 部署的名稱來列出關聯的 Pod。
```
kubectl get pods -l app=
```
1. 使用 Kubernetes Pod 的名稱來確定關聯節點的 EC2 執行個體 ID。
```
kubectl get pod -o wide
```
1. 使用 EC2 執行個體 ID 來擷取主控台輸出。
```
aws ec2 get-console-output --instance-id --latest --output text
```
## 使用*偵錯容器*和 `kubectl` CLI 取得節點日誌
要從 EKS 自動模式節點擷取日誌，建議的方法是使用 `NodeDiagnostic` 資源。相關步驟請參閱 [使用 kubectl 及 S3 擷取受管節點的節點日誌](auto-get-logs.md)。
但是，您可以使用 `kubectl debug node` 命令從執行個體即時串流日誌。此命令會在您要偵錯的節點上啟動新的 Pod，然後您可以互動式地使用。
1. 啟動偵錯容器。以下命令使用 `i-01234567890123456` 作為節點的執行個體 ID，`-it` 分配一個 `tty` 並附加 `stdin` 以供互動式使用，並使用 kubeconfig 檔案中的 `sysadmin` 設定檔。
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
範例輸出如下。
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. 從 shell 中，您現在可以安裝 `util-linux-core`，它提供了 `nsenter` 命令。使用 `nsenter` 進入主機上 PID 1 (`init`) 的掛載命名空間，並執行 `journalctl` 命令來從 `kubelet` 串流記錄：
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
為了安全起見，Amazon Linux 容器映像預設不安裝許多二進位檔。您可以使用 `yum whatprovides` 命令來識別必須安裝哪個套件才能提供給定的二進位檔。
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## 在 AWS 主控台中檢視與 EKS Auto Mode 相關聯的資源
您可以使用 AWS 主控台來檢視與 EKS Auto Mode 叢集相關聯的資源狀態。
+ [EBS 磁碟區](https://console.aws.amazon.com/ec2/home#Volumes)
+ 透過搜尋標籤鍵 `eks:eks-cluster-name` 來檢視 EKS 自動模式磁碟區
+ [負載平衡器](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ 搜尋標籤索引鍵 `eks:eks-cluster-name` 來檢視 EKS 自動模式負載平衡器
+ [EC2 執行個體](https://console.aws.amazon.com/ec2/home#Instances)
+ 透過搜尋標籤鍵 `eks:eks-cluster-name` 來檢視 EKS 自動模式執行個體
## 檢視您 AWS 帳戶中的 IAM 錯誤
1. 導覽至 CloudTrail 主控台
1. 從左側導覽窗格選取「事件歷程記錄」
1. 套用錯誤碼篩選條件：
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
尋找與您的 EKS 叢集相關的錯誤。透過錯誤訊息來更新您的 EKS 存取項目、叢集 IAM 角色或節點 IAM 角色。您可能需要為這些角色附加具有 EKS 自動模式許可的新政策。
## 對 Pod 無法排程到自動模式節點進行疑難排解
如果 Pod 停留在 `Pending` 狀態且無法被排程到自動模式節點，請確認您的 Pod 或部署資訊清單是否具有 `nodeSelector`。如果存在 `nodeSelector`，請確保它使用 `eks.amazonaws.com/compute-type: auto` 以便在由 EKS 自動模式建立的節點上進行排程。有關 EKS 自動模式使用的節點標籤的更多資訊，請參閱 [控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)。
## 對未加入叢集的節點進行疑難排解
EKS 自動模式會自動設定新的 EC2 執行個體，提供正確的資訊以加入叢集，包括叢集端點和叢集憑證認證機構 (CA)。然而，這些執行個體仍可能無法作為節點加入 EKS 叢集。執行以下命令來識別未加入叢集的執行個體：
1. 執行 `kubectl get nodeclaim` 來檢查 `NodeClaims` 是否為 `Ready = False`。
```
kubectl get nodeclaim
```
1. 執行 `kubectl describe nodeclaim ` 並在**狀態**下尋找阻止節點加入叢集的任何問題。
```
kubectl describe nodeclaim
```
**常見錯誤訊息：**
`Error getting launch template configs`
如果您使用預設叢集 IAM 角色許可在 `NodeClass` 中設定自訂標籤，可能會收到此錯誤。請參閱 [了解 EKS 自動模式中的身分和存取](auto-learn-iam.md)。
`Error creating fleet`
從 EC2 API 呼叫 `RunInstances` 時可能存在某些授權問題。Check AWS CloudTrail 是否有錯誤，請參閱 [Amazon EKS 自動模式叢集 IAM 角色](auto-cluster-iam-role.md) 以取得所需的 IAM 許可。
### 使用 `VPC Reachability Analyzer` 檢測節點連線問題
**注意**
您需要為 VPC Reachability Analyzer 執行的每次分析付費。如需定價的詳細資訊，請參閱 [Amazon VPC 定價](https://aws.amazon.com/vpc/pricing/)。
執行個體無法加入叢集的一個原因是網路連線問題阻止其連線到 API 伺服器。要診斷此問題，您可以使用 [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)，對無法加入叢集的節點與 API 伺服器之間的連線狀態執行分析。您需要兩條資訊：
+ 無法加入叢集的節點的**執行個體 ID**
+ **Kubernetes API 伺服器端點**的 IP 位址
要取得**執行個體 ID**，您需要在叢集上建立工作負載，以促使 EKS 自動模式啟動一個 EC2 執行個體。這也會在您的叢集中建立具有執行個體 ID 的 `NodeClaim` 物件。執行 `kubectl get nodeclaim -o yaml` 以列印叢集中的全部 `NodeClaims`。每個 `NodeClaim` 都包含執行個體 ID 作為欄位，並在 providerID 中再次出現：
```
kubectl get nodeclaim -o yaml
```
範例輸出如下。
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
您可以透過執行 `kubectl get endpoint kubernetes -o yaml` 來確定您的 **Kubernetes API 伺服器端點**。位址位於位址欄位中：
```
kubectl get endpoints kubernetes -o yaml
```
範例輸出如下。
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
透過這兩項資訊，您可以執行分析。首先導覽至 AWS 管理主控台中的 VPC Reachability Analyzer。
1. 按一下「建立並分析路徑」
1. 為分析提供一個名稱 (例如「Node Join Failure」)
1. 針對「來源類型」，選取「執行個體」
1. 輸入失敗節點的執行個體 ID 作為「來源」
1. 對於「路徑目的地」，選取「IP 位址」
1. 輸入 API 伺服器的其中一個 IP 位址作為「目的地位址」
1. 展開「其他封包標頭組態區段」
1. 輸入 443 的「目的地連接埠」
1. 如果尚未選取，選取「通訊協定」作為 TCP
1. 按一下「建立並分析路徑」
1. 分析可能需要幾分鐘的時間才會完成。如果分析結果顯示連線失敗，則將指出網路路徑中失敗的位置，以便您解決問題。
## 跨 Pod 共用磁碟區
EKS 自動模式節點設定為在強制模式下使用 SELinux，這為在同一節點上執行的 Pod 之間提供了更多隔離。啟用 SELinux 時，大多數非特殊權限 Pod 會自動套用其自己的多類別安全 (MCS) 標籤。此 MCS 標籤對每個 Pod 都是唯一的，旨在確保一個 Pod 中的程序無法操縱任何其他 Pod 或主機上的程序。即使帶有標籤的 Pod 以根目錄執行並具有對主機檔案系統的存取權，也將無法操縱檔案、在主機上進行敏感的系統呼叫、存取容器執行時期或取得 kubelet 的私密金鑰材料。
因此，當您嘗試在 Pod 之間共用資料時可能會遇到問題。例如，具有 `ReadWriteOnce` 存取模式的 `PersistentVolumeClaim` 仍然不允許多個 Pod 同時存取該磁碟區。
要啟用 Pod 之間的這種共用，您可以使用 Pod 的 `seLinuxOptions` 在這些 Pod 上設定相同的 MCS 標籤。在此範例中，我們為 Pod 分配了三個類別 `c123,c456,c789`。這不會與節點上自動分配給 Pod 的任何類別產生衝突，因為它們只會分配兩個類別。
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## 在控制平面日誌中檢視 Karpenter 事件
對於啟用了控制平面日誌的 EKS 叢集，您可透過查詢記錄來深入了解 Karpenter 的操作和決策程序。這對於對與節點佈建、擴展和終止相關的 EKS 自動模式問題進行疑難排解特別有用。要檢視 Karpenter 相關事件，請使用以下 CloudWatch Logs Insights 查詢：
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
此查詢在 kube-apiserver 稽核日誌中篩選特定的 [Karpenter 相關事件](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go)。這些事件包括各種中斷狀態、排程失敗、容量問題及節點相關問題。透過分析這些日誌，您可以更好地了解：
+ Karpenter 採取某些動作的原因。
+ 阻止正常節點佈建、擴展或終止的任何問題。
+ 與執行個體類型相關的潛在容量或相容性問題。
+ 節點生命週期事件，如中斷、移出或終止。
要使用此查詢：
1. 導覽至 CloudWatch 主控台
1. 從左側導覽窗格中選取「Logs Insights」
1. 選擇您的 EKS 叢集控制平面日誌的日誌群組
1. 將此查詢貼到查詢編輯器中
1. 視需要調整時間範圍
1. 執行查詢
結果將向您顯示 Karpenter 相關事件的時間軸，協助您對問題進行疑難排解，並了解 EKS 自動模式在您叢集中的行為。要檢視特定節點上的 Karpenter 操作，您可以將以下指定執行個體 ID 的行篩選器新增到上述查詢中：
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**注意**
要使用此查詢，必須在您的 EKS 叢集上啟用控制平面日誌。如果您還未這麼做，請參閱 [將控制平面日誌傳送至 CloudWatch Logs](control-plane-logs.md)。
## 對自動模式中包含的控制器進行疑難排解
如果控制器出現問題，您應該研究：
+ 與該控制器關聯的資源是否格式正確且有效。
+ 如果已為您的叢集正確設定 AWS IAM 和 Kubernetes RBAC 資源。如需詳細資訊，請參閱[了解 EKS 自動模式中的身分和存取](auto-learn-iam.md)。
## 相關資源
使用這些 AWS re：Post 中的文章進行進階故障診斷步驟：
+ [如何在 EKS 自動模式中對常見的擴展問題進行疑難排解？](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [如何對 Amazon EKS 自動模式中的自訂 NodePool 和 NodeClass 佈建問題進行疑難排解？](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [如何對狀態不明的 EKS 自動模式內建節點集區進行故障診斷？](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# 檢閱 EKS 自動模式版本備註
此頁面記錄 Amazon EKS 自動模式的更新。您可定期檢查本頁，以了解有關功能、錯誤修復、已知問題及已淘汰功能的公告。
如需接收有關此特定文件頁面所有來源檔案變更的通知，您可透過 RSS 閱讀器來訂閱以下 URL：
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2026 年 4 月 10 日
**新支援的執行個體類型**：p6-b200、p6-b300、p5e、p5en、trn2、hpc8a、x8aedz、x8i。如需支援執行個體的完整清單，請參閱 [了解 Amazon EKS 自動模式受管執行個體](automode-learn-instances.md)。
## 2026 年 4 月 2 日
**Chore**：NodeClass 試轉驗證現在會根據連結的 NodePools 使用動態選取的執行個體類型。
## 2026 年 2 月 2 日
**功能**：新增在 EKS Auto Mode IPv6 叢集中停用來自 IPv6 Pod 的 v4Egress 流量的支援。如需詳細資訊，請參閱[在 IPv4IPv6 叢集中停用 IPv6 Pod 的 IPv6 輸出。](create-node-class.md#enableV4Egress)。
## 2025 年 12 月 19 日
**功能**：新增對次要 IP 模式的支援，這些模式會佈建次要 IP 地址，而不是 Auto 節點的字首。模式會將一個次要 IP 維護為 MinimalIPTarget，並為不需要暖機更多次要 IP 或字首的客戶儲存 IPs 資源。如需詳細資訊，請參閱[節點類別規格](create-node-class.md#auto-node-class-spec)及[Pod 的次要 IP 模式](create-node-class.md#secondary-IP-mode)。
## 2025 年 11 月 19 日
**功能**：啟用了具有本機 NVMe 儲存體的 G、P 和 Trn 系列執行個體的 Seekable OCI (SOCI) 平行提取和解壓縮。SOCI 平行提取和解壓縮一律用於具有 EKS Auto 模式的這些執行個體系列，而且不需要變更組態即可啟用。如需 SOCI 的詳細資訊，請參閱[啟動部落格](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/)。
## 2025 年 11 月 19 日
**功能**：新增對維護固定數量節點的靜態容量節點集區的支援。如需詳細資訊，請參閱[EKS Auto 模式的靜態容量節點集區](auto-static-capacity.md)。
## 2025 年 10 月 23 日
**功能：**在美國區域中具有叢集的使用者現在可以在 NodeClass 定義`spec.advancedSecurity.fips`中指定 來請求使用 FIPS 相容 AMIs。
## 2025 年 10 月 1 日
**功能：**EKS Auto Mode 現在支援將節點部署至 AWS Local Zones。如需詳細資訊，請參閱[將 EKS Auto Mode 節點部署至 Local Zones](auto-local-zone.md)。
## 2025 年 9 月 30 日
**功能：**將對 instanceProfile 的支援新增至從 `spec.role` 欄位`spec.instanceProfile`互斥的 NodeClass。
## 2025 年 9 月 29 日
EKS Auto Mode 目前不支援 DRA。
## 2025 年 9 月 10 日
**例行維護：**自動模式運算控制器觸發的事件，現將使用名稱 `eks-auto-mode/compute`，而非 `karpenter`。
## 2025 年 8 月 24 日
**錯誤修復**：若 VPC 使用的 DHCP 選項集包含含大寫字母的自訂網域名稱，會因產生無效主機名稱導致節點無法加入叢集。此問題已解決，含大寫字母的網域名稱現可正常運作。
## 2025 年 8 月 15 日
**錯誤修復**：在 IPv4 EKS 叢集中，Pod 身分識別代理程式現將僅在 IPv4 連結本機位址上接聽，以避免 Pod 無法連接 IPv6 位址的問題。
## 2025 年 8 月 6 日
**功能：**在 NodeClass `spec.advancedNetworking.associatePublicIPAddress` 上新增組態，可透過此設定防止 Amazon EKS 自動模式節點被指派給公有 IP 位址。
## 2025 年 6 月 30 日
**功能：**除可讀寫資料磁碟區外，自動模式 NodeClass 現將使用已設定的自訂 KMS 金鑰，對執行個體的唯讀根磁碟區進行加密。此前，自訂 KMS 金鑰僅用於加密資料磁碟區。
## 2025 年 6 月 20 日
**功能：**支援控制工作負載部署至 EC2 隨需容量保留 (ODCR)。此功能在 NodeClass 中新增選用金鑰 `capacityReservationSelectorTerms`，可讓您明確控制工作負載所使用的 ODCR。如需詳細資訊，請參閱[使用 EKS 自動模式控制工作負載部署至容量保留](auto-odcr.md)。
## 2025 年 6 月 13 日
**功能：**在 `NodeClass` 中支援獨立的 Pod 子網路。此功能新增了選用金鑰 ``podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms`，可用於設定 Pod 的子網路與安全群組。如需詳細資訊，請參閱[Pod 的個別子網路和安全群組](create-node-class.md#pod-subnet-selector)。
## 2025 年 4 月 30 日
**功能：**在 `NodeClass` 中支援轉送網路代理。此功能新增選用金鑰 `advancedNetworking`，可用於設定您的 HTTPS 代理。如需詳細資訊，請參閱[節點類別規格](create-node-class.md#auto-node-class-spec)。
## 2025 年 4 月 18 日
**功能：**支援透過單播 DNS 解析 .local 網域 (通常保留給多播 DNS 使用)。
## 2025 年 4 月 11 日
**功能：**在 `NodeClass` 中新增 `certificateBundles` 與 `ephemeralStorage.kmsKeyID`。如需詳細資訊，請參閱[節點類別規格](create-node-class.md#auto-node-class-spec)。
**功能：**提升映像提取速度，尤其對於具本機執行個體儲存空間、可運用更快映像檔解壓縮速度的執行個體類型更為明顯。
**錯誤修復：**解決了競爭條件問題，該問題導致 Pod 在啟動時立即排程到節點時，有時會發生 FailedCreatePodSandBox 錯誤，以及撥號錯誤：dial tcp 127.0.0.1:50051: connect: connection refused。
## 2025 年 4 月 4 日
**功能：**將 `registryPullQPS` 從 5 增加到 25，並將 `registryBurst` 從 10 增加到 50，以減少用戶端強制執行的映像提取限流 (`Failed to pull image xyz: pull QPS exceeded`)。
## 2025 年 3 月 31 日
**錯誤修正：**修復了一個問題，即當 Core DNS Pod 在自動模式節點上運行時，來自該節點上 Pod 的 DNS 查詢會指向該 Core DNS Pod，而不是節點本機 DNS 伺服器。自動模式節點上 Pod 的 DNS 查詢現將一律指向節點本機 DNS。
## 2025 年 3 月 21 日
**錯誤修復：**即使叢集中未安裝 `kube-dns` 服務，自動模式節點現也能正確解析 `kube-dns.kube-system.svc.cluster.local`。解決 GitHub 問題 [\$12546](https://github.com/aws/containers-roadmap/issues/2546)。
## 2025 年 3 月 14 日
**功能**：在 `IPv4` 叢集中啟用 `IPv6` 輸出。從 `IPv6` 自動模式叢流出的 `IPv4` 流量，現在將自動轉譯為節點主要 ENI 的 `v4` 位址。