嘉宾 | 赵明山
随着K8s及云原生理念的普及，尤其是在持续部署流水线出现后，渐进式交付为互联网应用提供了基础设施和实现方法。
2022年7月27日，在由开放原子开源基金会主办的“2022开放原子全球开源峰会”上，阿里云技术专家、OpenKruise Maintainer主要贡献者赵明山（立衡）带来了《OpenKruise Rollout：灵活可插拔的渐进式发布框架》的主题演讲。
渐进式发布（Progressive Rollout）主要区别于全量/一次性发布，主要包括以下特点：
增量式的发布过程，把一次发布分为多个批次，并且可以严格控制每个批次的启动和停止；
实例与流量的双重维度的灰度，如金丝雀发布、A/B Testing发布、蓝绿发布；
阶段性的可验证性，发布的每个批次都可以验证发布的正确性及是否符合预期；
可暂停、可回滚、可继续、可自动化状态流转；
主要应用于提供Service服务的应用，而Job类型一般没有需求。
以一次版本发布为例：Version X ->Version Y
假如线上是X版本，现在需要发布到Y版本。首先会划分发布批次（如第一批只发布10个实例），然后，灰度一定规则的流量到Y版本。如淘宝在进行重大发布变革时，会采用A/B Testing的方式，只将公司员工灰度到新版本，通过日志、监控、测试等方式进行验证，验证通过之后，重复上述过程，完成后续批次的发布。如果在这个过程中发现了任何异常，可以快速回滚到X版本。
渐进式发布与全量发布相比，它最大的优势在于：增加了很多阶段性的验证步骤，极大地提升交付的稳定性及效率。尤其对于大规模场景来说，渐进式发布是必要条件。
在Kubernetes中，所有的Pod都是由工作负载来管理的，其中最常见的两个负载是Deployment和StatefulSet。
Deployment对于升级而言提供了maxUnavailable和maxSurge两个参数，但本质上来讲，Deployment只支持流式的一次性发布，用户并不能控制分批。
StatefulSet虽然支持分批，但跟我们想要的渐进式发布的能力还有较大距离。
OpenKruise是阿里云开源的云原生应用自动化管理套件，也是当前托管在CNCF下的Sandbox项目。在原有的工作负载、Sidecar管理等领域外，OpenKruise目前正在渐进式交付领域进行尝试。
工作负载feature对比
CloneSet是OpenKruise针对无状态应用扩展的工作负载，与K8s原生组件Deployment相比，它增加了很多额外的能力，如支持PVC、指定扩容顺序、支持分批发布等。
工作负载 VS. 渐进式发布
渐进式发布与基础工作负载，在发布能力上是一种包含关系。除了基础的Pod发布外，还有流量发布与进度控制。
Argo Rollouts的设计理念
Argo Rollouts是一个Kubernetes控制器和一组CRD，包含渐进式发布能力的工作负载（类Deployment），为Kubernetes提供高级部署功能，例如蓝绿部署、金丝雀部署、金丝雀分析、实验和渐进式交付功能。Argo Rllouts适用于定制化能力较强、没有存量Deployment工作负载的公司业务。
优点：
工作负载内置Rollout能力，配置简单；
功能丰富，各种发布策略、流量灰度、Metrics分析。
缺点：
不支持社区Deployment、StatefulSet（存量需要迁移）；
独立体系，与社区诸多方案存在Gap（需要定制化）。
Flagger的设计理念
Flagger是一个能使运行在K8s体系上的应用发布流程全自动（无人参与）的工具，它能减少发布的人为关注时间，并且在发布过程中能自动识别一些风险并回滚。
Flagger会创建一个Deployment Primary的工作负载，用户部署的工作负载为原数据，通过Copy Primary方式实现Rollout控制。Flagger适用于规模不大、基于社区方案部署、定制化较小的公司业务。
优点：
支持原生Deployment API，功能丰富；
兼容Helm、Argo-CD等社区方案。
缺点：
Rollout过程双倍Deployment资源消耗；
自建容器服务平台需要额外对接（对K8s资源存在修改，如：名字-Primary）。
Kruise Rollouts的设计理念
百花齐放是云原生的一大特点，阿里云容器团队负责整个容器平台云原生架构的演进，在应用渐进式交付领域也有强烈的需求，因此在参考社区方案以及考虑阿里内部场景的基础上，我们在设计Rollout过程中有以下几个目标：
非侵入性，支持原生Deployment API，不修改任何用户定义资源；
可扩展性，支持Ingress、Gateway等多种资源；
易用性，开箱即用，学习成本低，适用于Helm、Vela等多种部署方案。
Kruise Rollout API设计十分简单，可以分为四个部分。
objectRef：表明Kruise Rollout所作用的工作负载，如Deployment Name；
Strategy：定义Rollout发布的过程，如上图所示，是一个金丝雀发布的示例，第一批发布5%的实例，并且灰度5%流量到新版本，待人工确认后，再进行后续发布；
TrafficRouting：流量灰度所需要的资源Name，如Service、Ingress 或 Gateway API；
Status：展示Rollout的过程以及状态。
Kruise Rollout工作机制
首先，用户基于容器平台做一次版本发布（一次发布从本质上讲就是将K8s资源Apply到集群中）。
Kruise Rollout包含一个Webhook组件，它会拦截用户的发布请求，通过修改Workload Strategy的方式中止Workload控制器的工作；
随后根据用户的Rollout定义，动态调整Workload参数；
批次发布完成后，调整Ingress、Service配置，将特定的流量导入到新版本；
最后，Kruise Rollout通过Prometheus中的业务指标判断发布是否正常。
支持Gateway API（verifying）
Kruise Rollout已经兼容Gateway API，而K8s集群目前使用最多的仍是Ingress。Ingress虽然协议简单，但会导致大量开源项目自定义Network资源的问题。
Gateway API是Network兴趣小组为了解决这个问题所提供的新的API，以替换Ingress。目前Istio、Nginx、Kong等诸多开源产品都实现了这套接口。
支持Deployment原地分批发布（design）
Deployment本身并不支持分批发布，如何做到支持Deployment原地分批发布呢？可以分为以下三个步骤：
将Deployment的资源发布部署到K8s集群中，由Webhook拦截请求；
由Kruise Rollout接管，根据修改的配置，调整升级策略，完成分批发布；
在Kruise Rollout发布结束后，交还由K8s原生的控制器接管。
随着K8s上面部署的应用日益增多，如何做到业务快速迭代与应用稳定性之间的平衡，是平台建设方必须要解决的问题。Kruise Rollout是OpenKruise在渐进式交付领域的新探索，旨在解决应用交付领域的流量调度以及分批部署问题。
Kruise Rollout目前已经正式发布v0.2.0版本，并且与社区OAM KubeVela项目进行了集成，Vela用户可以通过Addons快速部署与使用Rollout能力。此外，也希望社区用户能够加入进来，一起在应用交付领域做更多的扩展。
