Kubernetes应用从AWS迁移至GCP的方法及涉及云服务咨询

先明确你提到的几个服务的定位、关联和对应关系：

• EC2（Elastic Compute Cloud）：AWS的基础虚拟机服务，是AWS所有计算资源的底层载体，EKS集群的工作节点默认就是运行在EC2实例上的，即使选择Fargate无服务器节点，底层本质还是AWS托管的EC2资源
• EKS（Elastic Kubernetes Service）：AWS提供的托管Kubernetes服务，官方负责K8s控制平面（apiserver、etcd、调度器等核心组件）的部署、运维、高可用和版本升级，用户只需要管理工作节点和部署在集群上的业务负载
• Compute Engine：GCP的基础虚拟机服务，和AWS EC2定位完全对等，是GKE集群工作节点的底层承载资源，如果选择GKE Autopilot模式可以完全托管节点，无需自行管理Compute Engine实例
• GKE（Google Kubernetes Engine）：GCP提供的托管Kubernetes服务，和AWS EKS定位对等，GCP负责K8s控制平面的全生命周期管理，是迁移后的K8s业务承载平台

整个迁移优先走无状态负载先迁、验证没问题再迁有状态负载、最后逐步切流量的流程，具体步骤如下：

• 前置检查
  先确认两边集群的K8s大版本差不超过1个小版本，避免API不兼容问题。导出EKS集群所有业务相关的K8s资源配置，可以用命令kubectl get all,cm,secret,ingress,pvc -n <你的业务命名空间> -o yaml > eks-backup.yaml批量导出，也可以用Velero这类集群备份工具做全量备份。
• 配置适配
  导出的配置里所有和AWS强绑定的字段需要替换为GCP对应的配置：
  • 存储类从AWS EBS对应的存储类，替换为GCE Persistent Disk对应的GKE默认存储类
  • Ingress注解从AWS ALB相关的配置，替换为GKE Ingress或者GCP负载均衡对应的注解
  • 服务账号权限配置从AWS IRSA（IAM Roles for Service Accounts）替换为GCP Workload Identity配置
  • 如果应用代码里有调用AWS服务（比如S3、SQS等）的逻辑，也要对应修改为GCP对等服务的调用逻辑
• 部署验证
  配置修改完成后，在GKE集群执行kubectl apply -f <修改后的配置文件路径>完成业务部署，先通过ClusterIP或者NodePort验证内部服务可用性，再通过测试域名验证对外服务的功能是否正常。
• 有状态负载数据迁移
  如果是有状态应用，需要同步持久化数据：可以直接用Velero的备份恢复功能同时迁移K8s资源和PV数据，也可以用存储同步工具将EBS的数据同步到GCE PD后再挂载到GKE的有状态负载上，迁移完成后必须做数据一致性校验。
• 流量切换
  业务验证正常后，先切10%以内的流量到GKE集群观察运行情况，没有异常再逐步调高流量比例，直到100%流量切到GKE，观察稳定后再下线EKS侧的所有相关资源。

• 迁移前务必梳理清楚所有业务依赖的云服务，除了K8s集群本身的资源外，如果用到了AWS的托管数据库、消息队列、对象存储等服务，也要提前准备对应GCP服务的迁移方案，避免漏项
• 建议先在测试环境跑一遍完整的迁移流程，确认所有步骤和配置都没有问题，再操作生产环境的资源

内容的提问来源于stack exchange，提问作者Alberto Piñón Formoso