Kubernetes滚动发布时，如何测试单个新Pod并仅在通过后部署剩余Pod？

完全可行，这种发布逻辑属于**金丝雀发布（灰度发布）**的变种，能有效降低新版本上线的风险，避免批量发布故障影响全量用户。

以下是几种落地实现方式：

1. 基于原生Deployment参数+手动/脚本验证 #

• 先调整Deployment的滚动更新策略，限制仅先启动1个新Pod：

  spec:
    strategy:
      rollingUpdate:
        maxSurge: 1  # 仅允许额外创建1个新Pod
        maxUnavailable: 0  # 不允许旧Pod被销毁
      type: RollingUpdate
  

• 触发Deployment更新后，等待新Pod进入Running且就绪（Ready）状态。
• 通过CI/CD脚本或手动方式对该Pod执行测试：比如用kubectl exec <新Pod名称> -- <容器内测试命令>运行单元/集成测试，或者调用Pod的业务接口做功能验证。
• 测试通过后，将maxSurge调整回常规值（比如25%或固定数值），让Deployment自动完成剩余Pod的滚动更新；如果测试失败，直接执行kubectl rollout undo deployment/<部署名>回滚即可。

2. 用Argo Rollouts实现自动化渐进发布 #

• Argo Rollouts是Kubernetes生态中专门用于渐进式发布的工具，支持更精细的发布流程控制。
• 可以在Rollout资源中配置分析任务（AnalysisRun），自动对新启动的单个Pod运行预设测试用例，只有测试通过后，才会自动推进发布流程（逐步扩容新版本、缩容旧版本）；测试失败则自动触发回滚。
• 核心思路：定义Rollout的金丝雀策略，设置初始新版本副本数为1，绑定分析任务完成验证，验证通过后按比例逐步提升新版本副本占比直至发布完成。

3. 自定义CI/CD流水线分步执行 #

• 在CI/CD流程中拆分布发布步骤，完全控制每一个环节：
  • 第一步：通过kubectl patch更新Deployment，仅启动1个新版本Pod（比如临时调整副本数+1并指定新版本镜像）。
  • 第二步：等待新Pod就绪后，通过Service定向访问或直接使用Pod IP执行测试验证。
  • 第三步：测试通过则执行完整的Deployment滚动更新；测试失败则删除该新Pod并回滚至旧版本镜像。

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