从 EKS Fargate 迁移到 EKS 自动模式 - Amazon EKS
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

帮助改进此页面

要帮助改进本用户指南,请选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。

从 EKS Fargate 迁移到 EKS 自动模式

本主题将演示使用 kubectl 将工作负载从 EKS Fargate 迁移到 Amazon EKS 自动模式的过程。迁移可以逐步执行,从而让您按照自己的节奏移动工作负载,同时在整个迁移期间保持集群稳定性和应用程序可用性。

借助下面概述的分步方法,您可以在迁移期间并行运行 EKS Fargate 和 EKS 自动模式。借助这种双重运行策略,您可以在完全停用 EKS Fargate 之前验证 EKS 自动模式下的工作负载行为,从而帮助保证平稳过渡。您可以逐一或分组迁移应用程序,从而灵活地适应自己的具体运行要求和风险承受能力。

将 Amazon EKS 自动模式与具有 Amazon Fargate 的 EKS 进行比较

对于希望运行 EKS 的客户来说,尽管具有 Amazon Fargate 的 Amazon EKS 仍是一种选择,但 Amazon EKS 自动模式是未来推荐的首选方法。EKS 自动模式完全符合 Kubernetes 要求,支持所有上游 Kubernetes 原语和平台工具,例如 Fargate 无法支持的 Istio。EKS 自动模式还完全支持所有 EC2 运行时购买选项,包括 GPU 和竞价型实例,有助于客户利用议定的 EC2 折扣以及其他节省机制。但是,将 EKS 与 Fargate 结合使用时,这些功能不可用。

此外,EKS 自动模式允许客户实现与 Fargate 相同的隔离模型,通过标准的 Kubernetes 调度功能确保每个 EC2 实例都运行一个应用程序容器。借助 Amazon EKS 自动模式,客户可以充分享受在 Amazon 上运行 Kubernetes 的全部优势。Kubernetes 是一个完全符合 Kubernetes 要求的平台,可以灵活利用所有 EC2 和购买选项,同时保留 Fargate 提供的易用性以及从基础设施管理中抽象化的能力。

在 EKS 自动模式下实现与 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 自动模式会根据需要自动预置新的 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

带有 requiredDuringSchedulingIgnoredDuringExecutionpodAntiAffinity 规则确保不能将两个带有标签 app: isolated-app 的容器组(pod)调度到同一个节点上。这种方法提供了与 Fargate 类似的硬隔离保障。

先决条件

开始迁移之前,请确保您满足以下条件

步骤 1:检查 Fargate 集群

  1. 检查带有 Fargate 的 EKS 集群是否正在运行:

    kubectl get node
    NAME STATUS ROLES AGE VERSION fargate-ip-192-168-92-52.ec2.internal Ready <none> 25m v1.30.8-eks-2d5f260 fargate-ip-192-168-98-196.ec2.internal Ready <none> 24m v1.30.8-eks-2d5f260
  2. 检查正在运行的容器组(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
  3. 在名为 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
  4. 应用部署:

    kubectl apply -f deployment_fargate.yaml
    deployment.apps/nginx-deployment created
  5. 检查容器组(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
  6. 检查节点:

    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 <none> 31s v1.30.8-eks-2d5f260 192.168.111.43 <none> Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25 fargate-ip-192-168-117-130.ec2.internal Ready <none> 36s v1.30.8-eks-2d5f260 192.168.117.130 <none> Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25 fargate-ip-192-168-74-140.ec2.internal Ready <none> 36s v1.30.8-eks-2d5f260 192.168.74.140 <none> Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25

步骤 2:在集群上启用 EKS 自动模式

  1. 使用 Amazon CLI 或管理控制台在现有集群上启用 EKS 自动模式。有关更多信息,请参阅 在现有集群上启用 EKS 自动模式

  2. 检查节点池:

    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 自动模式节点池接管。有关更多信息,请参阅 为 EKS 自动模式创建节点池

  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
  2. 应用部署。实施此更改后,即可在新的 EKS 自动模式节点上调度工作负载:

    kubectl apply -f deployment_fargate.yaml
  3. 检查部署是否正在 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 <none> <none> nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb <none> <none> nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb <none> <none>
  4. 确认 EKS 自动模式托管式节点中没有正在运行的 Fargate 节点和正在运行的部署:

    kubectl get node -owide
    NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME i-0845aafcb51630ffb Ready <none> 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 profile name> 替换为 Fargate 配置文件的名称:

aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name <fargate profile name>

步骤 6:缩减 CoreDNS

由于 EKS 自动模式可以处理 CoreDNS,因此可将 coredns 部署缩减到 0:

kubectl scale deployment coredns -n kube-system —-replicas=0