**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 使用節點管理運算資源
Kubernetes 節點是執行容器化應用程式的機器。每個節點皆具有下列元件：
+ **[容器執行時期](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)**：負責執行容器的軟體。
+ **[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)**：確保容器運作狀態良好並在其關聯的 Pod 中執行。
+ **[kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)**：維護允許與 Pod 通訊的網路規則。
如需詳細資訊，請參閱 Kubernetes 文件中的[節點](https://kubernetes.io/docs/concepts/architecture/nodes/)。
您的 Amazon EKS 叢集可在 [EKS 自動模式受管理節點](automode.md)、[自助管理節點](worker.md)、[Amazon EKS 受管理節點群組](managed-node-groups.md)、[AWS Fargate](fargate.md)與[Amazon EKS 混合節點](hybrid-nodes-overview.md)的任意組合上排程 Pod。若要進一步了解在叢集中部署的節點，請參閱 [在 中檢視 Kubernetes 資源 AWS 管理主控台](view-kubernetes-resources.md)。
**注意**
排除混合節點，節點必須與您在建立叢集時選取的子網路位於同一 VPC 中。不過，節點不需要位於相同的子網路中。
## 對比運算選項
下表提供了幾個準則，以便在決定哪些選項最符合您的要求時進行評估。自助管理節點是另一種選項，支援下表列出的所有標準，但需要更多手動維護工作。如需詳細資訊，請參閱[藉助自我管理節點來自行維護節點](worker.md)。
**注意**
Bottlerocket 與此表格中的一般資訊有一些特定的差異。如需詳細資訊，請參閱 GitHub 上的 Bottlerocket [文件](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md)。
| 條件 | EKS 受管節點群組 | EKS 自動模式 | Amazon EKS 混合節點 |
| --- | --- | --- | --- |
| 可以部署到 [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | 否 | 否 | 否 |
| 可以部署到 [AWS Local Zone](local-zones.md) | 是 | 否 | 否 |
| 可以執行需要 Windows 的容器 | 是 | 否 | 否 |
| 可以執行需要 Linux 的容器 | 是 | 是 | 是 |
| 可以執行需要 Inferentia 晶片的工作負載 | [是](inferentia-support.md)：僅限 Amazon Linux 節點 | 是 | 否 |
| 可以執行需要 GPU 的工作負載 | [是](eks-optimized-ami.md#gpu-ami)：僅限 Amazon Linux 節點 | 是 | 是 |
| 可以執行需要 Arm 處理器的工作負載 | [是](eks-optimized-ami.md#arm-ami) | 是 | 是 |
| 可以執行 AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | 是 | 是 | 否 |
| Pod 會與其他 Pod 共享 CPU、記憶體、儲存體和網路資源。 | 是 | 是 | 是 |
| 必須部署和管理 Amazon EC2 執行個體 | 是 | 否 - 了解 [EC2 受管執行個體](automode-learn-instances.md) | 是 – 內部部署實體或虛擬機器由您選擇的工具管理。 |
| 必須保護、維護和修補 Amazon EC2 執行個體的作業系統 | 是 | 否 | 是 – 在實體或虛擬機器上執行的作業系統由您選擇的工具管理。 |
| 可以在部署節點時提供引導引數，例如額外的 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引數。 | 是 – 以自訂 AMI 使用 `eksctl` 或[啟動範本](launch-templates.md)。 | 否 - [使用 `NodeClass` 設定節點](create-node-class.md) | 是 - 您可使用 nodeadm 自訂引導引數。請參閱 [混合節點 `nodeadm` 參考](hybrid-nodes-nodeadm.md)。 |
| 可以將 IP 位址指派給來自不同於將 IP 位址指派給節點之 CIDR 區塊的 Pod。 | 是：以自訂 AMI 使用啟動範本。如需詳細資訊，請參閱[使用啟動範本自訂受管節點](launch-templates.md)。 | 否 | 是，請參閱 [設定混合節點的 CNI](hybrid-nodes-cni.md)。 |
| 可以對節點執行 SSH | 是 | 否 - [了解如何對節點進行疑難排解](auto-troubleshoot.md) | 是 |
| 可以將自己的自訂 AMI 部署至節點 | 是：使用[啟動範本](launch-templates.md) | 否 | 是 |
| 可以將您自己的自訂 CNI 部署至節點 | 是：以自訂 AMI 使用[啟動範本](launch-templates.md) | 否 | 是 |
| 必須自行更新節點 AMI | [是](update-managed-node-group.md)：如果已部署 Amazon EKS 最佳化 AMI，Amazon EKS 主控台會在有可用更新時通知您。您只要在主控台中按一下即可執行更新。如果已部署自訂 AMI，Amazon EKS 主控台不會在有更新可用時通知您。您必須自行執行更新。 | 否 | 是 – 在實體或虛擬機器上執行的作業系統由您選擇的工具管理。請參閱 [準備混合節點的作業系統](hybrid-nodes-os.md)。 |
| 必須自行更新節點 Kubernetes 版本 | [是](update-managed-node-group.md)：如果已部署 Amazon EKS 最佳化 AMI，Amazon EKS 主控台會在有可用更新時通知您。您只要在主控台中按一下即可執行更新。如果已部署自訂 AMI，Amazon EKS 主控台不會在有更新可用時通知您。您必須自行執行更新。 | 否 | 是 - 您可以使用自選工具或 `nodeadm` 來管理混合節點的升級。請參閱 [升級叢集的混合節點](hybrid-nodes-upgrade.md)。 |
| 可以透過 Pod 使用 Amazon EBS 儲存體 | [是](ebs-csi.md) | 是，作為整合能力。了解如何[建立儲存類別。](create-storage-class.md) | 否 |
| 可以透過 Pod 使用 Amazon EFS 儲存體 | [是](efs-csi.md) | 是 | 否 |
| 可以搭配 Pod 使用 Amazon S3 檔案儲存 | [是](s3files-csi.md) | 是 | 否 |
| 可以透過 Pod 使用 Amazon FSx for Lustre 儲存體 | [是](fsx-csi.md) | 是 | 否 |
| 可以針對服務使用 Network Load Balancer | [是](network-load-balancing.md) | 是 | 是 - 必須使用目標類型 `ip`。 |
| Pod 可以在公有子網路中執行 | 是 | 是 | 否 - 在內部部署環境中執行的 Pod。 |
| 可以將不同的 VPC 安全群組指派給個別 Pod | [是](security-groups-for-pods.md) – 僅限 Linux 節點 | 否 | 否 |
| 可以執行 Kubernetes DaemonSets | 是 | 是 | 是 |
| 支援 Pod 資訊清單中的 `HostPort` 和 `HostNetwork` | 是 | 是 | 是 |
| AWS 區域可用性 | [所有 Amazon EKS 支援的區域](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [所有 Amazon EKS 支援的區域](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [所有 Amazon EKS 支援的區域](https://docs.aws.amazon.com/general/latest/gr/eks.html)， AWS GovCloud (US) 區域和中國區域除外。 |
| 可以在 Amazon EC2 專用主機上執行容器 | 是 | 否 | 否 |
| 定價 | 執行多個 Pod 的 Amazon EC2 執行個體的成本。如需詳細資訊，請參閱 [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)。 | 在叢集中啟用 EKS 自動模式時，除了標準 EC2 執行個體費用之外，您還需要為使用自動模式運算功能啟動的執行個體支付個別費用。數量會隨啟動的執行個體類型和叢集所在的 AWS 區域而有所不同。如需詳細資訊，請參閱 [Amazon EKS 定價](https://aws.amazon.com/eks/pricing/)。 | 每小時混合節點 vCPU 的成本。如需詳細資訊，請參閱 [Amazon EKS 定價](https://aws.amazon.com/eks/pricing/)。 |
# 透過受管節點群組來簡化節點生命週期
Amazon EKS 受管節點群組會自動化 Amazon EKS Kubernetes 叢集節點 (Amazon EC2 執行個體) 的佈建和生命週期管理。
使用 Amazon EKS 受管節點群組時，不需要個別佈建或註冊提供運算容量的 Amazon EC2 執行個體，來執行 Kubernetes 應用程式。您可以透過單一操作來建立、自動更新或終止叢集的節點。節點更新和終止會自動耗盡節點，以確保您的應用程式保持可用。
每個受管節點均會佈建為 Amazon EKS 為您管理的 Amazon EC2 Auto Scaling 群組的一部分。包括執行個體和 Auto Scaling 群組在內的每個資源都會在您的 AWS 帳戶中執行。每個節點群組都可以跨您定義的多個可用區域執行。
受管節點群組還可以選擇性地利用節點自動修復，進而持續監控節點的運作狀態。它會自動對偵測到的問題進行回應，並盡可能取代節點。此功能有助於提高叢集的整體可用性，並且盡可能減少手動介入。如需詳細資訊，請參閱[偵測節點運作狀態問題並啟用自動節點修復](node-health.md)。
您可以使用 Amazon EKS 主控台、`eksctl`、 AWS CLI、 AWS API 或基礎設施做為程式碼工具，包括 AWS CloudFormation，將受管節點群組新增至新的或現有的叢集。以受管節點群組身分啟動的節點，會自動標記以供 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) 自動探索。您可以使用節點群組將 Kubernetes 標籤套用至節點，並隨時加以更新。
使用 Amazon EKS 受管節點群組無需額外費用，您只需為佈建 AWS 的資源付費。其中包括 Amazon EC2 執行個體、Amazon EBS 磁碟區、Amazon EKS 叢集時數，以及任何其他 AWS 基礎設施。沒有最低費用，也沒有前期承諾。
若要開始使用新的 Amazon EKS 叢集和受管節點群組，請參閱 [開始使用 Amazon EKS – AWS 管理主控台 和 AWS CLI](getting-started-console.md)。
若要將受管理的節點群組新增至現有叢集，請參閱 [建立叢集的受管節點群組](create-managed-node-group.md)。
## 受管節點群組概念
+ Amazon EKS 受管節點群組會為您建立和管理 Amazon EC2 執行個體。
+ 每個受管節點均會佈建為 Amazon EKS 為您管理的 Amazon EC2 Auto Scaling 群組的一部分。此外，包括 Amazon EC2 執行個體和 Auto Scaling 群組在內的每個資源都會在您的 AWS 帳戶中執行。
+ Amazon EKS 會定期同步受管節點群組的擴展組態，以符合實際的 Auto Scaling 群組值。如果 Cluster Autoscaler 等外部演員修改 Auto Scaling 群組的大小， 最終`DescribeNodegroup`會反映這些變更。當您啟動節點群組更新或升級而不明確修改擴展組態時，工作流程會使用目前的 Auto Scaling 群組值，而不是節點群組的預存擴展組態。儲存的擴展組態只有在您明確地將其包含在`UpdateNodegroupConfig`請求中時才會優先。
+ 受管節點群組的 Auto Scaling 群組會跨越您在建立群組時指定的每個子網路。
+ Amazon EKS 會標記受管節點群組資源，以便將其設定為使用 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)。
**重要**
如果您跨越多個由 Amazon EBS 磁碟區提供的可用區域執行狀態應用程式，並且使用 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)，您應該設定多個節點群組，每個群組的範圍皆為單一可用區域。另外，您應該啟用 `--balance-similar-node-groups` 功能。
+ 部署受管節點時，您可以使用自訂啟動範本來獲得更高層級的靈活性和自訂能力。例如，可指定額外的 `kubelet` 引數並使用自訂 AMI。如需詳細資訊，請參閱[使用啟動範本自訂受管節點](launch-templates.md)。如果在第一次建立受管節點群組時未使用自訂啟動範本，會有一個自動產生的啟動範本。請勿手動修改此自動產生的範本，否則會發生錯誤。
+ Amazon EKS 會遵循受管節點群組上 CVE 和安全修補程式的共同責任模型。受管節點執行 Amazon EKS 最佳化 AMI 時，Amazon EKS 負責在報告錯誤或問題時建置 AMI 的修補版本。我們可以發佈修正程式。不過，您必須負責將這些修補的 AMI 版本部署至受管節點群組。當受管節點執行自訂 AMI 時，您必須負責在報告錯誤或問題時建置 AMI 的修補版本，然後部署 AMI。如需詳細資訊，請參閱[更新叢集的受管節點群組](update-managed-node-group.md)。
+ Amazon EKS 受管節點群組可以在公有和私有子網路中啟動。如果在 2020 年 4 月 22 日或之後啟動公有子網路中的受管節點群組，則子網路必須將 `MapPublicIpOnLaunch` 設定為「true」，執行個體才能成功加入叢集。如果公有子網路是在 2020 年 3 月 26 日或之後使用 `eksctl`或 [Amazon EKS vended AWS CloudFormation 範本](creating-a-vpc.md)建立，則此設定已設為 true。如果公有子網路是在 2020 年 3 月 26 日之前所建立，則必須手動變更設定。如需詳細資訊，請參閱[修改子網的公有 IPv4 定址屬性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)。
+ 在私有子網路中部署受管節點群組時，您必須確保該群組可存取 Amazon ECR 以提取容器映像。您可以透過將 NAT 閘道連接至子網路的路由表，或新增以下 [AWS PrivateLink VPC 端點](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)來執行此操作：
+ Amazon ECR API 端點界面 – `com.amazonaws.region-code.ecr.api`
+ Amazon ECR Docker 登錄檔 API 端點界面 – `com.amazonaws.region-code.ecr.dkr`
+ Amazon S3 閘道端點 – `com.amazonaws.region-code.s3`
如需了解其他常用的服務和端點，請參閱 [部署網際網路存取受到限制的私有叢集](private-clusters.md)。
+ 受管節點群組無法部署在 [AWS Outposts](eks-outposts.md) 上或 [AWS Wavelength](https://docs.aws.amazon.com/wavelength/) 中。受管節點群組可建立在 [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) 上。如需詳細資訊，請參閱[使用 AWS Local Zones 啟動低延遲 EKS 叢集](local-zones.md)。
+ 您可以在單一叢集內建立多個受管節點群組。例如，您可以針對某些工作負載建立具有標準 Amazon EKS 最佳化 Amazon Linux AMI 的節點群組，而針對需要 GPU 支援的工作負載使用 GPU 變體建立另一個節點群組。
+ 如果受管節點群組遇到 [Amazon EC2 執行個體狀態檢查](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html)故障問題，Amazon EKS 會傳回錯誤代碼，以協助您診斷問題。如需詳細資訊，請參閱[受管節點群組錯誤代碼](troubleshooting.md#troubleshoot-managed-node-groups)。
+ Amazon EKS 會將 Kubernetes 標籤新增至受管節點群組執行個體。這些 Amazon EKS 提供的標籤前面會加上 `eks.amazonaws.com`。
+ 在終止或更新期間，Amazon EKS 會使用 Kubernetes API 自動耗盡節點。
+ 使用 `AZRebalance` 終止節點或減少所需的節點計數時，不會遵守 Pod 中斷預算。這些動作會嘗試在該節點上移出 Pod。但如果需要超過 15 分鐘，則無論節點上的所有 Pod 是否終止，都會終止節點。若要延長期間直到節點終止，請將 lifecycle hook 新增至 Auto Scaling 群組。如需詳細資訊，請參閱 *Amazon EC2 Auto Scaling 使用者指南*中的[新增 lifecycle hook](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html)。
+ 若要在收到 Spot 中斷通知或容量重新平衡通知後正確執行耗盡程序，必須將 `CapacityRebalance` 設定為 `true`。
+ 更新受管節點群組會遵守您為 Pod 設定的 Pod 中斷預算。如需詳細資訊，請參閱 [了解節點更新的每個階段](managed-node-update-behavior.md)。
+ 使用 Amazon EKS 受管節點群組不會產生額外成本。您只需為佈建 AWS 的資源付費。
+ 如果要為節點加密 Amazon EBS 磁碟區，則可以使用啟動範本部署節點。若要在不使用啟動範本的情況下部署具有加密 Amazon EBS 磁碟區的受管節點，請加密帳戶中建立的所有新 Amazon EBS 磁碟區。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[預設加密](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)。
## 受管節點群組容量類型
建立受管節點群組時，您可以選擇隨需或 Spot 容量類型。Amazon EKS 部署具有 Amazon EC2 Auto Scaling 群組的受管節點群組，該群組僅包含隨需執行個體或僅包含 Amazon EC2 Spot 執行個體。您可以將具有容錯能力之應用程式的 Pod 排程到 Spot 受管節點群組，以及將具有容錯能力之應用程式的 Pod 排程到單一 Kubernetes 叢集中的隨需節點群組。依預設，受管節點群組會部署隨需 Amazon EC2 執行個體。
### On-Demand
透過隨需執行個體，您只需要按秒數支付運算容量開銷，無需簽訂長期合約。
預設情況下，如果未指定**容量類型**，則會使用隨需執行個體佈建受管節點群組。受管節點群組會代表您設定 Amazon EC2 Auto Scaling 群組，並套用下列設定：
+ 佈建隨需容量的配置策略設定為 `prioritized`。在滿足隨需容量時，受管節點群組會 API 中傳遞執行個體類型的順序，決定先使用哪一種執行個體類型。例如，您可以按照下列順序指定三種執行個體類型：`c5.large`、`c4.large`，以及 `c3.large`。當您的隨需執行個體啟動時，受管節點群組會從 `c5.large` 開始，然後是 `c4.large`，再來是 `c3.large`，以滿足隨需容量。如需詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》**中的 [Amazon EC2 Auto Scaling 群組](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies)。
+ Amazon EKS 會將下列 Kubernetes 標籤新增至指定容量類型之受管節點群組中的所有節點：`eks.amazonaws.com/capacityType: ON_DEMAND`。您可以使用此標籤，在隨需節點上排程可設定狀態或可容錯的應用程式。
### Spot
Amazon EC2 Spot 執行個體是備用的 Amazon EC2 容量，可提供隨需價格的極低折扣。EC2 需要取回容量時，就可能會以兩分鐘中斷通知的方式中斷 Amazon EC2 Spot 執行個體。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[Spot 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)。您可以使用 Amazon EC2 Spot 執行個體設定受管節點群組，以最佳化 Amazon EKS 叢集中執行之運算節點的成本。
若要在受管節點群組內使用 Spot 執行個體，請將容量類型設定為`spot`，以建立受管節點群組。受管節點群組代表您設定 Amazon EC2 Auto Scaling 群組，並套用下列 Spot 最佳實務：
+ 為確保您的 Spot 節點已在最佳 Spot 容量集區中佈建，配置策略會設定為下列之一：
+ `price-capacity-optimized` (PCO)：在具有 Kubernetes 版本 `1.28` 或更新版本的叢集中建立新節點群組時，配置策略會設定為 `price-capacity-optimized`。但是，在 Amazon EKS 受管節點群組開始支援 PCO 之前，系統不會變更已使用 `capacity-optimized` 建立的節點群組的配置策略。
+ `capacity-optimized` (CO)：在具有 Kubernetes 版本 `1.27` 或更低版本的叢集中建立新節點群組時，配置策略會設定為 `capacity-optimized`。
若要增加可用於配置容量的 Spot 容量集區數量，請將受管節點群組設定為使用多個執行個體類型。
+ 已啟用 Amazon EC2 Spot 容量重新平衡功能，以便 Amazon EKS 可以正常地消耗和重新平衡 Spot 節點，在 Spot 節點中斷風險提高時，將應用程式中斷情況降至最低。如需詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》中的 [Amazon EC2 Auto Scaling 容量重新平衡](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html)。
+ Spot 節點收到重新平衡建議時，Amazon EKS 會自動嘗試啟動新的替代 Spot 節點。
+ 如果 Spot 兩分鐘中斷通知在取代 Spot 節點處於 `Ready` 狀態前到達，則 Amazon EKS 會開始消耗收到重新平衡建議的 Spot 節點。Amazon EKS 將竭盡全力耗盡節點。因此，無法保證 Amazon EKS 會在耗盡現有節點之前等待替代節點加入叢集。
+ 啟動取代 Spot 節點，並且在 Kubernetes 處於 `Ready` 狀態時，Amazon EKS 會包圍隔離並消耗收到重新平衡建議的 Spot 節點。包圍隔離 Spot 節點可確保服務控制器不會將任何新的請求傳送到此 Spot 節點。它也會從狀況良好、作用中的 Spot 節點清單中移除。耗盡 Spot 節點可確保正在執行的 Pod 可以正常地移出。
+ Amazon EKS 會將下列 Kubernetes 標籤新增至指定容量類型之受管節點群組中的所有節點：`eks.amazonaws.com/capacityType: SPOT`。您可以使用此標籤在 Spot 節點上排程可容錯的應用程式。
**重要**
EC2 會在終止 [Spot 執行個體的兩分鐘前發出 Spot 中斷通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)。不過，Spot 節點上的 Pod 可能不會收到正常關閉的完整 2 分鐘時段。當 EC2 發出通知時，Amazon EKS 開始移出 Pod 之前會有延遲。移除會依序發生以保護 Kubernetes API 伺服器，因此在多個同時 Spot 回收期間，某些 Pod 可能會收到延遲的移出通知。Pod 可能會在不接收終止訊號的情況下強制終止，特別是在具有高 Pod 密度的節點上、在並行回收期間或使用長終止寬限期時。對於 Spot 工作負載，我們建議您使用 30 秒或更短的終止寬限期來設計應用程式，避免長時間執行preStop 掛鉤，並監控 Pod 移出指標，以了解叢集中的實際寬限期。對於需要保證正常終止的工作負載，我們建議您改用隨需容量。
決定是否要部署具有隨需或 Spot 容量的節點群組時，應考慮下列條件：
+ Spot 執行個體適用於無狀態、容錯、靈活的應用程式。其中包括批次和機器學習訓練工作負載、大數據 ETL (例如 Apache Spark)、佇列處理應用程式，以及無狀態 API 端點。由於 Spot 是可能隨時間變更的備用 Amazon EC2 容量，因此建議您將 Spot 容量用於可接受中斷的工作負載。更具體地說，Spot 容量適用於容錯期間無法使用所需容量的工作負載。
+ 我們建議您將隨需模式用於不容錯的應用程式。這包括叢集管理工具 (例如監控和操作工具)、需要 `StatefulSets` 的部署，以及狀態應用程式 (例如資料庫)。
+ 為了在使用 Spot 執行個體時最大化應用程式的可用性，建議您將 Spot 受管節點群組設定為使用多個執行個體類型。建議您在使用多個執行個體類型時，套用下列規則：
+ 在受管節點群組中，如果您使用 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)，則建議使用具有相同數量 vCPU 和記憶體資源的彈性執行個體類型集。這是為了確保叢集中的節點如預期般擴展。例如，如果您需要四個 vCPU 和八個 GiB 記憶體，請使用 `c3.xlarge`、`c4.xlarge`、`c5.xlarge`、`c5d.xlarge`、`c5a.xlarge`、`c5n.xlarge` 或其他類似的執行個體類型。
+ 若要增強應用程式可用性，建議部署多個 Spot 受管節點群組。為此，每個群組應該使用具有相同 vCPU 和記憶體資源的彈性執行個體類型集。例如，如果您需要 4 個 vCPU 和 8 個 GiB 記憶體，建議您使用 `c3.xlarge`、`c4.xlarge`、`c5.xlarge`、`c5d.xlarge`、`c5a.xlarge`、`c5n.xlarge` 或其他類似的執行個體類型建立一個受管節點群組，以及使用 `m3.xlarge`、`m4.xlarge`、`m5.xlarge`、`m5d.xlarge`、`m5a.xlarge`、`m5n.xlarge` 或其他類似的執行個體類型建立另一個受管節點。
+ 透過使用自訂啟動範本的 Spot 容量類型部署節點群組時，請使用 API 傳遞多個執行個體類型。請勿透過啟動範本傳遞單一執行個體類型。如需使用啟動範本部署節點群組的詳細資訊，請參閱 [使用啟動範本自訂受管節點](launch-templates.md)。
# 建立叢集的受管節點群組
本主題會描述如何啟動已向 Amazon EKS 叢集註冊的節點的 Amazon EKS 受管節點群組。節點加入叢集後，您就可以將 Kubernetes 應用程式部署至其中。
如果這是您第一次啟動 Amazon EKS 受管節點群組，建議您改為按照其中一個 [開始使用 Amazon EKS](getting-started.md) 指南的步驟進行。這些指南提供建立具有節點的 Amazon EKS 叢集的演練。
**重要**
Amazon EKS 節點是標準的 Amazon EC2 執行個體。我們會根據正常 Amazon EC2 價格向您收費。如需詳細資訊，請參閱 [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)。
您無法在已啟用 AWS Outposts 或 Wavelength AWS 的 AWS 區域中建立受管節點。您可改為建立自我管理的節點。如需詳細資訊，請參閱[建立自我管理的 Amazon Linux 節點](launch-workers.md)、[建立自我管理的 Microsoft Windows 節點](launch-windows-workers.md)及[建立自我管理的 Bottlerocket 節點](launch-node-bottlerocket.md)。您也可以在 Outpost 上建立自我管理的 Amazon Linux 節點群組。如需詳細資訊，請參閱[在 AWS Outpost 上建立 Amazon Linux 節點](eks-outposts-self-managed-nodes.md)。
如果您沒有為 Amazon EKS 最佳化 Linux 或 Bottlerocket 隨附的 `bootstrap.sh` 檔案[指定 AMI ID](launch-templates.md#launch-template-custom-ami)，則受管節點群組會對 `maxPods` 的值強制執行數量上限。對於少於 30 個 vCPU 的執行個體，數量上限為 `110`。對於具有 30 個以上 vCPU 的執行個體，數量上限會跳至 `250`。此強制執行會覆寫其他`maxPods`組態，包括 `maxPodsExpression`。如需如何`maxPods`確定以及如何自訂它的詳細資訊，請參閱 [maxPods的判斷方式](choosing-instance-type.md#max-pods-precedence)。
+ 現有 Amazon EKS 叢集。若要部署叢集，請參閱 [建立 Amazon EKS 叢集](create-cluster.md)。
+ 供節點使用的現有 IAM 角色。若要建立服務角色，請參閱[Amazon EKS 節點 IAM 角色](create-node-role.md)。如果此角色沒有任何 VPC CNI 的政策，則 VPC CNI Pod 需要以下個別角色。
+ (選用，但建議) Kubernetes 專用 Amazon VPC CNI 外掛程式的附加元件設定有自己的 IAM 角色，該角色已連接必要的 IAM 政策。如需詳細資訊，請參閱[設定 Amazon VPC CNI 外掛程式以使用 IRSA](cni-iam-role.md)。
+ 熟悉[選擇最佳 Amazon EC2 節點執行個體類型](choosing-instance-type.md)中所列的考量事項。取決於您選擇的執行個體類型，您的叢集和 VPC 可能還有其他先決條件。
+ 若要新增 Windows 受管節點群組，您必須先啟用叢集的 Windows 支援。如需詳細資訊，請參閱[在 EKS 叢集上部署 Windows 節點](windows-support.md)。
您可以透過以下任一項來建立受管節點群組：
+ [`eksctl`](#eksctl_create_managed_nodegroup)
+ [AWS 管理主控台](#console_create_managed_nodegroup)
## `eksctl`
**使用 eksctl 建立受管節點群組**
此程序需要 `eksctl` 版本 `0.215.0` 或更新版本。您可使用以下命令檢查您的版本：
```
eksctl version
```
如需有關安裝或更新 `eksctl` 的指示，請參閱 `eksctl` 文件中的 [Installation](https://eksctl.io/installation) 一節。
1. (選用) 如果 **AmazonEKS\$1CNI\$1Policy** 受管 IAM 政策已連接至您的 [Amazon EKS 節點 IAM 角色](create-node-role.md)，建議您改為將其指派給您與 Kubernetes `aws-node` 服務帳戶相關聯的 IAM 角色。如需詳細資訊，請參閱[設定 Amazon VPC CNI 外掛程式以使用 IRSA](cni-iam-role.md)。
1. 使用或不使用自訂啟動範本來建立受管節點群組。手動指定啟動範本可讓您更靈活地自訂節點群組。例如，此方式可以允許部署自訂 AMI，或對 Amazon EKS 最佳化 AMI 中的 `boostrap.sh` 指令碼提供引數。如需每個可用選項和預設值的完整清單，請輸入以下命令。
```
eksctl create nodegroup --help
```
在以下命令中，將 *my-cluster* 取代為您的叢集名稱，並將 *my-mng* 取代為您的節點群組名稱。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。
**重要**
如果在第一次建立受管的節點群組時未使用自訂啟動範本，請勿在之後針對節點群組使用自訂啟動範本。如果沒有指定自訂啟動範本，系統會自動產生啟動範本 (不建議手動修改該範本)。手動修改此自動產生的啟動範本可能會導致錯誤。
**沒有啟動範本**
`eksctl` 會在您的帳戶中建立預設 Amazon EC2 啟動範本，並使用根據您指定之選項建立的啟動範本來部署節點群組。指定 `--node-type` 的值之前，請參閱 [選擇最佳的 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。
使用允許的關鍵字取代 *ami-family*。如需詳細資訊，請參閱 `eksctl` 文件中的 [Setting the node AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) (設定節點 AMI 系列)。使用 Amazon EC2 金鑰對或公有金鑰的名稱取代 *my-key*。此金鑰會在節點啟動後用於將 SSH 套用至節點。
**注意**
對於 Windows，此命令不會啟用 SSH。而是將 Amazon EC2 金鑰對與執行個體建立關聯，讓您可以 RDP 至該執行個體中。
如果您還沒有 Amazon EC2 金鑰對，可以在 AWS 管理主控台中建立一個。如需 Linux 資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 使用者指南](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。如需 Windows 資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 金鑰對和 Windows 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)。
如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
如果要封鎖 Pod 對 IMDS 的存取，請將 `--disable-pod-imds` 選項新增至下列命令。
```
eksctl create nodegroup \
--cluster my-cluster \
--region region-code \
--name my-mng \
--node-ami-family ami-family \
--node-type m5.large \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--ssh-access \
--ssh-public-key my-key
```
您的執行個體可以選擇性地為 Pod 指派更多的 IP 位址、將 IP 位址指派給不同於執行個體之 CIDR 區塊的 Pod，以及在沒有網際網路存取的情況下部署到叢集。如需詳細資訊，請參閱 [將更多 IP 位址指派給具有字首的 Amazon EKS 節點](cni-increase-ip-addresses.md)、[使用自訂聯網在替代子網路中部署 Pod](cni-custom-network.md) 和 [部署網際網路存取受到限制的私有叢集](private-clusters.md) 以取得要新增至之前命令的其他選項。
受管節點群組會根據執行個體類型，計算並套用可在節點群組的每個節點上執行的 Pod 數量上限的單一數值。如果建立建具有不同執行個體類型的節點群組，則在所有執行個體類型中計算的最小值，會應用為可以在節點群組中的每種執行個體類型上執行的 Pod 數量上限。如需如何計算此值的詳細資訊，請參閱 [maxPods的判斷方式](choosing-instance-type.md#max-pods-precedence)。
**使用啟動範本**
啟動範本必須已經存在，且必須符合[啟動範本組態基礎知識](launch-templates.md#launch-template-basics)中指定的要求。如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
如果您要封鎖 Pod 對 IMDS 的存取，則請在啟動範本中指定必要的設定。
1. 將以下內容複製到您的裝置。取代範例值，然後執行修改後的命令來建立 `eks-nodegroup.yaml` 檔案。在不使用啟動範本的情況下部署時指定的數個設定會移至啟動範本。如果您未指定 `version`，即使用範本的預設版本。
```
cat >eks-nodegroup.yaml <
**使用 AWS 管理主控台 建立受管節點群組**
1. 等待您的叢集狀態顯示為 `ACTIVE`。您無法針對尚未進入 `ACTIVE` 狀態的叢集建立受管節點群組。
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇要在其中建立受管節點群組的叢集名稱。
1. 選取 **Compute** (運算) 標籤。
1. 選擇 **Add node group** (新增節點群組)。
1. 在 **Configure node group (配置節點群組)** 頁面上，相應地填寫參數，然後選擇 **Next (下一步)**。
+ **Name** (名稱) – 輸入受管節點群組的唯一名稱。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。
+ **Node IAM role** (節點 IAM 角色)：選擇要與節點群組搭配使用的節點執行個體角色。如需詳細資訊，請參閱[Amazon EKS 節點 IAM 角色](create-node-role.md)。
**重要**
您無法使用用於建立任何叢集的相同角色。
建議使用尚未被任何自我管理節點群組使用的角色。否則，您要計劃與新的自我管理節點組一起使用。如需詳細資訊，請參閱[從您的叢集刪除受管節點群組](delete-managed-node-group.md)。
+ **Use launch template** (使用啟動範本)：(選用) 選擇是否要使用現有的啟動範本。選取**啟動範本名稱**。然後，選取 **Launch template version** (啟動範本版本)。如果您沒有選取版本，則 Amazon EKS 會使用範本的預設版本。啟動範本允許對節點群組進行更多自訂，如允許您部署自訂 AMI、為 Pod 指派更多的 IP 位址、將 IP 位址指派給不同於執行個體之 CIDR 區塊的 Pod，以及將節點部署至沒有出站網際網路存取的叢集。如需詳細資訊，請參閱[將更多 IP 位址指派給具有字首的 Amazon EKS 節點](cni-increase-ip-addresses.md)、[使用自訂聯網在替代子網路中部署 Pod](cni-custom-network.md)及[部署網際網路存取受到限制的私有叢集](private-clusters.md)。
啟動範本必須滿足[透過啟動範本來自訂受管節點](launch-templates.md)中的要求。如果您不使用自己的啟動範本，Amazon EKS API 會在您的帳戶中建立預設的 Amazon EC2 啟動範本，並使用預設啟動範本部署節點群組。
如果您[為服務帳戶實作 IAM 角色](iam-roles-for-service-accounts.md)，請直接將必要的許可指派給需要存取 AWS 服務的每個 Pod，而且叢集中沒有任何 Pod 需要存取 IMDS，例如擷取目前 AWS 區域，則您也可以停用在啟動範本中未使用主機聯網之 Pod 的 IMDS 存取權。如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
+ **Kubernetes labels** (Kubernetes 標籤) – (選用) 您可以選擇將 Kubernetes 標籤套用至受管節點群組中的節點。
+ **Kubernetes 污點** – (選用) 您可以選擇將 Kubernetes 污點套用至受管節點群組中的節點。**Effect** (效果) 功能表中的可用選項是 ` NoSchedule `、` NoExecute ` 及 ` PreferNoSchedule `。如需詳細資訊，請參閱[配方：阻止在特定節點上排程 Pod](node-taints-managed-node-groups.md)。
+ **Tags** (標籤) – (選用) 您可以選擇標記 Amazon EKS 受管節點群組。這些標籤不會傳播到節點群組中的其他資源，例如 Auto Scaling 群組或執行個體。如需詳細資訊，請參閱[使用標籤組織 Amazon EKS 資源](eks-using-tags.md)。
1. 在 **Set compute and scaling configuration** (設定運算和擴展組態) 頁面上，相應地填寫參數，然後選擇 **Next** (下一步)。
+ **AMI 類型**：選取 AMI 類型。如果您在部署 Arm 執行個體，請務必在部署前檢閱 [Amazon EKS 最佳化 Arm Amazon Linux AMI](eks-optimized-ami.md#arm-ami) 中的考量事項。
如果您在上一頁中已指定啟動範本，並在啟動範本中指定了 AMI，則無法選取值。系統會顯示範本中的值。範本中指定的 AMI 必須符合[指定 AMI](launch-templates.md#launch-template-custom-ami) 中的要求。
+ **Capacity type** (容量類型) – 選取容量類型。如需選擇容量類型的詳細資訊，請參閱 [受管節點群組容量類型](managed-node-groups.md#managed-node-group-capacity-types)。您無法在同一節點群組中混合使用不同的容量類型。如果要同時使用這兩種容量類型，請建立個別的節點群組，每個群組都有自己的容量和執行個體類型。有關佈建和擴展 GPU 加速工作節點的資訊，請參閱[為受管節點群組保留 GPU](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html)。
+ **Instance types** (執行個體類型)：依預設會指定一或多個執行個體類型。若要移除預設執行個體類型，請選取執行個體類型的右側的 `X`。選擇要在受管節點群組中使用的執行個體類型。如需詳細資訊，請參閱[選擇最佳的 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。
主控台會顯示一組常用的執行個體類型。如果您需要使用未顯示的執行個體類型建立受管節點群組，請使用 `eksctl`、 CLI、 AWS CloudFormation AWS 或 SDK 來建立節點群組。如果您在上一頁指定了啟動範本，則無法選取值，因為必須在啟動範本中指定執行個體類型。系統會顯示啟動範本中的值。如果為 **Capacity type** (容量類型) 選取了 **Spot**，則建議您指定多個執行個體類型以增強可用性。
+ **Disk size** (磁碟大小) – 輸入要用於節點根磁碟區的磁碟大小 (以 GiB 為單位)。
如果您在上一頁指定了啟動範本，則無法選取值，因為必須在啟動範本中指定該值。
+ **Desired size** (所需大小) – 指定受管節點群組目前在啟動時應該維護的節點數量。
**注意**
Amazon EKS 不會自動擴展或縮減您的節點群組。不過，您可以設定 Kubernetes Cluster Autoscaler 為您執行這項操作。如需詳細資訊，請參閱 [Cluster Autoscaler on AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)。
+ **Minimum size** (大小下限) – 指定受管節點群組可縮減至的節點數量下限。
+ **Maximum size** (大小上限)：指定受管節點群組可擴增至的節點數量上限。
+ **Node group update configuration** (節點群組更新組態) – (選用) 您可以選取要平行更新的節點數量或百分比。這些節點在更新期間將無法使用。對於 **Maximum unavailable** (無法使用的上限)，選取下列其中一個選項，然後指定 **Value** (值)：
+ **Number** (數量)：選取並指定可平行更新節點群組的節點數量。
+ **Percentage** (百分比)：選取並指定可平行更新節點群組的節點百分比。如果您的節點群組中有大量節點，這會很有用。
+ **節點自動修復組態** - (選用) 如果您啟用**啟用節點自動修復**核取方塊，Amazon EKS 將在偵測到問題發生時自動取代節點。如需詳細資訊，請參閱[偵測節點運作狀態問題並啟用自動節點修復](node-health.md)。
+ **暖集區組態** – （選用） 如果您啟用**啟用暖集區組態**核取方塊，Amazon EKS 將在 ASG 上建立暖集區。如需詳細資訊，請參閱[使用具有受管節點群組的暖集區，減少開機時間較長之應用程式的延遲](warm-pools-managed-node-groups.md)。
1. 在 **Specify networking** (指定聯網) 頁面上，據此填寫參數，然後選擇 **Next** (下一步)。
+ **Subnets** (子網路)：選擇要將受管節點啟動至其中的子網路。
**重要**
如果您跨越多個由 Amazon EBS 磁碟區提供的可用區域執行狀態應用程式，並且使用 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)，您應該設定多個節點群組，每個群組的範圍皆為單一可用區域。另外，您應該啟用 `--balance-similar-node-groups` 功能。
**重要**
如果選擇公有子網路，而且您的叢集只啟用了公有 API 伺服器端點，則子網路的必須將 `MapPublicIPOnLaunch` 設定為 `true`，讓執行個體成功加入叢集。如果子網路是在 2020 年 3 月 26 日或之後使用 `eksctl`或 [Amazon EKS vended AWS CloudFormation 範本](creating-a-vpc.md)建立，則此設定已設定為 `true`。如果在 2020 年 3 月 26 日之前使用 `eksctl`或 AWS CloudFormation 範本建立子網路，則需要手動變更設定。如需詳細資訊，請參閱[修改子網的公有 IPv4 定址屬性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)。
如果使用啟動範本並指定多個網路介面，Amazon EC2 便不會自動指派公有 `IPv4` 位址，即使 `MapPublicIpOnLaunch` 已設定為 `true`。對於在此案例中加入叢集的節點，您必須啟用叢集的私有 API 伺服器端點，或使用透過其他方法 (例如 NAT Gateway) 提供的出站網際網存取，啟動私有子網路中的節點。如需詳細資訊，請參閱*《Amazon EC2 使用者指南》*中的 [Amazon EC2 執行個體 IP 定址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)。
+ **設定 SSH 存取節點** (選用)。啟用 SSH 可讓您連接到執行個體，並在發生問題時收集診斷資訊。強烈建議您在建立節點群組時啟用遠端存取。您無法在建立節點群組之後啟用遠端存取。
如果您選擇使用啟動範本，則不會顯示此選項。若要啟用節點的遠端存取，請在啟動範本中指定金鑰對，並確定您在啟動範本中指定之安全群組中的節點已開啟適當的連接埠。如需詳細資訊，請參閱[使用自訂安全群組](launch-templates.md#launch-template-security-groups)。
**注意**
對於 Windows，此命令不會啟用 SSH。而是將 Amazon EC2 金鑰對與執行個體建立關聯，讓您可以 RDP 至該執行個體中。
+ 對於 **SSH key pair** (SSH 金鑰對) (選用)，選擇要使用的 Amazon EC2 SSH 金鑰。如需 Linux 資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 使用者指南](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。如需 Windows 資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 金鑰對和 Windows 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)。如果您選擇使用啟動範本，則無法選取範本。當使用 Bottlerocket AMI 為節點群組提供 Amazon EC2 SSH 金鑰時，也會啟用管理容器。如需詳細資訊，請參閱 GitHub 上的[管理容器](https://github.com/bottlerocket-os/bottlerocket#admin-container)。
+ 對於 **Allow SSH remote access from** (允許 SSH 遠端存取來自)，如果要限制對特定執行個體的存取，請選取與這些執行個體相關聯的安全群組。如果沒有選取特定的安全群組，則允許從網際網路 (`0.0.0.0/0`) 上的任何地方存取 SSH。
1. 在 **Review and create (檢閱並建立)** 頁面上，檢閱您的受管節點群組組態，然後選擇 **Create (建立)**。
如果節點無法加入叢集，請參閱「故障診斷」章節中的 [節點無法加入叢集](troubleshooting.md#worker-node-fail)。
1. 查看節點的狀態，並等待他們到達 `Ready` 狀態。
```
kubectl get nodes --watch
```
1. (僅限 GPU 節點) 若您選擇了 GPU 執行個體類型和 Amazon EKS 最佳化加速 AMI，然後必須套用 [Kubernetes 專用 NVIDIA 裝置外掛程式](https://github.com/NVIDIA/k8s-device-plugin)作為叢集上的 DaemonSet。請先以您想要的 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) 版本來取代 *vX.X.X*，然後再執行下列命令。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
## 安裝 Kubernetes 附加元件
現在您已具備含節點之可正常運作的 Amazon EKS 叢集，您即可開始安裝 Kubernetes 附加元件並將應用程式部署到叢集。以下文件主題可協助您擴展叢集的功能。
+ 建立叢集的 [IAM 主體](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)是唯一可以使用 `kubectl` 或 AWS 管理主控台對 Kubernetes API 伺服器進行呼叫的主體。如果要其他 IAM 主體能夠存取叢集，則需新增這些主體。如需詳細資訊，請參閱[授予 IAM 使用者和角色對 Kubernetes APIs存取權](grant-k8s-access.md)及[所需的許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)。
+ 如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
+ 設定 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)，以自動調整節點群組中的節點數目。
+ 將[範例應用程式](sample-deployment.md)部署至叢集。
+ 使用管理叢集所需的重要工具來[組織和監控叢集資源](eks-managing.md)。
# 使用具有受管節點群組的暖集區，減少開機時間較長之應用程式的延遲
當您的應用程式有很長的初始化或開機時間時，向外擴展事件可能會導致延遲 - 新的節點必須完全開機並加入叢集，才能排程 Pod。此延遲可能會影響流量尖峰或快速擴展事件期間的應用程式可用性。暖集區透過維護已完成開機程序的預先初始化 EC2 執行個體集區來解決此問題。在橫向擴展事件期間，執行個體會直接從暖集區移至叢集，略過耗時的初始化步驟，並大幅減少新容量變成可用所需的時間。如需詳細資訊，請參閱[《Amazon EC2 Auto Scaling 使用者指南》中的使用暖集區縮短開機時間的應用程式延遲](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html)。 *Amazon EC2 Auto Scaling *
Amazon EKS 受管節點群組支援 Amazon EC2 Auto Scaling 暖集區。暖集區會與 Auto Scaling 群組一起維護預先初始化的 EC2 執行個體，以便在橫向擴展事件期間快速加入叢集。暖集區中的執行個體已完成開機初始化程序，並且可以保持在 `Stopped`、 `Running`或 `Hibernated` 狀態。
Amazon EKS 使用`AWSServiceRoleForAmazonEKSNodegroup`服務連結角色在整個節點群組生命週期中管理暖集區，以建立、更新和刪除暖集區資源。
## 運作方式
當您設定暖集區時，Amazon EKS 會建立連接到節點群組 Auto Scaling 群組的 EC2 Auto Scaling 暖集區。執行個體會在暖集區中啟動、完成開機初始化程序，並保持設定狀態 (`Running`、 `Stopped`或 `Hibernated`)，直到需要為止。在橫向擴展事件期間，執行個體會從暖集區移至 Auto Scaling 群組，完成 Amazon EKS 初始化程序以加入叢集，並可用於 Pod 排程。啟用執行個體重複使用時，執行個體可以在縮減事件期間返回暖集區。
**重要**
一律使用 `create-nodegroup`或 透過 Amazon EKS API 設定暖集區`update-nodegroup-config`。請勿使用 EC2 Auto Scaling API 手動修改暖集區設定，因為這可能會導致與 資源的 Amazon EKS 管理發生衝突。
## 考量事項
**重要**
在設定暖集區之前，請參閱《[Amazon EC2 Auto Scaling 使用者指南》中的 Amazon EC2 Auto Scaling 暖集區](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html)中的先決條件和限制。 *Amazon EC2 Auto Scaling * 並非所有執行個體類型、AMIs或組態都受到支援。
+ **IAM 許可** – `AWSServiceRoleForAmazonEKSNodegroup`服務連結角色 （使用第一個受管節點群組自動建立） 包含必要的暖集區管理許可。
+ **AMI 限制** – 暖集區不支援自訂 AMIs。您必須使用 Amazon EKS 最佳化 AMIs。
+ **Bottlerocket 限制** – 如果使用 Bottlerocket AMIs，則不支援`Hibernated`集區狀態。僅限使用 `Stopped`或`Running`集區狀態。此外， Bottlerocket AMIs 不支援`reuseOnScaleIn`此功能。
+ **休眠支援** – 集`Hibernated`區狀態僅支援特定執行個體類型。如需支援的執行個體類型，請參閱《*Amazon EC2 使用者指南*》中的[休眠先決條件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html)。
+ **成本影響** – 在不需要時建立暖集區可能會導致不必要的成本。
+ **容量規劃** – 根據擴展模式調整暖集區大小，以平衡成本和可用性。從 10-20% 的預期尖峰容量開始。
+ **VPC 聯網** – 確保 Auto Scaling 群組和暖集區執行個體都有足夠的 IP 地址。
## 設定暖集區
您可以在建立新的受管節點群組時設定暖集區，或更新現有的受管節點群組以新增暖集區支援。
### 組態參數
+ **enabled** – （布林值） 表示您將暖集區連接至受管節點群組的意圖。啟用暖集區支援時需要。
+ **maxGroupPreparedCapacity** – （整數） 跨暖集區和 Auto Scaling 群組合併的執行個體總數上限。
+ **minSize** – （整數） 在暖集區中維護的執行個體數目下限。預設：`0`。
+ **poolState** – （字串） 暖集區執行個體的狀態。預設：`Stopped`。
+ **reuseOnScaleIn** – （布林值） 執行個體是否在縮減事件期間返回暖集區，而不是終止它們。預設：`false`。Bottlerocket AMIs不支援。
### 使用 AWS CLI
您可以在建立受管節點群組時設定暖集區，或將暖集區新增至現有的節點群組。
**使用暖集區建立節點群組**
```
aws eks create-nodegroup \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--node-role arn:aws:iam::111122223333:role/AmazonEKSNodeRole \
--subnets subnet-12345678 subnet-87654321 \
--region us-east-1 \
--scaling-config minSize=2,maxSize=10,desiredSize=3 \
--warm-pool-config enabled=true,maxGroupPreparedCapacity=8,minSize=2,poolState=Stopped,reuseOnScaleIn=true
```
**將暖集區新增至現有的節點群組**
```
aws eks update-nodegroup-config \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--region us-east-1 \
--warm-pool-config enabled=true,maxGroupPreparedCapacity=8,minSize=2,poolState=Stopped,reuseOnScaleIn=true
```
## 更新組態
隨時使用 更新暖集區設定`update-nodegroup-config`。現有的暖集區執行個體不會立即受到影響；新設定適用於更新後進入暖集區的執行個體。
```
aws eks update-nodegroup-config \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--region us-east-1 \
--warm-pool-config enabled=true,maxGroupPreparedCapacity=10,minSize=3,poolState=Running,reuseOnScaleIn=true
```
若要停用連接到節點群組的暖集區，請設定 `enabled=false`：
```
aws eks update-nodegroup-config \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--region us-east-1 \
--warm-pool-config enabled=false
```
## 其他資源
+ 《[Amazon EC2 Auto Scaling 使用者指南》中的 Amazon EC2 Auto Scaling 的暖集區](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) *Amazon EC2 Auto Scaling *
+ [使用受管節點群組簡化節點生命週期](managed-node-groups.md)
# 更新叢集的受管節點群組
啟動受管節點群組更新後，Amazon EKS 會自動為您更新節點，完成[了解節點更新的每個階段](managed-node-update-behavior.md)中列出的步驟。如果使用的是 Amazon EKS 最佳化 AMI，則 Amazon EKS 會自動將最新的安全修補程式和作業系統更新套用至您的節點，作為最新 AMI 發行版本的一部分。
有數個案例可用於更新 Amazon EKS 受管節點群組的版本或組態：
+ 您已更新 Amazon EKS 叢集的 Kubernetes 版本，並且想要更新您的節點，以使用相同的 Kubernetes 版本。
+ 新的 AMI 發行版本可供受管節點群組使用。如需 AMI 版本的詳細資訊，請參閱下列各節：
+ [擷取 Amazon Linux AMI 版本資訊](eks-linux-ami-versions.md)
+ [使用最佳化的 Bottlerocket AMI 建立節點](eks-optimized-ami-bottlerocket.md)
+ [擷取 Windows AMI 版本資訊](eks-ami-versions-windows.md)
+ 您想要調整受管節點群組中執行個體的下限、上限或所需計數。
+ 您想要從受管節點群組中的執行個體新增或移除 Kubernetes 標籤。
+ 您想要從受管節點群組新增或移除 AWS 標籤。
+ 您需要部署具有組態變更的新版啟動範本，例如更新的自訂 AMI。
+ 您已部署 版本 `1.9.0`或更新版本的 Amazon VPC CNI 附加元件、啟用用於字首委派的附加元件，並希望節點群組中的新 AWS Nitro System 執行個體支援大幅增加的 Pod 數量。如需詳細資訊，請參閱[將更多 IP 位址指派給具有字首的 Amazon EKS 節點](cni-increase-ip-addresses.md)。
+ 您已為 Windows 節點啟用 IP 字首委派，並希望節點群組中的新 AWS Nitro System 執行個體支援大幅增加的 Pod 數量。如需詳細資訊，請參閱[將更多 IP 位址指派給具有字首的 Amazon EKS 節點](cni-increase-ip-addresses.md)。
如果有較新的受管節點群組之 Kubernetes 版本的 AMI 發行版本，則可以更新節點群組的版本，以使用較新的 AMI 版本。同樣地，如果叢集執行的 Kubernetes 版本比節點群組新，則可以更新節點群組，以使用符合叢集 Kubernetes 版本的最新 AMI 發行版本。
當受管節點群組中的節點由於擴展操作或更新而終止時，該節點中的 Pod 叢集會先耗盡。如需詳細資訊，請參閱[了解節點更新的每個階段](managed-node-update-behavior.md)。
## 更新節點群組版本
您可以透過以下任一項來更新節點群組版本：
+ [`eksctl`](#eksctl_update_managed_nodegroup)
+ [AWS 管理主控台](#console_update_managed_nodegroup)
您更新的版本不能比控制平面的版本還新。
## `eksctl`
**使用 `eksctl` 來更新受管節點群組**
使用下列命令，將受管節點群組更新至目前節點上所部署相同 Kubernetes 版本的最新 AMI 版本。使用您自己的值取代每一個*範例值*。
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code
```
**注意**
如果要將使用啟動範本部署的節點群組升級至新的啟動範本版本，則請將 `--launch-template-version version-number ` 新增至上述命令。啟動範本必須滿足[透過啟動範本來自訂受管節點](launch-templates.md)中所述的要求。如果啟動範本包含自訂 AMI，則 AMI 必須滿足[指定 AMI](launch-templates.md#launch-template-custom-ami) 中的要求。當您將節點群組升級至較新版本的啟動範本時，每個節點都會回收，以符合指定之啟動範本版本的新組態。
您無法直接將未部署啟動範本的節點群組升級至新的啟動範本版本。相反地，您必須使用啟動範本部署新的節點群組，才能將節點群組更新為新的啟動範本版本。
您可以將節點群組升級至與控制平面的 Kubernetes 版本相同的版本。例如，當您有一個正在執行 Kubernetes `1.35` 的叢集時，您可以使用下列命令，將目前執行 Kubernetes `1.34` 的節點升級到 `1.35` 版。
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.35
```
## AWS 管理主控台
**使用 AWS 管理主控台 來更新受管節點群組**
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇包含要更新之節點群組的叢集。
1. 如果至少有一個節點群組有可用的更新，則頁面頂部會出現一個方塊，通知您可用的更新。如果選取**運算**索引標籤，您會看到針對有可用更新之節點群組的**節點群組**資料表中 **AMI 發行版本**欄位中的**立即更新**。若要更新節點群組，請選擇 **Update now** (立即更新)。
您不會看到使用自訂 AMI 部署之節點群組的通知。如果節點是使用自訂 AMI 進行部署，則請完成以下步驟來部署新的已更新自訂 AMI。
1. 建立 AMI 的新版本。
1. 使用新的 AMI ID 建立新的啟動範本版本。
1. 將節點升級至啟動範本的新版本。
1. 在 **Update node group version** (更新節點群組版本) 對話方塊中，啟用或停用以下選項：
+ **Update node group version** (更新節點群組版本)：如果您部署了自訂 AMI，或經 Amazon EKS 優化的 AMI 目前是叢集的最新版本，則無法使用此選項。
+ **Change launch template version** (變更啟動範本版本)：如果節點群組是在沒有自訂啟動範本的情況下進行部署，則無法使用此選項。您只能更新已使用自訂啟動範本部署之節點群組的啟動範本版本。選取節點群組要更新至的 **Launch template version** (啟動範本版本)。如果節點群組設定了自訂 AMI，則您選取的版本也必須指定 AMI。當您升級至較新版本的啟動範本時，每個節點都會回收，以符合指定之啟動範本版本的新組態。
1. 對於 **Update strategy** (更新策略)，選取下列其中一個選項：
+ **Rolling update** (滾動更新) – 此選項會遵循叢集的 Pod 中斷預算。如果發生 Pod 中斷預算問題，導致 Amazon EKS 無法正常地消耗正在此節點群組上執行的 Pod，則更新會失敗。
+ **強制更新** – 此選項不會遵循 Pod 中斷預算。無論 Pod 中斷預算問題如何，都會強制節點重新啟動，進行更新。
1. 選擇 **Update** (更新)。
## 編輯節點群組組態
您可以修改受管節點群組中的部分組態。
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇包含要編輯之節點群組的叢集。
1. 選取 **Compute** (運算) 標籤。
1. 選取要編輯的節點群組，然後選擇 **Edit** (編輯)。
1. (選用) 在 **Edit node group** (編輯節點群組) 頁面上，執行以下作業：
1. 編輯 **Node group scaling configuration** (節點群組擴展組態)。
+ **Desired size** (所需大小) – 指定受管節點群組目前應該維護的工作者節點數量。
+ **Minimum size** (大小下限) – 指定受管節點群組可縮減至的節點數量下限。
+ **Maximum size** (大小上限)：指定受管節點群組可擴增至的節點數量上限。如需節點群組中支援的節點數量上限，請參閱 [檢視與管理 Amazon EKS 和 Fargate 服務配額](service-quotas.md)。
1. (選用) 將 **Kubernetes 標籤**新增至節點群組中的節點或從中移除這些標籤。這裡顯示的標籤只是您使用 Amazon EKS 所套用的標籤。其他標籤可能存在於這裡未顯示的節點上。
1. (選用) 將 **Kubernetes 污點**新增至節點群組中的節點或從中移除這些標籤。已新增的污點可能會有 ` NoSchedule `、` NoExecute ` 或 ` PreferNoSchedule ` 效果。如需詳細資訊，請參閱[配方：阻止在特定節點上排程 Pod](node-taints-managed-node-groups.md)。
1. (選用) 將 **Tags** (標籤) 新增至節點群組或從中移除標籤。這些標籤僅適用於 Amazon EKS 節點群組。標籤不會傳播到其他資源，例如節點群組中的子網路或 Amazon EC2 執行個體。
1. (選用) 編輯 **Node Group update configuration** (節點群組更新組態)。選取任何一個 **Number** (數字) 或 **Percentage** (百分比)。
+ **Number** (數量)：選取並指定可平行更新節點群組的節點數量。這些節點在更新期間將無法使用。
+ **Percentage** (百分比)：選取並指定可平行更新節點群組的節點百分比。這些節點在更新期間將無法使用。如果您的節點群組中有許多節點，這會很有用。
1. 完成編輯後，請選擇**儲存變更**。
**重要**
更新節點群組組態後，修改 [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html) 與 Pod 中斷預算 (PDB) 不相符。與[更新節點群組](managed-node-update-behavior.md)程序 (這會在升級階段期間消耗節點且與 PDB 相符) 不同的是，若更新擴展組態，會導致節點透過 Auto Scaling 群組 (ASG) 縮減呼叫立即終止。發生此情況不會考慮 PDB，無論您在縮減的目標大小為何。這意味著，若您減少 Amazon EKS 受管節點群組的 `desiredSize`，Pod 會在節點終止後立即移出，而不與任何 PDB 相符。
# 了解節點更新的每個階段
Amazon EKS 受管工作節點升級策略有四個不同的階段，如下節所述。
## 設定階段
設定階段具有下列步驟：
1. 它為與節點群組相關聯的 Auto Scaling 群組建立新的 Amazon EC2 啟動範本版本。新的啟動範本版本使用目標 AMI 或自訂啟動範本版本進行更新。
1. 它會更新 Auto Scaling 群組，以使用最新的啟動範本。
1. 它使用節點群組的 `updateConfig` 屬性決定要平行升級的節點數量上限。不可用節點上限配額為 100。預設值為一個節點。如需詳細資訊，請參閱《*Amazon EKS API 參考*》中的 [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) 屬性。
## 擴充規模階段
升級受管節點群組中的節點時，已升級的節點會在與正在升級的節點相同的可用區域中啟動。為了保證這種置放，我們使用 Amazon EC2 的可用區域重新平衡。如需詳細資訊，請參閱《[Amazon EC2 Auto Scaling 使用者指南](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)》中的*可用區域容量重新平衡*。為了滿足這項需求，我們可在受管節點群組中每個可用區域啟動最多兩個執行個體。
擴充規模階段具有下列步驟：
1. 它按下面的任一大小 (以較大者為准) 增加 Auto Scaling 群組的最大大小和所需大小：
+ Auto Scaling 群組部署的可用區域數量的兩倍。
+ 升級無法使用的上限。
例如，如果節點群組有五個可用區域，而 `maxUnavailable` 為一個，則升級程序最多能啟動 10 個節點。但是，當 `maxUnavailable` 為 20 (或任何大於 10 的數字)，該程序會啟動 20 個新節點。
1. 擴展 Auto Scaling 群組後，會檢查使用最新配置的節點是否存在於節點群組之中。只有在符合下列條件時，此步驟才會成功：
+ 在節點所在的每個可用區域中，至少會啟動一個新節點。
+ 每個新節點都應該處於 `Ready` 狀態。
+ 新節點應該有 Amazon EKS 套用標籤。
以下是一般節點群組中工作節點上的 Amazon EKS 套用標籤：
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
以下是自訂啟動範本或 AMI 節點群組中工作節點上的 Amazon EKS 套用標籤：
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
+ `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId`
+ `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion`
**注意**
在未變更擴展組態的情況下啟動更新或升級時，工作流程會使用即時 Auto Scaling 群組值作為起點，而不是節點群組的儲存擴展組態。如需詳細資訊，請參閱[受管節點群組概念](managed-node-groups.md#managed-node-group-concepts)。
1. 它將節點標記為不可排程，以避免排程新的 Pod。它還使用 `node.kubernetes.io/exclude-from-external-load-balancers=true` 標記節點，以便在終止節點之前從負載平衡器中移除舊節點。
以下是在這個階段中會導致 `NodeCreationFailure` 錯誤的已知原因：
**可用區域中的容量不足**
可用區域可能沒有所請求執行個體類型的容量。建議在建立受管節點群組時設定多個執行個體類型。
**您帳戶中的 EC2 執行個體限制**
您可能需要增加帳戶可以使用 Service Quotas 同時執行的 Amazon EC2 執行個體的數量。如需詳細資訊，請參閱《[Amazon Elastic Compute Cloud Linux 執行個體使用者指南](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)》中的 *EC2 Service Quotas*。
**自訂使用者資料**
自訂使用者資料有時會中斷引導程序。這種情況可能會導致 `kubelet` 未在節點上啟動或節點上未取得預期的 Amazon EKS 標籤。如需詳細資訊，請參閱[指定 AMI](launch-templates.md#launch-template-custom-ami)。
**讓節點運作狀態不佳或未就緒的任何變更**
節點磁碟壓力、記憶體壓力和類似情況，可能導致節點無法進入 `Ready` 狀態。
**每個節點在 15 分鐘內必須完成引導**
如果任何節點需要超過 15 分鐘才能完成引導並加入叢集，則會導致升級逾時。這是從需要新節點到新階段加入叢集時，測量的引導新節點的總執行時期。升級受管節點群組時，時間計數器會在 Auto Scaling 群組大小增加時立即啟動。
## 升級階段
升級階段有有兩種不同的行為方式，具體視*更新策略*而定。更新策略有兩種：**預設**和**最低**。
大多數情況下，我們建議使用預設策略。它會在終止舊節點之前建立新節點，以便在升級階段維持可用容量。在資源或成本受限制的情況下 (例如使用 GPU 等硬體加速器)，這種最低策略非常有用。它會在建立新節點之前終止舊節點，以便總容量永遠不會超過您設定的數量。
*預設*更新策略包含下列步驟：
1. 它會增加 Auto Scaling 群組中的節點數量 (所需計數)，進而導致節點群組建立額外的節點。
1. 它隨機選取需要升級的節點，最大不超過為節點群組設定的無法使用上限。
1. 其會耗盡節點中的 Pod。如果 Pod 沒有在 15 分鐘內離開節點，並且沒有強制旗標，則升級階段將失敗，並會出現 `PodEvictionFailure` 錯誤。在這種情況下，您可以應用強制旗標，同時使用 `update-nodegroup-version` 請求刪除 Pod。
1. 在每個 Pod 被移出並等待 60 秒後，其會包圍隔離節點。這樣做是為了讓服務控制器不會將任何新的請求傳送到此節點，並將此節點從其作用中的節點清單中移除。
1. 它將終止請求傳送之包圍隔離節點的 Auto Scaling 群組。
1. 它重複步驟先前的升級步驟，直到節點群組中沒有使用舊版啟動範本部署的節點為止。
*最低*更新策略包含下列步驟：
1. 它會在開頭包圍隔離節點群組的所有節點，以便服務控制器不會將任何新請求傳送至這些節點。
1. 它隨機選取需要升級的節點，最大不超過為節點群組設定的無法使用上限。
1. 它會從選取的節點中耗盡 Pod。如果 Pod 沒有在 15 分鐘內離開節點，並且沒有強制旗標，則升級階段將失敗，並會出現 `PodEvictionFailure` 錯誤。在這種情況下，您可以應用強制旗標，同時使用 `update-nodegroup-version` 請求刪除 Pod。
1. 在每個 Pod 被移出並等待 60 秒後，其會向選取的節點的 Auto Scaling 群組傳送終止請求。Auto Scaling 群組會建立新的節點 (與選取的節點的數量相同)，以取代缺少的容量。
1. 它重複步驟先前的升級步驟，直到節點群組中沒有使用舊版啟動範本部署的節點為止。
### 升級階段期間的 `PodEvictionFailure` 錯誤
以下是在這個階段中會導致 `PodEvictionFailure` 錯誤的已知原因：
**積極 PDB**
在 Pod 上定義積極的 PDB，或有多個 PDB 指向同一個 Pod。
**可容忍所有污點的部署**
一旦移出每個 Pod，節點預期為空，因為節點在先前的步驟中會受到[污染](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。但是，如果部署容忍每一個污點，則節點更有可能是非空白，導致 Pod 移出失敗。
## 縮減規模階段
縮減規模階段會將 Auto Scaling 群組的大小上限和所需大小遞減一，以便回到更新開始之前的值。
如果升級工作流程判斷 Cluster Autoscaler 在工作流程的縮減規模階段期間擴充節點群組，它會立即結束，而不會將節點群組恢復至原始大小。
**注意**
```
If your node group has a warm pool enabled, warm pool instances are drained before the scale-up operation begins. This is because warm pool instances have not been updated to the new launch template configuration — during the scale-up phase, they would be pulled into the Auto Scaling Group instead of launching new instances with the updated configuration, which would break the upgrade process. Draining the warm pool ensures that only new instances with the updated configuration are launched. Once the scale-down operation completes, the warm pool is restored, and the new instances in the warm pool are launched with the updated launch template configuration.
```
如需有關暖集區的詳細資訊，請參閱 [使用具有受管節點群組的暖集區，減少開機時間較長之應用程式的延遲](warm-pools-managed-node-groups.md)。
# 使用啟動範本自訂受管節點
對於最高層級的自訂，您可以根據此頁面上的步驟，使用自己的啟動範本部署受管節點。使用啟動範本可讓 等功能在部署節點期間提供引導引數 （例如，額外的 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引數）、從與指派給節點的 IP 地址不同的 CIDR 區塊將 IP 地址指派給 Pod、將您自己的自訂 AMI 部署至節點，或將您自己的自訂 CNI 部署至節點。
如果您在第一次建立受管節點群組期間提供自己的啟動範本，稍後也會得到更出色的靈活性。只要使用自己的啟動範本部署受管節點群組，您就可以使用不同版本的相同啟動範本來反覆更新。將節點群組更新為不同版本的啟動範本時，群組中的所有節點都會回收，以符合指定啟動範本版本的新組態。
一律使用 Amazon EC2 Auto Scaling 群組所使用的啟動範本部署受管節點群組。如果未提供啟動範本，Amazon EKS API 會使用帳戶中的預設值自動建立此啟動範本。然而，我們不建議您修改自動產生的啟動範本。此外，未使用自訂啟動範本的現有節點群組無法直接更新。相反，您必須建立具有自訂啟動範本的新節點群組，才能執行此動作。
## 啟動範本組態基礎知識
您可以使用 、 AWS 管理主控台 AWS CLI 或 AWS SDK 建立 Amazon EC2 Auto Scaling 啟動範本。如需詳細資訊，請參閱*《Amazon EC2 Auto Scaling 使用者指南》*中的[建立 Auto Scaling 群組的啟動範本](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)。啟動範本中的某些設定與用於受管理節點組態的設定類似。使用啟動範本部署或更新節點群組時，必須在節點群組組態或啟動範本其中一個位置中指定某些設定。請勿同時在兩個位置指定設定。如果設定存在於不應該的地方，則建立或更新節點群組之類的動作會失敗。
下表會列出啟動範本中禁止的設定。該表也會列出受管節點群組組態中需要的類似設定 (如果有)。列出的設定是顯示在主控台中的設定。它們在 CLI 和 SDK AWS 中可能有類似但不同的名稱。
| 啟動範本：禁止 | Amazon EKS 節點群組組態 |
| --- | --- |
| **Network interfaces** (網路介面) (**Add network interface** (新增網路介面)) 下的 **Subnet** (子網) | **Specify networking** (指定聯網) 頁面上 **Node Group network configuration** (節點群組網路組態) 下的 **Subnets** (子網) |
| **Advanced details** (進階詳細資訊) 下的 **IAM instance profile** (IAM 執行個體描述檔) | **Configure Node Group** (設定節點群組) 頁面上 **Node Group configuration** (節點群組組態) 下的 **Node IAM Role** (節點 IAM 角色) |
| **Advanced details** (進階詳細資訊) 下的 **Shutdown behavior** (關機行為) 和 **Stop - Hibernate behavior** (停用 – 休眠行為)。為兩種設定在啟動範本中保留預設**請勿包含在啟動範本設定中**。 | 無同等。Amazon EKS 必須控制執行個體生命週期，而非 Auto Scaling 群組。 |
下表會列出受管節點群組組態中禁止的設定。該表也會列出類似的設定 (如果有)，這些設定在啟動範本中是必要設定。列出的設定是顯示在主控台中的設定。它們在 CLI 和 SDK AWS 中可能會有類似的名稱。
| Amazon EKS 節點群組組態設定：禁止 | 啟動範本 |
| --- | --- |
| (僅當您在啟動模板中指定了自訂 AMI 時) 在 **Set compute and scaling configuration** (設定運算和擴展組態) 頁面上 **Node Group compute configuration** (節點群組運算組態) 下的 **AMI type** (AMI 類型) – 主控台顯示 **Specified in launch template** (在啟動範本中指定) 以及指定的 AMI ID。 如果未在啟動範本中指定**應用程式和作業系統映像 (Amazon Machine Image)**，您可在節點群組組態中選取 AMI。 | **Launch template contents** (啟動範本內容) 下的 **Application and OS Images (Amazon Machine Image)** (應用程式和作業系統映像 (Amazon Machine Image))：如果您有下列任一要求，則必須指定 ID： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/launch-templates.html) |
| **Set compute and scaling configuration** (設定運算和擴展組態) 頁面上 **Node Group compute configuration** (節點群組運算組態) 下的 **Disk size** (磁碟大小)：主控台顯示 **Specified in launch template** (在啟動範本中指定)。 | **Storage (Volumes)** (儲存 (磁碟區)) (**Add new volume** (新增磁碟區)) 下的 **Size** (大小)。您必須在啟動範本中指定此選項。 |
| **Specify Networking** (指定聯網) 頁面上 **Node Group configuration** (節點群組組態) 下的 **SSH key pair** (SSH 金鑰對) – 主控台會顯示在啟動範本中指定的金鑰，或顯示 **Not specified in launch template** (未在啟動範本中指定)。 | **Key pair (login)** (金鑰對 (登入)) 下的 **Key pair name** (金鑰對名稱)。 |
| 使用啟動範本時，您無法指定允許遠端存取的來源安全群組。 | 針對執行個體的 **Network settings** (網路設定) 下的 **Security groups** (安全群組) 或 **Network interfaces** (網路介面) 下的 **Security groups** (安全群組) (**Add network interface** (新增網路介面))，但不能兩者同時選擇。如需詳細資訊，請參閱[使用自訂安全群組](#launch-template-security-groups)。 |
**注意**
如果使用啟動範本部署節點群組，請在啟動範本的 **Launch template contents** (啟動範本內容) 中指定零或一個 **Instance type** (執行個體類型)。您也可以在主控台上的 **Set compute and scaling configuration** (設定運算和擴展組態) 頁面中，為 **Instance types** (執行個體類型) 指定 0 到 20 個執行個體類型。您還可以使用其他使用 Amazon EKS API 的工具來執行這項操作。如果在啟動範本中指定執行個體類型，並使用該啟動範本來部署節點群組，則無法在主控台中指定任何執行個體類型，或使用其他使用 Amazon EKS API 的工具。如果未在啟動範本、主控台中或使用其他使用 Amazon EKS API 的工具指定執行個體類型，請使用 `t3.medium` 執行個體類型。如果您的節點群組正在使用 Spot 容量類型，則建議使用主控台指定多個執行個體類型。如需詳細資訊，請參閱[受管節點群組容量類型](managed-node-groups.md#managed-node-group-capacity-types)。
如果您部署到節點群組的任何容器使用執行個體中繼資料服務版本 2，請確定在啟動範本中將 **Metadata response hop limit** (中繼資料回應躍點限制) 設定為 `2`。如需詳細資訊，請參閱《Amazon EC2 使用者指南》**中的[執行個體中繼資料與使用者資料](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)。
啟動範本不支援允許靈活的執行個體類型選取的 `InstanceRequirements` 功能。
## 標記 Amazon EC2 執行個體
您可以使用啟動範本的 `TagSpecification` 參數，以指定要將哪些標籤套用至節點群組中的 Amazon EC2 執行個體。IAM 實體呼叫 `CreateNodegroup` 或 `UpdateNodegroupVersion` API 必須擁有 `ec2:RunInstances` 和 `ec2:CreateTags` 許可，而且標籤必須新增至啟動範本。
## 使用自訂安全群組
您可以使用啟動範本來指定自訂 Amazon EC2 [安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)以套用至節點群組中的執行個體。這可以是在執行個體層級安全群組參數中，也可以是網路介面組態參數的一部分。不過，您無法建立同時指定執行個體層級和網路介面安全群組的啟動範本。請考慮下列適用於搭配受管節點群組使用之自訂安全群組的條件：
+ 使用 時 AWS 管理主控台，Amazon EKS 僅允許具有單一網路介面規格的啟動範本。
+ 預設情況下，Amazon EKS 將[叢集安全群組](sec-group-reqs.md)套用至節點群組中的執行個體，以促進節點與控制平面之間的通訊。如果使用先前提到的任一選項在啟動範本中指定自訂安全群組，則 Amazon EKS 不會新增叢集安全群組。因此，您必須確保安全群組的傳入和傳出規則可啟用與叢集端點的通訊。如果安全群組規則不正確，工作節點便無法加入叢集。如需安全群組規則的詳細資訊，請參閱 [檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md)。
+ 如需 SSH 存取節點群組中的執行個體，請包含允許該存取的安全群組。
## Amazon EC2 使用者資料
啟動範本包含自訂使用者資料的區段。您可以在此區段中指定節點群組的組態設定，無需手動建立個別自訂 AMI。如需有關 Bottlerocket 可用設定的詳細資訊，請參閱 GitHub 上的[使用使用者資料](https://github.com/bottlerocket-os/bottlerocket#using-user-data)。
您可以在啟動執行個體時使用 `cloud-init` 提供啟動範本中的 Amazon EC2 使用者資料。如需詳細資訊，請參閱 [cloud-init 文件](https://cloudinit.readthedocs.io/en/latest/index.html)。您的使用者資料可用來執行一般組態操作。這包含下列操作：
+ [包括使用者或群組](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [安裝套件 ](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
與受管節點群組搭配使用的啟動範本中的 Amazon EC2 使用者資料，必須為 Amazon Linux AMI 的 [MIME 分段封存](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive)格式和 Bottlerocket AMI 的 TOML 格式。這是因為您的使用者資料與節點加入叢集所需的 Amazon EKS 使用者資料合併。請勿在啟動或修改 `kubelet` 的使用者資料中指定任何命令。這會作為 Amazon EKS 合併使用者資料的一部分執行。某些 `kubelet` 參數 (例如在節點上設定標籤) 可以透過受管節點群組 API 直接設定。
**注意**
如果有關進階 `kubelet` 自訂 (包括手動啟動或傳入自訂組態參數) 的詳細資訊，請參閱 [指定 AMI](#launch-template-custom-ami)。如果在啟動範本中指定自訂 AMI ID，Amazon EKS 不會合併使用者資料。
下列詳細資訊提供有關使用者資料區段的詳細資訊。
**Amazon Linux 2 使用者資料**
您可以將多個使用者資料區塊組合在一起成為單一 MIME 分段檔案。例如，您可以將設定 Docker 常駐程式的雲端 Boothook 與安裝自訂套件的使用者資料 Shell 指令碼合併。MIME 分段檔案包含下列元件：
+ 內容類型和部分邊界宣告：`Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="`
+ MIME 版本宣告：`MIME-Version: 1.0`
+ 包含以下元件的一或多個使用者資料區塊：
+ 開啟邊界，表示使用者資料區塊的開始 – `--==MYBOUNDARY==`
+ 區塊的內容類型宣告：`Content-Type: text/cloud-config; charset="us-ascii"`。如需內容類型的詳細資訊，請參閱 [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html) 文件。
+ 使用者資料的內容 (例如，Shell 命令或 `cloud-init` 指令的清單)。
+ 結束邊界，表示 MIME 分段檔案的結束：`--==MYBOUNDARY==--`
以下是您可以用來建立自己的 MIME 分段檔案的範例。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
--==MYBOUNDARY==--
```
**Amazon Linux 2023 使用者資料**
Amazon Linux 2023 (AL2023) 推出了新的節點初始化程序 `nodeadm`，該程序會使用 YAML 組態結構描述。如果您使用自我管理節點群組或具有啟動範本的 AMI，則在建立新節點群組時，需要明確提供額外的叢集中繼資料。以下連結展示了一個包含最低必要參數的[範例](https://awslabs.github.io/amazon-eks-ami/nodeadm/)，其中 `apiServerEndpoint`、`certificateAuthority` 和服務 `cidr` 現在是必需的：
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
您通常會在使用者資料中設定此組態，可以依原狀設定，也可以內嵌在 MIME 分段文件中：
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]
--BOUNDARY--
```
在 AL2 中，這些參數的中繼資料是透過 Amazon EKS `DescribeCluster` API 呼叫自動發現的。在 AL2023 中，此行為已改變，因為額外的 API 呼叫在大規模節點擴展時有被限流的風險。如果您使用沒有啟動範本的受管節點群組，或使用 Karpenter，則此變更不會對您造成影響。如需有關 `certificateAuthority` 和服務 `cidr` 的更多資訊，請參閱《*Amazon EKS API 參考*》中的 [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)。
以下是 AL2023 使用者資料的完整範例，其中結合用於自訂節點的 Shell 指令碼 (例如安裝套件或預先快取容器映像) 與所需的 `nodeadm` 組態。此範例顯示常見的自訂，包括：\$1 安裝其他系統套件 \$1 預先快取容器映像，以改善 Pod 啟動時間 \$1 設定 HTTP 代理組態 \$1 設定節點標籤的 `kubelet` 旗標
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset
# Install additional packages
yum install -y htop jq iptables-services
# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &
# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF
--BOUNDARY
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
clusterDNS:
- 10.100.0.10
flags:
- --node-labels=app=my-app,environment=production
--BOUNDARY--
```
**Bottlerocket 使用者資料**
Bottlerocket 會以 TOML 格式建構使用者資料。您可以提供要與 Amazon EKS 提供的使用者資料合併的使用者資料。例如，您可以提供額外的 `kubelet` 設定。
```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
如需有關受支援設定的詳細資訊，請參閱 [Bottlerocket 文件](https://github.com/bottlerocket-os/bottlerocket)。您可以在使用者資料中設定節點標籤和[污點](node-taints-managed-node-groups.md)。不過，建議您改為在節點群組內設定。在執行這項操作時，Amazon EKS 會套用這些組態。
合併使用者資料時，不會保留格式設定，但內容保持不變。您在使用者資料中提供的組態會覆寫 Amazon EKS 所設定的任何設定。所以，如果您設定 `settings.kubernetes.max-pods` 或 `settings.kubernetes.cluster-dns-ip`，則使用者資料中的值會套用至節點。
Amazon EKS 不支援所有有效的 TOML。以下是已知不支援格式的清單：
+ 引號鍵內的引號：`'quoted "value"' = "value"`
+ 值中的溢出引號：`str = "I’m a string. \"You can quote me\""`
+ 混合浮點數和正整數：`numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]`
+ 陣列中的混合類型：`contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]`
+ 帶引號鍵的括號標題：`[foo."bar.baz"]`
**Windows 使用者資料**
Windows 使用者資料會使用 PowerShell 命令。建立受管節點群組時，您的自訂使用者資料會與 Amazon EKS 受管使用者資料結合。您的 PowerShell 命令為優先，然後是受管的使用者資料命令，所有這些命令都在一個 `` 標籤中。
建立 Windows 節點群組時，Amazon EKS 會更新 `aws-auth` `ConfigMap`，以允許 Linux 型節點加入叢集。服務不會自動設定 Windows AMI 的許可。如果您使用的是 Windows 節點，您將需要透過存取項目 API 或直接更新 `aws-auth` `ConfigMap` 來管理存取。如需詳細資訊，請參閱[在 EKS 叢集上部署 Windows 節點](windows-support.md)。
如果啟動範本中未指定任何 AMI ID，請勿在使用者資料中使用 Windows Amazon EKS 引導指令碼來設定 Amazon EKS。
範例使用者資料如下。
```
Write-Host "Running custom user data script"
```
## 指定 AMI
如果有下列其中一項要求，請在啟動範本 `ImageId` 欄位中指定 AMI ID。選取您對其他資訊的要求。
### 提供使用者資料將引數傳遞給 `bootstrap.sh` 檔案，其中包含 Amazon EKS 最佳化 Linux/Bottlerocket AMI
引導是一個術語，用於描述新增在執行個體啟動時可以執行的命令。例如，引導允許使用額外的 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引數。您可以使用 `eksctl` 將引數傳遞給 `bootstrap.sh` 而不指定啟動範本。您也可以在啟動範本的使用者資料區段中指定資訊來執行此動作。
**eksctl，無需指定啟動範本**
使用下列內容，建立名為 *my-nodegroup.yaml* 的檔案。使用您自己的值取代每一個*範例值*。`--apiserver-endpoint`、`--b64-cluster-ca`，和 `--dns-cluster-ip` 引數為選用。但是，定義引述會允許 `bootstrap.sh` 指令碼避免進行 `describeCluster` 呼叫。這在經常縮減和擴增節點的私有叢集設定或叢集中非常有用。如需 `bootstrap.sh` 指令碼的詳細資訊，請參閱 GitHub 上的 [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) 檔案。
+ 唯一需要的引數是叢集名稱 (*my-cluster*)。
+ 若要擷取 `ami-1234567890abcdef0 ` 的最佳化 AMI ID，您請參閱下列章節：
+ [擷取建議的 Amazon Linux AMI ID](retrieve-ami-id.md)
+ [擷取建議的 Bottlerocket AMI ID](retrieve-ami-id-bottlerocket.md)
+ [擷取建議的 Microsoft Windows AMI ID](retrieve-windows-ami-id.md)
+ 若要擷取您的叢集的 *certificate-authority*，請執行下列命令。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ 若要擷取您的叢集的 *api-server-endpoint*，請執行下列命令。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ `--dns-cluster-ip` 的值是結尾處為 `.10` 的服務 CIDR。若要擷取您的叢集的 *service-cidr*，請執行下列命令。例如，如果傳回的值是 `ipv4 10.100.0.0/16`，則您的值是 *10.100.0.10*。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ 此範例使用其中包含 Amazon EKS 最佳化 AMI 的 `bootstrap.sh` 指令碼提供 `kubelet` 引數來設定自訂 `max-pods` 值。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。如需選取 *my-max-pods-value* 的說明，請參閱 [maxPods的判斷方式](choosing-instance-type.md#max-pods-precedence)。如需使用受管節點群組時如何`maxPods`決定 的詳細資訊，請參閱 [maxPods的判斷方式](choosing-instance-type.md#max-pods-precedence)。
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
managedNodeGroups:
- name: my-nodegroup
ami: ami-1234567890abcdef0
instanceType: m5.large
privateNetworking: true
disableIMDSv1: true
labels: { x86-al2-specified-mng }
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
```
針對每一個可用的 `eksctl` `config` 檔案選項，請參閱 `eksctl` 文件中的 [Config file schema](https://eksctl.io/usage/schema/) (組態檔案結構描述)。此 `eksctl` 公用程式仍會為您建立啟動範本，並使用在 `config` 檔案提供的資料來填入其使用者資料。
使用下列命令來建立節點群組。
```
eksctl create nodegroup --config-file=my-nodegroup.yaml
```
**啟動範本中的使用者資料**
在啟動範本的使用者資料區段中指定下列資訊。使用您自己的值取代每一個*範例值*。`--apiserver-endpoint`、`--b64-cluster-ca`，和 `--dns-cluster-ip` 引數為選用。但是，定義引述會允許 `bootstrap.sh` 指令碼避免進行 `describeCluster` 呼叫。這在經常縮減和擴增節點的私有叢集設定或叢集中非常有用。如需 `bootstrap.sh` 指令碼的詳細資訊，請參閱 GitHub 上的 [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) 檔案。
+ 唯一需要的引數是叢集名稱 (*my-cluster*)。
+ 若要擷取您的叢集的 *certificate-authority*，請執行下列命令。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ 若要擷取您的叢集的 *api-server-endpoint*，請執行下列命令。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ `--dns-cluster-ip` 的值是結尾處為 `.10` 的服務 CIDR。若要擷取您的叢集的 *service-cidr*，請執行下列命令。例如，如果傳回的值是 `ipv4 10.100.0.0/16`，則您的值是 *10.100.0.10*。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ 此範例使用其中包含 Amazon EKS 最佳化 AMI 的 `bootstrap.sh` 指令碼提供 `kubelet` 引數來設定自訂 `max-pods` 值。如需選取 *my-max-pods-value* 的說明，請參閱 [maxPods的判斷方式](choosing-instance-type.md#max-pods-precedence)。如需使用受管節點群組時如何`maxPods`決定 的詳細資訊，請參閱 [maxPods的判斷方式](choosing-instance-type.md#max-pods-precedence)。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
--==MYBOUNDARY==--
```
### 提供使用者資料將引數傳遞給 `Start-EKSBootstrap.ps1` 檔案，其中包含 Amazon EKS 最佳化 Windows AMI
引導是一個術語，用於描述新增在執行個體啟動時可以執行的命令。您可以使用 `eksctl` 將引數傳遞給 `Start-EKSBootstrap.ps1` 而不指定啟動範本。您也可以在啟動範本的使用者資料區段中指定資訊來執行此動作。
如果您想指定自訂 Windows AMI ID，請注意下列考量事項：
+ 您必須使用啟動範本，並在使用者資料區段中提供所需引導命令。若要擷取所需的 Windows ID，您可以使用[使用最佳化的 Windows AMI 建立節點](eks-optimized-windows-ami.md)中的資料表。
+ 您需滿足幾個限制和條件。例如，您必須將 `eks:kube-proxy-windows`新增至 IAM Authenticator AWS 組態映射。如需詳細資訊，請參閱[指定 AMI ID 時的限制和條件](#mng-ami-id-conditions)。
在啟動範本的使用者資料區段中指定下列資訊。使用您自己的值取代每一個*範例值*。`-APIServerEndpoint`、`-Base64ClusterCA`，和 `-DNSClusterIP` 引數為選用。但是，定義引述會允許 `Start-EKSBootstrap.ps1` 指令碼避免進行 `describeCluster` 呼叫。
+ 唯一需要的引數是叢集名稱 (*my-cluster*)。
+ 若要擷取您的叢集的 *certificate-authority*，請執行下列命令。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ 若要擷取您的叢集的 *api-server-endpoint*，請執行下列命令。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ `--dns-cluster-ip` 的值是結尾處為 `.10` 的服務 CIDR。若要擷取您的叢集的 *service-cidr*，請執行下列命令。例如，如果傳回的值是 `ipv4 10.100.0.0/16`，則您的值是 *10.100.0.10*。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ 如需其他引數，請參閱 [引導指令碼組態參數](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)。
**注意**
如果您使用的是自訂服務 CIDR，則需要使用 `-ServiceCIDR` 參數來對其進行指定。否則，叢集中 Pod 的 DNS 解析將會失敗。
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### 由於特定安全、合規或內部政策要求，執行自訂 AMI
如需詳細資訊，請參閱*《Amazon EC2 使用者指南》*中的 [Amazon Machine Images (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)。Amazon EKS AMI 建置規範包含用於建置基於 Amazon Linux 的自訂 Amazon EKS AMI 的資源和組態指令碼。如需詳細資訊，請參閱 GitHub 上的 [Amazon EKS AMI 建置規範](https://github.com/awslabs/amazon-eks-ami/)。若要建置使用其他作業系統安裝的自訂 AMI，則請參閱 GitHub 上的 [Amazon EKS 樣本自訂 AMI](https://github.com/aws-samples/amazon-eks-custom-amis)。
在與受管節點群組搭配使用的啟動範本中，您無法使用 AMI ID 的動態參數參考。
**重要**
指定 AMI 時，Amazon EKS 不會針對叢集的控制平面版本驗證 AMI 中內嵌的 Kubernetes 版本。您有責任確保自訂 AMI 的 Kubernetes 版本符合 [Kubernetes 版本扭曲政策](https://kubernetes.io/releases/version-skew-policy)：
節點上的`kubelet`版本不得比叢集版本更新
節點上的`kubelet`版本必須等於或最多 3 個次要版本 （適用於 Kubernetes 版本 `1.28`或更高版本），或最多 2 個次要版本 （適用於 Kubernetes 版本 `1.27`或更低版本）
建立具有版本扭曲違規的受管節點群組可能會導致：
節點無法加入叢集
未定義的行為或 API 不相容
叢集不穩定或工作負載失敗
指定 AMI 時，Amazon EKS 不會合併任何使用者資料。相反，您必須負責提供所需的 `bootstrap` 命令，讓節點加入叢集。如果節點無法加入叢集，則 Amazon EKS `CreateNodegroup` 和 `UpdateNodegroupVersion` 動作也會失敗。
## 指定 AMI ID 時的限制和條件
以下是使用受管節點群組指定 AMI ID 所涉及的限制和條件：
+ 您必須建立新的節點群組，才能在指定啟動範本的 AMI ID 與不指定 AMI ID 之間切換。
+ 有較新的 AMI 版本可用時，您不會在主控台中收到通知。若要將節點群組更新為較新的 AMI 版本，您需要使用更新的 AMI ID 來建立新版本的啟動範本。然後，您需要使用新的啟動範本版本更新節點群組。
+ 如果指定 AMI ID，則無法在 API 中設定下列欄位：
+ `amiType`
+ `releaseVersion`
+ `version`
+ 如果您指定 AMI ID，則 API 的任何 `taints` 集合都會以非同步方式套用。若要在節點加入叢集之前套用污點，您必須使用 `--register-with-taints` 命令列旗標將污點傳遞給使用者資料的 `kubelet`。如需詳細資訊，請參閱 Kubernetes 文件中的 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)。
+ 為 Windows 受管節點群組指定自訂 AMI ID 時，請將 `eks:kube-proxy-windows`新增至您的 AWS IAM Authenticator 組態映射。必須要有這項，DNS 才能正常運作。
1. 開啟 AWS IAM Authenticator 組態映射以進行編輯。
```
kubectl edit -n kube-system cm aws-auth
```
1. 將此項目新增至與 Windows 節點關聯的每個 `rolearn` 下的 `groups` 清單中。您的組態映射看起來應該類似於 [aws-auth-cm-windows.yaml](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)。
```
- eks:kube-proxy-windows
```
1. 儲存檔案並結束您的文字編輯器。
+ 對於任何使用自訂啟動範本的 AMI，受管節點群組的預設 `HttpPutResponseHopLimit` 已設定為 `2`。
# 從您的叢集刪除受管節點群組
本主題會描述可以如何刪除 Amazon EKS 受管節點群組。刪除受管節點群組時，Amazon EKS 會先將 Auto Scaling 群組的最小、最大和所需大小設定為零。這就會讓節點群組縮減規模。
在每個執行個體終止之前，Amazon EKS 會傳送訊號以耗盡該節點。在耗盡過程中，Kubernetes 會對節點上的每個 Pod 執行下列動作： 執行任何設定的`preStop`生命週期掛鉤、將`SIGTERM`訊號傳送至容器，然後等待 `terminationGracePeriodSeconds`正常關閉。如果節點在 5 分鐘後尚未耗盡，Amazon EKS 可讓 Auto Scaling 繼續強制終止執行個體。終止所有執行個體後，會刪除 Auto Scaling 群組。
**重要**
如果刪除使用節點 IAM 角色的受管節點群組，且角色未被叢集中任何其他受管節點群組使用，則此角色會從 `aws-auth` `ConfigMap` 移除。如果叢集中有任何自我管理節點群組使用相同的節點 IAM 角色，則自我管理節點會轉為 `NotReady` 狀態。此外，叢集操作也會中斷。若要僅針對自我管理節點群組新增您正在使用之角色的映射，請參閱 [建立存取項目](creating-access-entries.md)，前提是您的叢集的平台版本不低於[使用 EKS 存取項目授予 IAM 使用者 Kubernetes 的存取權](access-entries.md)部分中列出的最低版本。如果您的平台版本早於存取項目所需的最低版本，您可以將項目新增回 `aws-auth` `ConfigMap`。如需詳細資訊，請在您的終端機中輸入 `eksctl create iamidentitymapping --help`。
您可以透過以下方式刪除受管節點群組：
+ [`eksctl`](#eksctl-delete-managed-nodegroup)
+ [AWS 管理主控台](#console-delete-managed-nodegroup)
+ [AWS CLI](#awscli-delete-managed-nodegroup)
## `eksctl`
**使用 `eksctl` 刪除受管節點群組**
輸入以下命令。使用您自己的值取代每一個 ``。
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
如需更多選項，請參閱 `eksctl` 文件中的[刪除和耗盡節點群組](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)。
## AWS 管理主控台
**使用 AWS 管理主控台 刪除受管節點群組**
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在**叢集**頁面上，選擇包含要刪除之節點群組的叢集。
1. 在所選叢集頁面上，選擇**運算**索引標籤。
1. 在 **Node Groups** (節點群組) 區段中，選擇要刪除的節點群組。然後選擇**刪除**。
1. 在**刪除節點群組**確認對話方塊中，輸入節點群組的名稱。然後選擇**刪除**。
## AWS CLI
**使用 CLI AWS 刪除受管節點群組**
1. 輸入以下命令。使用您自己的值取代每一個 ``。
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
1. 如果在 CLI 組態中`cli_pager=`設定 ，請使用鍵盤上的方向鍵來捲動回應輸出。完成後按下 `q` 鍵。
如需更多選項，請參閱 CLI ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) `命令參考中的 命令。 * AWS *
# 藉助自我管理節點來自行維護節點
叢集包含排程 Pod 的一或多個 Amazon EC2 節點。Amazon EKS 節點會在您的 AWS 帳戶中執行並透過叢集 API 伺服器端點連接至您叢集的控制平面。會根據 Amazon EC2 價格收費。如需詳細資訊，請參閱 [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)。
一個叢集可以包含數個節點群組。每個節點群組包含一個或多個部署在 [Amazon EC2 Auto Scaling 群組](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)的節點。群組節點的執行個體類型可能會有所不同，例如透過 [Karpenter](https://karpenter.sh/) 使用[以屬性為基礎的執行個體類型選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)時。節點群組的所有執行個體都必須使用 [Amazon EKS 節點 IAM 角色](create-node-role.md)。
Amazon EKS 提供專門的Amazon 機器映像 (AMI)，稱為Amazon EKS 最佳化 AMI。AMI 已設定為搭配 Amazon EKS 一起使用。它們的元件包括 `containerd`、`kubelet` 和 AWS IAM 驗證器。AMI 還包含特殊化[啟動程序指令碼](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)，使其可自動探索並連接至您叢集的控制平面。
如果使用 CIDR 區塊限制對叢集公有端點的存取，則建議您也啟用私有端點存取。這樣可以讓節點與叢集通訊。若不啟用私有端點，您指定用於公有存取的 CIDR 區塊必須包含來自 VPC 的輸出來源。如需詳細資訊，請參閱 [叢集 API 伺服器端點](cluster-endpoint.md)。
若要將自我管理節點新增至 Amazon EKS 叢集，請參閱以下主題。如果手動啟動自我管理節點，請將以下標籤新增至每個節點，同時確保 `` 與您的叢集相符。如需詳細資訊，請參閱[新增和刪除個別資源的標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)。如果遵循以下指南中的步驟，系統會為您自動新增必要的標籤至節點。
| 金鑰 | 值 |
| --- | --- |
| `kubernetes.io/cluster/` | `owned` |
**重要**
Amazon EC2 執行個體中繼資料服務 (IMDS) 中的標籤與 EKS 節點不相容。啟用執行個體中繼資料標籤後，不能在標籤值中使用正斜線 ('/')。此限制可能會導致無法啟動執行個體，使用 Karpenter 或叢集自動擴展期等節點管理工具時尤其如此，因為這些服務依賴於包含正斜線的標籤來提供適當的功能。
如需 Kubernetes 對節點普遍觀點的詳細資訊，請參閱 Kubernetes 文件中的[節點](https://kubernetes.io/docs/concepts/architecture/nodes/)。
**Topics**
+ [建立自我管理的 Amazon Linux 節點](launch-workers.md)
+ [建立自我管理的 Bottlerocket 節點](launch-node-bottlerocket.md)
+ [建立自我管理的 Microsoft Windows 節點](launch-windows-workers.md)
+ [建立自我管理的 Ubuntu Linux 節點](launch-node-ubuntu.md)
+ [更新您的叢集的自我管理節點](update-workers.md)
# 建立自我管理的 Amazon Linux 節點
本主題會說明如何啟動已向 Amazon EKS 叢集註冊的 Linux 節點的 Auto Scaling 群組。節點加入叢集後，您就可以將 Kubernetes 應用程式部署至其中。您也可以使用 `eksctl`或 啟動自我管理的 Amazon Linux 節點 AWS 管理主控台。如果您需要在 AWS Outposts 上啟動節點，請參閱 [在 AWS Outpost 上建立 Amazon Linux 節點](eks-outposts-self-managed-nodes.md)。
+ 現有 Amazon EKS 叢集。若要部署叢集，請參閱 [建立 Amazon EKS 叢集](create-cluster.md)。如果您在已啟用 AWS Outposts、 AWS Wavelength 或 AWS Local Zones AWS 的區域中有子網路，則這些子網路不得在您建立叢集時傳入。
+ 供節點使用的現有 IAM 角色。若要建立服務角色，請參閱[Amazon EKS 節點 IAM 角色](create-node-role.md)。如果此角色沒有任何 VPC CNI 的政策，則 VPC CNI Pod 需要以下個別角色。
+ (選用，但建議) Kubernetes 專用 Amazon VPC CNI 外掛程式的附加元件設定有自己的 IAM 角色，該角色已連接必要的 IAM 政策。如需詳細資訊，請參閱[設定 Amazon VPC CNI 外掛程式以使用 IRSA](cni-iam-role.md)。
+ 熟悉[選擇最佳 Amazon EC2 節點執行個體類型](choosing-instance-type.md)中所列的考量事項。取決於您選擇的執行個體類型，您的叢集和 VPC 可能還有其他先決條件。
您可以使用下列任意一項啟動自我管理的 Linux 節點：
+ [`eksctl`](#eksctl_create_managed_amazon_linux)
+ [AWS 管理主控台](#console_create_managed_amazon_linux)
## `eksctl`
**使用 `eksctl` 啟動自我管理的 Linux 節點**
1. 在您的裝置或 AWS CloudShell 上安裝版本 `0.215.0`或更新版本的`eksctl`命令列工具。如需有關安裝或更新 `eksctl` 的指示，請參閱 `eksctl` 文件中的[安裝](https://eksctl.io/installation)一節。
1. (選用) 如果 **AmazonEKS\$1CNI\$1Policy** 受管 IAM 政策已連接至您的 [Amazon EKS 節點 IAM 角色](create-node-role.md)，建議您改為將其指派給您與 Kubernetes `aws-node` 服務帳戶相關聯的 IAM 角色。如需詳細資訊，請參閱[設定 Amazon VPC CNI 外掛程式以使用 IRSA](cni-iam-role.md)。
1. 以下命令會在現有的叢集建立節點群組。將 *al-nodes* 取代為您的節點群組名稱。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。使用您叢集的名稱取代 *my-cluster*。此名稱僅能使用英數字元 (區分大小寫) 和連字號。必須以英數字元開頭，且長度不可超過 100 個字元。名稱在您要建立叢集 AWS 的區域和 AWS 帳戶中必須是唯一的。使用您自己的值取代其餘*範例值*。依預設，系統會使用與控制平面相同的 Kubernetes 版本來建立節點。
選擇 `--node-type` 的值之前，請檢閱[選擇最佳 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。
使用 Amazon EC2 金鑰對或公有金鑰的名稱取代 *my-key*。此金鑰會在節點啟動後用於將 SSH 套用至節點。如果您還沒有 Amazon EC2 金鑰對，可以在 AWS 管理主控台中建立一個。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。
使用下列命令來建立您的節點群組。
**重要**
如果您想要將節點群組部署至 AWS Outposts、Wavelength 或 Local Zone 子網路，還有其他考量：
在建立叢集時，不得傳入子網路。
您必須使用指定子網路和 ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2` 的組態檔案來建立節點群組。如需詳細資訊，請參閱 `eksctl` 文件中的[從組態檔案建立節點群組](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)和[組態檔案結構描述](https://eksctl.io/usage/schema/)。
```
eksctl create nodegroup \
--cluster my-cluster \
--name al-nodes \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--ssh-access \
--managed=false \
--ssh-public-key my-key
```
若要部署節點群組：
+ 其可以將比預設組態更大量的 IP 位址指派給 Pod，請參閱 [將更多 IP 位址指派給具有字首的 Amazon EKS 節點](cni-increase-ip-addresses.md)。
+ 其可以從與執行個體不同的 CIDR 區塊將 `IPv4` 地址指派給 Pod，請參閱 [使用自訂聯網在替代子網路中部署 Pod](cni-custom-network.md)。
+ 其可以將 `IPv6` 地址指派給 Pod 和服務，請參閱 [了解叢集、Pod 與服務的 IPv6 位址](cni-ipv6.md)。
+ 沒有傳入網際網路存取，請參閱 [部署網際網路存取受到限制的私有叢集](private-clusters.md)。
如需所有可用選項和預設值的完整清單，請輸入以下命令。
```
eksctl create nodegroup --help
```
如果節點無法加入叢集，請參閱「故障診斷」章節中的 [節點無法加入叢集](troubleshooting.md#worker-node-fail)。
範例輸出如下。建立節點時，會有數行輸出。輸出的最後幾行之一類似於以下的範例行。
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (選用) 部署[範例應用程式](sample-deployment.md)以測試您的叢集和 Linux 節點。
1. 如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
## AWS 管理主控台
**步驟 1：使用 AWS 管理主控台 啟動自我管理的 Linux 節點**
1. 下載最新版本的 AWS CloudFormation 範本。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml
```
1. 等待您的叢集狀態顯示為 `ACTIVE`。如果在叢集處於作用中狀態之前啟動節點，則節點向叢集註冊將會失敗，導致必須再次啟動。
1. 開啟 [AWS CloudFormation 主控台](https://console.aws.amazon.com/cloudformation/)。
1. 選擇 **Create stack** (建立堆疊)，然後選取 **With new resources (standard)** (使用新資源 (標準))。
1. 針對 **Specify template** (指定範本)，選取 **Upload a template file** (上傳範本檔案)，然後選取 **Choose file** (選擇檔案)。
1. 選取您下載的 `amazon-eks-nodegroup.yaml` 檔案。
1. 選取**下一步**。
1. 在 **Specify stack details** (指定堆疊詳細資訊) 頁面上，據此填寫下列參數，然後選擇 **Next** (下一步)：
+ **堆疊名稱**：為您的 AWS CloudFormation 堆疊選擇堆疊名稱。例如，您可以稱它為 *my-cluster-nodes*。此名稱僅能使用英數字元 (區分大小寫) 和連字號。必須以英數字元開頭，且長度不可超過 100 個字元。名稱在您要建立叢集 AWS 的區域和 AWS 帳戶中必須是唯一的。
+ **ClusterName**：輸入建立 Amazon EKS 叢集時使用的名稱。此名稱必須與叢集名稱相同，否則節點無法加入叢集。
+ **ClusterControlPlaneSecurityGroup**：從您在建立 [VPC](creating-a-vpc.md) 時產生的 AWS CloudFormation 輸出中選擇 **SecurityGroups** 值。
下列步驟顯示擷取適用群組的一種操作。
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇叢集的名稱。
1. 選擇 **Networking (網路)** 索引標籤。
1. 從 **ClusterControlPlaneSecurityGroup** 下拉式清單中選取時，請使用 **Additional Security Group** (其他安全群組) 值作為參考。
+ **ApiServerEndpoint**：輸入 EKS 叢集的 API 伺服器端點。這可在 EKS 叢集主控台的詳細資訊區段中找到
+ **CertificateAuthorityData**：輸入 base64 編碼的憑證授權機構資料，也可以在 EKS 叢集主控台的詳細資訊區段中找到。
+ **ServiceCidr**：輸入用於將 IP 地址配置到叢集內 Kubernetes 服務的 CIDR 範圍。這可在 EKS 叢集主控台的聯網索引標籤中找到。
+ **AuthenticationMode**：透過檢閱 EKS 叢集主控台中的存取索引標籤，選取 EKS 叢集中使用的身分驗證模式。
+ **NodeGroupName**：輸入節點群組的名稱。此名稱稍後可用於識別為您節點建立的 Auto Scaling 節點群組。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。
+ **NodeAutoScalingGroupMinSize**：輸入節點 Auto Scaling 群組可以縮減的最低節點數。
+ **NodeAutoScalingGroupDesiredCapacity**：堆疊建立時，輸入欲擴展的所需節點數量。
+ **NodeAutoScalingGroupMaxSize**：輸入節點 Auto Scaling 群組可以擴增的最大節點數。
+ **NodeInstanceType**：選擇節點的執行個體類型。如需詳細資訊，請參閱[選擇最佳的 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。
+ **NodeImageIdSSMParam**：為變數 Kubernetes 版本預先填入最近 Amazon EKS 最佳化 Amazon Linux 2023 AMI 的 Amazon EC2 Systems Manager 參數。若要使用 Amazon EKS 支援不同的 Kubernetes 次要版本，請將 *1.XX* 取代為不同的[支援的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。建議指定與叢集相同的 Kubernetes 版本。
您也可以將 *amazon-linux-2023* 取代為不同的 AMI 類型。如需詳細資訊，請參閱[擷取建議的 Amazon Linux AMI ID](retrieve-ami-id.md)。
**注意**
Amazon EKS 節點 AMI 以 Amazon Linux 為基礎。您可以在 Amazon Linux 安全[中心追蹤 Amazon Linux](https://alas.aws.amazon.com/alas2023.html) 2023 的安全或隱私權事件，或訂閱相關聯的 [RSS 摘要](https://alas.aws.amazon.com/AL2023/alas.rss)。安全與隱私權事件包含問題的概觀、哪些套件受到影響，以及如何更新您的執行個體以修正問題。
+ **NodeImageId**：（選用） 如果您使用自己的自訂 AMI （而非 Amazon EKS 最佳化 AMI)，請輸入您 AWS 區域的節點 AMI ID。如果您在此指定值，則會覆寫 **NodeImageIdSSMParam** 欄位中的任何值。
+ **NodeVolumeSize**：為您的節點指定根磁碟區大小 (以 GiB 為單位)。
+ **NodeVolumeType**：為您的節點指定根磁碟區類型。
+ **KeyName**：輸入 Amazon EC2 SSH 金鑰對的名稱，您可以在節點啟動後使用該金鑰對來透過 SSH 連接至節點。如果您還沒有 Amazon EC2 金鑰對，可以在 AWS 管理主控台中建立一個。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。
+ **VpcId**：輸入您建立的 [VPC](creating-a-vpc.md) ID。
+ **子網路**：選擇您為 VPC 建立的子網路。如果您已依照[為您的 Amazon EKS 叢集建立 Amazon VPC](creating-a-vpc.md) 中所述的步驟建立 VPC，則只需指定要啟動節點的 VPC 中的私有子網路。您可以看到哪些子網是私有子網，方法是從叢集的 **Networking** (聯網) 標籤打開每一個子網連結。
**重要**
如有任何子網路是公有子網路，則必須啟用自動公有 IP 地址指派設定。如果未針對公有子網路啟用 設定，則您部署至該公有子網路的任何節點都不會指派公有 IP 地址，也無法與叢集或其他 AWS 服務通訊。如果子網路是在 2020 年 3 月 26 日之前使用任一 [Amazon EKS AWS CloudFormation VPC 範本](creating-a-vpc.md)或使用 部署，`eksctl`則會停用公有子網路的自動公有 IP 地址指派。如需如何啟用子網路的公有 IP 地址指派的相關資訊，請參閱[修改您子網路的公有 IPv4 定址屬性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)。如果節點部署到私有子網路，則可以透過 NAT 閘道與叢集和其他 AWS 服務通訊。
如果子網路無法存取網際網路，請確保您已知悉[部署網際網路存取受到限制的私有叢集](private-clusters.md)中的考量事項和額外步驟。
如果您選取 AWS Outpost、Wavelength 或 Local Zone 子網路，則建立叢集時不得傳入子網路。
1. 請在 **Configure stack options** (設定堆疊選項) 頁面上選取所需的選項，然後選擇 **Next** (下一頁)。
1. 選取**我確認 AWS CloudFormation 可能會建立 IAM 資源**的左側核取方塊，然後選擇**建立堆疊**。
1. 當當堆疊已完成建立時，從主控台將其選取，然後選擇 **Outputs (輸出)**。如果您使用 `EKS API`或 `EKS API and ConfigMap` 身分驗證模式，這是最後一個步驟。
1. 如果您使用`ConfigMap`身分驗證模式，請記錄已建立節點群組的 **NodeInstanceRole**。
**步驟 2：讓節點加入叢集**
**注意**
只有在 EKS 叢集中使用 Configmap 身分驗證模式時，才需要下列兩個步驟。此外，如果您在沒有傳出網際網路存取的情況下在私有 VPC 內啟動節點，請務必讓節點從 VPC 內加入您的叢集。
1. 檢查以瞭解是否有 `aws-auth` `ConfigMap`。
```
kubectl describe configmap -n kube-system aws-auth
```
1. 如果您看到 `aws-auth` `ConfigMap`，請視需要更新之。
1. 開啟 `ConfigMap` 進行編輯。
```
kubectl edit -n kube-system configmap/aws-auth
```
1. 視需要新增 `mapRoles` 個項目。將 `rolearn` 值設定為您在先前程序中記錄的 **NodeInstanceRole** 值。
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
1. 儲存檔案並結束您的文字編輯器。
1. 如果您收到錯誤，指出「`Error from server (NotFound): configmaps "aws-auth" not found`，請套用堆疊 `ConfigMap`。
1. 下載組態對應。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. 在 `aws-auth-cm.yaml` 檔案中，將 `rolearn` 值設定為您在先前程序中紀錄的 **NodeInstanceRole** 值。您可以使用文字編輯器來完成此操作，或者透過取代 *my-node-instance-role* 並執行下列命令：
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. 套用組態。此命令可能需要幾分鐘的時間來完成。
```
kubectl apply -f aws-auth-cm.yaml
```
1. 查看節點的狀態，並等待他們到達 `Ready` 狀態。
```
kubectl get nodes --watch
```
輸入 `Ctrl`\$1`C` 傳回 Shell 提示。
**注意**
如果您收到任何授權或資源類型錯誤，請參閱故障診斷主題中的[未經授權或存取遭拒 (`kubectl`)](troubleshooting.md#unauthorized)。
如果節點無法加入叢集，請參閱「故障診斷」章節中的 [節點無法加入叢集](troubleshooting.md#worker-node-fail)。
1. (僅限 GPU 節點) 若您選擇了 GPU 執行個體類型和 Amazon EKS 最佳化加速 AMI，則必須套用 [Kubernetes 專用 NVIDIA 裝置外掛程式](https://github.com/NVIDIA/k8s-device-plugin)作為叢集上的 DaemonSet。請先以您想要的 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) 版本來取代 *vX.X.X*，然後再執行下列命令。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
**步驟 3：其他動作**
1. (選用) 部署[範例應用程式](sample-deployment.md)以測試您的叢集和 Linux 節點。
1. (選用) 如果 **AmazonEKS\$1CNI\$1Policy** 受管 IAM 政策 (如果您有 `IPv4` 叢集) 或 *AmazonEKS\$1CNI\$1IPv6\$1Policy* (您[自我建立的政策](cni-iam-role.md#cni-iam-role-create-ipv6-policy)，前提是如果您有 `IPv6` 叢集) 連接至 [Amazon EKS 節點 IAM 角色](create-node-role.md)，建議改為將其指派給您與 Kubernetes `aws-node` 服務帳戶相關聯的 IAM 角色。如需詳細資訊，請參閱[設定 Amazon VPC CNI 外掛程式以使用 IRSA](cni-iam-role.md)。
1. 如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
# 建立自我管理的 Bottlerocket 節點
**注意**
受管節點群組可能會為您的使用案例提供一些優勢。如需詳細資訊，請參閱[透過受管節點群組來簡化節點生命週期](managed-node-groups.md)。
本主題會說明如何啟動向 Amazon EKS 叢集註冊的 [Bottlerocket](https://aws.amazon.com/bottlerocket/) 節點的 Auto Scaling 群組。Bottlerocket 是以 Linux 為基礎的開放原始碼作業系統 AWS ，可用於在虛擬機器或裸機主機上執行容器。節點加入叢集後，您就可以將 Kubernetes 應用程式部署至其中。如需 Bottlerocket 的詳細資訊，請參閱 GitHub 上的[搭配 Amazon EKS 使用 Bottlerocket AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) 和 `eksctl` 文件上的[自訂 AMI 支援](https://eksctl.io/usage/custom-ami-support/)。
如需就地升級的資訊，請參閱 GitHub 上的 [Bottlerocket 更新運算子](https://github.com/bottlerocket-os/bottlerocket-update-operator)。
**重要**
Amazon EKS 節點為標準 Amazon EC2 執行個體，會根據一般 Amazon EC2 執行個體價格向您收取這些節點的費用。如需詳細資訊，請參閱 [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)。
您可以在 AWS Outposts 上的 Amazon EKS 擴充叢集中啟動 Bottlerocket 節點，但無法在 AWS Outposts 的本機叢集中啟動它們。如需詳細資訊，請參閱[使用 AWS Outposts 在內部部署 Amazon EKS](eks-outposts.md)。
您可以使用 `x86` 或 Arm 處理器部署至 Amazon EC2 執行個體。不過，您無法部署至具有 Inferentia 晶片的執行個體。
Bottlerocket 與 AWS CloudFormation 相容。但是，沒有可複製的官方 CloudFormation 範本來部署 Amazon EKS 的 Bottlerocket 節點。
Bottlerocket 映像不會隨附 SSH 伺服器或 Shell。您可以使用頻外存取方法來允許 SSH 啟用管理員容器，並傳遞一些引導組態步驟與使用者資料。如需詳細資訊，請參閱 GitHub 上 [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) 中的這些部分：
[探勘](https://github.com/bottlerocket-os/bottlerocket#exploration)
[管理員容器](https://github.com/bottlerocket-os/bottlerocket#admin-container)
[Kubernetes 設定](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings)
此程序需要 `eksctl` 版本 `0.215.0` 或更新版本。您可使用以下命令檢查您的版本：
```
eksctl version
```
如需如何安裝或升級 `eksctl` 的指示，請參閱 `eksctl` 文件中的[安裝](https://eksctl.io/installation)。注意：此程序僅適用於使用 `eksctl` 建立的叢集。
1. 將以下內容複製到您的裝置。使用您叢集的名稱取代 *my-cluster*。此名稱僅能使用英數字元 (區分大小寫) 和連字號。必須以英數字元開頭，且長度不可超過 100 個字元。名稱在您要建立叢集 AWS 的區域和 AWS 帳戶中必須是唯一的。使用您的節點群組名稱取代 *ng-bottlerocket*。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。若要在 Arm 執行個體上部署，請使用 Arm 執行個體類型取代 *m5.large*。使用 Amazon EC2 SSH 金鑰對名稱取代 *my-ec2-keypair-name*，您可以在節點啟動後使用該金鑰對來透過 SSH 連接至節點。如果您還沒有 Amazon EC2 金鑰對，可以在 AWS 管理主控台中建立一個。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。使用您自己的值取代其餘所有範例值。完成取代後，請執行修改後的命令以建立 `bottlerocket.yaml` 檔案。
如果指定 Arm Amazon EC2 執行個體類型，則請在部署前檢閱 [Amazon EKS 最佳化 Arm Amazon Linux AMI](eks-optimized-ami.md#arm-ami) 的考量事項。如需了解如何使用自訂 AMI 部署，請參閱 GitHub 上的[建置 Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) 和 `eksctl` 文件中的[自訂 AMI 支援](https://eksctl.io/usage/custom-ami-support/)。若要部署受管節點群組，請使用啟動範本部署自訂 AMI。如需詳細資訊，請參閱[使用啟動範本自訂受管節點](launch-templates.md)。
**重要**
若要將節點群組部署至 AWS Outposts、 AWS Wavelength 或 AWS Local Zone 子網路，請勿在建立叢集時傳遞 AWS Outposts、 AWS Wavelength 或 AWS Local Zone 子網路。您必須在下列範例中指定子網路。如需詳細資訊，請參閱 `eksctl` 文件中的[從組態檔案建立節點群組](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)和[組態檔案結構描述](https://eksctl.io/usage/schema/)。將 *region-code* 取代為您的叢集所在的 AWS 區域。
```
cat >bottlerocket.yaml <
本主題說明如何啟動已向 Amazon EKS 叢集註冊的 Windows 節點的 Auto Scaling 群組。節點加入叢集後，您就可以將 Kubernetes 應用程式部署至其中。
**重要**
Amazon EKS 節點為標準 Amazon EC2 執行個體，會根據一般 Amazon EC2 執行個體價格向您收取這些節點的費用。如需詳細資訊，請參閱 [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)。
您可以在 AWS Outposts 上的 Amazon EKS 延伸叢集中啟動 Windows 節點，但無法在 AWS Outposts 的本機叢集中啟動它們。如需詳細資訊，請參閱[使用 AWS Outposts 在內部部署 Amazon EKS](eks-outposts.md)。
為您的叢集啟用 Windows 支援。我們建議您在啟動 Windows 節點群組之前，先檢閱重要的考量。如需詳細資訊，請參閱[啟用 Windows 支援](windows-support.md#enable-windows-support)。
您可以使用下列任意一項啟動自我管理的 Windows 節點：
+ [`eksctl`](#eksctl_create_windows_nodes)
+ [AWS 管理主控台](#console_create_windows_nodes)
## `eksctl`
**使用 `eksctl` 啟動自我管理的 Windows 節點**
此程序需要您已安裝 `eksctl`，且您的 `eksctl` 版本至少是 `0.215.0`。您可使用以下命令檢查您的版本。
```
eksctl version
```
如需有關安裝或更新 `eksctl` 的指示，請參閱 `eksctl` 文件中的 [Installation](https://eksctl.io/installation) 一節。
**注意**
此程序只適用於使用 `eksctl` 所建立的叢集。
1. (選用) 如果 **AmazonEKS\$1CNI\$1Policy** 受管 IAM 政策 (如果您有 `IPv4` 叢集) 或 *AmazonEKS\$1CNI\$1IPv6\$1Policy* (您[自我建立的政策](cni-iam-role.md#cni-iam-role-create-ipv6-policy)，前提是如果您有 `IPv6` 叢集) 連接至 [Amazon EKS 節點 IAM 角色](create-node-role.md)，建議改為將其指派給您與 Kubernetes `aws-node` 服務帳戶相關聯的 IAM 角色。如需詳細資訊，請參閱[設定 Amazon VPC CNI 外掛程式以使用 IRSA](cni-iam-role.md)。
1. 此程序假設您有現有的叢集。如果您尚未擁有可新增 Windows 節點群組的 Amazon EKS 叢集和 Amazon Linux 節點群組，我們建議您遵循 [Amazon EKS 入門 – `eksctl`](getting-started-eksctl.md)。該指南提供了建立具有 Amazon Linux 節點的 Amazon EKS 叢集的完整演練。
使用下列命令來建立您的節點群組。將 *region-code* 取代為您的叢集所在的 AWS 區域。使用您的叢集名稱取代 *my-cluster*。此名稱僅能使用英數字元 (區分大小寫) 和連字號。必須以英數字元開頭，且長度不可超過 100 個字元。在您建立叢集 AWS 的區域和 AWS 帳戶中，名稱必須是唯一的。使用您的節點群組名稱取代 *ng-windows*。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。您可以使用 取代 *2019* `2022` 以使用 Windows Server 2022 或使用 `2025` Windows Server 2025。使用您自己的值取代範例值的其餘部分。
**重要**
若要將節點群組部署至 AWS Outposts、 AWS Wavelength 或 AWS Local Zone 子網路，請勿在建立叢集時傳遞 AWS Outposts、Wavelength 或 Local Zone 子網路。使用組態檔案建立節點群組，指定 AWS Outposts、Wavelength 或 Local Zone 子網路。如需詳細資訊，請參閱 `eksctl` 文件中的[從組態檔案建立節點群組](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)和[組態檔案結構描述](https://eksctl.io/usage/schema/)。
```
eksctl create nodegroup \
--region region-code \
--cluster my-cluster \
--name ng-windows \
--node-type t2.large \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false \
--node-ami-family WindowsServer2019FullContainer
```
**注意**
如果節點無法加入叢集，請參閱故障診斷指南中的 [節點無法加入叢集](troubleshooting.md#worker-node-fail)。
若要查看 `eksctl` 命令可用的選項，請輸入下列命令。
```
eksctl command -help
```
範例輸出如下。建立節點時，會有數行輸出。輸出的最後幾行之一類似於以下的範例行。
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (選用) 部署[範例應用程式](sample-deployment.md)以測試您的叢集和 Windows 節點。
1. 如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
## AWS 管理主控台
**先決條件**
+ 現有 Amazon EKS 叢集和 Linux 節點群組。如果您沒有這些資源，我們建議您遵循我們 [開始使用 Amazon EKS](getting-started.md) 中的其中一個指南來建立這些資源。這些指南說明如何建立具有 Linux 節點的 Amazon EKS 叢集。
+ 符合 Amazon EKS 叢集要求的現有 VPC 和安全群組。如需詳細資訊，請參閱[檢視 VPC 和子網路的 Amazon EKS 聯網需求](network-reqs.md)及[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md)。[開始使用 Amazon EKS](getting-started.md) 中的指南會建立符合要求的 VPC。或者，您也可以遵循[為您的 Amazon EKS 叢集建立 Amazon VPC](creating-a-vpc.md) 手動建立一個。
+ 現有的 Amazon EKS 叢集，其使用符合 Amazon EKS 叢集要求的 VPC 和安全群組。如需詳細資訊，請參閱[建立 Amazon EKS 叢集](create-cluster.md)。如果您在已啟用 AWS AWS Outposts、 AWS Wavelength 或 AWS Local Zones 的區域中有子網路，則這些子網路不得在您建立叢集時傳入。
**步驟 1：使用 AWS 管理主控台 啟動自我管理的 Windows 節點**
1. 等待您的叢集狀態顯示為 `ACTIVE`。如果在叢集處於作用中狀態之前啟動節點，則節點向叢集註冊將會失敗，導致您必須再次啟動。
1. 開啟 [AWS CloudFormation 主控台](https://console.aws.amazon.com/cloudformation/)
1. 選擇**建立堆疊**。
1. 對於 **Specify template** (指定範本)，選取 **Amazon S3 URL**。
1. 複製以下 URL 並將其貼到 **Amazon S3 URL** 中。
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
```
1. 選取 **Next** (下一步) 兩次。
1. 在 **Quick create stack** (快速建立堆疊) 頁面上，視需要輸入下列參數：
+ **堆疊名稱**：為您的 AWS CloudFormation 堆疊選擇堆疊名稱。例如，您可以稱它為 `my-cluster-nodes`。
+ **ClusterName**：輸入建立 Amazon EKS 叢集時使用的名稱。
**重要**
此名稱必須與您在[步驟 1：建立 Amazon EKS 叢集](getting-started-console.md#eks-create-cluster)中使用的名稱完全相符。否則，您的節點無法加入叢集。
+ **ClusterControlPlaneSecurityGroup**：從您在建立 [VPC](creating-a-vpc.md) 時產生的 AWS CloudFormation 輸出中選擇安全群組。下列步驟顯示擷取適用群組的一種方法。
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇叢集的名稱。
1. 選擇 **Networking (網路)** 索引標籤。
1. 從 **ClusterControlPlaneSecurityGroup** 下拉式清單中選取時，請使用 **Additional Security Group** (其他安全群組) 值作為參考。
+ **NodeGroupName**：輸入節點群組的名稱。此名稱稍後可用於識別為您節點建立的 Auto Scaling 節點群組。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。
+ **NodeAutoScalingGroupMinSize**：輸入節點 Auto Scaling 群組可以縮減的最低節點數。
+ **NodeAutoScalingGroupDesiredCapacity**：堆疊建立時，輸入欲擴展的所需節點數量。
+ **NodeAutoScalingGroupMaxSize**：輸入節點 Auto Scaling 群組可以擴增的最大節點數。
+ **NodeInstanceType**：選擇節點的執行個體類型。如需詳細資訊，請參閱[選擇最佳的 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。
**注意**
最新版本的 [Kubernetes 專用 Amazon VPC CNI 外掛程式](https://github.com/aws/amazon-vpc-cni-k8s)支援的執行個體類型會在 GitHub 上的 [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) 中列出。您可能需要更新 CNI 版本，才能使用最新支援的執行個體類型。如需詳細資訊，請參閱[使用 Amazon VPC CNI 將 IP 指派給 Pod](managing-vpc-cni.md)。
+ **NodeImageIdSSMParam**：預先填入目前所建議 Amazon EKS 最佳化 Windows Core AMI ID 的 Amazon EC2 Systems Manager 參數。若要使用完整版本的 Windows，請使用 `Full` 取代 *Core*。
+ **NodeImageId**：（選用） 如果您使用自己的自訂 AMI （而非 Amazon EKS 最佳化 AMI)，請輸入您 AWS 區域的節點 AMI ID。如果您在此欄位指定值，則會覆寫 **NodeImageIdSSMParam** 欄位中的任何值。
+ **NodeVolumeSize**：為您的節點指定根磁碟區大小 (以 GiB 為單位)。
+ **KeyName**：輸入 Amazon EC2 SSH 金鑰對的名稱，您可以在節點啟動後使用該金鑰對來透過 SSH 連接至節點。如果您還沒有 Amazon EC2 金鑰對，可以在 AWS 管理主控台中建立一個。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)。
**注意**
如果您未在此處提供金鑰對，則無法建立 AWS CloudFormation 堆疊。
+ **BootstrapArguments**：指定要傳遞至節點引導指令碼的任何選用引數，例如使用 `-KubeletExtraArgs` 的額外 `kubelet` 引數。
+ **DisableIMDSv1**：預設情況下，每個節點都支援執行個體中繼資料服務版本 1 (IMDSv1) 和 IMDSv2。您可以停用 IMDSv1。若要防止節點群組中的未來節點和 Pod 使用 MDSv1，請將 **DisableIMDSv1** 設定為 **true**。如需 IMDS 的詳細資訊，請參閱[設定執行個體中繼資料服務](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)。
+ **VpcId**：選取您建立的 [VPC](creating-a-vpc.md) ID。
+ **NodeSecurityGroups**：選取在建立 [VPC](creating-a-vpc.md) 時為您的 Linux 節點群組建立的安全群組。如果 Linux 節點連接了一個以上的安全群組，請指定所有的群組。例如，如果 Linux 節點群組是使用 `eksctl` 建立。
+ **Subnets** (子網路)：選擇您建立的子網路。如果您已依照[為您的 Amazon EKS 叢集建立 Amazon VPC](creating-a-vpc.md) 中的步驟建立 VPC，則只需指定要啟動節點的 VPC 中的私有子網路。
**重要**
如有任何子網路是公有子網路，則必須啟用自動公有 IP 地址指派設定。如果未針對公有子網路啟用 設定，則您部署至該公有子網路的任何節點都不會指派公有 IP 地址，也無法與叢集或其他 AWS 服務通訊。如果子網路是在 2020 年 3 月 26 日之前使用任一 [Amazon EKS AWS CloudFormation VPC 範本](creating-a-vpc.md)或使用 部署，`eksctl`則會停用公有子網路的自動公有 IP 地址指派。如需如何啟用子網路的公有 IP 地址指派的相關資訊，請參閱[修改您子網路的公有 IPv4 定址屬性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)。如果節點部署到私有子網路，則可以透過 NAT 閘道與叢集和其他 AWS 服務通訊。
如果子網路無法存取網際網路，則請確保您已知悉[部署網際網路存取受到限制的私有叢集](private-clusters.md)中的考量事項和額外步驟。
如果您選取 AWS Outpost、Wavelength 或 Local Zone 子網路，則建立叢集時不得傳入子網路。
1. 確認堆疊可建立 IAM 資源，然後選擇 **Create stack** (建立堆疊)。
1. 當當堆疊已完成建立時，從主控台將其選取，然後選擇 **Outputs (輸出)**。
1. 為已建立的節點群組記錄 **NodeInstanceRole**。當您設定 Amazon EKS Windows 節點時會需要此值。
**步驟 2：讓節點加入叢集**
1. 檢查以瞭解是否有 `aws-auth` `ConfigMap`。
```
kubectl describe configmap -n kube-system aws-auth
```
1. 如果您看到 `aws-auth` `ConfigMap`，請視需要更新之。
1. 開啟 `ConfigMap` 進行編輯。
```
kubectl edit -n kube-system configmap/aws-auth
```
1. 視需要新增 `mapRoles` 個項目。將 `rolearn` 值設定為您在先前程序中記錄的 **NodeInstanceRole** 值。
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows
[...]
```
1. 儲存檔案並結束您的文字編輯器。
1. 如果您收到一個錯誤，說明 "`Error from server (NotFound): configmaps "aws-auth" not found`，那麼請套用股票 `ConfigMap`。
1. 下載組態對應。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml
```
1. 在 `aws-auth-cm-windows.yaml` 檔案中，將 `rolearn` 值設定為您在先前程序中記錄的適用 **NodeInstanceRole** 值。您可以使用文字編輯器來完成此操作，或者透過取代範例值並執行下列命令：
```
sed -i.bak -e 's||my-node-linux-instance-role|' \
-e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml
```
**重要**
請勿修改此檔案中的任何其他行。
請勿為 Windows 節點和 Linux 節點使用相同的 IAM 角色。
1. 套用組態。此命令可能需要幾分鐘的時間來完成。
```
kubectl apply -f aws-auth-cm-windows.yaml
```
1. 查看節點的狀態，並等待他們到達 `Ready` 狀態。
```
kubectl get nodes --watch
```
輸入 `Ctrl`\$1`C` 傳回 Shell 提示。
**注意**
如果您收到任何授權或資源類型錯誤，請參閱故障診斷主題中的[未經授權或存取遭拒 (`kubectl`)](troubleshooting.md#unauthorized)。
如果節點無法加入叢集，請參閱「故障診斷」章節中的 [節點無法加入叢集](troubleshooting.md#worker-node-fail)。
**步驟 3：其他動作**
1. (選用) 部署[範例應用程式](sample-deployment.md)以測試您的叢集和 Windows 節點。
1. (選用) 如果 **AmazonEKS\$1CNI\$1Policy** 受管 IAM 政策 (如果您有 `IPv4` 叢集) 或 *AmazonEKS\$1CNI\$1IPv6\$1Policy* (您[自我建立的政策](cni-iam-role.md#cni-iam-role-create-ipv6-policy)，前提是如果您有 `IPv6` 叢集) 連接至 [Amazon EKS 節點 IAM 角色](create-node-role.md)，建議改為將其指派給您與 Kubernetes `aws-node` 服務帳戶相關聯的 IAM 角色。如需詳細資訊，請參閱[設定 Amazon VPC CNI 外掛程式以使用 IRSA](cni-iam-role.md)。
1. 如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
# 建立自我管理的 Ubuntu Linux 節點
**注意**
受管節點群組可能會為您的使用案例提供一些優勢。如需詳細資訊，請參閱[透過受管節點群組來簡化節點生命週期](managed-node-groups.md)。
本主題會說明如何啟動向 Amazon EKS 叢集註冊的 [Amazon Elastic Kubernetes Service (EKS) 上的 Ubuntu](https://cloud-images.ubuntu.com/aws-eks/) 或 [Amazon Elastic Kubernetes Service (EKS) 上的 Ubuntu Pro](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) 節點的 Auto Scaling 群組。Ubuntu 和 Ubuntu Pro for EKS 是以官方 Ubuntu Minimal LTS 為基礎，包括與 共同開發的自訂 AWS 核心 AWS，並專門為 EKS 建置。Ubuntu Pro 透過支援 EKS 延長支援期間、核心 livepatch、FIPS 合規以及執行無限 Pro 容器的能力來新增額外的安全涵蓋範圍。
節點加入叢集後，您就可以將容器化應用程式部署至其中。如需詳細資訊，請參閱 `eksctl` 文件中的 [AWS上的 Ubuntu](https://documentation.ubuntu.com/aws/en/latest/) 和[自訂 AMI 支援](https://eksctl.io/usage/custom-ami-support/)。
**重要**
Amazon EKS 節點為標準 Amazon EC2 執行個體，會根據一般 Amazon EC2 執行個體價格向您收取這些節點的費用。如需詳細資訊，請參閱 [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)。
您可以在 AWS Outposts 上的 Amazon EKS 擴充叢集中啟動 Ubuntu 節點，但無法在 AWS Outposts 的本機叢集中啟動它們。如需詳細資訊，請參閱[使用 AWS Outposts 在內部部署 Amazon EKS](eks-outposts.md)。
您可以使用 `x86` 或 Arm 處理器部署至 Amazon EC2 執行個體。不過，具有 Inferentia 晶片的執行個體可能需要先安裝 [Neuron SDK](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/)。
此程序需要 `eksctl` 版本 `0.215.0` 或更新版本。您可使用以下命令檢查您的版本：
```
eksctl version
```
如需如何安裝或升級 `eksctl` 的指示，請參閱 `eksctl` 文件中的[安裝](https://eksctl.io/installation)。注意：此程序僅適用於使用 `eksctl` 建立的叢集。
1. 將以下內容複製到您的裝置。使用您叢集的名稱取代 `my-cluster`。此名稱僅能使用英數字元 (區分大小寫) 和連字號。必須以字母字元開頭，且長度不可超過 100 個字元。將 `ng-ubuntu` 取代為您的節點群組名稱。節點群組名稱不可超過 63 個字元。它必須以字母或數字開頭，但剩餘字元也可以包含連字符和底線。若要在 Arm 執行個體上部署，請以 Arm 執行個體類型取代 `m5.large`。使用 Amazon EC2 SSH 金鑰對名稱取代 `my-ec2-keypair-name`，您可以在節點啟動後使用該金鑰對來透過 SSH 連接至節點。如果您還沒有 Amazon EC2 金鑰對，可以在 AWS 管理主控台中建立一個。如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。使用您自己的值取代其餘所有範例值。完成取代後，請執行修改後的命令以建立 `ubuntu.yaml` 檔案。
**重要**
若要將節點群組部署至 AWS Outposts、 AWS Wavelength 或 AWS Local Zone 子網路，請勿在建立叢集時傳遞 AWS Outposts、 AWS Wavelength 或 AWS Local Zone 子網路。您必須在下列範例中指定子網路。如需詳細資訊，請參閱 `eksctl` 文件中的[從組態檔案建立節點群組](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)和[組態檔案結構描述](https://eksctl.io/usage/schema/)。將 *region-code* 取代為您的叢集所在的 AWS 區域。
```
cat >ubuntu.yaml <
全新 Amazon EKS 最佳化 AMI 發行時，請考量以新 AMI 取代自我管理節點群組中的節點。同樣地，如果更新 Amazon EKS 叢集的 Kubernetes 版本，請更新節點以使用具相同 Kubernetes 版本的節點。
**重要**
本主題涵蓋自我管理節點的節點更新。若使用[受管節點群組](managed-node-groups.md)，則請參閱 [更新叢集的受管節點群組](update-managed-node-group.md)。
有兩種基本方法可以將叢集中的自我管理節點群組更新成使用新的 AMI：
**[將應用程式移轉至新的節點群組](migrate-stack.md)**
建立新的節點群組，並將 Pod 移轉至該群組。移轉至新節點群組比在現有 AWS CloudFormation 堆疊中更新 AMI ID 更順利。這是因為移轉過程會將舊節點群組[汙染](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)為 `NoSchedule`，並在新堆疊準備好接受現有的 Pod 工作負載之後耗盡節點。
**[更新 AWS CloudFormation 節點堆疊](update-stack.md)**
更新現有節點群組的 AWS CloudFormation 堆疊，以使用新的 AMI。不支援對使用 `eksctl` 建立的節點群組使用這個方法。
# 將應用程式移轉至新的節點群組
此主題會說明如何建立新的節點群組，將現有的應用程式從容遷移至新群組，接著從叢集移除舊的節點群組。您可以使用 `eksctl` 或 AWS 管理主控台遷移至新的節點群組。
+ [`eksctl`](#eksctl_migrate_apps)
+ [AWS 管理主控台 和 AWS CLI](#console_migrate_apps)
## `eksctl`
**使用 `eksctl` 將應用程式移轉至新的節點群組**
如需有關將 eksctl 用於移轉的詳細資訊，請參閱 `eksctl` 文件中的[未受管的節點群組](https://eksctl.io/usage/nodegroup-unmanaged/)。
此程序需要 `eksctl` 版本 `0.215.0` 或更新版本。您可使用以下命令檢查您的版本：
```
eksctl version
```
如需有關安裝或更新 `eksctl` 的指示，請參閱 `eksctl` 文件中的 [Installation](https://eksctl.io/installation) 一節。
**注意**
此程序只適用於使用 `eksctl` 所建立的叢集和節點群組。
1. 擷取現有節點群組的名稱，使用叢集名稱取代 *my-cluster*。
```
eksctl get nodegroups --cluster=my-cluster
```
範例輸出如下。
```
CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID
default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12
```
1. 使用以下命令啟動具備 `eksctl` 的新節點群組。在命令中，使用您自己的值取代每一個*範例值*。版本編號不能晚於控制平面的 Kubernetes 版本。也不能比控制平面的 Kubernetes 版本早兩個以上的次要版本。建議使用與控制平面相同的版本。
如果下列條件為真，我們建議封鎖 Pod 對 IMDS 的存取：
+ 您計劃將 IAM 角色指派給您的所有 Kubernetes 服務帳戶，以便 Pod 僅具有所需的最低許可。
+ 叢集中沒有任何 Pod 因其他原因需要存取 Amazon EC2 執行個體中繼資料服務 (IMDS)，例如擷取目前 AWS 區域。
如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
若要封鎖 Pod 對 IMDS 的存取，請將 `--disable-pod-imds` 選項新增至下列命令。
**注意**
如需更多可用旗標及其描述的資訊，請參閱 https://eksctl.io/。
```
eksctl create nodegroup \
--cluster my-cluster \
--version 1.35 \
--name standard-nodes-new \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false
```
1. 之前的命令完成時，使用下列命令來確認所有節點已達到 `Ready` 狀態：
```
kubectl get nodes
```
1. 使用下列命令來刪除原始的節點群組。在命令中，使用您的叢集和節點群組名稱取代每一個*範例值*：
```
eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
```
## AWS 管理主控台 和 AWS CLI
**使用 AWS 管理主控台 和 AWS CLI 將應用程式遷移至新的節點群組**
1. 依照[建立自我管理的 Amazon Linux 節點](launch-workers.md)中概述的步驟啟動新的節點群組。
1. 當當堆疊已完成建立時，從主控台將其選取，然後選擇 **Outputs (輸出)**。
1. 為已建立的節點群組記錄 **NodeInstanceRole**。您需要這樣才能新增 Amazon EKS 節點至叢集。
**注意**
如果已將任何額外的 IAM 政策連接至舊節點群組 IAM 角色，則請將相同政策連接至新節點群組 IAM 角色，以便在新群組維持該功能。例如，如果為 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) 新增許可，則適用此操作。
1. 更新兩個節點群組的安全群組，使其能夠互相通訊。如需詳細資訊，請參閱[檢視叢集的 Amazon EKS 安全群組要求](sec-group-reqs.md)。
1. 記錄兩個節點群組的安全群組 ID。這在 AWS CloudFormation 堆疊輸出中顯示為 **NodeSecurityGroup** 值。
您可以使用下列 AWS CLI 命令，從堆疊名稱取得安全群組 IDs。在這些命令中， `oldNodes`是舊版節點堆疊的 AWS CloudFormation 堆疊名稱，而 `newNodes`是您要遷移至的堆疊名稱。使用您自己的值取代每一個*範例值*。
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
```
1. 新增輸入規則至每個節點安全群組，使其接受彼此的流量。
下列 AWS CLI 命令會將傳入規則新增至每個安全群組，以允許來自其他安全群組的所有通訊協定上的所有流量。此組態可讓每個節點群組中的 Pod 在您將工作負載移轉至新群組時互相通訊。
```
aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. 編輯 `aws-auth` configmap 以在 RBAC 中對應新的節點執行個體角色。
```
kubectl edit configmap -n kube-system aws-auth
```
為新節點群組新增 `mapRoles` 項目。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: ARN of instance role (not instance profile)
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
- rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
```
使用您在[上一個步驟](#node-instance-role-step)中記錄的 **NodeInstanceRole** 值來取代*執行個體角色 ARN (非執行個體設定檔)* 程式碼片段。接著，儲存並關閉檔案以套用更新的 configmap。
1. 注意節點狀態並等待新的節點加入叢集和達到 `Ready` 狀態。
```
kubectl get nodes --watch
```
1. (選用) 如果您使用的是 [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)，請將部署縮減為零 (0) 個複本以避免衝突的擴展動作。
```
kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
```
1. 使用以下命令污染每個您想要用 `NoSchedule` 移除的節點。這樣就不會在您要取代的節點上排程或重新排程新的 Pod。如需詳細資訊，請參閱 Kubernetes 文件中的[污點和容差](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。
```
kubectl taint nodes node_name key=value:NoSchedule
```
如果要將節點升級至新的 Kubernetes 版本，您可以使用以下程式碼片段識別並標示特定 Kubernetes 版本 (在此情況下為 `1.33`) 的所有節點。版本編號不能晚於控制平面的 Kubernetes 版本。也不能比控制平面的 Kubernetes 版本早兩個以上的次要版本。建議使用與控制平面相同的版本。
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Tainting $node"
kubectl taint nodes $node key=value:NoSchedule
done
```
1. 判斷叢集的 DNS 提供商。
```
kubectl get deployments -l k8s-app=kube-dns -n kube-system
```
範例輸出如下。此叢集針對 DNS 解析度使用 CoreDNS，但您的叢集可能會傳回 `kube-dns`：
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 1 1 1 1 31m
```
1. 如果您目前的部署執行少於 2 個複本，請將部署擴增為 2 個複本。如果您先前的命令輸出傳回該項目，請以 `kubedns` 取代 *coredns*。
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. 使用以下命令清空您想要從叢集移除的每個節點：
```
kubectl drain node_name --ignore-daemonsets --delete-local-data
```
如果您要將節點升級至新的 Kubernetes 版本，請使用下列程式碼片段識別並耗盡特定 Kubernetes 版本 （在本例中為 *1.33*) 的所有節點。
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Draining $node"
kubectl drain $node --ignore-daemonsets --delete-local-data
done
```
1. 在舊的節點完成消耗後，請撤銷您先前授權的安全群組傳入規則。然後，刪除 AWS CloudFormation 堆疊以終止執行個體。
**注意**
如果您將任何其他 IAM 政策連接至舊節點群組 IAM 角色，例如新增 [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) 的許可，請先從角色分離這些其他政策，然後才能刪除 AWS CloudFormation 堆疊。
1. 撤銷您先前為節點安全群組建立的傳入規則。在這些命令中， `oldNodes`是舊版節點堆疊的 AWS CloudFormation 堆疊名稱，而 `newNodes`是您要遷移至的堆疊名稱。
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. 開啟 [AWS CloudFormation 主控台](https://console.aws.amazon.com/cloudformation/)。
1. 選取舊的節點堆疊。
1. 選擇 **刪除**。
1. 在 **Delete stack** (刪除堆疊) 確認對話方塊中，選擇 **Delete stack** (刪除堆疊)。
1. 編輯 `aws-auth` configmap 以從 RBAC 移除舊的節點執行個體角色。
```
kubectl edit configmap -n kube-system aws-auth
```
刪除舊節點群組的 `mapRoles` 項目。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
```
儲存並關閉檔案以套用更新的 configmap。
1. (選用) 如果您使用的是 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)，請將部署縮減回 1 個複本。
**注意**
您也必須適當標記新的 Auto Scaling 群組 (例如 `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`)，並更新 Cluster Autoscaler 部署的命令，以指向新標記的 Auto Scaling 群組。如需詳細資訊，請參閱 [Cluster Autoscaler on AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws)。
```
kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
```
1. (選用) 確認您使用的是最新版本的 [Kubernetes 專用 Amazon VPC CNI 外掛程式](https://github.com/aws/amazon-vpc-cni-k8s)。您可能需要更新 CNI 版本，才能使用最新支援的執行個體類型。如需詳細資訊，請參閱[使用 Amazon VPC CNI 將 IP 指派給 Pod](managing-vpc-cni.md)。
1. 如果您的叢集針對 DNS 解析度使用 `kube-dns` (請參閱 [[migrate-determine-dns-step]](#migrate-determine-dns-step))，請將 `kube-dns` 部署縮減至一個複本。
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```
# 更新 an AWS CloudFormation 節點堆疊
本主題說明如何使用新的 AMI 更新現有的 AWS CloudFormation 自我管理節點堆疊。您可以使用此程序在叢集更新後將節點更新至新版本的 Kubernetes。否則，您可以針對現有 Kubernetes 版本更新至最新的 Amazon EKS 最佳化 AMI。
**重要**
本主題涵蓋自我管理節點的節點更新。若要了解[透過受管節點群組來簡化節點生命週期](managed-node-groups.md)的相關詳細資訊，請參閱 [更新叢集的受管節點群組](update-managed-node-group.md)。
最新的預設 Amazon EKS node AWS CloudFormation 範本已設定為在移除舊執行個體之前，在叢集中啟動具有新 AMI 的執行個體，一次一個。此組態可確保您在滾動更新期間，都能掌握叢集中 Auto Scaling 群組所需的作用中執行個體計數。
**注意**
不支援對使用 `eksctl` 建立的節點群組使用這個方法。如果透過 `eksctl` 建立叢集或節點群組，則請參閱 [將應用程式移轉至新的節點群組](migrate-stack.md)。
1. 判斷叢集的 DNS 供應商。
```
kubectl get deployments -l k8s-app=kube-dns -n kube-system
```
範例輸出如下。此叢集針對 DNS 解析度使用 CoreDNS，但您的叢集可能會傳回 `kube-dns`。根據您使用的 `kubectl` 版本，輸出可能會有所不同。
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 1 1 1 1 31m
```
1. 如果您目前的部署執行少於 2 個複本，請將部署擴增為 2 個複本。如果您先前的命令輸出傳回該項目，請以 `kube-dns` 取代 *coredns*。
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. (選用) 如果您使用的是 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)，請將部署縮減為零 (0) 個複本以避免衝突的擴展動作。
```
kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
```
1. 確定目前節點群組的執行個體類型和所需執行個體計數。您稍後更新群組的 AWS CloudFormation 範本時，會輸入這些值。
1. 前往 https://console.aws.amazon.com/ec2/ 開啟 Amazon EC2 主控台。
1. 在左側導覽窗格中，選擇 **Launch Configurations** (啟動組態)，並記下現有節點啟動組態的執行個體類型。
1. 在左側導覽窗格中，選擇 **Auto Scaling Groups** (Auto Scaling 群組)，並注意現有節點 Auto Scaling 群組的 **Desired** (所需) 執行個體計數。
1. 開啟 [AWS CloudFormation 主控台](https://console.aws.amazon.com/cloudformation/)。
1. 選取您的節點群組堆疊，然後選擇 **Update** (更新)。
1. 選取 **Replace current template (取代目前的範本)**，然後選取 **Amazon S3 URL**。
1. 對於 **Amazon S3 URL**，請將下列 URL 貼到文字區域，以確保您使用的是最新版本的 node AWS CloudFormation 範本。然後選擇 **Next** (下一步)：
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml
```
1. 在 **Specify stack details (指定堆疊詳細資訊)** 頁面上，填寫下列參數，然後選擇 **Next (下一步)**：
+ **NodeAutoScalingGroupDesiredCapacity**：輸入在[先前步驟](#existing-worker-settings-step)中記錄的所需執行個體計數。或者，在堆疊更新時，輸入欲擴展的所需節點數量。
+ **NodeAutoScalingGroupMaxSize**：輸入節點 Auto Scaling 群組可以擴增的最大節點數。此值必須至少超過所需容量一個節點。這樣才能夠在更新期間執行節點滾動更新，而不必減少節點計數。
+ **NodeInstanceType**：選擇在[先前步驟](#existing-worker-settings-step)中記錄的執行個體類型。或者，為節點選擇不同的執行個體類型。選擇不同的執行個體類型之前，請檢閱[選擇最佳 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。每個 Amazon EC2 執行個體類型都支援最大數量的彈性網路介面 (網路介面)，且每個網路介面支援最大數量的 IP 地址。由於為每個工作節點和 Pod 指派了自己的 IP 位址，因此請務必選擇支援要在每個 Amazon EC2 節點上執行之最大 Pod 數量的執行個體類型。如需執行個體類型支援的網路介面和 IP 地址數量清單，請參閱[每種執行個體類型每個網路介面的 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)。例如，`m5.large` 執行個體類型最多支援工作節點和 Pod 的 30 個 IP 位址。
**注意**
最新版本的 [Kubernetes 專用 Amazon VPC CNI 外掛程式](https://github.com/aws/amazon-vpc-cni-k8s)支援的執行個體類型會顯示在 GitHub 上的 [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go)。您可能需要更新適用於 Kubernetes 的 Amazon VPC CNI 版本，才能使用最新支援的執行個體類型。如需詳細資訊，請參閱[使用 Amazon VPC CNI 將 IP 指派給 Pod](managing-vpc-cni.md)。
**重要**
有些執行個體類型可能無法在所有 AWS 區域中使用。
+ **NodeImageIdSSMParam** – 您要更新的 AMI ID 的 Amazon EC2 Systems Manager 參數。以下值對 Kubernetes `1.35` 版使用最新的 Amazon EKS 最佳化 AMI。
```
/aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id
```
您可以使用相同的[平台版本](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)取代 *1.35*。或者比控制平面上執行的 Kubernetes 版本早一個版本號的版本。建議您將節點保持在與控制平面相同的版本。您亦可使用不同的 AMI 類型來取代 *amazon-linux-2*。如需詳細資訊，請參閱[擷取建議的 Amazon Linux AMI ID](retrieve-ami-id.md)。
**注意**
使用 Amazon EC2 Systems Manager 參數可讓您在未來更新節點，而無需查詢和指定 AMI ID。如果您的 AWS CloudFormation 堆疊使用此值，任何堆疊更新一律會針對您指定的 Kubernetes 版本啟動最新的建議 Amazon EKS 最佳化 AMI。即使沒有變更範本中的任何值，情況也會如此。
+ **NodeImageId**：若要使用您自己的自訂 AMI，請輸入要使用的 AMI 的 ID。
**重要**
此值會覆寫 **NodeImageIdSSMParam** 指定的任何值。如果您想要使用 **NodeImageIdSSMParam** 值，請確定 **NodeImageId** 的值為空白。
+ **DisableIMDSv1**：在預設情況下，每個節點都支援執行個體中繼資料服務版本 1 (IMDSv1) 和 IMDSv2。不過，您可以停用 IMDSv1。如果不想要任何節點，或節點群組中排定的任何 Pod 使用 IMDSv1，則請選取 **true** (是)。如需 IMDS 的詳細資訊，請參閱[設定執行個體中繼資料服務](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)。如果您已為服務帳戶實作 IAM 角色，請直接將必要的許可指派給需要存取 AWS 服務的所有 Pod。如此一來，叢集中沒有任何 Pod 因為其他原因需要存取 IMDS，例如擷取目前的 AWS 區域。然後，您也可以針對不使用主機聯網的 Pod 停用對 IMDSv2 的存取。如需詳細資訊，請參閱[限制存取指派給工作節點的執行個體設定檔](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)。
1. (選用) 在 **Options (選項)** 頁面上，為堆疊資源加上標籤。選擇**下一步**。
1. 在 **Review** (檢閱) 頁面上檢閱您的資訊，確認該堆疊可建立 IAM 資源，然後選擇 **Update stack** (更新堆疊)。
**注意**
叢集中每個節點的更新，都需要幾分鐘的時間。請等待所有節點更新完成再執行後續步驟。
1. 如果您叢集的 DNS 供應商為 `kube-dns`，請將 `kube-dns` 部署縮減至 1 個複本。
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```
1. (選用) 如果您使用的是 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)，請將部署縮減回您想要的複本數量。
```
kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
```
1. (選用) 確認您使用的是最新版本的 [Kubernetes 專用 Amazon VPC CNI 外掛程式](https://github.com/aws/amazon-vpc-cni-k8s)。您可能需要更新適用於 Kubernetes 的 Amazon VPC CNI 版本，才能使用最新支援的執行個體類型。如需詳細資訊，請參閱[使用 Amazon VPC CNI 將 IP 指派給 Pod](managing-vpc-cni.md)。
# 使用 AWS Fargate 簡化運算管理
本主題討論如何使用 Amazon EKS 在 AWS Fargate 上執行 Kubernetes Pod。Fargate 是一種為[容器](https://aws.amazon.com/what-are-containers)提供隨需、適當大小運算容量的科技。有了 Fargate，就不再需要自行佈建、設定或擴展虛擬機器的群組來執行容器。您也無需選擇伺服器類型、決定何時擴展節點群組，或最佳化叢集壓縮。
您可以控制哪些 Pod 要在 Fargate 上啟動，以及其如何搭配 [Fargate 設定檔](fargate-profile.md)執行。Fargate 描述檔會定義為 Amazon EKS 叢集的一部分。Amazon EKS 使用控制器將 Kubernetes 與 Fargate 整合，而控制器則是透過 AWS 使用 Kubernetes 提供的上游、可擴充模型建立。這些控制器作為 Amazon EKS 受管 Kubernetes 控制平面的一部分執行，且負責將原生 Kubernetes Pod 排程至 Fargate。Fargate 控制器包括新的排程器，除了數個變換與驗證許可控制器之外，也會隨著預設 Kubernetes 排程器執行。當您啟動符合在 Fargate 上執行的條件的 Pod 時，在叢集中執行的 Fargate 控制器便會辨識、更新 Pod 並將 Pod 排程至 Fargate。
本主題會說明在 Fargate 上執行的不同 Pod 元件，並注意搭配使用 Fargate 與 Amazon EKS 的特殊考量。
## AWS Fargate 考慮因素
以下是在 Amazon EKS 上使用 Fargate 的考慮因素。
+ 在 Fargate 上執行的每個 Pod 都有自己的運算界限。這些 Pod 不會與其他 Pod 共用基礎核心、CPU 資源、記憶體資源或彈性網路介面。
+ Network Load Balancer 和 Application Load Balancer (ALB) 可以僅與具有 IP 目標的 Fargate 搭配使用。如需詳細資訊，請參閱[建立 Network Load Balancer](network-load-balancing.md#network-load-balancer)及[透過 Application Load Balancer 路由應用程式與 HTTP 流量](alb-ingress.md)。
+ Fargate 的公開服務僅能在目標類型 IP 模式下執行，不能在節點 IP 模式下執行。若要檢查在受管節點上和在 Fargate 上執行的服務的連線狀態，建議透過服務名稱來連線。
+ Pod 必須與其排程時的 Fargate 設定檔相符，以在 Fargate 上執行。與 Fargate 設定檔不相符的 Pod 可能會卡在 `Pending` 狀態。如果存在相符的 Fargate 設定檔，您可以刪除已建立的待定 Pod，以將其重新排程至 Fargate。
+ Fargate 不支援 Daemonsets。如果您的應用程式需要常駐程式，請重新設定該常駐程式，以作為您 Pod 中的附屬容器執行。
+ Fargate 不支援具有特殊權限的容器。
+ 在 Fargate 上執行的 Pod 不能指定 Pod 資訊清單中的 `HostPort` 或 `HostNetwork`。
+ 預設 `nofile` 和 `nproc` 軟性限制為 1024，而 Fargate Pod 的硬性限制為 65535。
+ GPU 目前無法在 Fargate 上使用。
+ 只有私有子網路支援在 Fargate 上執行的 Pod (具有對 AWS 服務的 NAT 閘道存取，但沒有網際網路閘道的直接路由)，因此您叢集的 VPC 必須具有可用的私有子網路。如需沒有傳出網際網路存取權的叢集，請參閱 [部署網際網路存取受到限制的私有叢集](private-clusters.md)。
+ 您可以使用[透過 Vertical Pod Autoscaler 來調整 Pod 資源](vertical-pod-autoscaler.md)為 Fargate Pod 設定 CPU 和記憶體的初始正確大小，然後使用[使用 Horizontal Pod Autoscaler 擴展 Pod 部署](horizontal-pod-autoscaler.md)來擴展這些 Pod。如果要 Vertical Pod Autoscaler 自動將 Pod 重新部署到具有較大 CPU 和記憶體組合的 Fargate，請將 Vertical Pod Autoscaler 的模式設定為 `Auto` 或 `Recreate` 以確保正確的功能。如需詳細資訊，請參閱 GitHub 上的 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) 文件。
+ 您的 VPC 必須啟用 DNS 解析和 DNS 主機名稱。如需詳細資訊，請參閱[檢視與更新 VPC 的 DNS 支援](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)。
+ Amazon EKS Fargate 透過在虛擬機器 (VM) 中隔離每個 Pod，為 Kubernetes 應用程式增加深度防禦功能。此 VM 界限可防止在容器逸出時存取其他 Pod 使用的主機型資源，這是攻擊容器化應用程式並存取容器外資源的常用方法。
使用 Amazon EKS 並不會變更您在[共同責任模式](security.md)下所需承擔的責任。您應該審慎考慮叢集安全性和控管控制項的組態。隔離應用程式最安全的方法是永遠在個別的叢集中執行。
+ Fargate 描述檔支援從 VPC 次要 CIDR 區塊指定子網路。您可能想要指定次要 CIDR 區塊。這是因為子網路僅提供數量有限的 IP 位址。因此，叢集中可建立的 Pod 數量也有限。如果為 Pod 使用不同的子網路，您可增加可用 IP 位址的數量。如需詳細資訊，請參閱[為 VPC 新增 IPv4 CIDR 區塊。](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize)
+ 部署到 Fargate 節點的 Pod 不提供 Amazon EC2 執行個體中繼資料服務 (IMDS)。如果有部署到 Fargate 且需要 IAM 憑證的 Pod，則請使用[服務帳戶的 IAM 角色](iam-roles-for-service-accounts.md)將其指派給 Pod。如果您的 Pod 需要存取 IMDS 提供的其他資訊，則必須將此資訊硬式編碼至 Pod 規格中。這包括部署 Pod 的 AWS 區域或可用區域。
+ 您無法將 Fargate Pod 部署到 AWS Outposts、AWS Wavelength 或 AWS Local Zones。
+ Amazon EKS 必須定期修補 Fargate Pod 來確保其安全。我們嘗試以減少影響的方式進行更新，但有時，如果沒有成功移出 Pod，則必須將其刪除。您可採取一些措施以盡可能地減少中斷。如需詳細資訊，請參閱 [設定 AWS Fargate OS 修補事件的動作](fargate-pod-patching.md)。
+ [適用於 Amazon EKS 的 Amazon VPC CNI 外掛程式](https://github.com/aws/amazon-vpc-cni-plugins)會安裝在 Fargate 叢集上。您無法將[適用於 Amazon EKS 叢集的替代 CNI 外掛程式](alternate-cni-plugins.md)與 Fargate 節點搭配使用。
+ 在 Fargate 上執行的 Pod 會自動掛載 Amazon EFS 檔案系統，而無需執行手動驅動程式安裝步驟。您不能將動態持久性磁碟區佈建與 Fargate 節點搭配使用，但可以使用靜態佈建。
+ Amazon EKS 不支援 Fargate Spot。
+ 您無法將 Amazon EBS 磁碟區掛載到 Fargate Pod。
+ 您可以在 Fargate 節點上執行 Amazon EBS CSI 控制器，但是 Amazon EBS CSI 節點 DaemonSet 僅能在 Amazon EC2 執行個體上執行。
+ 在 [Kubernetes 任務](https://kubernetes.io/docs/concepts/workloads/controllers/job/)標記為 `Completed` 或 `Failed` 之後，任務建立的 Pod 通常會繼續存在。此行為允許您檢視日誌和結果，但使用 Fargate，如果您之後不清理任務，將產生費用。
若要在任務完成或失敗後自動刪除相關的 Pod，您可以使用存留時間 (TTL) 控制器來指定時間間隔。下列範例顯示在您的任務資訊清單中指定 `.spec.ttlSecondsAfterFinished`。
```
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "sleep 10"]
restartPolicy: Never
ttlSecondsAfterFinished: 60 # <-- TTL controller
```
## Fargate 比較表
| 條件 | AWS Fargate |
| --- | --- |
| 可以部署到 [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | 否 |
| 可以部署到 [AWS Local Zone](local-zones.md) | 否 |
| 可以執行需要 Windows 的容器 | 否 |
| 可以執行需要 Linux 的容器 | 是 |
| 可以執行需要 Inferentia 晶片的工作負載 | 否 |
| 可以執行需要 GPU 的工作負載 | 否 |
| 可以執行需要 Arm 處理器的工作負載 | 否 |
| 可以執行 AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | 否 |
| Pod 與其他 Pod 共享核心執行時期環境 | 否：每個 Pod 都有專用核心 |
| Pod 會與其他 Pod 共享 CPU、記憶體、儲存體和網路資源。 | 否：每個 Pod 都有專用資源，可以獨立調整大小，以最大化資源使用率。 |
| Pod 可以使用的硬體和記憶體比 Pod 規格要求的更多 | 否：Pod 可以使用較大的 vCPU 和記憶體組態重新部署。 |
| 必須部署和管理 Amazon EC2 執行個體 | 否 |
| 必須保護、維護和修補 Amazon EC2 執行個體的作業系統 | 否 |
| 可以在部署節點時提供引導引數，例如額外的 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引數。 | 否 |
| 可以將 IP 位址指派給來自不同於將 IP 位址指派給節點之 CIDR 區塊的 Pod。 | 否 |
| 可以對節點執行 SSH | 否：沒有節點主機作業系統可供 SSH 使用。 |
| 可以將自己的自訂 AMI 部署至節點 | 否 |
| 可以將您自己的自訂 CNI 部署至節點 | 否 |
| 必須自行更新節點 AMI | 否 |
| 必須自行更新節點 Kubernetes 版本 | 否：您未管理節點。 |
| 可以透過 Pod 使用 Amazon EBS 儲存體 | 否 |
| 可以透過 Pod 使用 Amazon EFS 儲存體 | [是](efs-csi.md) |
| 可以透過 Pod 使用 Amazon FSx for Lustre 儲存體 | 否 |
| 可以針對服務使用 Network Load Balancer | 是，使用[建立 Network Load Balancer](network-load-balancing.md#network-load-balancer) 時 |
| Pod 可以在公有子網路中執行 | 否 |
| 可以將不同的 VPC 安全群組指派給個別 Pod | 是 |
| 可以執行 Kubernetes DaemonSets | 否 |
| 支援 Pod 資訊清單中的 `HostPort` 和 `HostNetwork` | 否 |
| AWS 區域可用性 | [部分 Amazon EKS 支援的區域](https://docs.aws.amazon.com/general/latest/gr/eks.html) |
| 可以在 Amazon EC2 專用主機上執行容器 | 否 |
| 定價 | 獨立 Fargate 記憶體和 CPU 組態的成本。每個 Pod 都有自己的成本。如需詳細資訊，請參閱 [AWS Fargate 定價](https://aws.amazon.com/fargate/pricing/)。 |
# 為您的叢集開始使用 AWS Fargate
本主題說明如何開始使用 Amazon EKS 叢集在 AWS Fargate 上執行 Pod。
如果使用 CIDR 區塊限制對叢集公有端點的存取，則建議您也啟用私有端點存取。這樣一來，Fargate Pod 即可與叢集通訊。若不啟用私有端點，您指定用於公有存取的 CIDR 區塊必須包含來自 VPC 的傳出來源。如需詳細資訊，請參閱[叢集 API 伺服器端點](cluster-endpoint.md)。
**先決條件**
現有的叢集。如果還沒有 Amazon EKS 叢集，請參閱 [開始使用 Amazon EKS](getting-started.md)。
## 步驟 1：確認現有節點可以與 Fargate Pod 進行通訊
如果正在使用無節點的新叢集，或叢集只有受管節點群組 (請參閱 [透過受管節點群組來簡化節點生命週期](managed-node-groups.md))，您可以跳至 [步驟 2：建立 Fargate Pod 執行角色](#fargate-sg-pod-execution-role)。
假設您正在使用的現有叢集已經具有與其相關聯的節點。請確保在這些節點上的 Pod 可以自由地與在 Fargate 上執行的 Pod 進行通訊。在 Fargate 上執行的 Pod 會自動設定為使用其相關聯之叢集的叢集安全群組。請務必確認叢集中的任何現有節點可以傳送與接收叢集安全群組的流量。受管節點群組也會自動設定為使用叢集安全群組，因此您不需要為此相容性修改或檢查它們 (請參閱 [透過受管節點群組來簡化節點生命週期](managed-node-groups.md))。
對於使用 `eksctl`或 Amazon EKS Managed AWS CloudFormation 範本建立的現有節點群組，您可以將叢集安全群組手動新增至節點。您還可以修改節點群組的 Auto Scaling 群組啟動範本，從而將叢集安全群組連接至執行個體。如需詳細資訊，請參閱《*Amazon VPC 使用者指南*》中的[變更執行個體的安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership)。
您可以在叢集**的網路**區段 AWS 管理主控台 下的 中，檢查叢集的安全群組。或者，您可以使用下列 CLI AWS 命令來執行此操作。使用此命令時，請以您叢集的名稱取代 ``。
```
aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
## 步驟 2：建立 Fargate Pod 執行角色
當您的叢集在 AWS Fargate 上建立 Pod 時，在 Fargate 基礎設施上執行的元件必須代表您呼叫 AWS APIs。Amazon EKS Pod 執行角色提供進行此類工作的 IAM 許可。若要建立 AWS Fargate Pod 執行角色，請參閱 [Amazon EKS Pod 執行 IAM 角色](pod-execution-role.md)。
**注意**
如果您使用 `--fargate` 選項以 `eksctl` 建立叢集，則您的叢集已擁有 Pod 執行角色，您可以在 IAM 主控台中使用模式 `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL` 找到該角色。同樣地，如果您使用 `eksctl` 建立 Fargate 設定檔，`eksctl` 將建立 Pod 執行角色 (如果該角色尚未建立)。
## 步驟 3：為您的叢集建立 Fargate 設定檔
您必須定義 Fargate 設定檔，指定哪些 Pod 在啟動時使用 Fargate，然後才能排程在叢集 Fargate 上執行的 Pod。如需詳細資訊，請參閱[定義哪些 Pod 在啟動時會使用 AWS Fargate](fargate-profile.md)。
**注意**
若您使用 `--fargate` 選項以 `eksctl` 建立叢集，則您叢集的 Fargate 設定檔已建立完成，並包含在 `kube-system` 和 `default` 命名空間中所有 Pod 的選取器。使用下列程序來為您想要搭配 Fargate 使用的任何其他命名空間建立 Fargate 描述檔。
您可以使用下列任一工具建立 Fargate 設定檔：
+ [`eksctl`](#eksctl_fargate_profile_create)
+ [AWS 管理主控台](#console_fargate_profile_create)
### `eksctl`
此程序需要 `eksctl` 版本 `0.215.0` 或更新版本。您可使用以下命令檢查您的版本：
```
eksctl version
```
如需有關安裝或更新 `eksctl` 的指示，請參閱 `eksctl` 文件中的 [Installation](https://eksctl.io/installation) 一節。
**若要使用 `eksctl` 建立 Fargate 設定檔**
使用以下 `eksctl` 命令建立您的 Fargate 設定檔，並以您自己的值取代每一個 ``。您必須指定一個命名空間。不過，`--labels` 選項並非必要項目。
```
eksctl create fargateprofile \
--cluster \
--name \
--namespace \
--labels
```
對於 `` 和 `` 標籤可以使用某些萬用字元。如需詳細資訊，請參閱[Fargate 設定檔萬用字元](fargate-profile.md#fargate-profile-wildcards)。
### AWS 管理主控台
**若要使用 AWS 管理主控台 建立 Fargate 設定檔**
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇要為其建立 Fargate 設定檔的叢集。
1. 選擇 **Compute** (運算) 索引標籤。
1. 在 **Fargate profiles** (Fargate 設定檔) 下，選擇 **Add Fargate profile** (新增 Fargate 設定檔)。
1. 在 **Configure Fargate profile** (設定 Fargate 設定檔) 頁面上，執行以下操作：
1. 對於 **Name** (名稱)，輸入您 Fargate 描述檔的名稱。名稱必須是唯一的。
1. 對於 **Pod 執行角色**，請選擇要搭配您的 Fargate 設定檔使用的 Pod 執行角色。只會顯示具有 `eks-fargate-pods.amazonaws.com` 服務委託人的 IAM 角色。如果未列出任何角色，您必須建立一個。如需詳細資訊，請參閱[Amazon EKS Pod 執行 IAM 角色](pod-execution-role.md)。
1. 視需要修改選取的**子網路**。
**注意**
只有私有子網路支援在 Fargate 上執行的 Pod。
1. 對於 **Tags** (標籤)，您可以選擇標記 Fargate 設定檔。這些標籤不會傳播至與設定檔相關聯的其他資源，例如 Pod。
1. 選擇**下一步**。
1. 在**設定 Pod 選擇**頁面上，執行以下作業：
1. 針對**命名空間**，輸入與 Pod 相符的命名空間。
+ 您可以使用特定的命名空間進行比對，例如 `kube-system` 或 `default`。
+ 您可以使用某些萬用字元 (例如 `prod-*`) 來比對多個命名空間 (例如 `prod-deployment` 和 `prod-test`)。如需詳細資訊，請參閱[Fargate 設定檔萬用字元](fargate-profile.md#fargate-profile-wildcards)。
1. (選用) 將 Kubernetes 標籤新增至選取器。將其特別新增至需與特定命名空間中的 Pod 相符的選取器。
+ 您可以將標籤 `infrastructure: fargate` 新增至選取器，因此只有在也有 `infrastructure: fargate` Kubernetes 標籤之指定命名空間中的 Pod 與選取器相符。
+ 您可以使用某些萬用字元 (例如 `key?: value?`) 來比對多個命名空間 (例如 `keya: valuea` 和 `keyb: valueb`)。如需詳細資訊，請參閱[Fargate 設定檔萬用字元](fargate-profile.md#fargate-profile-wildcards)。
1. 選擇**下一步**。
1. 在 **Review and create** (檢閱和建立) 頁面，檢閱您 Fargate 設定檔的資訊並選擇 **Create** (建立)。
## 步驟 4：更新 CoreDNS
CoreDNS 預設為在 Amazon EKS 叢集上的 Amazon EC2 基礎設施上執行。若您希望*僅*在叢集的 Fargate 上執行 Pod，請完成以下步驟。
**注意**
如果透過 `--fargate` 選項使用 `eksctl` 建立叢集，您可以直接跳至 [後續步驟](#fargate-gs-next-steps)。
1. 使用下列命令來刪除 CoreDNS 的 Fargate 設定檔。使用您的叢集名稱取代 ``、使用您的帳戶 ID 取代 `<111122223333>`、使用您的 Pod 執行角色名稱取代 ``，並使用私有子網路的 ID 取代 `<000000000000000a>`、`<000000000000000b>` 和 `<000000000000000c>`。若沒有 Pod 執行角色，則必須先建立一個 (請參閱 [步驟 2：建立 Fargate Pod 執行角色](#fargate-sg-pod-execution-role))。
**重要**
角色 ARN 不能包含 `/` 之外的[路徑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names)。例如，如果您的角色名稱是 `development/apps/AmazonEKSFargatePodExecutionRole`，則您必須在指定角色的 ARN 時將其變更為 `AmazonEKSFargatePodExecutionRole`。角色 ARN 的格式必須是 ` arn:aws: iam::<111122223333>:role/`。
```
aws eks create-fargate-profile \
--fargate-profile-name coredns \
--cluster-name \
--pod-execution-role-arn arn:aws: iam::<111122223333>:role/ \
--selectors namespace=kube-system,labels={k8s-app=kube-dns} \
--subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c>
```
1. 觸發 `coredns` 部署的推展。
```
kubectl rollout restart -n kube-system deployment coredns
```
## 後續步驟
+ 您可以透過以下工作流程開始遷移現有的應用程式，以在 Fargate 上執行。
1. [建立 Fargate 設定檔](fargate-profile.md#create-fargate-profile)，與您的應用程式的 Kubernetes 命名空間和 Kubernetes 標籤相符。
1. 刪除並重建新立任何現有 Pod，以便在 Fargate 上對其進行排程。修改 `` 和 ``，以更新您的特定 Pod。
```
kubectl rollout restart -n deployment
```
+ 部署 [透過 Application Load Balancer 路由應用程式與 HTTP 流量](alb-ingress.md) 來允許您在 Fargate 執行的 Pod 輸入物件。
+ 您可以使用 [透過垂直 Pod 自動擴展器來調整 Pod 資源](vertical-pod-autoscaler.md) 為 Fargate Pod 設定 CPU 和記憶體的初始正確大小，然後使用 [使用 Horizontal Pod Autoscaler 擴展 Pod 部署](horizontal-pod-autoscaler.md) 來擴展這些 Pod。若要讓 Vertical Pod Autoscaler 自動將 Pod 重新部署到具有較高 CPU 和記憶體組合的 Fargate，請將 Vertical Pod Autoscaler 的模式設定為 `Auto` 或 `Recreate`。這是為了確認功能可以運作正確。如需詳細資訊，請參閱 GitHub 上的 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) 文件。
+ 請遵循[以下說明](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html)設定 [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel) (ADOT) 收集器，以便監控應用程式。
# 定義哪些 Pod 在啟動時會使用 AWS Fargate
您必須定義至少一個 Fargate 設定檔，指定哪些 Pod 在啟動時使用 Fargate，才能排程您叢集中 Fargate 上的 Pod。
管理員可以使用 Fargate 設定檔宣告哪些 Pod 要在 Fargate 上執行。您可以透過設定檔的選取器來執行此操作。您最多可以將五個選取器新增至每個設定檔。每個選取器必須包含一個命名空間。選取器還可以包括標籤。標籤欄位由多個選用鍵/值對組成。與選取器相符的 Pod 會排程在 Fargate 上執行。比對 Pod 時，會使用命名空間和在選取器中指定的標籤。如果命名空間選取器未以標籤定義，Amazon EKS 會嘗試使用設定檔，將以該命名空間執行的所有 Pod 排程至 Fargate。如果要排程的 Pod 符合 Fargate 設定檔中的任一選取器，則該 Pod 會在 Fargate 上排程。
如果 Pod 與多個 Fargate 設定檔相符，您可以將下列 Kubernetes 標籤新增至 Pod 規格，以指定 Pod 使用哪個設定檔：`eks.amazonaws.com/fargate-profile: my-fargate-profile`。Pod 必須與該設定檔中的選取器相符，才能排程至 Fargate。Kubernetes 親和性/反親和性規則不適用，並且對 Amazon EKS Fargate Pod 而言也非必要。
建立 Fargate 設定檔時，您必須指定 Pod 執行角色。此執行角色適用於使用設定檔在 Fargate 基礎設施上執行的 Amazon EKS 元件。其會新增至叢集的 Kubernetes [角色型存取控制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC)，以進行身分授權。這樣一來，在 Fargate 基礎設施上執行的 `kubelet` 就可以註冊到您的 Amazon EKS 叢集，並作為節點出現在您的叢集中。Pod 執行角色也為 Fargate 基礎結構提供 IAM 許可，以允許對 Amazon ECR 映像儲存庫的讀取存取權。如需詳細資訊，請參閱 [Amazon EKS Pod 執行 IAM 角色](pod-execution-role.md)。
Fargate 設定檔無法變更。不過，您可以建立新的已更新設定檔來取代現有設定檔，然後刪除原始的設定檔。
**注意**
刪除設定檔時，使用 Fargate 設定檔執行的任何 Pod 將停止並進入待定狀態。
如果在叢集中的任何 Fargate 設定檔處於 `DELETING` 狀態，您必須等候該 Fargate 設定檔刪除後，才能在該叢集建立任何其他設定檔。
**注意**
Fargate 目前不支援 Kubernetes [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)。
Amazon EKS 和 Fargate 會嘗試在 Fargate 設定檔所定義的每個子網路中散佈 Pod。不過，最終可能會產生不均勻的散佈結果。如果必須產生均勻的散佈結果，請使用兩個 Fargate 設定檔。在您想要部署兩個複本且不希望任何停機時間的情況下，均勻的散佈結果相當重要。我們建議每個設定檔只定義一個子網路。
## Fargate 描述檔元件
下列元件包含在 Fargate 描述檔中。
**Pod 執行角色**
當您的叢集在 AWS Fargate 上建立 Pod 時，在 Fargate 基礎結構上執行的 `kubelet` 必須代表您呼叫 AWS API。例如，它必須透過呼叫從 Amazon ECR 提取容器映像。Amazon EKS Pod 執行角色提供進行此類工作的 IAM 許可。
建立 Fargate 設定檔時，您必須指定要搭配 Pod 使用的 Pod 執行角色。此角色會新增至叢集的 Kubernetes [角色型存取控制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC)，以進行身分授權。這是為了讓在 Fargate 基礎結構上執行的 `kubelet` 可以註冊到您的 Amazon EKS 叢集並作為節點出現在您的叢集中。如需詳細資訊，請參閱 [Amazon EKS Pod 執行 IAM 角色](pod-execution-role.md)。
**子網路**
要在其中啟動 Pod 並使用該設定檔的子網路 ID。目前不會對在 Fargate 上執行的 Pod 指派公有 IP 位址。因此，此參數僅接受私有子網路 (不具網際網路閘道的直接路由)。
**選取器**
要與 Pod 相符的選取器，以使用此 Fargate 設定檔。您最多可在一個 Fargate 設定檔中指定五個選取器。選取器具有下列元件：
+ **命名空間**：您必須指定選取器的命名空間。選取器僅與在此命名空間中建立的 Pod 相符。不過，您可以建立多個選取器來定義多個命名空間。
+ **標籤**：您可以選擇指定符合選取器的 Kubernetes 標籤。選取器僅與擁有在選取器中指定之所有標籤的 Pod 相符。
## Fargate 設定檔萬用字元
除了 Kubernetes 允許的字元之外，您還可以在命名空間、標籤索引鍵和標籤值的選取器條件中使用 `*` 和 `?`：
+ `*` 代表無、一個或多個字元。例如，`prod*` 可以代表 `prod` 和 `prod-metrics`。
+ `?` 代表單一字元 (例如，`value?` 可以代表 `valuea`)。不過，它不能代表 `value` 和 `value-a`，因為 `?` 只能代表確切一個字元。
這些萬用字元適用於任何位置和組合 (例如，`prod*`、`*dev`，以及 `frontend*?`)。其他萬用字元和模式比對形式 (例如規則運算式) 則不支援。
如果 Pod 規格中的命名空間和標籤有多個相符的設定檔，Fargate 會根據設定檔名稱的英數字元排序選擇設定檔。例如，如果設定檔 A (名稱為 `beta-workload`) 和設定檔 B (名稱為 `prod-workload`) 都具有要啟動的 Pod 的相符選取器，則 Fargate 將為 Pod 選擇設定檔 A (`beta-workload`)。Pod 在 Pod 上具有含設定檔 A 的標籤 (例如，`eks.amazonaws.com/fargate-profile=beta-workload`)。
如果您想要將現有的 Fargate Pod 移轉至使用萬用字元的新設定檔，有兩種方法：
+ 使用相符的選取器建立新的設定檔，然後刪除舊設定檔。標有舊設定檔的 Pod 會重新排程為新的相符設定檔。
+ 如果您想要移轉工作負載，但不確定每個 Fargate Pod 上有哪些 Fargate 標籤，則可使用以下方法。建立新的設定檔，其名稱在同一叢集上的設定檔中按英數字元順序排列在第一位。然後，回收需要移轉到新設定檔的 Fargate Pod。
## 建立 Fargate 設定檔
本節說明如何建立 Fargate 設定檔。您還必須建立用於 Fargate 設定檔的 Pod 執行角色。如需詳細資訊，請參閱 [Amazon EKS Pod 執行 IAM 角色](pod-execution-role.md)。只有私有子網路支援在 Fargate 上執行的 Pod (具有對 AWS 服務的 [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)存取，但沒有網際網路閘道的直接路由)。因此，您叢集的 VPC 必須具有可用的私有子網路。
您可以執行下列操作來建立設定檔：
+ [`eksctl`](#eksctl_create_a_fargate_profile)
+ [AWS 管理主控台](#console_create_a_fargate_profile)
## `eksctl`
**若要使用 `eksctl` 建立 Fargate 設定檔**
使用下列 `eksctl` 命令建立您的 Fargate 設定檔，並以您自己的值取代每一個範例值。您必須指定一個命名空間。不過，`--labels` 選項並非必要項目。
```
eksctl create fargateprofile \
--cluster my-cluster \
--name my-fargate-profile \
--namespace my-kubernetes-namespace \
--labels key=value
```
對於 `my-kubernetes-namespace` 和 `key=value` 標籤可以使用某些萬用字元。如需詳細資訊，請參閱 [Fargate 設定檔萬用字元](#fargate-profile-wildcards)。
## AWS 管理主控台
**若要使用 AWS 管理主控台 建立 Fargate 設定檔**
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 選擇要為其建立 Fargate 設定檔的叢集。
1. 選擇 **Compute** (運算) 索引標籤。
1. 在 **Fargate profiles** (Fargate 設定檔) 下，選擇 **Add Fargate profile** (新增 Fargate 設定檔)。
1. 在 **Configure Fargate profile** (設定 Fargate 設定檔) 頁面上，執行以下作業：
1. 對於 **Name** (名稱)，輸入 Fargate 設定檔的唯一名稱，例如 `my-profile`。
1. 對於 **Pod 執行角色**，請選擇要搭配您的 Fargate 設定檔使用的 Pod 執行角色。只會顯示具有 `eks-fargate-pods.amazonaws.com` 服務委託人的 IAM 角色。如果未列出任何角色，您必須建立一個。如需詳細資訊，請參閱 [Amazon EKS Pod 執行 IAM 角色](pod-execution-role.md)。
1. 視需要修改選取的**子網路**。
**注意**
只有私有子網路支援在 Fargate 上執行的 Pod。
1. 對於 **Tags** (標籤)，您可以選擇標記 Fargate 設定檔。這些標籤不會傳播至與設定檔相關聯的其他資源，例如 Pod。
1. 選擇**下一步**。
1. 在**設定 Pod 選擇**頁面上，執行以下作業：
1. 針對**命名空間**，輸入與 Pod 相符的命名空間。
+ 您可以使用特定的命名空間進行比對，例如 `kube-system` 或 `default`。
+ 您可以使用某些萬用字元 (例如 `prod-*`) 來比對多個命名空間 (例如 `prod-deployment` 和 `prod-test`)。如需詳細資訊，請參閱 [Fargate 設定檔萬用字元](#fargate-profile-wildcards)。
1. (選用) 將 Kubernetes 標籤新增至選取器。將其特別新增至需與特定命名空間中的 Pod 相符的選取器。
+ 您可以將標籤 `infrastructure: fargate` 新增至選取器，因此只有在也有 `infrastructure: fargate` Kubernetes 標籤之指定命名空間中的 Pod 與選取器相符。
+ 您可以使用某些萬用字元 (例如 `key?: value?`) 來比對多個命名空間 (例如 `keya: valuea` 和 `keyb: valueb`)。如需詳細資訊，請參閱 [Fargate 設定檔萬用字元](#fargate-profile-wildcards)。
1. 選擇**下一步**。
1. 在 **Review and create** (檢閱和建立) 頁面，檢閱您 Fargate 設定檔的資訊並選擇 **Create** (建立)。
# 刪除 Fargate 描述檔
本主題說明如何刪除 Fargate 設定檔。當您刪除 Fargate 描述檔時，使用描述檔排程至 Fargate 的任何 Pod 都會遭到刪除。若這些 Pod 符合其他 Fargate 設定檔，其便會使用該設定檔在 Fargate 上排程。如果其不再符合任何 Fargate 設定檔，則不會排程至 Fargate，且可能仍為待定狀態。
一個叢集中一次只能有一個 Fargate 描述檔可以處於 `DELETING` 狀態。請等候 Fargate 描述檔完成刪除動作，才可以刪除該叢集中的任何其他描述檔。
您可以使用以下任何工具刪除設定檔：
+ [`eksctl`](#eksctl_delete_a_fargate_profile)
+ [AWS 管理主控台](#console_delete_a_fargate_profile)
+ [AWS CLI](#awscli_delete_a_fargate_profile)
## `eksctl`
**使用 `eksctl` 刪除 Fargate 設定檔**
使用下列命令從叢集刪除設定檔。使用您自己的值取代每一個*範例值*。
```
eksctl delete fargateprofile --name my-profile --cluster my-cluster
```
## AWS 管理主控台
**使用 AWS 管理主控台 刪除 Fargate 設定檔**
1. 開啟 [Amazon EKS 主控台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左側導覽窗格中選擇**叢集**。在叢集清單中，選擇您要從中刪除 Fargate 設定檔的叢集。
1. 選擇 **Compute** (運算) 索引標籤。
1. 選擇要刪除的 Fargate 設定檔，然後選擇 **Delete** (刪除)。
1. 在 **Delete Fargate profile** (刪除 Fargate 設定檔) 頁面上，輸入設定檔名稱，然後選擇 **Delete** (刪除)。
## AWS CLI
**使用 AWS CLI 刪除 Fargate 設定檔**
使用下列命令從叢集刪除設定檔。使用您自己的值取代每一個*範例值*。
```
aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster
```
# 了解 Fargate Pod 組態詳細資訊
本節會描述部分適用於在 AWS Fargate 上執行 Kubernetes Pod 的專用 Pod 組態詳細資訊。
## Pod CPU 和記憶體
透過 Kubernetes，您可定義請求、最低 vCPU 數量，以及配置給 Pod 中每個容器的記憶體資源。Pod 是由 Kubernetes 排程，以確保至少每個 Pod 的請求資源可在運算資源上使用。如需詳細資訊，請參閱 Kubernetes 文件中的[管理容器的運算資源](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)。
**注意**
由於 Amazon EKS Fargate 的每個節點僅會執行一個 Pod，因此不會發生在資源較少的情況下將 Pod 移出的情況。所有 Amazon EKS Fargate Pod 都是以保證優先順序的方式執行，因此請求的 CPU 和記憶體必須等同於所有容器的限制。如需詳細資訊，請參閱《Kubernetes 說明文件》中的[設定 Pod 的服務品質](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)。
當 Pod 在 Fargate 上排程時，在 Pod 規格內的 vCPU 與記憶體保留決定了多少 CPU 和記憶體會佈建給 Pod。
+ 任何 Init 容器的最大請求用於判斷 Init 請求 vCPU 和記憶體需求。
+ 所有長期執行容器的請求會加總，以判斷長期執行請求 vCPU 和記憶體需求。
+ 先前兩個值中較大的值會選擇作為用於您 Pod 的 vCPU 和記憶體請求。
+ Fargate 會將 256 MB 新增至所需 Kubernetes 元件之每個 Pod 的記憶體保留 (`kubelet`、`kube-proxy` 和 `containerd`)。
Fargate 會四捨五入至以下最接近 vCPU 和記憶體請求總和的運算組態，以確保 Pod 隨時擁有其執行所需的資源。
若您未指定 vCPU 和記憶體的組合，則會使用最小可用的組合 (0.25 個 vCPU 和 0.5 GB 記憶體)。
下表顯示可用於在 Fargate 上執行之 Pod 的 vCPU 和記憶體組合。
| vCPU 數值 | 記憶體數值 |
| --- | --- |
| .25 vCPU | 0.5 GB、1 GB、2 GB |
| .5 vCPU | 1 GB、2 GB、3 GB、4 GB |
| 1 vCPU | 2 GB、3 GB、4 GB、5 GB、6 GB、7 GB、8 GB |
| 2 vCPU | 介於 4 GB 與 16 GB 之間，以 1 GB 為單位遞增 |
| 4 vCPU | 介於 8 GB 與 30 GB 之間，以 1 GB 為單位遞增 |
| 8 vCPU | 介於 16 GB 與 60 GB 之間，以 4 GB 為單位遞增 |
| 16 vCPU | 介於 32 GB 與 120 GB 之間，以 8 GB 為單位遞增 |
為 Kubernetes 元件預訂的額外記憶體，可能會導致 Fargate 任務佈建了超出原先請求數量的 vCPU。例如，對 1 個 vCPU 和 8 GB 記憶體的請求將會新增 256 MB 至其記憶體請求，並且會佈建具有 2 個 vCPU 和 9 GB 記憶體的 Fargate 任務，因為沒有任何具有 1 個 vCPU 和 9 GB 記憶體的可用任務。
在 Fargate 上執行的 Pod 大小與 Kubernetes 使用 `kubectl get nodes` 報告的節點大小之間沒有相關性。報告的節點大小通常大於 Pod 的容量。您可以使用下列命令確認 Pod 容量。以您 Pod 的命名空間來取代*預設*，並以您 Pod 的名稱來取代 *pod-name*。
```
kubectl describe pod --namespace default pod-name
```
範例輸出如下。
```
[...]
annotations:
CapacityProvisioned: 0.25vCPU 0.5GB
[...]
```
`CapacityProvisioned` 註釋代表強制執行的 Pod 容量，並決定在 Fargate 上執行 Pod 的成本。如需運算組態的定價資訊，請參閱 [AWS Fargate 定價](https://aws.amazon.com/fargate/pricing/)。
## Fargate 儲存
在 Fargate 上執行的 Pod 會自動掛載 Amazon EFS 檔案系統，而無需執行手動驅動程式安裝步驟。您不能將動態持久性磁碟區佈建與 Fargate 節點搭配使用，但可以使用靜態佈建。如需詳細資訊，請參閱 GitHub 上的 [Amazon EFS CSI 驅動程式](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md)。
佈建時，在 Fargate 上執行的每個 Pod 均會收到預設 20 GiB 的暫時性儲存。此類型的儲存會在 Pod 停止後刪除。在 Fargate 上啟動的新 Pod，預設皆會啟用暫時性儲存磁碟區的加密。暫時性 Pod 儲存會以使用 AWS Fargate 受管金鑰的 AES-256 加密演算法來加密。
**注意**
在 Fargate 上執行的 Amazon EKS Pod 預設可用儲存空間少於 20 GiB。這是因為部分空間由 Pod 內部載入的 `kubelet` 和其他 Kubernetes 模組使用。
您可以增加暫時性儲存的總量，最多可達 175 GiB。若要使用 Kubernetes 設定大小，請將 `ephemeral-storage` 資源的請求指定到 Pod 中的每個容器。當 Kubernetes 排程了 Pod，它可以確保每個 Pod 的資源請求總計少於 Fargate 任務的容量。如需詳細資訊，請參閱 Kubernetes 文件中的 [Pod 和容器的資源管理](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)。
Amazon EKS Fargate 佈建的暫時性儲存空間比系統使用目的之要求更多。例如，100 GiB 的請求將佈建具有 115 GiB 暫時性儲存的 Fargate 任務。
# 設定 AWS Fargate OS 修補事件的動作
Amazon EKS 會定期修補 AWS Fargate 節點的 OS 來確保節點的安全。作為修補程序的一部分，我們會回收節點以安裝作業系統修補程式。以對您的服務產生最小影響的方式嘗試更新。但是，如果未成功移出 Pod，有時必須將其刪除。您可以採取以下措施，以最大限度地減少潛在的中斷：
+ 設定適當的 Pod 中斷預算 (PDB)，以控制同時關閉的 Pod 數量。
+ 建立 Amazon EventBridge 規則，以便在刪除 Pod 之前處理失敗的移出事件。
+ 在您收到的通知中發布的移出日期之前，手動重新啟動受影響的 Pod。
+ 在 AWS 使用者通知中建立通知組態。
Amazon EKS 與 Kubernetes 社群密切合作，以盡快提供錯誤修復和安全修補程式。所有 Fargate Pod 均從最新的 Kubernetes 修補程式版本開始，該修補程式版本可從 Amazon EKS 取得，用於您叢集的 Kubernetes 版本。若您的 Pod 具有較舊的修補程式版本，Amazon EKS 可能會予以回收，以將其更新到最新版本。這可確保您的 Pod 配備了最新的安全更新。這樣，如果有一個關鍵 [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVE) 問題，您將隨時了解最新資訊，以降低安全風險。
更新 AWS Fargate OS 時，Amazon EKS 會傳送通知給您，其中包括受影響的資源和即將移出 Pod 的日期。如果提供的移出日期不方便，您可以選擇在通知中發布的移出日期之前，手動重新啟動受影響的 Pod。在您收到通知之前建立的任何 Pod 都會被移出。如需如何手動重新啟動 Pod 的進一步指示，請參閱 [Kubernetes 文件](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart)。
若要限制在回收 Pod 時同時關閉的 Pod 數量，您可以設定 Pod 中斷預算 (PDB)。您可以使用 PDB 根據每個應用程式的要求定義最低可用性，同時仍允許進行更新。PDB 的最低可用性必須小於 100%。如需詳細資訊，請參閱 Kubernetes 文件中的[為應用程式指定中斷預算](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)。
Amazon EKS 使用[移出 API](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) 以安全地消耗 Pod，同時尊重您為應用程式設定的 PDB。可用區域將 Pod 移出，以最大限度地減少影響。如果移出成功，新 Pod 將會取得最新的修補程式，且無須採取進一步的動作。
當 Pod 的移出失敗時，Amazon EKS 會向您的帳戶傳送一個事件，其中包含有關移出失敗的 Pod 的詳細資訊。您可以在計劃終止時間之前對訊息執行操作。具體時間根據修補程式的緊迫性而有所不同。到了該時間時，Amazon EKS 會再次嘗試移出 pod。但是，這次如果移出失敗，則不會傳送新事件。如果移出再次失敗，則會定期刪除現有的 Pod，以便新 Pod 具有最新的修補程式。
以下是當 Pod 移出失敗時收到的範例事件。其中包含有關叢集、Pod 名稱、Pod 命名空間、Fargate 設定檔和計劃終止時間的詳細資訊。
```
{
"version": "0",
"id": "12345678-90ab-cdef-0123-4567890abcde",
"detail-type": "EKS Fargate Pod Scheduled Termination",
"source": "aws.eks",
"account": "111122223333",
"time": "2021-06-27T12:52:44Z",
"region": "region-code",
"resources": [
"default/my-database-deployment"
],
"detail": {
"clusterName": "my-cluster",
"fargateProfileName": "my-fargate-profile",
"podName": "my-pod-name",
"podNamespace": "default",
"evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget",
"scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]"
}
}
```
此外，將多個 PDB 與 Pod 關聯可能會導致移出失敗事件。此事件傳回以下錯誤訊息。
```
"evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support",
```
您可以根據此事件建立所需的動作。例如，您可以調整 Pod 中斷預算 (PDB)，以控制如何移出 Pod。更具體地說，假設您從指定可用 Pod 的目標百分比的 PDB 開始。在升級期間強制終止 Pod 之前，您可以將 PDB 調整為不同百分比的 Pod。若要接收此事件，您必須在叢集所屬的 AWS 帳戶和 AWS 區域中建立 Amazon EventBridge 規則。規則必須使用以下**自訂模式**。如需詳細資訊，請參閱*《Amazon EventBridge 使用者指南》*中的[建立對事件做出反應的 Amazon EventBridge 規則](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)。
```
{
"source": ["aws.eks"],
"detail-type": ["EKS Fargate Pod Scheduled Termination"]
}
```
可以為事件設定合適的目標以進行擷取。如需可用目標的完整清單，請參閱*《Amazon EventBridge 使用者指南》*中的 [Amazon EventBridge 目標](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)。您也可以在 AWS 使用者通知中建立通知組態。使用 AWS 管理主控台 建立通知時，請在**事件規則**下，選擇 **Elastic Kubernetes Service (EKS)** 作為 **AWS 服務名稱**，並選擇 **EKS Fargate Pod 排程終止** 作為**事件類型**。如需詳細資訊，請參閱《AWS 使用者通知使用者指南》中的 [AWS 使用者通知入門](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html)。
如需有關 EKS Pod 移出的常見問答集，請參閱 * AWS re:Post* 中的[常見問答集：Fargate Pod 移出通知](https://repost.aws/knowledge-center/fargate-pod-eviction-notice)。
# 收集 AWS Fargate 應用程式和用量指標
您可以收集 AWS Fargate 的系統指標和 CloudWatch 用量指標。
## 應用程式指標
對於在 Amazon EKS 和 AWS Fargate 上執行的應用程式，您可以使用 AWS Distro for OpenTelemetry (ADOT)。ADOT 允許您收集系統指標並將其傳送到 CloudWatch Container Insights 儀表板。若要在 Fargate 上執行的應用程式開始使用 ADOT，請參閱 ADOT 文件中的[使用 CloudWatch Container Insights 搭配 AWS Distro for OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights)。
## 用量指標
您可以使用 CloudWatch 用量指標來了解您帳戶的資源用量。使用這些指標，以 CloudWatch 圖表和儀表板視覺化目前的服務使用狀況。
AWS Fargate 用量指標對應至 AWS 服務配額。您可以設定警示，在您的用量接近服務配額時發出警示。如需 Fargate 的服務配額詳細資訊，請參閱 [檢視與管理 Amazon EKS 和 Fargate 服務配額](service-quotas.md)。
AWS Fargate 會在 ` AWS/Usage` 命名空間中發佈下列指標。
| 指標 | Description |
| --- | --- |
| `ResourceCount` | 您的帳戶中正在執行的特定資源總數。資源由與指標相關聯的維度定義。 |
下列維度用於精簡 AWS Fargate 發佈的用量指標。
| 維度 | Description |
| --- | --- |
| `Service` | 包含資源 AWS 的服務名稱。對於 AWS Fargate 用量指標，此維度的值為 `Fargate`。 |
| `Type` | 正在報告的實體類型。目前， AWS Fargate 用量指標的唯一有效值為 `Resource`。 |
| `Resource` | 正在執行的資源類型。 目前， AWS Fargate 會傳回 Fargate 隨需用量的相關資訊。Fargate 隨需用量的資源值為 `OnDemand`。 [注意] ==== Fargate 隨需用量結合了使用 Fargate 的 Amazon EKS Pod、使用 Fargate 啟動類型的 Amazon EKS 任務，以及使用 `FARGATE` 容量提供者的 Amazon ECS 任務。 ==== |
| `Class` | 正在追蹤的資源類別。目前， AWS Fargate 不使用類別維度。 |
### 建立 CloudWatch 警示來監控 Fargate 資源用量指標
AWS Fargate 提供對應至 Fargate 隨需資源用量 AWS 服務配額的 CloudWatch 用量指標。在 Service Quotas 主控台中，您可以在圖表上一目了然地查看使用情況。您也可以設定警示，在您的用量接近服務配額時發出警示。如需詳細資訊，請參閱[收集 AWS Fargate 應用程式和用量指標](#monitoring-fargate-usage)。
使用下列步驟，根據其中一個 Fargate 資源用量指標來建立 CloudWatch 警示。
1. 開啟 Service Quotas 主控台，網址為 https://console.aws.amazon.com/servicequotas/。
1. 在左側導覽窗格中，選擇 ** AWS 服務**。
1. 從** AWS 服務**清單中，搜尋並選取 ** AWS Fargate**。
1. 在 **Service quotas** (服務配額) 清單中，選擇您要為其建立警示的 Fargate 用量配額。
1. 在 Amazon CloudWatch alarms (Amazon CloudWatch 警示) 區段中，選擇 **Create** (建立)。
1. 針對 **Alarm threshold (警示閾值)**，選擇您想要多少百分比的套用配額值設為警示值。
1. 針對 **Alarm name (警示名稱)**，輸入警示的名稱，然後選擇 **Create (建立)**。
# 為您的叢集啟動 AWS Fargate 記錄
Amazon EKS on Fargate 提供了基於 Fluent Bit 的內建日誌路由器。這表示您沒有明確地執行 Fluent Bit 容器以作為附屬，但 Amazon 會為您執行。您只需設定日誌路由器即可。組態會透過必須符合以下條件的專用 `ConfigMap` 生效：
+ 名稱 `aws-logging`
+ 在名為 `aws-observability` 的專用命名空間中建立
+ 不可超過 5300 個字元。
一旦建立了 `ConfigMap`，Amazon EKS on Fargate 會使用其自動偵測並設定日誌路由器。Fargate 使用 Fluent Bit 的 AWS 版本，是由 AWS 管理的 Fluent Bit 上游合規發行版本。如需詳細資訊，請參閱 GitHub 上的[適用於 Fluent Bit 的 AWS](https://github.com/aws/aws-for-fluent-bit)。
日誌路由器可讓您使用 AWS 服務廣度進行日誌分析和儲存。您可以直接將日誌從 Fargate 串流至 Amazon CloudWatch 和 Amazon OpenSearch Service。您也可以透過 [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/) 將日誌串流至 [Amazon S3](https://aws.amazon.com/s3/)、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 與合作夥伴工具等目的地。
+ 指定您部署 Fargate Pod 的現有 Kubernetes 命名空間的現有 Fargate 設定檔。如需詳細資訊，請參閱 [步驟 3：為您的叢集建立 Fargate 設定檔](fargate-getting-started.md#fargate-gs-create-profile)。
+ 現有 Fargate Pod 執行角色。如需詳細資訊，請參閱 [步驟 2：建立 Fargate Pod 執行角色](fargate-getting-started.md#fargate-sg-pod-execution-role)。
## 日誌路由器組態
**重要**
若要成功發布日誌，您叢集所在的 VPC 必須具有對日誌目的地的網路存取權。這主要涉及使用者為其 VPC 自訂輸出規則。如需使用 CloudWatch 的範例，請參閱《*Amazon CloudWatch Logs 使用者指南*》中的[搭配介面 VPC 端點使用 CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)。
在下列步驟中，使用您自己的值取代每一個*範例值*。
1. 建立名為 `aws-observability` 的專用 Kubernetes 命名空間。
1. 將下列內容儲存到電腦上名為 `aws-observability-namespace.yaml` 的檔案中。`name` 的值必須為 `aws-observability`，且需要 `aws-observability: enabled` 標籤。
```
kind: Namespace
apiVersion: v1
metadata:
name: aws-observability
labels:
aws-observability: enabled
```
1. 建立命名空間。
```
kubectl apply -f aws-observability-namespace.yaml
```
1. 建立具有 `Fluent Conf` 資料值的 `ConfigMap`，將容器日誌寄送至目的地。Fluent Conf 就是 Fluent Bit，這是一種快速且輕量的日誌處理器組態語言，可用於將容器日誌路由至您選擇的日誌目的地。如需詳細資訊，請參閱 Fluent Bit 文件中的[組態檔案](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file)。
**重要**
一般 `Fluent Conf` 中包含的主要區段是 `Service`、`Input`、`Filter` 和 `Output`。然而，Fargate 日誌路由器僅接受：
`Filter` 和 `Output` 區段。
`Parser` 區段。
如果您提供任何其他區段，則這些區段將被拒絕。
Fargate 日誌路由器管理 `Service` 和 `Input` 區段。其具有下列 `Input` 區段，無法修改，也不需要在您的 `ConfigMap` 中。但是，您可以從中取得洞察，例如記憶體緩衝區限制和套用於日誌的標籤。
```
[INPUT]
Name tail
Buffer_Max_Size 66KB
DB /var/log/flb_kube.db
Mem_Buf_Limit 45MB
Path /var/log/containers/*.log
Read_From_Head On
Refresh_Interval 10
Rotate_Wait 30
Skip_Long_Lines On
Tag kube.*
```
建立 `ConfigMap` 時，請考慮下列 Fargate 用來驗證欄位的規則：
+ 應該在每個相應的索引鍵下指定 `[FILTER]`、`[OUTPUT]` 和 `[PARSER]`。例如，`[FILTER]` 必須位於 `filters.conf` 之下。您可以在 `filters.conf` 下有一或多個 `[FILTER]`。`[OUTPUT]` 和 `[PARSER]` 區段也應該位於其相應的索引鍵之下。透過指定多個 `[OUTPUT]` 區段中，您可以同時將日誌路由到不同的目的地。
+ Fargate 驗證每個區段所需的索引鍵。`Name` 和 `match` 對於每個 `[FILTER]` 和 `[OUTPUT]` 都是必要項目。`Name` 和 `format` 對於每個 `[PARSER]` 都是必要項目。索引鍵不區分大小寫。
+ `ConfigMap` 中不允許環境變數 (例如 `${ENV_VAR}`)。
+ 在每個 `filters.conf`、`output.conf` 和 `parsers.conf` 中每個指令或鍵值對的縮排必須是相同的。鍵值對必須比指令縮排更多。
+ Fargate 會根據以下支援的篩選條件進行驗證：`grep`、`parser`、`record_modifier`、`rewrite_tag`、`throttle`、`nest`、`modify` 和 `kubernetes`。
+ Fargate 會根據以下支援的輸出進行驗證：`es`、`firehose`、`kinesis_firehose`、`cloudwatch`、`cloudwatch_logs` 和 `kinesis`。
+ 必須在 `ConfigMap` 中提供至少一個支援的 `Output` 外掛程式來啟用記錄。啟用記錄時不需要 `Filter` 和 `Parser`。
您也可以使用所需的組態在 Amazon EC2 上執行 Fluent Bit，以對因驗證而產生的任何問題進行故障診斷。使用下列範例之一建立您的 `ConfigMap`。
**重要**
Amazon EKS Fargate 記錄不支援 `ConfigMap` 的動態組態。`ConfigMap` 的任何變更僅適用於新的 Pod。變更不會套用至現有 Pod。
使用您所需的日誌目的地範例建立 `ConfigMap`。
**注意**
您也可以將 Amazon Kinesis Data Streams 用於您的日誌目的地。如果您使用 Kinesis Data Streams，請確定 Pod 執行角色已獲 `kinesis:PutRecords` 許可。如需詳細資訊，請參閱《*Fluent Bit：官方手冊*》中的 Amazon Kinesis Data Streams [許可](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions)。
**Example**
------
#### [ CloudWatch ]
使用 CloudWatch 時，您有兩個輸出選項：
+ [用 C 編寫的輸出外掛程式](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch)
+ [用 Golang 編寫的輸出外掛程式](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit)
以下範例顯示如何使用 `cloudwatch_logs` 外掛程式將日誌傳送至 CloudWatch。
1. 將下列內容儲存到名為 `aws-logging-cloudwatch-configmap.yaml` 的檔案中。使用叢集所在的 AWS 區域取代 *region-code*。`[OUTPUT]` 下的參數為必要項目。
```
kind: ConfigMap
apiVersion: v1
metadata:
name: aws-logging
namespace: aws-observability
data:
flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch.
filters.conf: |
[FILTER]
Name parser
Match *
Key_name log
Parser crio
[FILTER]
Name kubernetes
Match kube.*
Merge_Log On
Keep_Log Off
Buffer_Size 0
Kube_Meta_Cache_TTL 300s
output.conf: |
[OUTPUT]
Name cloudwatch_logs
Match kube.*
region region-code
log_group_name my-logs
log_stream_prefix from-fluent-bit-
log_retention_days 60
auto_create_group true
parsers.conf: |
[PARSER]
Name crio
Format Regex
Regex ^(?