操作指南：将云实例迁移到 AMD EPYC（霄龙）

Mar 21, 2026

Server room center exchanging cyber datas 3D rendering

随着贵组织的业务发展，云服务的使用量逐步增加，云计算支出也可能随之增长。许多组织正在重新评估用于运行其工作负载的实例类型，以优化云环境，从而提升成本效益、性能表现和可持续性。对于各大云服务提供商而言，最常见的一种优化方案就是迁移到基于 AMD EPYC（霄龙）的实例。

目前，各大云服务提供商均提供基于 AMD EPYC（霄龙）处理器的实例，包括通用型、计算优化型和内存优化型系列，这使得用户无需更改应用代码、操作系统或容器镜像，即可完成实例迁移。AMD EPYC（霄龙）实例采用 x86_64 架构，因此迁移过程无需重构应用、重新编译二进制文件或重建容器镜像。实际上，大多数生产环境的迁移关键在于部署策略，而非代码变更。然而，组织仍需一条安全可靠的迁移路径，以充分降低风险、保障可用性，并保留现有的自动化流程和扩展机制。

本博文提供了一份最佳实践指南，旨在讲解如何将生产工作负载迁移至基于 AMD 的云实例。本文聚焦于两种常见的部署模式：

  • 基于虚拟机 (VM) 的工作负载
  • Kubernetes 集群中的容器化工作负载

关键考量因素

大多数成功的迁移都遵循相同的模式：先确认兼容性、准备纯净的基础镜像、验证性能表现，并定义回滚路径，然后再切换生产流量。首先需要验证的是，现有的 AMI 或容器镜像是否能不经修改就在 AMD 实例上直接运行。对于大多数客户而言，这通常不是问题，因为标准 Linux 发行版、内核模块和 cloud-init 脚本在不同 x86 CPU 厂商的系统上运行方式一致。如果您使用监控代理、安全代理或自定义二进制文件，最简单的验证方法便是：启动一个 AMD 实例，运行引导流程，并确认一切是否正常运行。现在，您可以着手构建（或克隆）一个全新的“黄金 AMI”以进行部署。

存储是下一个需要考虑的因素。如果您的现有机群使用 EBS 卷，则可以在 AMD 实例上重新挂载或重新创建这些卷，而无需进行更改。如果现有应用使用本地临时磁盘，则需要针对这些工作负载制定数据迁移计划，或者确认在滚动更新过程中可以安全地丢弃数据。

此外，还有必要了解迁移如何影响现有的云成本承诺，包括预留实例、企业折扣计划、私有定价协议、承诺使用量或节省计划折扣。有些组织专门采用分阶段迁移方式，以避免预留实例重叠，而有些组织则将迁移作为调整实例规格或整合实例类型的契机。这些因素都不会阻碍迁移，但是提前规划远比在迁移过程中规划要更为轻松。对于 AWS，迁移至 AMD（如 M8a）不会产生任何影响，除非您使用特定实例系列专属的预留实例，因为这些预留实例已锁定，而不会自动应用于 M8a。在这种情况下，除非将预留实例转换、出售或任其到期，否则折扣将失效。但是，这不会影响计算节省计划，这类计划适用于所有实例系列、规格和 CPU 厂商，无需任何操作即可生效。同样的原则也适用于 Google Cloud 的承诺使用折扣 (CUD) 和 Azure 的计算节省计划：只要您保持相同的承诺类型（按 vCPU 数量/使用时长或按支出金额），即使底层虚拟机 SKU 切换为 AMD，这些计划仍将继续生效。

在充分考虑上述因素后，您即可正式开始迁移。

部署策略

将 AMD 实例引入生产环境有多种方式，大多数组织通常采用以下三种模式之一：滚动更新、蓝绿部署或金丝雀 (Canary) 部署。这三种策略均可让您在不中断服务的情况下引入 AMD 实例，并且都提供了明确的回滚路径以备不时之需。极少数组织会采用“一次性”部署模式

一次性：一次性切换是指一步替换所有正在提供服务的实例。这种模式通常仅适用于以下情况：有明确的维护窗口、机群规模较小，或者应用可以接受短暂的中断。应选择何种策略取决于是否需要零停机，以及在迁移期间可承载多少并行流量。

滚动更新：滚动更新是指逐步替换实例，同时保留最少数量的正常实例。如果您已使用自动扩缩组、虚拟机规模集或托管实例组，则仅需创建一个指定 AMD 实例类型的新模板或映像，然后交由平台逐个替换实例即可。在此过程中，应用始终保持在线，若运行状况检查失败，更新过程可自动暂停或回滚。

蓝绿部署：该模式并行维护两个完整的机群：现有环境（蓝）和新 AMD 环境（绿）。在将生产流量路由到新机群（绿色环境）之前，需对新机群进行全面验证，包括运行功能检查、负载测试甚至影子流量。完成流量切换后，旧机群（蓝色环境）即可停用。在正式切换流量之前，绿色环境将保持原状，但这意味着暂时需要消耗双倍算力资源。

金丝雀部署：这种模式会先将少量生产流量（例如 10%）路由到 AMD 实例。如果性能、错误率或延迟保持在预期阈值内，则流量分配将逐步增加至 100%。金丝雀部署环境在初期仅需承载少量的并行流量。

基于虚拟机 (VM) 的工作负载

自动扩缩组实例刷新

要迁移到 AMD 实例，最简单的一种方法便是使用“实例刷新”方法。借助这种方法，您可以根据更新的启动配置，逐步用新实例替换自动扩缩组 (ASG) 中的实例。这是一种滚动更新策略，即每次仅替换一个或几个实例，机群中的其余实例则继续正常承载流量。

选择现有的启动模板，并通过修改实例类型（例如改为 M7a）来创建新版本。然后，在自动扩缩组中编辑设置，并将目标指向启动模板的最新版本。接着，通过控制台或 AWS CLI 发起实例刷新。此操作将逐步终止旧的实例，并用新的 AMD 实例替换旧实例，在保持最少可用实例的同时，确保您的应用始终正常可用。

		aws autoscaling start-instance-refresh \ 
  --auto-scaling-group-name my-asg \ 
  --strategy Rolling \ 
  --preferences MinHealthyPercentage=90,InstanceWarmup=300

MinHealthyPercentage 设置可定义在更新过程中机群内必须有多少实例保持可用，而 InstanceWarmup 可确保在每个替换的新实例完全初始化后再终止下一个旧实例。

使用负载均衡器逐步转移流量

如果您的现有机群位于应用负载均衡器 (ALB) 后端。您可以通过黄金 AMI 使用 AMD 实例配置一个新机群，并采用与原有实例相同的安全组。将 AMD 机群注册到一个单独的负载均衡器目标组中，即绿色目标组。验证绿色组是否正常运行，并更新监听器以将部分或全部流量发送至绿色组。若需先进行金丝雀测试，请为绿色组分配较小的权重（流量百分比）。测试完成后，将绿色组的权重设为 100%。

ALB 监听器的操作可通过控制台或 AWS CLI 进行编辑。 以下示例展示了如何通过 CLI 实现渐进式流量迁移：先将 5% 的流量导向绿色组以进行金丝雀测试，同时 95% 的流量仍流向蓝色组。

		aws elbv2 modify-listener \ 
  --listener-arn arn:aws:elasticloadbalancing:...:listener/app/my-alb/abc/def \ 
  --default-actions '[ 
    { 
      "Type": "forward", 
      "ForwardConfig": { 
        "TargetGroups": [ 
          {"TargetGroupArn": "arn:...:targetgroup/blue-tg/111", "Weight": 95}, 
          {"TargetGroupArn": "arn:...:targetgroup/green-tg/222", "Weight": 5} 
        ] 
      } 
    } 
  ]'

一旦新目标组接收 100% 的流量且保持正常运行状态，即可注销并删除旧目标组。回滚操作很简单，仅需反转监听器规则，使其重新指向蓝色目标组，因此无需替换任何实例即可实现恢复。

		aws autoscaling detach-load-balancer-target-groups \ 
  --auto-scaling-group-name blue-asg \ 
  --target-group-arns arn:aws:elasticloadbalancing:...:targetgroup/prod-tg/ABC

请务必确认绿色目标组的运行状况检查路径和端口与您的应用相匹配，错误的路径会导致绿色目标组的健康目标数始终为 0，从而阻断迁移。

如果您希望完全进行带外验证，可以将绿色机群挂载到独立的 ALB 上运行检查，待准备就绪后再对生产环境的 ALB 进行监听器切换。您也可以选择使用 Route 53 加权记录进行 DNS 切换，但进行 ALB 目标组切换更为简单，因为无需管理 TTL 和多个负载均衡器端点，只需保留一个主机名、一个负载均衡器，并将流量转发决策统一移至监听器内部。

Kubernetes 集群中的容器化工作负载

Kubernetes 不依赖特定的 CPU 架构，因此将容器化工作负载迁移到基于 AMD 的工作节点非常简单，因为两种架构都运行相同的 linux/amd64 容器镜像。因此，无需重建或重新标记镜像，无需多架构镜像库，也无需修改 Dockerfile 或 CI 流水线。此外，由于工作负载已与底层主机解耦，迁移将在节点层而非应用层进行。

添加 AMD 节点组

Kubernetes 支持在同一集群中同时安全运行原有和 AMD 节点。您可以引入新的 AMD 节点组，同时让原有节点保持活动状态，并通过调度控制逐步迁移工作负载，而非逐个替换实例。这套机制在托管服务（EKS、GKE、AKS）和自托管集群中完全一致。

如果您在 AWS 上使用 EKS，则需基于 AMD 实例（例如 m8a.8xlarge）创建新的节点组。这可以通过 eksctl 使用托管式节点组来实现，如果您需要更加灵活地管理节点扩缩，也可以使用 Karpenter 这样的自定义配置程序。

		eksctl create nodegroup \ 
  --cluster your-cluster-name \ 
  --name amd-nodes \ 
  --node-type m8a.2xlarge \ 
  --nodes 3 \ 
  --nodes-min 2 \ 
  --nodes-max 5

在 AMD 节点组准备就绪后，您可以为新节点添加标签或污点 (taint)，以控制将哪些工作负载调度到这些节点上，如下所示。此外，您还可以通过 DaemonSet 动态添加标签。

kubectl label nodes <amd-node-name> node-type=amd

这将创建一个基于 AMD 的节点组，并预先加好标签。一旦节点加入集群，您就可以使用污点 (taint)、节点选择器 (nodeSelector)、节点亲和性 (nodeAffinity) 或容忍度 (toleration)，将部署的特定工作负载调度到这些节点上。

		managedNodeGroups: 

 - name: amd-nodes 

    instanceType: m8a.xlarge 

    desiredCapacity: 3 
   
    minSize: 2 

  maxSize: 6 
    
    amiFamily: ubuntu 
    
    labels: { node-type: amd } 
    
    tags: 
      
       role: application

基于标签的滚动发布：

Kubernetes 不会自动在节点组之间移动 Pod，因此迁移完全由调度规则控制。您可以利用节点选择器 (nodeselector) 以及之前为节点分配的标签，将部署的工作负载调度至新的 AMD 节点组。

		spec: 
  template: 
    spec: 
      nodeSelector: 
        node-type: amd

配置生效后，相应工作负载的新 Pod 仅会被调度到 AMD 节点上。现有 Pod 将继续在原有节点上运行，直到被重新调度（通过滚动发布、节点排空或重启操作），这意味着无需强制中断业务即可平稳推进迁移过程。此策略常用于无状态工作负载，例如 API 后端、微服务、工作进程和 Web 应用，因为在这些场景中 Pod 可以自由重新调度。

基于污点与容忍度的金丝雀部署：

对于需要加强控制的工作负载（例如具有不可预测的性能特征、低延迟要求或长期连接的应用），您可能不希望 Pod 自动调度到新的 AMD 节点上。

污点会阻止 Pod 调度到相应节点上，除非这些 Pod 具有匹配的容忍度。在迁移过程中，污点可帮助防止 Kubernetes 将 Pod 调度到新的 AMD 节点，直到您准备就绪。您可以先用几个具有容忍度的 Pod 进行测试，当一切正常运行后，移除污点并让更多流量流向新节点。

		managedNodeGroups: 
  - name: amd-ng  
 instanceType: m8a.xlarge 
    taints: 
      - key: "cpu" 
        value: "amd" 
        effect: "NoSchedule"

选择金丝雀部署，仅向该部署添加匹配的容忍度。

		spec: 
  replicas: 1 
  template: 
    spec: 
      tolerations: 
        - key: "cpu" 
          operator: "Equal" 
          value: "amd" 
          effect: "NoSchedule" 
      nodeSelector: 
        node-type: amd

配置生效后，仅该部署有资格在 AMD 节点上运行。集群中的所有其他 Pod 将继续在旧节点上运行，即使 AMD 节点处于空闲状态也是如此。您还可以添加节点选择器 (nodeSelector)，以确保金丝雀部署仅在 AMD 节点上运行。

当组织希望先在 AMD 节点上运行一个真正的 Pod 时，通常会采用这种模式，这不是基准测试，也不是预发布流量，而是承载真实请求的实际生产工作负载。如有需要，回滚操作可瞬间完成：移除容忍度设置后，Kubernetes 会将 Pod 重新调度回原来的节点。当金丝雀部署稳定后，您可以进行扩展，为其他服务添加容忍度/选择器，或在 eksctl 配置中移除 AMD 节点组的污点，并重新创建/更新配置以允许正常调度。

基于亲和性的蓝绿部署：

Kubernetes 内的蓝绿部署与虚拟机模式相类似，即并行运行同一应用的两个副本：绿色版本部署在 AMD 节点上，在生产环境中进行验证，然后一步切换流量。

要将绿色部署调度到 AMD 节点上，最简洁的方式就是使用节点亲和性。蓝色部署保持其当前调度规则，而绿色部署则包含一条要求使用 AMD 节点的规则。两者使用独立的 Service（服务）作为前端，以便您可以在切换生产流量之前测试绿色部署堆栈。蓝色和绿色部署通过独立的 Service 对外公开。在验证期间，您可以直接访问绿色部署的 Service，并运行合成检查或影子流量。

		spec: 
   affinity: 
     nodeAffinity: 
          requiredDuringSchedulingIgnoredDuringExecution: 
            nodeSelectorTerms: 
              - matchExpressions: 
                - key: node-type 
                  operator: In 
                  values: ["amd"]

测试完成后，即可开始切换流量。最简单的做法是更新原始 Service 选择器，使其指向绿色部署，从而立即将所有流量重定向至基于 AMD EPYC（霄龙）的应用。由于蓝色部署和绿色部署均已在正常运行，此变更可即时生效且完全可逆。

如果您的客户端使用 ClusterIP Service，则可以通过修补 Service 上的选择器使其指向绿色标签，从而实现流量切换。

		kubectl patch service my-app -n my-namespace -p '{"spec":{"selector":{"app":"my-app-green"}}}'

如果您使用的是 Ingress（流量入口），则可以通过调整权重来逐步增加流向绿色环境的流量（例如，在验证期间将绿色环境权重设为 80%，蓝色环境权重设为 20%）。 

		metadata: 
  name: my-app 
  annotations: 
    kubernetes.io/ingress.class: alb 
    alb.ingress.kubernetes.io/actions.weighted-routing: > 
      {"type":"forward","forwardConfig":{"targetGroups":[ 
        {"serviceName":"my-app-blue-svc","servicePort":"80","weight":20}, 
        {"serviceName":"my-app-green-svc","servicePort":"80","weight":80} 
      ]}}

最终，您可以通过在注解中将绿色环境的权重设置为 100，将流量完全切换至绿色环境：

		metadata: 
  name: my-app 
  annotations: 
    kubernetes.io/ingress.class: alb 
    alb.ingress.kubernetes.io/actions.weighted-routing: > 
      {"type":"forward","forwardConfig":{"targetGroups":[ 
        {"serviceName":"my-app-green-svc","servicePort":"80","weight":100} 
      ]}}

如果您希望同一应用的不同版本之间彼此隔离，或者同一应用在不同实例类型上的部署之间彼此隔离，此方法非常有用。当您需要测试基于 AMD EPYC（霄龙）的实例，同时又不改变现有工作负载规格时，这是一种很好的方案。

使用 Cordon（隔离）和 Drain（排空）机制退役原有节点

无论是通过基于标签的滚动发布、基于污点与容忍度的金丝雀部署，还是蓝绿部署方式，一旦将工作负载成功迁移到 AMD 节点，最后一步便是让原有的节点组安全退役。Kubernetes 为此提供了两个内置机制：Cordon（隔离）和 Drain（排空）。

Cordon 会将节点标记为不可调度，从而阻止新 Pod 被分配到该节点，但现有 Pod 仍会正常运行。Drain 则会正常地将 Pod 从节点中移出，并将其重新调度到集群中的其他位置。

您可以先对原有节点执行 Cordon 操作以阻止新 Pod 被调度，然后再执行 Drain 操作以将现有工作负载安全移出并重新调度到新的 AMD 节点，从而逐步排空这些旧节点。

		kubectl cordon <intel-node-name> 
kubectl drain  <intel-node-name> --ignore-daemonsets --delete-emptydir-data

如果所有工作负载均在基于 AMD 的实例上成功运行且未发现任何问题，即可删除基于旧节点的组，以此清理环境。 

		eksctl delete nodegroup \ 
--cluster  \ 
--name intel-ng

当最后一个旧节点移除后，集群将变为纯 AMD 集群，所有工作负载将继续正常运行且无需更改配置规格。现有的 Service、Ingress、自动扩缩规则和 Pod 规格仍然有效，因为迁移是在节点层而非应用层完成。

结语

迁移至 AMD 云实例并不会带来重大的基础设施变化，不会导致服务中断。由于 AMD 实例兼容 x86 架构，运行相同的操作系统、容器镜像和编排平台，因此迁移的核心问题在于如何引入新节点，而非应用能否在新节点上运行。本指南详细介绍了滚动替换、蓝绿部署和金丝雀部署等模式，许多组织早已使用这些部署策略来进行版本升级；通过采用这些策略，可循序渐进地完成迁移，而且在每一步都能实现全面可观测性和即时回滚。

完成迁移后，组织将获得更灵活的计算能力、更低的云运营支出、更高的单位成本性能、更高的单节点 vCPU 密度、经过优化的许可成本、更出色的性能功耗比，同时还可选用不同云服务提供商提供的更为丰富多样的实例。迁移带来的效率提升意味着，组织可以扩充扩展空间并降低工作负载成本，同时工具链、CI/CD 流程、应用代码及运维流程均可保持不变。无论您是正准备开始迁移，还是已在运行混合型机群，亦或是希望对不同实例和调优模式进行更深入的评估，都欢迎您联系我们。我们非常乐意协助您充分释放现有基础设施的潜力与价值。

Share:

Article By

Profile Image of Noor fairoza Khan

Noor fairoza Khan

Related Blogs

View All Blogs