前言
Kruise Rollout 是 OpenKruise 社区开源提出的一个渐进式交付框架。其设计理念是提供一组能够将流量发布与实例灰度相结合，支持金丝雀、蓝绿、A/B Testing等多样化发布形式，以及支持基于 Prometheus Metrics 等自定义 Metrics 实现发布过程自动化，无感对接、易扩展的旁路式标准 Kubernetes 发布组件。
在最新发布的 Kruise Rollout 0.3.0 版本中，我们为大家带来了几个非常有趣的新特性：一是针对 Kubernetes 社区应用最为广泛的 Deployment 工作负载的发布能力进行了重磅增强；二是对流量灰度能力进行了进一步扩展；三是支持以插入 Lua 脚本的方式来支持更多网关协议的扩展：
-
Deployment 分批发布：Deployment 能够像 StatefulSet 或 CloneSet 一样具有分批发布 Pod 的能力。
-
基于 Header&Cookie 南北向流量灰度：允许用户在发布时对七层流量按照 Header&Cookie 匹配规则进行划分，并将不同流量群体导入不同版本实例，以便对新特性进行 A/B Testing 或进行更细粒度的流量调度。
-
基于 Lua 脚本的 Ingress 流量扩展：允许用户以配置 Lua 脚本的方式，为更多类型的流量组件制定 Kruise Rollout 插件，支持更多类型的 Ingress 扩展协议。
概念说明
在介绍新特性之前，让我们先一起梳理一下目前 Kubernetes 工作负载主流的发布形式：
- 滚动升级：原生 Deployment 自带的主流发布模式，流式滚动升级，无法设置卡点。
-
- 优势：发布效率高；
- 劣势：爆炸半径大，容易出现大规模发布故障。
- 金丝雀发布：Flagger 和 Kruise Rollout 等组件都支持的一种针对 Deployment 的发布模式，在发布时会创建一个金丝雀版本的 Deployment 进行验证，当验证通过后，再进行全量的工作负载升级，并删除金丝雀版本的 Deployment。
-
- 优势：回滚无需重建或重新发布 Pod，所以回滚非常快速和方便；
- 劣势：发布时需要额外的资源消耗，并且需要重复发布新版本 Pod，发布时不能完全兼容 HPA。
完整内容请点击下方链接查看：
developer.aliyun.com/article/117…
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
