K8s 增强版工作负载 OpenKruise（二）

前面我们和大家已经学习了 的基本概念以及 这个控制器的使用，接下来我们将继续学习 中的其他控制器。

Advanced StatefulSet

该控制器在原生的 StatefulSet 基础上增强了发布能力，比如 并行发布、原地升级等，该对象的名称也是 ，但是 apiVersion 是 ，这个 CRD 的所有默认字段、默认行为与原生 StatefulSet 完全一致，除此之外还提供了一些可选字段来扩展增强的策略。因此，用户从原生 StatefulSet 迁移到 ，只需要把 修改后提交即可：

最大不可用

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

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

比如现在我们创建一个如下所示的 Advanced StatefulSet：

直接创建该对象，由于对象名称也是 StatefulSet，所以不能直接用 来获取了，要通过 获取：

该应用下有五个 Pod，并且应用能容忍 3 个副本不可用，当我们把 StatefulSet 里的 Pod 升级版本的时候，可以通过以下步骤来做：

设置 maxUnavailable=3

(可选) 如果需要灰度升级，设置 ，Partition 默认的意思是 order 大于等于这个数值的 Pod 才会更新，在这里就只会更新 P4，即使我们设置了 。

在 P4 升级完成后，把 partition 调整为 0，此时，控制器会同时升级 P1、P2、P3 三个 Pod。注意，如果是原生 StatefulSet，只能串行升级 P3、P2、P1。

一旦这三个 Pod 中有一个升级完成了，控制器会立即开始升级 P0。

比如这里我们把上面应用的镜像版本进行修改，更新后查看 Pod 状态，可以看到有 3 个 Pod 并行升级的：

原地升级

此外 Advanced StatefulSet 也增加了 来允许用户指定重建升级还是原地升级。此外还在原地升级中提供了 graceful period 选项，作为优雅原地升级的策略。用户如果配置了 这个字段，控制器在原地升级的过程中会先把 Pod status 改为 ，然后等一段时间（gracePeriodSeconds），最后再去修改 Pod spec 中的镜像版本。这样，就为 endpoints-controller 这些控制器留出了充足的时间来将 Pod 从 endpoints 端点列表中去除。

如果使用 或 策略，必须要增加一个 ，用来在原地升级的时候控制器将 Pod 设置为 NotReady，比如设置上面的应用为原地升级的方式：

这里我们设置 为 模式，表示尽可能使用原地升级的方式进行更新，此外在 Pod 模板中我们还添加了一个 属性，可以用来确保 Pod 在发生原地更新时保持在 NotReady 状态。比如我们现在使用上面资源清单更新应用，然后重新修改镜像的版本更新，则会进行原地升级：

同样的 Advanced StatefulSet 也支持原地升级自动预热。

也可以通过设置 paused 为 true 来暂停发布，不过控制器还是会做 replicas 数量管理：

另外 Advanced StatefulSet 还支持序号保留功能，通过在 字段中写入需要保留的序号，Advanced StatefulSet 会自动跳过创建这些序号的 Pod，如果 Pod 已经存在，则会被删除。

注意， 是期望运行的 Pod 数量， 是要跳过的序号。

比如上面的描述 的 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]）。

为了避免在一个新 Advanced StatefulSet 创建后有大量失败的 pod 被创建出来，从 Kruise v0.10.0 版本开始引入了在 scale strategy 中的 maxUnavailable 策略，这和 CloneSet 的流式扩容是一样的方式。

当这个字段被设置之后，Advanced StatefulSet 会保证创建 pod 之后不可用 pod 数量不超过这个限制值。比如说，上面这个 StatefulSet 一开始只会一次性创建 个 pod，在此之后，每当一个 pod 变为 running、ready 状态后，才会再创建一个新 pod 出来。

注意，这个功能只允许在 podManagementPolicy 是 的 StatefulSet 中使用。

同样 Advanced StatefulSet 和 CloneSet 提供的生命周期钩子也是一样的，可以通过 字段来设置：

Advanced DaemonSet

同样这个控制器基于原生 上增强了发布能力，比如灰度分批、按 Node label 选择、暂停、热升级等。同样的该对象的 Kind 名字也是 ，只是 apiVersion 是 ，这个 CRD 的所有默认字段、默认行为与原生 DaemonSet 完全一致，除此之外还提供了一些可选字段来扩展增强的策略。

因此，用户从原生 DaemonSet 迁移到 Advanced DaemonSet，只需要把 apiVersion 修改后提交即可：

升级

Advanced DaemonSet 在 中有一个 字段，标识了如何进行滚动升级：

: 对于每个节点，控制器会先删除旧的 daemon Pod，再创建一个新 Pod，和原生 DaemonSet 行为一致，同样也可以通过 或 来控制重建新旧 Pod 的顺序。

: 对于每个 node，控制器会先创建一个新 Pod，等它 ready 之后再删除老 Pod。

: 控制器会尽量采用原地升级的方式，如果不行则重建升级，注意，在这个类型下，只能使用 而不能用 。

创建如下所示的资源对象：

创建后需要通过 来获取该对象：

我们这里只有两个 Work 节点，所以一共运行了 2 个 Pod，每个节点上一个，和默认的 DaemonSet 行为基本一致。此外这个策略还支持用户通过配置 node 标签的 selector，来指定灰度升级某些特定类型 node 上的 Pod，比如现在我们只升级 node1 节点的应用，则可以使用 标签来标识：

更新应用后可以看到只会更新 node1 节点上的 Pod：

和前面两个控制器一样，Advanced DaemonSet 也支持分批灰度升级，使用 Partition 进行配置，Partition 的语义是保留旧版本 Pod 的数量，默认为 0，如果在发布过程中设置了 partition，则控制器只会将 数量的 Pod 更新到最新版本。

同样 Advanced DaemonSet 也是支持原地升级的，只需要设置 为支持原地升级的类型即可，比如这里我们将上面的应用升级方式设置为 即可：

更新后可以通过查看控制器的事件来验证是否是通过原地升级方式更新应用：

不过需要注意目前 Advanced DaemonSet 只支持 PreDelete hook，它允许用户在 daemon Pod 被删除前执行一些自定义的逻辑。

BroadcastJob

这个控制器将 Pod 分发到集群中每个节点上，类似于 DaemonSet，但是 BroadcastJob 管理的 Pod 并不是长期运行的 daemon 服务，而是类似于 Job 的任务类型 Pod，在每个节点上的 Pod 都执行完成退出后， 和这些 Pod 并不会占用集群资源。这个控制器非常有利于做升级基础软件、巡检等过一段时间需要在整个集群中跑一次的工作。

比如我们声明一个如下所示的 对象：

直接创建上面的资源对象，

我们可以看到创建了一个 BroadcastJob 对象后，同时启动了两个 Pod 任务，每个节点上一个，这和原生的 Job 是不太一样的。创建的 BroadcastJob 一共有以下几种状态：

: 期望的 Pod 数量（等同于当前集群中匹配的节点数量）

: 运行中的 Pod 数量

: 执行成功的 Pod 数量

: 执行失败的 Pod 数量

此外在 对象中还可以配置任务完成后的一些策略，比如配置 ，表示这个 job 会在执行结束后 30s 被删除。

配置 为 10，表示这个 job 会在运行超过 10s 之后被标记为失败，并把下面还在运行的 Pod 删除掉。

类型除了 之外还可以设置为 ，表示这个 job 会持续运行即使当前所有节点上的 Pod 都执行完成了。

比如说，用户希望对集群中每个节点都下发一个配置，包括后续新增的节点，那么就可以创建一个 策略的 。

此外也可以配置 表示最多能允许多少个 Pod 同时在执行任务，默认不做限制。比如，一个集群里有 10 个 node、并设置了 为 3，那么 会保证同时只会有 3 个 node 上的 Pod 在执行。每当一个 Pod 执行完成， 才会创建一个新 Pod 执行。

AdvancedCronJob

是对于原生 CronJob 的扩展版本，根据用户设置的 规则，周期性创建 Job 执行任务，而 的 template 支持多种不同的 job 资源：

：与原生 CronJob 一样创建 Job 执行任务

：周期性创建 BroadcastJob 执行任务

AdvancedCronJob

上述 YAML 定义了一个 ，每分钟创建一个 对象，这个 会在所有节点上运行一个 job 任务。

默认情况下，所有 AdvancedCronJob schedule 调度时，都是基于 容器本地的时区所计算的。

在 v1.3.0 版本中引入了 字段，可以将它设置为任意合法时区的名字。例如，设置 则 Kruise 会根据国内的时区计算 schedule 任务触发时间。