Kubernetes/k8s 灰度发布 (deployment分批发布）

 

 

为何需要灰度发布

生产环境从来都需要心存敬畏的， 一旦变更失误会严重影响公网顾客的访问和体验，且实践过程中发现，发布和变更是两个重要的故障来源。

IDC迁移到K8S后，虽然K8S配置rolling策略可实现maxSurge=1/n ， 分批升级工作负载deployment， 但分批之间是没有停停顿

---

疼点

1）缺陷：假设deployment_v1一组有10个pod， 内置rolling方式， 发布pod_1更新代码为v2版本后， 中间不作任何等待，就会继续发布pod 2-10,  PRD环境的业务代码是非常脆弱的， 万一v2出现异常， 即使运维/研发发现了异常， 也无法阻止pod2-10更新为v2版本。

2）替代方案：有人说用ISTIO、有人说用nginx-ingress，但感觉实现起来很重。不太适合国内中小企业使用。 最后突然想起selector，配置方法如下

---

灰度发布（selector）

Selector关联deployment_v1 / v2 到同一个service下

 

deployment_v1.yaml 和 v2.yaml 区别如