作者：褚杏娟
采访嘉宾 ：王思宇（花名：酒祝）
2021 年 12 月，CNCF 开源项目 OpenKruise 正式宣布了 v1.0 大版本的发布。
OpenKruise 是一个基于 Kubernetes 的扩展套件，主要聚焦在云原生应用的自动化，例如部署、发布、运维以及可用性防护等。更新到 v1.0 版本后，OpenKruise 目前主要提供应用工作负载、Sidecar 管理、增强运维能力、分区部署弹性策略、应用可用性防护等功能，为云原生应用提供落地能力。
目前，OpenKruise 官方登记的 Adopter 数量达到 35+，阿里巴巴、蚂蚁集团、美团、携程、网易、小米、OPPO、苏宁等都在生产环境使用了 OpenKruise 功能，国外如北美的 Lyft、以色列的 Bringg、面向东南亚市场的 Shopee 等也都使用了 OpenKruise。
为更复杂的场景而生
OpenKruise 源于阿里巴巴经济体应用过去多年的大规模应用部署、发布与管理的最佳实践。阿里拥有超大规模的互联网应用场景，而如此丰富的业务线和庞大数量的应用实例绝大部分都是以容器的方式运行在阿里云云原生平台维护的容器集群中。
在 2011 年，阿里就开始发展基于 LXC 的容器技术，随后逐渐完成了集团业务部署的全面容器化。近几年，随着云技术发展和云原生的兴起，阿里将过去的 T4 容器迁移到了新的架构系统 --ASI（Alibaba Serverless Infrastructure）。ASI 在原生 Kubernetes 的基础上，通过标准化扩展的方式提供了更多增强功能和适配阿里集团场景的落地能力，支撑了各种各样的复杂场景和需求。
随着越来越多样化的业务迁移到了 ASI 云原生集群中，阿里开始考虑将这些组件功能开放给全球的 Kubernetes 用户，于是便有了 OpenKruise 开源项目。2019 年 6 月，OpenKruise 的第一个预览版本发布，并在 KubeCon 云原生技术峰会上宣布开源。
在阿里云技术团队看来，开源绝不是仅仅将代码拷贝后开放出来。“我们曾经看到一些开源项目，仅仅是每隔几个月甚至更久的时间将内部代码选择性地拿出一部分更新到 GitHub 上。这绝不是一种健康、可持续的开源方式，无法形成社区凝聚力。”阿里云技术专家王思宇说道。
因此，在最初构想到首个开源版本发布的两个多月时间里，阿里云技术团队主要在解决以下两件事：
- 设计开放的开源与内部协作流程。经过反复斟酌，团队最终决定将 OpenKruise 的基础仓库完全托管在社区，内部仅维护一个 fork 仓库，并不断从 GitHub 上游同步代码进来。因此，OpenKruise 所有功能的开发都是基于 GitHub 协作、提交和评审，所有过程对社区开放，任何人都可以参与。阿里内部的 fork 仓库只保留了少量适配接口，并将内外代码的一致率维持在 95% 以上。
- 制定合理的功能开源路径。ASI 中的扩展功能非常丰富，但并非所有功能都适配任意的原生 Kubernetes，此外很多功能也不够完善，可能存在更好的设计与实现方式。因此，阿里选择先从一些既足够成熟、易用，又能保证足够通用性和向后兼容性的特性开始，逐步将其开放到社区。
2020 年 11 月，阿里将 OpenKruise 捐赠给 CNCF 基金会托管，并将于 2022 年初提出 CNCF Incubation 申请。
为什么说是一次大升级
2021 年 3 月，OpenKruise 发布了 v0.8.0 版本。在这个版本之前，OpenKruise 更多地专注在工作负载（Workload）领域，CloneSet、Advanced StatefulSet、SidecarSet 等功能满足了各种各样业务和容器的部署场景。
但阿里云技术团队认为，OpenKruise 作为一个面向 Kubernetes 应用自动化管理的项目，不应该仅仅局限在应用“部署”上。因此，团队在 2021 年提出了“More than Workloads”的规划，从 v0.8.0 到 v1.0 大版本，OpenKruise 应用管理的支持范围不断扩大。
多种增强的 Workload 类型
首先，在最新的 v1.0 大版本中，OpenKruise 提供了多种增强的 Workload 类型。
王思宇介绍，Kubernetes 原生的 Workload 在真实的生产环境下只能满足 40%~60% 较为简单和通用的场景，但这些不包括来自阿里巴巴等互联网公司的许多超大规模和复杂业务场景。因此，OpenKruise 针对这些场景做了很多改进，比如有对标 Deployment 的无状态应用管理负载 CloneSet 。
下表是 CloneSet 和 Deployment 在扩缩容弹性和发布能力上的差异对比。可以看到，CloneSet 满足了很多真实生产场景下的业务诉求，而这些是 Deployment 所不具备的。
原地升级大幅加强
在 v1.0 版本中，OpenKruise 还对原地升级这一核心功能做了大幅加强。
相比现在开发者使用 Deployment 升级时删除、新建 Pod 的方式，原地升级可以使 Pod 对象、所在 Node、IP、Volume 挂载卷和数据等都不发生任何变化，甚至 Pod 中一个容器进行原地升级时，其他容器保持正常运行。
据了解，在超大规模集群和业务发布高峰的情况下，原地升级相比大量的 Pod 重建升级，不仅保证了发布的稳定性，还优化了 60%~80% 的发布效率。目前有两种主流的原地升级方式：
- 对于容器镜像的原地升级。由 Kruise controller 修改 Pod 中的 image 字段，修改后，kubelet 会感知到 Pod 中对应容器的 hash 值发生了变化，随后把旧的容器停掉，然后用 Pod 中的新容器（镜像）再次执行拉取、创建、启动等操作。
- 对于通过 Downward API 定义的容器环境变量等字段的原地升级。每个节点上的 kruise-daemon 组件将 Downward API 带入容器计算真实的 hash 值。当 hash 值发生变化，也就是 Downward API 引用的 labels/annotations 值被更新，kruise-daemon 就会通过 CRI 接口停掉当前运行的容器，kubelet 发现容器停止后再根据 Pod 将新容器重建出来，从而生效了新的环境变量等配置。
据王思宇介绍，考虑到对企业架构和设计的改动，Kubernetes 社区目前只有针对 VPA，即资源原地升级的提案，而更多的如镜像原地升级等在云原生社区只有 OpenKruise 在做。截至 v1.0 版本，OpenKruise 通过 Downward API 方式，提供了针对容器 image 和 env/command/args 等字段的原地升级。
高可用性防护提升
众所周知，Kubernetes 的面向终态自动化是一把 “双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大。例如“级联删除”机制，正常情况（非 orphan 删除）下，一旦父类资源被删除，那么所有子类资源都会被关联删除：
*删除一个 CRD，其所有对应的 CR 都被清理掉；
删除一个 namespace，这个命名空间下包括 Pod 在内所有资源都被一起删除；
删除一个 Workload（Deployment/StatefulSet/...），则下属所有 Pod 被删除。*
任何一家企业的生产环境中发生大规模误删除都是不可承受的，因此不少社区 Kubernetes 用户和开发者都在抱怨类似 “级联删除” 带来的问题。因此，OpenKruise 开源的首个防护功能，就是对“级联删除”机制的兜底保护。
简单来说，用户在给 CRD、namespace、Workloads 打上防级联删除的标签后，这些资源被调用删除时，Kruise 会帮助用户校验本次删除是否存在级联风险，比如一个 namespace 下还有正在运行和服务的 Pod，那么 Kruise 会禁止直接删除该 namespace，避免误删业务 Pod。
除此之外，OpenKruise 还提供了原生 Pod Disruption Budget（PDB）的增强版本 Pod Unavailable Budget（PUB）。PDB 只是防护 Pod 驱逐操作，而 PUB 防护了所有会导致 Pod 不可用的操作，包括了驱逐操作和更多的 Pod 删除、原地升级等。
运维升级
当前，Kubernetes 在应用运维方面被“吐槽”很多的一点就是，将下层的容器运行时（Container Runtime）封装得太严实。
Runtime 层的容器创建只有一个 Pod 资源，此外没有任何接口可以让用户能够通过 Kubernetes API 层面来执行一些 Runtime 相关操作，比如拉取镜像、重启容器等，但这些都是来自业务场景的现实诉求。
由于 kubelet 缺乏类似于 plugin 的扩展机制，OpenKruise 便创建了一个名为 kruise-daemon 的节点组件。kruise-daemon 可以理解 OpenKruise 定义的一些 CRD 和扩展协议，并与自己所在节点上的 CRI（Container Runtime Interface）通信，传递对节点容器的操作。通过这种方式，OpenKruise 提供了镜像预热、容器重启等 CRD，用户可以通过提交 YAML 来指定需要下发预热的 image 镜像，或指定 Pod 中的一个或多个容器执行重启。
除此之外，OpenKruise 的最新版本还支持资源跨 namespace 分发、容器启动顺序控制等运维功能。前者支持将一份 ConfigMap、Secret 配置分发到一批 namespace 之下，后者则能够帮助用户控制 Pod 中有强依赖关系的多个容器的启动顺序。
下一步：运行时
据王思宇介绍，不同的用户使用 OpenKruise 的侧重点也会不一样。
阿里巴巴、携程等公司实际上已经把 OpenKruise 作为业务部署的统一应用负载。比如阿里巴巴的电商、生活服务等多数业务都是通过 CloneSet 部署和发布管理，而 Nacos 等中间件则是通过 Advanced StatefulSet 部署。有的公司按需使用了部分 OpenKruise 提供的功能，如有的使用 SidecarSet 独立管理、注入和升级 sidecar 容器，也有的只依赖了一些增强运维能力，如镜像预热、容器重启等。
在王思宇看来，目前 OpenKruise 在 Workload 领域已经趋向成熟，可以满足大部分较通用的应用部署发布场景，但围绕 Kubernetes 运行时方面的问题，还有不少值得提升和完善的地方。
“我们已经不止一次收到用户反馈，他们在使用原生 Kubernetes 的 LivenessProbe 探针时出现了 probe 配置错误或探测有误，导致整个应用下的所有 Pod 都发生了异常重启，但在 Pod 中的进程是正常的，从而使得整个应用停止了服务，触发了比较大的故障。”王思宇表示，OpenKruise 接下来会定义一套旁路的 LivenessProbe，并能够让用户定义触发重启时的限流策略，从而避免对应用的全量 Pod 造成不可用的影响。
王思宇透露，OpenKruise 正在研发一个探索性项目——ControllerMesh。该项目使用一个代理容器拦截用户的 operator（controller）与 kube-apiserver 的通信，通过在 Proxy 层对请求 / 返回数据修改和转发，从而实现 operator 的多租部署、动态隔离、灰度升级、故障注入、客户端侧的限流熔断等策略。
“这是一个对 Kubernetes controller 运行时前所未有的强大扩展，并且对于用户 operator 自身无任何侵入。”王思宇说道。
嘉宾介绍：
王思宇（花名：酒祝），阿里云技术专家，OpenKruise maintainer，Kubernetes member，多届 KubeCon 等云原生峰会讲师，有多年超大规模容器和云原生领域的调度编排和管理经验。
戳此处，查看 OpenKruise 项目官方主页与文档！！