**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在現有的 EKS 叢集上啟用 EKS 自動模式
您可以在現有的 EKS 叢集上啟用 EKS 自動模式。
** AWS 支援下列移轉：**
+ 從 Karpenter 移轉至 EKS 自動模式節點。如需詳細資訊，請參閱 [使用 kubectl 從 Karpenter 移轉至 EKS 自動模式](auto-migrate-karpenter.md)。
+ 從 EKS 受管節點群組移轉至 EKS 自動模式節點。如需詳細資訊，請參閱 [從 EKS 受管節點群組移轉至 EKS 自動模式](auto-migrate-mng.md)。
+ 從 EKS Fargate 移轉至 EKS 自動模式。如需詳細資訊，請參閱 [從 EKS Fargate 移轉至 EKS 自動模式](auto-migrate-fargate.md)。
** AWS 不支援下列移轉：**
+ 將磁碟區從 EBS CSI 控制器 (使用 Amazon EKS 附加元件) 移轉至 EKS 自動模式 EBS CSI 控制器 (由 EKS 自動模式管理)。使用其中一個製作的 PVC 無法由另一個掛載，因為它們使用的是兩個不同的 Kubernetes 磁碟區佈建程式。
+ [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (AWS 實驗室專案) 可在標準 EBS CSI StorageClass (`ebs.csi.aws.com`) 和 EKS 自動 EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`) 之間進行移轉。請注意，移轉需要刪除並重新建立現有的 PersistentVolumeClaim/PersistentVolume 資源，因此在實作之前，請務必在非生產環境中進行驗證。
+ 將負載平衡器從 AWS Load Balancer 控制器移轉至 EKS 自動模式
您可以在 Amazon EKS 自動模式叢集上安裝 AWS Load Balancer 控制器。使用 `IngressClass` 或 `loadBalancerClass` 選項，將服務和傳入資源與 Load Balancer 控制器或 EKS 自動模式建立關聯。
+ 使用替代 CNI 或其他不支援的網路組態移轉 EKS 叢集
## 移轉參考
使用下列移轉參考，將 Kubernetes 資源設定為由自我管理控制器或 EKS 自動模式擁有。
| 功能 | 資源 | 欄位 | 自我管理 | EKS 自動模式 |
| --- | --- | --- | --- | --- |
| 區塊儲存 | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| 負載平衡 | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| 負載平衡 | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| 負載平衡 | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 負載平衡 | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 運算 | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## 移轉 EBS 磁碟區
將工作負載移轉至 EKS 自動模式時，由於 CSI 驅動程式佈建程式不同，您需要處理 EBS 磁碟區移轉：
+ EKS 自動模式佈建程式：`ebs.csi.eks.amazonaws.com`
+ 開放原始碼 EBS CSI 佈建程式：`ebs.csi.aws.com`
請遵循下列步驟，移轉您的持久性磁碟區：
1. **修改磁碟區保留政策**：將現有平台版本的 (PV) `persistentVolumeReclaimPolicy` 變更為 `Retain`，以確保不會刪除基礎 EBS 磁碟區。
1. **從 Kubernetes 移除 PV**：刪除舊 PV 資源，同時保持實際 EBS 磁碟區原封不動。
1. **使用靜態佈建建立新的 PV**：建立參考相同 EBS 磁碟區且可與目標 CSI 驅動程式搭配使用的新 PV。
1. **繫結至新的 PVC**：使用 `volumeName` 欄位建立專門參考 PV 的新 PVC。
### 考量事項
+ 在開始此移轉之前，請確保您的應用程式已停止。
+ 在開始移轉程序之前，備份您的資料。
+ 每個持久性磁碟區皆需執行此程序。
+ 工作負載必須更新，才能使用新的 PVC。
## 移轉負載平衡器
您無法將現有的負載平衡器從自我管理 AWS 負載平衡器控制器直接轉移至 EKS 自動模式。相反地，您必須實作藍綠部署策略。這包括在受管控制器下建立新的負載平衡器時，維護現有的負載平衡器組態。
若要最大限度地減少服務中斷，我們建議採用 DNS 型流量轉移方法。首先，使用 EKS 自動模式建立新的負載平衡器，同時保持現有組態正常運作。然後，使用 DNS 路由 (例如 Route 53)，逐步將流量從舊負載平衡器轉移至新的負載平衡器。成功移轉流量並驗證新組態後，您即可停用舊負載平衡器和自我管理控制器。
# 在現有叢集上啟用 EKS 自動模式
本主題描述如何在現有的 Amazon EKS 叢集上啟用 Amazon EKS Auto Mode。在現有叢集上啟用自動模式需要更新 IAM 許可，並設定 EKS 自動模式核心設定。一旦啟用，您可以開始移轉現有的運算工作負載，以利用自動模式的簡化操作和自動化基礎結構管理。
**重要**
在啟用 EKS 自動模式之前，請確認您已安裝特定 Amazon EKS 附加元件的最低所需版本。如需詳細資訊，請參閱[所需的附加元件版本](#auto-addons-required)。
開始之前，請確認您擁有 Amazon EKS 叢集的管理員存取權限及修改 IAM 角色的許可。本主題中的步驟會引導您使用 AWS 管理主控台 或 CLI AWS 來啟用自動模式。
## AWS 管理主控台
您必須使用管理 IAM、EKS 和 EC2 資源的許可登入 AWS 主控台。
**注意**
EKS 叢集的叢集 IAM 角色在叢集建立後無法變更。EKS 自動模式需要此角色的額外許可。您必須在目前角色上附加其他政策。
### 更新叢集 IAM 角色
1. 在 AWS 管理主控台中開啟您的叢集概觀頁面。
1. 在**叢集 IAM 角色 ARN** 下，選取在 **IAM 中檢視**。
1. 從**新增許可**下拉式清單中，選取**連接政策**。
1. 使用**搜尋**方塊，尋找並選取以下政策：
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. 選取**新增許可**
1. 從**信任關係**索引標籤，選取**編輯信任政策**
1. 插入下列叢集 IAM 角色信任政策，並選取**更新政策**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### 啟用 EKS 自動模式
1. 在 AWS 管理主控台中開啟您的叢集概觀頁面。
1. 在 **EKS 自動模式**下，選取**管理**
1. 將 **EKS 自動模式**切換為開啟。
1. 從 **EKS 節點集區**下拉式清單中，選取要建立的預設節點集區。
+ 進一步了解 EKS 自動模式的節點集區。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
1. 如果您先前已建立此 AWS 帳戶的 EKS 自動模式節點 IAM 角色，請在**節點 IAM 角色**下拉式清單中選取該角色。如果您之前尚未建立此角色，請選取**建立建議的角色**，並依步驟操作。
## AWS CLI
### 先決條件
+ 現有 EKS 叢集的叢集 IAM 角色必須包含 EKS 自動模式所需的足夠許可，如下列政策：
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ 叢集 IAM 角色必須具有更新的信任政策，包括 `sts:TagSession` 動作。如需有關建立 IAM 角色的詳細資訊，請參閱 [使用 CLI AWS 建立 EKS 自動模式叢集](automode-get-started-cli.md)。
+ 已安裝 `aws` CLI、登入且版本足夠。您必須具有管理 IAM、EKS 和 EC2 資源的許可。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
### 程序
使用以下命令，在現有叢集上啟用 EKS 自動模式。
**注意**
運算、區塊儲存和負載平衡功能必須在同一請求中全部啟用或停用。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## 所需的附加元件版本
如果您計劃在現有叢集上啟用 EKS 自動模式，您可能需要更新特定附加元件。版本備註：
+ 這僅適用於轉換為 EKS 自動模式的現有叢集。
+ 啟用 EKS 自動模式時建立的新叢集無需這些更新。
如果您安裝了以下任何附加元件，請確保其至少為指定的最低版本：
| 附加元件名稱 | 所需的最低版本 |
| --- | --- |
| Kubernetes 專用 Amazon VPC CNI 外掛程式 | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/auto-enable-existing.html) |
| Amazon EBS CSI 驅動程式 | v1.37.0-eksbuild.1 |
| CSI 快照控制器 | v8.1.0-eksbuild.2 |
| EKS Pod 身分識別代理程式 | v1.3.4-eksbuild.1 |
如需詳細資訊，請參閱[更新 Amazon EKS 附加元件](updating-an-add-on.md)。
## 後續步驟
+ 要移轉管理節點群組工作負載，請參閱 [從 EKS 受管節點群組移轉至 EKS 自動模式](auto-migrate-mng.md)。
+ 要從自我管理 Karpenter 移轉，請參閱 [使用 kubectl 從 Karpenter 移轉至 EKS 自動模式](auto-migrate-karpenter.md)。
# 使用 kubectl 從 Karpenter 移轉至 EKS 自動模式
本主題將逐步引導您使用 kubectl 將工作負載從 Karpenter 移轉至 Amazon EKS 自動模式。移轉可以逐步進行，讓您能夠按照自己的步調移動工作負載，同時在整個轉換期間保持叢集穩定性和應用程式可用性。
下面概述的逐步方法使您能夠在移轉期間同時執行 Karpenter 和 EKS 自動模式。這種雙重操作策略有助於確保平穩轉換，讓您可以在完全停用 Karpenter 之前，驗證工作負載在 EKS 自動模式上的行為。您可以單獨或分組移轉應用程式，提供靈活性以適應您的特定運營要求與風險承受能力。
## 先決條件
開始移轉之前，請確保您已具備下列項目：
+ 在叢集上安裝了 Karpenter v1.1 或以上版本。如需詳細資訊，請參閱 Karpenter 文件中的[升級至版本 1.1.0 及以上](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110)。
+ 已安裝並將 `kubectl` 連接到您的叢集。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
本主題假設您熟悉 Karpenter 及 NodePools。如需詳細資訊，請參閱 [Karpenter](https://karpenter.sh/) 文件。
## 步驟 1：在叢集上啟用 EKS 自動模式
使用 CLI 或 管理主控台在現有叢集上啟用 AWS EKS 自動模式。如需詳細資訊，請參閱[在現有叢集上啟用 EKS 自動模式](auto-enable-existing.md)。
**注意**
啟用 EKS 自動模式時，切勿在轉換期間的此階段啟用 `general purpose` nodepool。此節點集區不具選擇性。
如需詳細資訊，請參閱[啟用或停用內建的 NodePool](set-builtin-node-pools.md)。
## 步驟 2：建立帶有污點的 EKS 自動模式 NodePool
為 EKS 自動模式建立帶有污點的新 NodePool。這確保了現有的 Pod 不會自動排程到新的 EKS 自動模式節點上。此節點集區使用 EKS 自動模式內建的 `default` `NodeClass`。如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。
帶有污點的節點集區範例：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
更新節點集區的需求，以符合您要從中移轉的 Karpenter 組態。您至少需要一個需求。
## 步驟 3：更新工作負載以進行移轉
識別並更新您想要移轉至 EKS 自動模式的工作負載。向這些工作負載新增容差和節點選取器：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
此變更可讓工作負載排程至新的 EKS 自動模式節點。
EKS 自動模式使用與 Karpenter 不同的標籤。與 EC2 受管執行個體相關的標籤以 `eks.amazonaws.com` 開頭。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
## 步驟 4：逐步移轉工作負載
針對要移轉的每個工作負載重複步驟 3。這使您可根據需求和風險承受能力，單獨或分組移動工作負載。
## 步驟 5：移除原始 Karpenter NodePool
所有工作負載移轉完成後，即可移除原始的 Karpenter NodePool：
```
kubectl delete nodepool
```
## 步驟 6：從 EKS 自動模式 NodePool 移除污點 (選用)
如果您希望 EKS 自動模式成為新工作負載的預設值，可以從 EKS 自動模式 NodePool 中移除污點：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## 步驟 7：從工作負載移除節點選取器 (選用)
如果您已從 EKS 自動模式 NodePool 移除污點，可以選擇從工作負載移除節點選取器，因為 EKS 自動模式現在是預設值：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## 步驟 8：從叢集解除安裝 Karpenter
移除 Karpenter 的步驟取決於您的安裝方式。如需詳細資訊，請參閱 [Karpenter 安裝說明](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter)。
# 從 EKS 受管節點群組移轉至 EKS 自動模式
當您將 Amazon EKS 叢集轉換為使用 EKS 自動模式時，可以使用 eksctl CLI 工具從受管節點群組順暢地移轉現有工作負載。此程序能確保應用程式持續可用，同時 EKS 自動模式會最佳化您的運算資源。移轉可以在對執行中應用程式造成最小干擾的情況下進行。
本主題將引導您完成從現有受管節點群組耗盡 Pod，並讓 EKS 自動模式在新佈建的執行個體上重新排程它們的步驟。透過遵循此程序，您可在整個移轉過程中保持應用程式可用性的同時，利用 EKS 自動模式的智慧型工作負載整合功能。
## 先決條件
+ 已啟用 EKS 自動模式的叢集
+ 已安裝並將 `eksctl` CLI 連接到您的叢集。如需詳細資訊，請參閱 [設定以使用 Amazon EKS](setting-up.md)。
+ 叢集上未安裝 Karpenter。
## 程序
使用以下 `eksctl` CLI 命令來開始從現有受管節點群組執行個體排空 Pod。EKS 自動模式將建立新節點，以支援被取代的 Pod。
```
eksctl delete nodegroup --cluster= --name=
```
您需要為叢集中的每個受管節點群組執行此命令。
有關此命令的更多資訊，請參閱 eksctl 文件中的[刪除和耗盡節點群組](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)。
# 從 EKS Fargate 移轉至 EKS 自動模式
本主題將引導您使用 `kubectl` 將工作負載從 EKS Fargate 移轉至 Amazon EKS 自動模式的程序。移轉可以逐步進行，讓您能夠按照自己的步調移動工作負載，同時在整個轉換期間保持叢集穩定性和應用程式可用性。
下面概述的逐步方法使您能夠在移轉期間同時執行 EKS Fargate 和 EKS 自動模式。這種雙重操作策略有助於確保平穩轉換，讓您可以在完全停用 EKS Fargate 之前，驗證工作負載在 EKS 自動模式上的行為。您可以單獨或分組移轉應用程式，提供靈活性以適應您的特定運營要求與風險承受能力。
## 使用 AWS Fargate 比較 Amazon EKS Auto 模式和 EKS
對於想要執行 EKS 的客戶而言，Amazon EKS 搭配 AWS Fargate 仍然是選項，但 Amazon EKS Auto Mode 是建議的方法。EKS 自動模式完全符合 Kubernetes 規範，支援所有上游 Kubernetes 基本元件與 Istio 等平台工具，而這些是 Fargate 無法支援的。EKS 自動模式還完全支援所有 EC2 執行時期購買選項，包括 GPU 和 Spot 執行個體，使客戶能夠利用協商後的 EC2 折扣和其他節省機制。這些功能在使用帶有 Fargate 的 EKS 時不可用。
此外，EKS 自動模式允許客戶實現與 Fargate 相同的隔離模型，使用標準的 Kubernetes 排程功能來確保每個 EC2 執行個體運行單個應用程式容器。透過採用 Amazon EKS Auto Mode，客戶可以釋放在 上執行 Kubernetes 的完整優點 AWS ：完全符合 Kubernetes 的平台，提供彈性以利用整個 EC2 的廣度和購買選項，同時保留 Fargate 提供的基礎設施管理的易用性和抽象性。
### 在 EKS Auto 模式下實現類似 Fargate 的隔離
若要複寫 Fargate 的 Pod 隔離模型，其中每個 Pod 在自己的專用執行個體上執行，您可以使用 Kubernetes 拓撲分散限制條件。這是控制跨節點 Pod 分佈的建議方法：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
在此組態中：
+ `maxSkew: 1` 確保任何兩個節點之間的 Pod 計數差異最多為 1，每個節點可有效分配一個 Pod
+ `topologyKey: kubernetes.io/hostname` 將節點定義為拓撲網域
+ `whenUnsatisfiable: DoNotSchedule` 如果無法滿足限制條件， 會阻止排程
+ `minDomains: 1` 確保在排程之前至少有一個網域 （節點）
EKS Auto Mode 將視需要自動佈建新的 EC2 執行個體，以滿足此限制，提供與 Fargate 相同的隔離模型，同時讓您存取完整的 EC2 執行個體類型和購買選項。
或者，您可以使用 Pod 反親和性規則進行更嚴格的隔離：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
使用 的`podAntiAffinity`規則`requiredDuringSchedulingIgnoredDuringExecution`可確保在相同節點上`app: isolated-app`無法排程具有標籤的兩個 Pod。此方法提供與 Fargate 類似的硬隔離保證。
## 先決條件
開始移轉之前，請確保您已具備下列項目
+ 使用 Fargate 設定叢集。如需詳細資訊，請參閱[為您的叢集開始使用 AWS Fargate](fargate-getting-started.md)。
+ 已安裝並將 `kubectl` 連接到您的叢集。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。
## 步驟 1：檢查 Fargate 叢集
1. 檢查帶有 Fargate 的 EKS 叢集是否正在執行：
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. 檢查執行中的 Pod：
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. 在名為 `deployment_fargate.yaml` 的檔案中建立部署：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 套用部署：
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. 檢查 Pod 與部署狀態：
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. 檢查節點：
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## 步驟 2：在叢集上啟用 EKS 自動模式
1. 使用 CLI 或 管理主控台在現有叢集上啟用 AWS EKS 自動模式。如需詳細資訊，請參閱[在現有叢集上啟用 EKS 自動模式](auto-enable-existing.md)。
1. 檢查 nodepool：
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## 步驟 3：更新工作負載以進行移轉
識別並更新您想要移轉至 EKS 自動模式的工作負載。
要將工作負載從 Fargate 移轉至 EKS 自動模式，請套用註釋 `eks.amazonaws.com/compute-type: ec2`。這能確保即使存在 Fargate 設定檔，該工作負載也不會由 Fargate 排程，而是由 EKS 自動模式 NodePool 接管。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。
1. 修改您的部署 (例如 `deployment_fargate.yaml` 檔案)，將運算類型變更為 `ec2`：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. 套用部署。此變更可讓工作負載排程至新的 EKS 自動模式節點：
```
kubectl apply -f deployment_fargate.yaml
```
1. 檢查部署是否在 EKS 自動模式叢集中執行：
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. 確認沒有 Fargate 節點在執行，且部署正在 EKS 自動模式受管節點上執行：
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## 步驟 4：逐步移轉工作負載
針對要移轉的每個工作負載重複步驟 3。這使您可根據需求和風險承受能力，單獨或分組移動工作負載。
## 步驟 5：移除原始的 Fargate 設定檔
所有工作負載移轉完成後，即可移除原始的 `fargate` 設定檔。將 ** 取代為您的 Fargate 設定檔名稱：
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## 步驟 6：縮減 CoreDNS 規模
由於 EKS 自動模式會處理 CoreDNS，您可將 `coredns` 部署縮減到 0：
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```