共计 4791 个字符，预计需要花费 12 分钟才能阅读完成。
作者 | 王思宇（酒祝）
起源 | 阿里巴巴云原生公众号
前言
OpenKruise 是阿里云开源的大规模利用自动化治理引擎，在性能上对标了 Kubernetes 原生的 Deployment/StatefulSet 等控制器，但 OpenKruise 提供了更多的加强性能，如：优雅原地降级、公布优先级 / 打散策略、多可用区 workload 形象治理、对立 sidecar 容器注入治理等，这些都是经验了阿里巴巴超大规模利用场景打磨出的外围能力，这些 feature 帮忙咱们应答了更加多样化的部署环境和需要、为集群维护者和利用开发者带来了更加灵便的部署公布组合策略。
目前在阿里巴巴外部云原生环境中，利用全副对立应用 OpenKruise 的能力做 Pod 部署、公布治理，而不少业界公司和阿里云上的客户因为 K8s 原生 Deployment 等负载不能齐全满足需要，也转而采纳 OpenKruise 作为利用部署载体。咱们心愿 OpenKruise 能够让每一位 Kubernetes 开发者和阿里云上的用户，都能便捷地应用上阿里巴巴外部云原生利用所对立应用的部署公布能力！
附：OpenKruise 在阿里巴巴的利用参考文章
新版本概览
Kruise 在 2020 年 11 月 16 日公布了最新的 v0.7.0 版本，包含了一些主体性能和优化迭代。以下内容将对新版本做一个整体的概览介绍。
1. Advanced StatefulSet
Advanced StatefulSet 基于原生 StatefulSet 上加强了公布能力，比方 maxUnavailable 并行公布、原地降级等。
官网文档：https://openkruise.io/zh-cn/docs/advanced_statefulset.html
1）OpenKruise 中首个进入 v1beta1 版本的 CRD
过来 OpenKruise 中提供的自定义 workload 均是 v1alpha1 版本，随着阿里巴巴外部和泛滥社区用户的大规模应用，咱们会逐步将稳固的能力降级到更高的版本。本次 Advanced StatefulSet 是首个进入 v1beta1 的 CRD，后续 CloneSet、SidecarSet 等资源也会逐步跟进。
那么对于过来应用 v1alpha1 版本 Advanced StatefulSet 的用户，降级到 v1beta1 版本是否会有问题呢？这里明确地通知大家：是没有危险的。不仅存量的 Advanced StatefulSet 对象会主动转到 v1beta1 版本，而且用户还能够持续沿用 v1alpha1 的接口和客户端来操作新版本的对象。
首先看图中新版本 Advanced StatefulSet 的 CRD 定义：
- 设置了 conversion 字段，其中指定通过 kruise-webhook-service 来提供 convert 服务，这个 service 后端挂载的其实就是 kruise-controller-manager 节点。Kruise 的 MutatingWebhookConfiguration/ValidationWebhookConfiguration 中配置的也是这个 service。
- versions 列表中目前有 v1alpha1 和 v1beta1 两个版本，其中后者的 storage 设置为 true，示意在 etcd 中存储的是这个版本。
再来看图中的 conversion 链路：
- 当用户间接应用 v1beta1 接口操作 Advanced StatefulSet，不须要 conversion 转换，apiserver 间接和 etcd 交互。
-
如果用户应用老版本的 v1alpha1 接口操作 Advanced StatefulSet：
- 写操作：apiserver 会先调用 webhook 将用户写的 v1alpha1 对象转为 v1beta1，并写入 etcd。
- 读操作：apiserver 将来自于 etcd 的 v1beta1 对象通过 webhook 转为 v1alpha1，再返回给用户。
对多版本 conversion 的逻辑有趣味的同学能够浏览源码：https://github.com/openkruise/kruise/blob/master/apis/apps/v1alpha1/statefulset_conversion.go
2）Ordinal 序号保留
通常来说，不论是社区原生 StatefulSet 或是 Advanced StatefulSet，扩容进去的 Pod 以及 PVC 都是间断序号。比方，对于一个 replicas=4 的 StatefulSet，那么创立进去的 Pod 序号则是 [0,1,2,3]。
但有些状况下，用户须要指定删除一个序号的 Pod，并心愿 StatefulSet 临时跳过这个序号。这种需要在应用 Local PV 的场景下尤为突出：当一些节点呈现故障的时候，如果只是删除原 Pod，那么当重建出雷同序号的 Pod 复用了原有的 PVC/PV，还是会调度到原来的节点上。
从 Advanced StatefulSet 的 v1beta1 版本开始（对应 Kruise 版本 >= v0.7.0），咱们提供了序号保留性能：
apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
spec:
# ...
replicas: 4
reserveOrdinals:
- 1 通过在 reserveOrdinals 字段中写入须要保留的序号，Advanced StatefulSet 会主动跳过创立这些序号的 Pod。如果 Pod 曾经存在，则会被删除。留神，spec.replicas 是冀望运行的 Pod 数量，spec.reserveOrdinals 是要跳过的序号。
因而，对于一个 replicas=4, reserveOrdinals=[1] 的 Advanced StatefulSet，理论运行的 Pod 序号为 [0,2,3,4]。
- 如果要把 Pod-3 做迁徙并保留序号，则把 3 追加到 reserveOrdinals 列表中。控制器会把 Pod-3 删除并创立 Pod-5（此时运行中 Pod 为
[0,2,4,5]）。 - 如果只想删除 Pod-3，则把 3 追加到 reserveOrdinals 列表并同时把 replicas 减一批改为 3。控制器会把 Pod-3 删除（此时运行中 Pod 为
[0,2,4]）。
2. CloneSet
CloneSet 控制器提供了高效治理无状态利用的能力，它能够对标原生的 Deployment，但相比之下，CloneSet 提供了很多加强性能。
官网文档：http://openkruise.io/zh-cn/docs/cloneset.html
1）partition 反对百分比
CloneSet 中反对应用 partition 字段管制公布时的灰度数量，过来版本中这个字段只能设置为一个绝对值，而从 v0.7.0 开始能够设置为百分比。它的语义是： 保留旧版本 Pod 的数量或百分比 ，默认为 0。
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
# ...
updateStrategy:
partition: 80% # 示意只将 20% 比例的 Pod 降级为新版本；或者也能够设置为保留旧版本数量的绝对值 如果在公布过程中设置了 partition：
- 如果是数字，控制器会将
(replicas - partition)数量的 Pod 更新到最新版本。 - 如果是百分比，控制器会将
(replicas * (100% - partition))数量的 Pod 更新到最新版本。
2）其余优化点
解决了过来一些边缘场景下的 bug（其中要感激社区同学们的反馈和奉献）：
- 不满足 selector 匹配条件的 Pod 主动去除 owner reference。
- 解决 resourceVersionExpectation 偶发的 race condition。
- 解决应用了 gracePeriodSeconds 优雅原地降级时间断降级的版本笼罩问题。
3. AdvancedCronJob（新增控制器）
AdvancedCronJob 是 v0.7.0 中新增的控制器，它一个 CronJob 的扩大版本，感激来自 Spectro Cloud 的 rishi-anand 的奉献！
原生 CronJob 只反对创立 Job 执行工作，而 AdvancedCronJob 容许用户设置多种不同类型的 template，即用户能够配置 schedule 规定周期性创立 Job 或 BroadcastJob 来执行工作（后者能够散发 Job 到所有或特定 node 上执行工作）。
apiVersion: apps.kruise.io/v1alpha1
kind: AdvancedCronJob
spec:
template:
# Option 1: use jobTemplate, which is equivalent to original CronJob
jobTemplate:
# ...
# Option 2: use broadcastJobTemplate, which will create a BroadcastJob object when cron schedule triggers
broadcastJobTemplate:
# ...
# Options 3(future): ...- jobTemplate：与原生 CronJob 一样创立 Job 执行工作。
- broadcastJobTemplate：周期性创立 BroadcastJob 执行工作。
4. Webhook 自运维控制器
Kruise 运行的 kruise-controller-manager 组件，其中蕴含了多个 controller 和 webhook。
理解 webhook 的同学应该晓得，它须要生成一套残缺的 TLS cert 证书，webhook server 端的 HTTPS 服务启动时应用这个证书，同时要把 ca 证书写到 MutatingWebhookConfiguration、ValidatingWebhookConfiguration、CRD conversion 的 caBundle 中。
因而，对于如何主动生成证书、配置到上述 configuration 资源中，以及如果 configuration 被重置后如何从新写入，都是以后写 webhook 会遇到的运维难题。
Kruise 最新版本中实现了一个 webhook controller，这个控制器反对对 Kruise 本身的 TLS certs 以及相干配置资源做自运维。即：主动生成证书 -> 存储到 secret -> 写到本地供 HTTPS 服务启动应用 -> 将 ca cert 写入 MutatingWebhookConfiguration / ValidatingWebhookConfiguration / CRD conversion，并继续 list watch 这些资源，一旦发生变化，从新刷入 ca 证书。
有趣味的同学能够看源码：https://github.com/openkruise/kruise/blob/master/pkg/webhook/util/controller/webhook_controller.go
后续咱们也会将这部分性能抽出到一个公共仓库中，大家在编写 webhook 的时候能够很不便地复用这套 webhook 自运维能力。
总结
后续，OpenKruise 还会继续在利用自动化上做出更深的优化，本月底会凋谢 OpenKruise 下一步的 Roadmap 布局，咱们将不再局限于 workload 利用治理能力，而会扩大到更多危险防控、operator 加强等畛域。
同时也欢送每一位云原生爱好者独特参加 OpenKruise 的建设。与其余开源我的项目不同，OpenKruise 并不是阿里外部代码的复刻，恰恰相反，OpenKruise Github 仓库是阿里外部代码库的 upstream。因而，你奉献的每一行代码，都将运行在阿里外部的所有 Kubernetes 集群中、都将独特撑持阿里巴巴寰球顶尖规模的云原生利用场景！钉钉搜寻群号：23330762，即可退出交换群！