【恭喜 OpenKruise 开源项目 在双十一这个阿里人的节日里成为了 CNCF Sandbox 的一员！！】
一、基本介绍
OpenKruise（ https://github.com/openkruise/kruise ）是阿里云开源的 Kubernetes 扩展应用负载项目，同时也是阿里巴巴经济体上云全面使用的部署基座。
基于目前“某些”开源项目的现状，一定有人会问：阿里内部大规模使用的真的是 Github 上这个项目吗？
从图中可以看出：Github 上的 OpenKruise 就是我们主体的上游仓库，而内部的下游仓库只基于公共接口实现了极少数内部耦合功能（这部分代码只占据了不到 5%），也就是说阿里巴巴内部运行的 OpenKruise 其中 95% 以上的代码完全来自于社区仓库。
有两点值得说明：
- 所有通用能力，我们都会直接基于开源仓库开发和提交，然后再同步到内部环境；
- 社区成员给 OpenKruise 贡献的每一行代码，都将运行在阿里内部环境中；
截止 2020 年双十一，阿里巴巴内部已经运行着近十万 OpenKruise 的 workload、管理着上百万的容器。
二、什么是应用负载
做上层业务的同学可能对 “应用负载（workload）” 缺乏概念，这里先简单做个介绍。
不知道你是否有好奇过，每一次应用扩缩容、发布操作的背后是如何实现的呢？在云原生的环境下，我们都是通过面向终态的方式去描述应用的部署需求（需要的机器数、镜像版本等等），见下图：
应用负载（workload）主要指的就是这个 YAML 定义和对应的控制器：
- 当应用扩缩容时，PaaS（运维平台）会修改上述 YAML 对象中的需求机器数（比如扩容 10 台改为 110，再缩容 5 台则改为 105），然后控制器就会按照 workload 期望的数量来调整实际运行的 Pod（容器）数量。
- 当应用触发发布或回滚时，PaaS（运维平台）则会修改上述 YAML 对象中的镜像版本和发布策略，控制器就会按照给指定的发布策略来将所有管理的 Pod（容器）重建为期望版本。
（这只是一些便于理解的简化描述，实际工作机制会复杂得多）
也就是说，应用负载（workload）管理着应用所有容器的生命周期。不仅应用扩容、缩容、发布都依赖于 workload 的工作，workload 还负责持续维持应用运行时的 Pod（容器）数量，来保证持续有符合期望数量的实例在跑着。如果有宿主机发生故障、上面的应用实例被驱逐，那么 workload 会立即再为应用扩出新的容器。
三、为什么说是全链路的部署基座
随着阿里巴巴经济体上云，双十一主体相关的电商类业务、以及中间件等应用都迁移到了云原生环境下，统一使用 OpenKruise 的应用负载能力做部署。OpenKruise 提供了多种不同类型的 workload 来支持不同的部署方式：
- CloneSet：（无状态应用）这是规模最大的部分，绝大部分泛电商业务都是通过 CloneSet 来部署发布。
- Advanced StatefulSet：（有状态应用）目前主要是用于中间件在云原生环境的部署。
- SidecarSet：（sidecar 生命周期管理）可以将定义好的 sidecar 容器动态注入到新建的 Pod 中，云上的运维容器、 mesh 容器都是通过这种机制加入到业务 Pod 中。
- Advanced DaemonSet：将宿主机级别的守护进程部署到所有节点上，包括各种用于给业务容器配置网络、存储的基础组件。
因此，我们看到从上层电商业务到中间件，再到运维容器、基础组件，整个上下游链路都是依赖于 OpenKruise 提供的 workload 做部署和运行。不管是应用运行时的机器数量、版本管理，还是紧急扩容、发布等操作，都有 OpenKruise 无时无刻在维护着。
可以想象，如果 OpenKruise 出现了故障会发生什么？
- 如果只是控制器挂了，则应用扩缩容、发布操作全量失败
- 而如果控制器逻辑存在重大bug，比如数量或版本号计算错误，甚至可能引起业务容器大规模误删或是升级为错误的版本
（当然，针对这类高危情况，我们做了很多重的防护措施，务必保障业务的稳定可用）
这就是阿里巴巴的云上部署基座，OpenKruise 承载了几乎全量双十一业务的部署管理与运维职责。
四、解决了什么问题
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 已经完成了社区开源，并且内外的版本做到几乎完全一致。除此之外，我们还将 OpenKruise 提供到了阿里云容器服务的应用目录中，公有云上的任意客户都可以一键安装和使用 OpenKruise。目前 ACK 上有不少已经在使用 OpenKruise 的客户，包括斗鱼TV、申通、有赞等，而开源社区中携程、Lyft等公司也都是 OpenKruise 的重度用户和贡献者。
OpenKruise 将基于阿里巴巴超大规模场景锤炼出的云原生应用负载能力开放出来，不仅在云原生社区中补充了扩展应用负载的重要板块，还为云上客户提供了阿里巴巴多年应用部署的管理经验和云原生化历程的最佳实践成果。
后续，OpenKruise 的重点包括但不限于以下几个目标：
- 继续将阿里巴巴内部沉淀的通用云原生应用自动化能力输出，走可持续的三位一体发展战略
- 深度挖掘细分领域的应用负载需求，比如我们正在探索针对 FaaS 场景的池化能力
- 与其他相关领域的开源产品做更紧密的结合，如 OAM、kubevela 等，打造更完整的云原生应用体系
如果你对 OpenKruise 的发展有任何建议，可以在下方评论。另外，我们衷心欢迎每一位开源爱好者来参与 OpenKruise 的建设，共同打造云原生领域最成熟、面向最大规模的应用自动化引擎。