简介： Kruise 是 Cruise 的谐音，'K' for Kubernetes，寓意 Kubernetes 上应用的航行和自动巡行，它满载着阿里巴巴多年在大规模应用部署、发布与管理最佳实践，以及阿里云 Kubernetes 服务数千客户的需求沉淀。

来源 | 阿里巴巴云原生公众号

作者 | 王思宇（酒祝）

OpenKruise 是由阿里云于 2019 年 6 月开源的云原生应用自动化引擎，本质是基于 Kubernetes 标准扩展出来一个的应用负载项目，它可以配合原生 Kubernetes 使用，并为管理应用容器、sidecar、镜像分发等方面提供更加强大和高效的能力，从而在不同维度上通过自动化的方式解决 Kubernetes 之上应用的规模化运维和规模化建站问题，包括部署、升级、弹性扩缩容、Qos 调节、健康检查、迁移修复等等。

OpenKruise 官网：https://openkruise.io/
GitHub 项目地址：https://github.com/openkruise/kruise

Kruise 是 Cruise 的谐音，'K' for Kubernetes，寓意 Kubernetes 上应用的航行和自动巡行，它满载着阿里巴巴多年在大规模应用部署、发布与管理最佳实践，以及阿里云 Kubernetes 服务数千客户的需求沉淀。

OpenKruise: 阿里巴巴双11 全链路应用的云原生部署基座

在阿里巴巴经济体的整体云原生化过程当中，阿里的技术团队逐渐沉淀出了一套紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。这其中，最重要的无疑是如何对应用进行自动化的发布、运行和管理。于是，阿里云容器团队将这些能力通过 OpenKruise 反哺社区，以期指引业界云原生化最佳实践，少走弯路。

今年双11，阿里巴巴实现了核心系统的全面云原生化。截至 2020 年双11，阿里巴巴内部已运行近十万 OpenKruise 的 workload、管理着上百万容器。

1. 内部运行的 OpenKruise 版本代码超 95% 来自社区仓库

下图展示了阿里巴巴内部运行的 OpenKruise 版本与开源版本之间的关系：

从上图可以看出：Github 上的 OpenKruise 就是我们主体的上游仓库，而内部的下游仓库只基于公共接口实现了极少数内部耦合功能（这部分代码只占据了不到 5%），也就是说阿里巴巴内部运行的 OpenKruise 其中 95% 以上的代码完全来自于社区仓库。

有两点值得说明：

所有通用能力，我们都会直接基于开源仓库开发和提交，然后再同步到内部环境。
社区成员为 OpenKruise 贡献的每一行代码，都将运行在阿里内部环境中。

2. 在 Kubernetes 上自动化应用程序工作负载管理

做上层业务的同学可能对 “应用负载（workload）” 缺乏概念，这里先简单做个介绍。不知道你是否有好奇过，每一次应用扩缩容、发布操作的背后是如何实现的呢？在云原生的环境下，我们都是通过面向终态的方式去描述应用的部署需求（需要的机器数、镜像版本等等），见下图：

应用负载（workload）主要指的就是这个 YAML 定义和对应的控制器：

当应用扩缩容时，PaaS（运维平台）会修改上述 YAML 对象中的需求机器数（比如扩容 10 台改为 110，再缩容 5 台则改为 105），然后控制器就会按照 workload 期望的数量来调整实际运行的 Pod（容器）数量。当应用触发发布或回滚时，PaaS（运维平台）则会修改上述 YAML 对象中的镜像版本和发布策略，控制器就会按照给指定的发布策略来将所有管理的 Pod（容器）重建为期望版本（这只是一些便于理解的简化描述，实际工作机制会复杂得多）。

也就是说，应用负载（workload）管理着应用所有容器的生命周期。不仅应用扩容、缩容、发布都依赖于 workload 的工作，workload 还负责持续维持应用运行时的 Pod（容器）数量，来保证持续有符合期望数量的实例在跑着。如果有宿主机发生故障、上面的应用实例被驱逐，那么 workload 会立即再为应用扩出新的容器。

3. 双11 核心应用全面基于 OpenKruise 部署

随着阿里巴巴经济体上云，双11 主体相关的电商类业务、以及中间件等应用都迁移到了云原生环境下，统一使用 OpenKruise 的应用负载能力做部署。OpenKruise 提供了多种不同类型的 workload 来支持不同的部署方式：

CloneSet：（无状态应用）这是规模最大的部分，绝大部分泛电商业务都是通过 CloneSet 来部署发布。
Advanced StatefulSet：（有状态应用）目前主要是用于中间件在云原生环境的部署。
SidecarSet：（sidecar 生命周期管理）可以将定义好的 sidecar 容器动态注入到新建的 Pod 中，云上的运维容器、 mesh 容器都是通过这种机制加入到业务 Pod 中。
Advanced DaemonSet：将宿主机级别的守护进程部署到所有节点上，包括各种用于给业务容器配置网络、存储的基础组件。

因此，我们看到从上层电商业务到中间件，再到运维容器、基础组件，整个上下游链路都是依赖于 OpenKruise 提供的 workload 做部署和运行。不管是应用运行时的机器数量、版本管理，还是紧急扩容、发布等操作，都有 OpenKruise 无时无刻在维护着。

可以想象，如果 OpenKruise 出现了故障会发生什么？

如果只是控制器挂了，则应用扩缩容、发布操作全量失败。
而如果控制器逻辑存在重大 bug，比如数量或版本号计算错误，甚至可能引起业务容器大规模误删或是升级为错误的版本。

当然，针对以上高危情况，我们做了很多重的防护措施，务必保障业务的稳定可用。

这就是阿里巴巴的云上部署基座，OpenKruise 几乎承载了全量双11 业务的部署管理与运维职责。

4. 主要能力

OpenKruise 从何而来？或者说什么问题或需求促使了 OpenKruise 的诞生呢？

当上云成为大势、当云原生逐渐成为标准，我们却发现 Kubernetes 原生提供的 workload 能力根本无法满足阿里巴巴超大规模业务场景的需求：

应用发布时，所有容器都要飘移重建：对于我们来说几乎无法接受，在发布高峰期如果阿里巴巴的大规模应用都在大规模重建，这是不管对于业务自身还是其他调度器、中间件、网络/存储组件都是一种灾难性的压力。
无状态应用负载（Deployment）无法灰度升级容器。
有状态应用负载（StatefulSet）无法并行升级容器。
还有很多，这里不一一列举......

在这种背景下，OpenKruise 出现了。我们通过或是全新开发（CloneSet、SidecarSet），或是兼容性增强（Advanced StatefulSet、Advanced DaemonSet），来使得上层业务终于可以顺利落地云原生。

OpenKruise 首推的功能就是“原地升级”。通过这种能力，我们终于可以使应用发布不需要将容器飘移重建，而是在原地、原 Pod 上只升级需要更新的镜像。这样带来的好处太多了：

发布效率大大提升。根据不完全统计数据，在大部分业务场景下原地升级至少比完全重建升级提升了 80% 以上的发布速度：不仅省去了调度、分配网络、分配远程盘的耗时，连拉取新版本镜像的时候都得益于 node 上已有旧镜像、只需要拉取较少的增量 layer。
发布前后 IP 不变、升级过程 Pod 网络不断，并且 Pod 中除了正在升级容器之外的其他容器都一直保持正常运行。
Volume 不变，完全复用原容器的挂载设备。
确保了集群确定性，使全链路压测通过后的集群拓扑为大促提供保障。

当然，除此之外我们还增强了许多其他的高级能力，满足了许多种面向大规模场景下的业务诉求，本文不做一一介绍，但下图可以看到 OpenKruise 与 Kubernetes 原生应用负载针对无状态、有状态应用的功能对比：

OpenKruise 已正式进入 CNCF Sandbox

2020 年 11 月 11 日，在这个特殊的时点，阿里巴巴技术人又迎来一件大事：经 CNCF 技术监督委员会全体成员投票，一致同意将阿里云开源的 OpenKruise 正式晋级为 CNCF 托管项目。

正如开篇所说，OpenKruise 已经完成了社区开源，并且内外的版本做到几乎完全一致。除此之外，我们还将 OpenKruise 提供到了阿里云容器服务的应用目录中，公有云上的任意客户都可以一键安装和使用 OpenKruise，真正实现 OpenKruise 在阿里集团内部业务、云产品、开源社区中的“三位一体”。目前在 ACK 上使用 OpenKruise 的客户主要包括斗鱼 TV、申通、有赞等，而开源社区中携程、Lyft 等公司也都是 OpenKruise 的用户和贡献者。

OpenKruise 将基于阿里巴巴超大规模场景锤炼出的云原生应用负载能力开放出来，不仅在云原生社区中补充了扩展应用负载的重要板块，还为云上客户提供了阿里巴巴多年应用部署的管理经验和云原生化历程的最佳实践成果。从正式开源之日起，OpenKruise 项目已经建立多个关键里程碑：

Maintainer 5 位成员来自阿里巴巴、腾讯、Lyft
44 位贡献者
- 国内：阿里云、蚂蚁集团、携程、腾讯、拼多多...
- 国外：微软、Lyft、Spectro Cloud、Dsicord...
1900+ GitHub Stars
300+ Forks

后续，OpenKruise 的重点包括但不限于以下几个目标：