为何需要灰度发布
生产环境从来都需要心存敬畏的, 一旦变更失误会严重影响公网顾客的访问和体验,且实践过程中发现,发布和变更是两个重要的故障来源。
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)相同点:看上图,