基于蓝绿部署的EKS 1.21至1.27/1.28版本迁移方案咨询

一、前期准备 #

• 导出原集群全量资源：执行 kubectl get all -A -o yaml > cluster-resources.yaml 备份所有应用、组件资源，同时单独记录StorageClass、CRD、自定义控制器这类易遗漏的资源
• 做应用兼容性校验：检查应用使用的K8s API版本，比如1.21常用的extensions/v1beta1 Ingress需替换为networking.k8s.io/v1，podsecuritypolicy在1.25已移除，需提前用Pod Security Admission替代
• 升级工具链：将eksctl、kubectl升级到匹配目标版本的最新稳定版，避免集群创建或资源部署时出现兼容性问题
• 备份核心数据：通过AWS控制台或eksctl utils snapshot-cluster生成ETCD快照，同时备份数据库、持久化卷的业务数据

二、搭建绿色集群（目标版本） #

• 创建目标版本集群，以1.28为例：

  eksctl create cluster --name green-eks --version 1.28 --region cn-north-1 --nodegroup-name ng-green --node-type m5.large --nodes 3 --node-volume-size 20
  

• 同步原集群核心配置：
  • 复制原集群的节点IAM角色策略、Pod IAM角色（IRSA）到绿色集群，确保组件、应用权限一致
  • 创建与原集群相同的StorageClass、ConfigMap、Secret，避免应用启动时依赖缺失
  • 部署基础组件：安装适配目标版本的ALB Ingress Controller、Metrics Server、日志采集组件，验证组件运行状态
• 集群健康检查：执行kubectl get nodes确认节点就绪，kubectl get pods -n kube-system检查系统组件无异常

三、应用迁移与验证 #

• 部署应用到绿色集群：
  • 调整资源清单中的API版本后，执行kubectl apply -f adjusted-app-manifests.yaml部署应用
  • 有状态应用先恢复数据到绿色集群PVC，比如通过备份工具将MySQL数据导入新集群的数据库实例
• 业务验证：
  • 通过临时NodePort或测试Ingress访问绿色集群的应用，验证核心业务逻辑、接口响应正常
  • 检查监控指标（CPU、内存、请求延迟），确认资源使用符合预期
  • 验证持久化数据的读写、同步功能正常

四、流量切换（蓝绿核心环节） #

• 流量灰度切换：
  • 若使用AWS Route 53，将原域名的解析记录添加绿色集群ALB的权重路由（初始权重设为10，原集群设为90）
  • 若使用Nginx Ingress，可通过修改Ingress的后端服务指向绿色集群，或调整DNS指向绿色集群的Ingress IP
• 逐步放量：
  • 每间隔1-2小时提升绿色集群的流量比例（10%→30%→50%→100%），每次切换后监控业务报错、延迟指标
  • 全量切换后持续监控24小时，确认无异常

五、旧集群清理 #

• 确认绿色集群稳定后，停止原EKS 1.21集群的所有应用
• 删除原集群资源：

  eksctl delete nodegroup --name ng-blue --cluster blue-eks
  eksctl delete cluster --name blue-eks
  

• 清理关联资源：删除原集群绑定的负载均衡器、闲置EBS卷、无人使用的IAM角色

关键踩坑点 #

• 1.25版本移除了PodSecurityPolicy，必须提前用Pod Security Admission配置对应权限，否则应用可能无法启动
• IRSA配置需严格同步原集群的OIDC提供商、角色信任关系，避免应用访问AWS服务时权限不足
• 有状态应用迁移时，建议先做增量数据同步，再进行短时间停机切换，确保数据一致性
• 切换流量前准备好回滚方案：一旦出现异常，立即将流量切回原集群，排查问题后再重试

内容的提问来源于stack exchange，提问作者sof23