OpenKruise v0.5.0 版本发布，支持无损的流式分批发布策略

作者 | 酒祝 阿里云技术专家
导读：
OpenKruise 是阿里云开源的大规模应用自动化管理引擎，在功能上对标了 Kubernetes 原生的 Deployment/StatefulSet 等控制器，但 OpenKruise 提供了更多的增强功能如 优雅原地升级、发布优先级/打散策略、多可用区 workload 抽象管理、统一 sidecar 容器注入管理等，都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。目前在阿里巴巴内部云原生环境中，绝大部分应用都统一使用 OpenKruise 的能力做 Pod 部署、发布管理，而不少业界公司和阿里云上客户由于 K8s 原生 Deployment 等负载不能完全满足需求，也转而采用 OpenKruise 作为应用部署载体。在介绍 OpenKruise 新增能力之前，我们先来看一下原生 K8s workload 所提供的发布能力：

以上这些策略在测试环境或是小场景下尚且可行，但其实无法完全满足开发云主机域名大规模的应用场景。比方说：这里我们只针对 v0.5.0 版本 CloneSet 和 SidecarSet 的两个主要功能改动来介绍，有兴趣的同学可以在 Github changelog 上看到版本改动明细：
https://github.com/openkruise/kruise/blob/master/CHANGELOG.md 。在阿里巴巴内部的云原生环境下，绝大部分无状态应用都使用 CloneSet 管理。为了应对超大规模应用的极致部署需求，我们在其中支持：而在今年 2 月份的 Kruise v0.4.0 版本中，我们将 CloneSet 推出到开源。CloneSet 一经发布就广受关注，目前已经有多家知名互联网公司在调研使用。最初版本的 CloneSet 并未支持 maxSurge（先扩后缩发布），只支持了 maxUnavailable、partition 等策略。这对阿里巴巴内部的大体量应用来说不是问题，但是很多社区用户的平台上都有小规模的应用，如果不能配置先扩后缩，那么在发布阶段可能会影响到应用的可用性。在收到社区的 issue
#250
#260 反馈后，我们在 CloneSet 中新增了 maxSurge 策略的支持并于 v0.5.0 版本中提供，在此也感谢社区
fatedier
shiyan2016 等成员的参与贡献和宝贵建议。至此，CloneSet 已经覆盖了 K8s 原生 workload 的所有发布策略，下图构建了 CloneSet 目前提供的发布功能：
这里暂时不对 CloneSet 的发布策略做详细说明，我们后续会有专项文章来介绍。我们只看一下新增的 maxSurge 是如何配合流式、分批发布来实现的呢？接下来我们用几个简单的例子来看一下：当开始发布时，CloneSet 会先根据 maxSurge 多扩出来一个 Pod，此时 Pod 总数为 6（5 个旧版，1 个新版）：随后，CloneSet 会在保证 maxUnavailable 的前提下逐渐把 Pod 删除、新建的方式更新，直到满足 partition=3 即剩余 3 个旧版本 Pod。此时，因为已经达到了期望的终态，CloneSet 会把新版本 Pod 删除一个，此时 Pod 总数为 5（3 个旧版，2 个新版）：这里可以观察一段时间，当需要继续往下发布时，再次修改 partition 为 0。然后，CloneSet 会再次根据 maxSurge 多扩出来一个 Pod，此时 Pod 总数为 6（3 个旧版，3 个新版）：随后，CloneSet 会在保证 maxUnavailable 的前提下逐渐把 Pod 删除、新建的方式更新，直到满足 partition=0 即所有 Pod 都升级到新版本。最后，CloneSet 会把新版本 Pod 删除一个，此时 Pod 总数为 5（5 个新版）：CloneSet 提供了 Pod 原地升级和重建升级两种升级方式，都可以配合 maxSurge / maxUnavailable / partition 等策略来发布。如果在原地升级方式下配置了 maxSurge，CloneSet 会先扩出来 maxSurge 数量的 Pod，然后对旧版本 Pod 采用 in-place 的方式来升级（更新 Pod spec 中的 image 镜像），最后在满足 partition 终态之后再清理删掉 maxSurge 数量的 Pod。通过这种方式，既保证了发布过程的业务可用性，也尽量使 Pod 发布过程中 IP、volume 等信息不变。SidecarSet 是 Kruise 提供的另一个重磅功能，不同于 CloneSet/StatefulSet 这些管理业务 Pod 的 workload，SidecarSet 是负责统一管理集群中的 sidecar 容器版本和注入。而 v0.5.0 版本中新增的功能，就是在 sidecar 容器注入的时候，解决了 SidecarSet 和 Pod 中 volume 重复定义的冲突问题。这也是来自于一个社区 issue
#254 反馈，他们使用 SidecarSet 做日志采集 sidecar 的管理，并期望以旁路的方式注入到所有 Pod 中。举个例子，我们需要往集群中每个 Pod 都注入一个日志采集 sidecar 容器。但是一来我们无法让每个应用开发者都在自己的 CloneSet/Deployment 中增加这个容器的定义，二来即使在所有应用的 workload 中都加了，如果我们想要升级这个日志采集容器的镜像版本，还得更新所有应用的 workload，这样做的成本实在太高了！而 OpenKruise 提供的 SidcarSet 正是为了解决上述这个问题。我们只需要将 sidecar 定义写到一个全局的 SidcarSet 中，不管用户用 CloneSet、Deployment、StatefulSet 等任何方式部署，扩出来的 Pod 中都会注入我们定义好的 sidecar 容器。
以日志采集为例，我们可以先定义一个 SidecarSet：这里大家可能会问，如果每个应用打出日志的目录路径不同，怎么办？不要急，这就是本次 volume merge 的功能所在。这个时候，比如有一个应用 A 扩容的原始 Pod 如下：那么 kruise webhook 就会将 SidecarSet 中定义的 log sidecar 容器注入到 Pod 中：可以看到，因为 SidecarSet 和 Pod 中定义的日志 volume 名字都叫 log-volume，那么在注入的时候就会以 Pod 中定义的 volume 为准。比如这里 Pod 中的 volume 采用了 pvc 的方式来挂载 pv，那么注入 sidecar 后，同样会把这个卷挂到 sidecar 容器中的 /var/log 目录下，然后执行日志采集即可。这样以 SidecarSet 的方式管理 sidecar 容器，既和应用部署发布做了解耦，也同样可以和应用容器共享 volume 卷，来实现日志采集、监控等相关 sidecar 功能。本次 v0.5.0 版本的升级，主要带来了应用无损发布和 sidecar 容器管理上更加便捷的能力。后续 OpenKruise 还会持续在应用部署/发布能力上做出更深的优化，我们也欢迎更多的同学参与到
OpenKruise 社区来，共同建设一个场景更加丰富、完善的 K8s 应用管理、交付扩展能力，能够面向更加规模化、复杂化、极致性能的场景。为了更多开发者能够享受到 Serverless 带来的红利，这一次，我们集结了 10+ 位阿里巴巴 Serverless 领域技术专家，打造出最适合开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。点击即可免费观看课程：
https://developer.aliyun.com/learning/roadmap/serverless“
阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

相关推荐: kubernetes集群安装指南：客户端安装及各组件认证文件创建

大多情况，证书用于服务安全访问（即https访问）所需要，在kubernetes集群中，如果关闭了匿名访问，开启了集群HTTPS访问以及TLS双向认证；如：worker节点组件HTTPS访问apiserver服务时，Apiserver还需要验证客户端是否合法，…