如何将现有Standard GKE集群迁移至Autopilot GKE集群

GKE 目前没有提供原地把 Standard 集群转换为 Autopilot 模式的能力，全量迁移走新建集群+资源搬迁+流量切流的路径最稳妥，按以下步骤执行即可：

一、迁移前准备与兼容性校验 #

• 先扫一遍工作负载兼容性：Autopilot 是谷歌托管节点的模式，有强制的安全约束和资源规格要求，提前把原集群所有工作负载配置拉出来核对：禁止特权容器、默认不允许hostPath直接挂载、Pod的CPU/内存request必须满足Autopilot最小规格（CPU不低于100m、内存不低于128Mi），如果原来配置了自定义节点污点、节点选择器绑定特定机型，要提前调整，避免迁过去后Pod一直Pending。
• 导出全量业务资源：执行命令kubectl get all,configmap,secret,ingress,pvc,serviceaccount,role,rolebinding -A -o yaml > standard-all-resources.yaml把所有命名空间下的业务相关资源导出即可，kube-system、gke-managed这类命名空间下的GKE托管系统资源不用导，Autopilot集群会自动部署对应组件。导出后清理掉资源文件里Standard集群独有的注解、资源版本不兼容的字段，避免部署时报错。
• 基础环境对齐：新建Autopilot集群时和原Standard集群部署在同一个VPC下，规划好不冲突的Pod网段、Service网段，提前放通两个集群之间的网络访问策略；如果用到了Cloud Load Balancing、Cloud DNS、SSL证书这类云服务周边资源，提前规划好流量切换路径，避免切流时出现访问中断。
• 有状态服务提前备份：如果集群内运行了数据库、消息队列这类带持久化存储的服务，提前给对应持久化盘打快照，不建议直接把原集群的PV挂到新集群，Autopilot默认用GCE PD CSI驱动挂载存储，和旧版in-tree存储驱动存在兼容差异，用快照在新集群新建PVC恢复数据最稳妥。

二、零停机迁移执行步骤 #

• 先部署非核心无状态服务：把清理好的资源文件先应用到Autopilot集群，优先部署非核心、无依赖的无状态服务，验证服务启动正常、日志无报错、依赖访问通畅，这个阶段所有线上流量还是走原Standard集群，不会影响业务。
• 配置跨集群访问能力：通过CoreDNS配置转发、GKE服务目录等方式打通两个集群的服务发现，保证两边服务可以互相访问，方便后续灰度切流。
• 灰度切流验证：在入口层（通常是Ingress/负载均衡）按比例切少量流量（比如10%）到Autopilot集群的对应服务，持续观察错误率、请求延迟、资源使用率等核心指标，跑满1-2个完整业务周期没有异常后，再逐步提升流量比例直到100%切到新集群。
• 有状态服务切换：等所有无状态服务全量切流验证稳定后，再处理有状态服务：先暂停原集群有状态服务的写入流量，等数据同步追平（如果提前做了双写同步就校验数据一致性），再在Autopilot集群启动有状态服务接入流量，验证读写正常。
• 预留回滚窗口：迁移完成后不要立刻删除原Standard集群，至少保留7天的兜底回滚周期，期间如果新集群出现问题可以立刻把流量切回原集群，故障恢复后再重新推进迁移。

三、迁移后校验 #

• 工作负载状态校验：执行kubectl get pods -A检查所有业务Pod状态，确认没有CrashLoopBackOff、Pending等异常，如果出现Pending优先看事件日志，基本都是资源请求不符合Autopilot规格、安全策略拦截导致的，对应调整配置即可。
• 业务逻辑校验：挨个验证核心业务接口、定时任务、消息消费、外部依赖调用链路，确保没有功能异常、没有丢流量的情况。
• 成本与性能调优：Autopilot按Pod实际申请的资源计费，稳定运行3天左右核对成本监控、性能监控，调整不合理的资源request配置，避免资源浪费。

踩坑提醒：不要尝试在原Standard集群上执行修改模式的操作尝试原地转Autopilot，这个操作目前不被官方支持，直接操作有概率把整个集群搞挂，生产环境禁止这么做。

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