《 九 阴 真 经 卷 九 》OpenKruise

《 九 阴 真 经 卷 九 》OpenKruise

https://jimmysong.io/kubernetes-handbook/practice/openkruise.html
https://openkruise.io/zh/

一、OpenKruise

OpenKruise 是阿里云开源的大规模应用自动化管理引擎，于 2021 年 12 月发布 1.0 。在 Kubernetes 原生 Deployment/StatefulSet 等控制器基础上，提供了更多的增强功能如：

应用工作负载：面向无状态、有状态、daemon 等多种类型应用的高级部署发布策略，例如原地升级、灰度流式发布等。
Sidecar 容器管理：支持独立定义 sidecar 容器，完成动态注入、独立原地升级、热升级等功能。
增强运维能力：包括容器原地重启、镜像预拉取、容器启动顺序保障等。
应用分区管理：管理应用在多个分区（可用区、不同机型等）上的部署比例、顺序、优先级等。
应用安全防护：帮助应用在 Kubernetes 之上获得更高的安全性保障与可用性防护。
这些控制器可以帮助开发者应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。

二、扩展控制器

1. CloneSet

CloneSet 是对 Deployment 的增强版，主要用于管理对实例顺序没有要求的无状态应用。
对于 Kubernetes 原生支持的 Deployment 控制器， CloneSet 在以下方面做出了增强：
支持原地升级（In Place Update），需要在 updateStrategy 中配置，默认的升级策略为 ReCreate；

• 支持为每个 Pod 设置 PVC；
• 支持选择性的删除某个 Pod；
• 更加高级的升级和发布策略；

2. AdvancedStatefulSet

AdvancedStatefulSet 是对 Kubernetes 原生的 StatefulSet 的增强。

AdvancedStatefulSet 基本保留了 Kubernetes 原生的 StatefulSet 的使用用法。在声明 AdvancedStatefulSet 时保留了 CRD 的名字 StatefulSet，不过将原来的 apiVersion 的值从 apps/v1 修改为了 apps.kruise.io/v1alpha1 ，并做出的如下方面的增强：

支持原地升级，同 CloneSet 一样，需要在 updateStrategy 中配置，默认的升级策略为 ReCreate；
支持更高级的更新策略，例如根据权重按照特定的顺序更新 pod，而不是按照 pod 的名称顺序；

MaxUnavailable 最大不可用

Advanced StatefulSet 在 RollingUpdateStatefulSetStrategy 中新增了 maxUnavailable 策略来支持并行 Pod 发布，它会保证发布过程中最多有多少个 Pod 处于不可用状态。注意，maxUnavailable 只能配合 podManagementPolicy 为 Parallel 来使用。

这个策略的效果和 Deployment 中的类似，但是可能会导致发布过程中的 order 顺序不能严格保证。 如果不配置 maxUnavailable，它的默认值为 1，也就是和原生 StatefulSet 一样只能 one by one 串行发布 Pod

原地升级

https://developer.aliyun.com/article/765421

Advanced StatefulSet 增加了 podUpdatePolicy 来允许用户指定重建升级还是原地升级。

ReCreate: 控制器会删除旧 Pod 和它的 PVC，然后用新版本重新创建出来。
InPlaceIfPossible: 控制器会优先尝试原地升级 Pod，如果不行再采用重建升级。具体参考下方阅读文档。
InPlaceOnly: 控制器只允许采用原地升级。因此，用户只能修改上一条中的限制字段，如果尝试修改其他字段会被 Kruise 拒绝。

什么是原地升级？

原地升级（In-place update）是一种 Kubernetes 中的 Pod 升级方式，这种升级方式可以更新 Pod 中某一个或多个容器的镜像版本，而不影响 Pod 中其余容器的运行，同时保持 Pod 的网络和存储状态不变。

Kubernetes 原生工作负载，不论是 Deployment、StatefulSet 还是 Pod 本身，如果你想升级 Pod 中的镜像，那么 Kubernetes 就会重新销毁该 Pod 并重新调度并创建一个 Pod，对于 StatefulSet 虽然可以保持原有 Pod 的名字，但是实际 UID 及 Pod IP 都将发生改变。如果你还使用了 Istio，那么在更新 Sidecar 容器的时候，所有植入 Sidecar 容器的 Pod 都需要销毁、重新调度和重建，这将带来极大的开销，同时也影响了业务的稳定性。

原地升级的优势

原地升级的模式极大地提升了应用发布的效率，

节省了调度的耗时，Pod 的位置、资源都不发生变化；
节省了分配网络的耗时，Pod 还使用原有的 IP；
节省了分配、挂载远程盘的耗时，Pod 还使用原有的 PV（且都是已经在 Node 上挂载好的）；
节省了大部分拉取镜像的耗时，因为 Node 上已经存在了应用的旧镜像，当拉取新版本镜像时只需要下载很少的几层 layer；

原地升级自动预热

FEATURE STATE: Kruise v0.10.0

如果你在安装或升级 Kruise 的时候启用了 PreDownloadImageForInPlaceUpdate feature-gate， Advanced StatefulSet 控制器会自动在所有旧版本 pod 所在 node 节点上预热你正在灰度发布的新版本镜像。 这对于应用发布加速很有帮助。

默认情况下 Advanced StatefulSet 每个新镜像预热时的并发度都是 1，也就是一个个节点拉镜像。 如果需要调整，你可以通过 apps.kruise.io/image-predownload-parallelism annotation 来设置并发度。

另外从 Kruise v1.1.0 开始，你可以使用 apps.kruise.io/image-predownload-min-updated-ready-pods 来控制在少量新版本 Pod 已经升级成功之后再执行镜像预热。它的值可能是绝对值数字或是百分比。