共计 4765 个字符，预计需要花费 12 分钟才能阅读完成。
作者：褚杏娟
采访嘉宾：王思宇（花名：酒祝）
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 我的项目官方主页与文档！！
