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

Posted 2023-02-22 江南飞羽

 

 

为何需要灰度发布

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

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 区别如下：

1）区别：看上图 name/lable.version区别

2）相同点：看上图， selector.k8s-app=dep1 , v1/v2都有这配置，故都关联到同一个svc下

步骤小结

---

整个灰度发布（也称金丝雀Canary发布）过程小结如下：

1）创建v2版本deployment的yaml文件， 切记selector.label.k8s-app=dep1，必须与 v2版本yaml一致（也是selector.label.k8s-app=dep1）

2）v2.yaml 中name不能为dep1, 需修改，如dep-v2

3) kubectl apply -f v2.yaml  , 即可生成2个v2版本的pod， 且与v1关联在同一个service下

4) 验证v2业务监控(4xx/5xx/url/qps)、主机监控(cpu/ram)是否异常， 如正常则继续，否则回滚

5) 删除 kubectl delete -f v1.yaml