作者 | 王思宇（酒祝）
起源 | 阿里巴巴云原生公众号
背景
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 等。
- CloneSet：提供了更加高效、确定可控的利用治理和部署能力，反对优雅原地降级、指定删除、公布程序可配置、并行 / 灰度公布等丰盛的策略，能够满足更多样化的利用场景。
- Advanced StatefulSet：基于原生 StatefulSet 之上的加强版本，默认行为与原生完全一致，在此之外提供了原地降级、并行公布（最大不可用）、公布暂停等性能。
- SidecarSet：对 sidecar 容器做对立治理，在满足 selector 条件的 Pod 中注入指定的 sidecar 容器。
- UnitedDeployment：通过多个 subset workload 将利用部署到多个可用区。
- BroadcastJob: 配置一个 job，在集群中所有满足条件的 Node 上都跑一个 Pod 工作。
- Advanced DaemonSet：基于原生 DaemonSet 之上的加强版本，默认行为与原生统一，在此之外提供了灰度分批、按 Node label 抉择、暂停、热降级等公布策略。
- AdvancedCronJob：一个扩大的 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/
- 钉钉交换群：钉钉搜寻群号 23330762