OpenKruise 2021 规划曝光：More than workloads

作者 | 王思宇（酒祝）

背景

OpenKruise 项目地址：https://github.com/openkruise/kruise

OpenKruise 是什么？它是阿里云开源的云原生应用自动化管理引擎，也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀，是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件，一套紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。

值得一提的是，阿里内部使用的 OpenKruise 完全来自于社区版本、代码几乎完全一致。此外，OpenKruise 还被提供到了阿里云容器服务（ACK）的应用目录中，任意云上客户都可以一键安装和使用 OpenKruise。目前在 ACK 上使用 OpenKruise 的客户主要包括斗鱼 TV、申通等，而开源社区中携程、Lyft、有赞等公司也都是 OpenKruise 的用户和贡献者（参考：）。

版本回顾

从 2019 年 6 月开源伊始，OpenKruise 聚焦于云原生应用部署/发布管理相关领域，扩展应用工作负载（workloads）。从最初的 Advanced StatefulSet、BroadcastJob，到“终极”的无状态应用负载 CloneSet、应用 sidecar 容器管理“利器” SidecarSet、多可用区管理负载 UnitedDeployment 等。

• ：提供了更加高效、确定可控的应用管理和部署能力，支持优雅原地升级、指定删除、发布顺序可配置、并行/灰度发布等丰富的策略，可以满足更多样化的应用场景。

• ：基于原生 之上的增强版本，默认行为与原生完全一致，在此之外提供了原地升级、并行发布（最大不可用）、发布暂停等功能。

• ：对 sidecar 容器做统一管理，在满足 selector 条件的 Pod 中注入指定的 sidecar 容器。

• ：通过多个 subset workload 将应用部署到多个可用区。

• : 配置一个 job，在集群中所有满足条件的 Node 上都跑一个 Pod 任务。

• ：基于原生 DaemonSet 之上的增强版本，默认行为与原生一致，在此之外提供了灰度分批、按 Node label 选择、暂停、热升级等发布策略。

• ：一个扩展的 CronJob 控制器，目前 template 模板支持配置使用 Job 或 BroadcastJob。
  

当前 OpenKruise 丰富的 workloads 几乎覆盖了绝大多数通用的应用部署场景，这也是目前社区用户对 OpenKruise 的认知。但 OpenKruise 并不仅仅局限于此，以面向云原生场景的应用自动化为目标，必然不止是“部署”那么简单（当然它并不简单）。

规划一览

在 2021 上半年，OpenKruise 新版本会先围绕应用风险防控、Operator 运行时扩展、daemon 旁路扩展等方面展开，而在此之后，还有增强版本的 HPA、无代码控制器尚在排期中。

1. 风险防控

面向终态的自动化是一把 “双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大。在发生操作故障时副本数维持、版本一致性、级联删除等机制反而很可能导致爆炸半径扩大，例如：

• 错误地删除一个（多个） CRD，所有对应的 CR 都被清理掉。

• 错误地删除一个（多个） workload，其下所有 Pod 都被级联删除。

• 发布时在 workload 中配置错了策略，超过预期数量（甚至全部）的 Pod 被同时升级。

• 批量给 Node 打了一个错误的 taint，导致上面所有 Pod 被驱逐。

• 因为各种各样原因引发的 Pod 批量被删除 ......

在实际的生产集群中存在了各种各样的高危操作，OpenKruise 计划通过一系列可选的风险防控机制来为应用最终的可用性做兜底：

• 定义“禁止级联删除”标签：带这个标签的 CRD、Workload 被删除时，Kruise 会校验如果尚存在 CR 或运行中的 Pod 则拒绝删除。

• 定义 Pod 删除流控策略：用户可以定义一个集群中 Pod 删除的限流值，比如 1 分钟、10  分钟、1 小时、1 天等时间窗口内最多允许删除多少个 Pod，一旦超出阈值则更多的 Pod 删除请求会被拒绝（可以放大限流值解决）。

• 新增 PodUnavailableBudget（PUB）自定义资源：原生 PDB 只能限制 Pod 驱逐，无法限制删除等操作，局限性非常大。而 PUB 将会采取统一机制，对 Pod 删除/驱逐/原地升级 等所有会导致 Pod 变为不可用状态的操作做校验，一旦某个应用的不可用数量超过（或可用数量低于）策略阈值，PUB 会拒绝这个应用下更多的 Pod 操作。

• 支持为 workload 自动生成 PUB/PDB：一般来说用户只会配置自身应用的 workload，不管使用的是原生 Deployment 还是 OpenKruise 的 CloneSet/Advanced StatefulSet，其实只是针对应用部署/发布的定义。我们希望 PUB/PDB 能逐渐成为与每个 workload 配对的保护策略，通过自动匹配生成，尽量在用户无感（或极小改动）的情况下得到完善的应用运行时保护。

2. kruise-daemon

过去 OpenKruise 只是作为一个中心 kruise-controller-manager 组件运行、提供 controller/webhook 服务，因此其实对于单机侧的操作无法介入。接下来，我们会引入 kruise-daemon 作为单机侧组件，支持在 Kubelet 之外的旁路实现扩展：

• 新增镜像预热：通过定义 NodeImage 和 ImagePullJob 实现每台 Node 层面需要执行预热的列表和预热状态上报，以及 ImagePullJob 来指定集群中按什么范围来做规模化预热。

• 通过镜像预热实现发布加速：在 CloneSet、Advanced StatefulSet 等 workload 做原地升级时，Pod 不会发生重建和飘移，仍然在原先节点上做容器重建升级。因此当用户做灰度（partition）原地升级时，OpenKruise 可以提前在未升级 Pod 所在节点做新版本镜像预热，这样在后续 Pod 做升级的过程中就省去了拉镜像所花费的时间，可以有效提升整体应用发布的速度和效率。

• 支持指定容器重启：目前在对 Pod 中某个容器原地升级时，Kubelet 会执行容器重建操作，我们看到不少用户也依赖于这个能力做重启。但原地升级是必须修改 image 镜像的，是否有办法不修改镜像实现重启呢？后续 kruise-daemon 会支持此类操作，不过对于 Pod 容器启动、停止顺序等需求还是无法代替 Kubelet 实现的。

• 提供单机调度优化：通过在调整应用 Pod 的 cgroup 系统来实现单机侧的资源最大化利用和应用 SLO 保障。这是一个探索性的方向，目前尚不确定是否会于 2021 在社区提供稳定版实现。

3. ControllerMesh

Kubernetes 能击败 Mesos/Swarm 等对标产品、成为容器集群调度管理引擎的事实标准，其强大而又灵活的扩展能力功不可没。Operator 既是一种特殊的应用，也是不少有状态应用的自动化管理者。而过去社区整体 Operator 趋势还停留在数量野蛮增长、周边运行时机制却无太大进步，这就导致各类 Controller/Operator 的数量和复杂性也逐渐增加，变得越来越难以理解和管理。

单主问题带来的控制器单点运行，无法负载均衡、无法水平扩展；版本升级一次性切换、无法灰度，A/B 测试、金丝雀等模式都无法实现。另外控制器潜在的爆炸半径大，也没有系统性的防护、速率限制、熔断机制。其他可观测性方面的监控、追踪、度量等也都缺乏统一的方式。

我们希望设计一个方案，能提供对整个控制器运行平面的行为洞察和操作控制的能力，以及一个完整的满足 Controller/Operator 应用各种部署管理与运行时需求的解决方案。这套方案将实现 Operator 分片运行，从而带来水平扩展、灰度升级等能力，除此之外还将会提供故障注入、更灵活的租户隔离、安全防护、可观测性等系统性的平台能力。

总结

目前版本的 OpenKruise 已经提供了丰富的 workloads 与部署发布策略，几乎覆盖了绝大多数通用的应用场景。值此 2021 “牛转乾坤”之际，OpenKruise 打出了“More than workloads”口号，在新的一年里 OpenKruise 将走出现有的应用负载领域，覆盖更多云原生场景、挖掘更深层面的应用自动化需求。我们欢迎每一位云原生爱好者共同参与 OpenKruise 的建设，共同打造业界顶尖的云原生应用自动化引擎！

• Github：
  https://github.com/openkruise/kruise
• Official：
  https://openkruise.io/
• 钉钉交流群：

戳原文，立即了解该项目！