Advanced StatefulSet

这个控制器基于原生 StatefulSet 上增强了发布能力，比如 maxUnavailable 并行发布、原地升级等。

注意 Advanced StatefulSet 是一个 CRD，kind 名字也是 StatefulSet，但是 apiVersion 是 apps.kruise.io/v1alpha1 和 apps.kruise.io/v1beta1。 这个 CRD 的所有默认字段、默认行为与原生 StatefulSet 完全一致，除此之外还提供了一些 optional 字段来扩展增强的策略。

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

  1. -  apiVersion: apps/v1
  2. +  apiVersion: apps.kruise.io/v1beta1
  3.    kind: StatefulSet
  4.    metadata:
  5.      name: sample
  6.    spec:
  7.      #...

注意从 Kruise 0.7.0 开始，Advanced StatefulSet 版本升级到了 v1beta1，并与 v1alpha1 兼容。对于低于 v0.7.0 版本的 Kruise，只能使用 v1alpha1。

MaxUnavailable 策略

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

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

  1. apiVersion: apps.kruise.io/v1beta1
  2. kind: StatefulSet
  3. spec:
  4.   # ...
  5.   podManagementPolicy: Parallel
  6.   updateStrategy:
  7.     type: RollingUpdate
  8.     rollingUpdate:
  9.       maxUnavailable: 20%

比如说，一个 Advanced StatefulSet 下面有 P0 到 P4 五个 Pod，并且应用能容忍 3 个副本不可用。 当我们把 StatefulSet 里的 Pod 升级版本的时候，可以通过以下步骤来做：

  1. 设置 maxUnavailable=3
  2. (可选) 如果需要灰度升级，设置 partition=4。Partition 默认的意思是 order 大于等于这个数值的 Pod 才会更新，在这里就只会更新 P4，即使我们设置了 maxUnavailable=3。
  3. 在 P4 升级完成后，把 partition 调整为 0。此时，控制器会同时升级 P1、P2、P3 三个 Pod。注意，如果是原生 StatefulSet，只能串行升级 P3、P2、P1。
  4. 一旦这三个 Pod 中有一个升级完成了，控制器会立即开始升级 P0。

In-Place Pod Update Strategy

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

  • ReCreate: 控制器会删除旧 Pod 和它的 PVC，然后用新版本重新创建出来。
  • InPlaceIfPossible: 控制器会优先尝试原地升级 Pod，如果不行再采用重建升级。目前，只有修改 spec.template.metadata.* 和 spec.template.spec.containers[x].image 这些字段才可以走原地升级。
  • InPlaceOnly: 控制器只允许采用原地升级。因此，用户只能修改上一条中的限制字段，如果尝试修改其他字段会被 Kruise 拒绝。

当一个 Pod 被原地升级时，控制器会先把 Pod status 中修改为 not-ready 状态，然后再更新 Pod spec 中的 image 字段来触发 Kubelet 重建对应的容器。 不过这样可能存在的一个风险：有时候 Kubelet 重建容器太快，还没等到其他控制器如 endpoints-controller 感知到 Pod not-ready，可能会导致流量受损。

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

  1. apiVersion: apps.kruise.io/v1beta1
  2. kind: StatefulSet
  3. spec:
  4.   # ...
  5.   podManagementPolicy: Parallel
  6.   updateStrategy:
  7.     type: RollingUpdate
  8.     rollingUpdate:
  9.       podUpdatePolicy: InPlaceIfPossible
  10.       inPlaceUpdateStrategy:
  11.         gracePeriodSeconds: 10

更重要的是，如果使用 InPlaceIfPossible 或 InPlaceOnly 策略，必须要增加一个 InPlaceUpdateReady readinessGate，用来在原地升级的时候控制器将 Pod 设置为 NotReady。

一个完整的原地升级 StatefulSet 例子如下：

  1. apiVersion: apps.kruise.io/v1beta1
  2. kind: StatefulSet
  3. metadata:
  4.   name: sample
  5. spec:
  6.   replicas: 3
  7.   serviceName: fake-service
  8.   selector:
  9.     matchLabels:
  10.       app: sample
  11.   template:
  12.     metadata:
  13.       labels:
  14.         app: sample
  15.     spec:
  16.       readinessGates:
  17.          # A new condition that ensures the pod remains at NotReady state while the in-place update is happening
  18.       - conditionType: InPlaceUpdateReady
  19.       containers:
  20.       - name: main
  21.         image: nginx:alpine
  22.   podManagementPolicy: Parallel # allow parallel updates, works together with maxUnavailable
  23.   updateStrategy:
  24.     type: RollingUpdate
  25.     rollingUpdate:
  26.       # Do in-place update if possible, currently only image update is supported for in-place update
  27.       podUpdatePolicy: InPlaceIfPossible
  28.       # Allow parallel updates with max number of unavailable instances equals to 2
  29.       maxUnavailable: 2

升级顺序

Advanced StatefulSet 在 spec.updateStrategy.rollingUpdate 下面新增了 unorderedUpdate 结构，提供给不按 order 顺序的升级策略。 如果 unorderedUpdate 不为空，所有 Pod 的发布顺序就不一定会按照 order 顺序了。注意，unorderedUpdate 只能配合 Parallel podManagementPolicy 使用。

目前，unorderedUpdate 下面只包含 priorityStrategy 一个优先级策略。

优先级策略

这个策略定义了控制器计算 Pod 发布优先级的规则，所有需要更新的 Pod 都会通过这个优先级规则计算后排序。 目前 priority 可以通过 weight(权重) 和 order(序号) 两种方式来指定。

  • weight: Pod 优先级是由所有 weights 列表中的 term 来计算 match selector 得出。如下：
  1. apiVersion: apps.kruise.io/v1beta1
  2. kind: StatefulSet
  3. spec:
  4.   # ...
  5.   updateStrategy:
  6.     rollingUpdate:
  7.       unorderedUpdate:
  8.         priorityStrategy:
  9.           weightPriority:
  10.           - weight: 50
  11.             matchSelector:
  12.               matchLabels:
  13.                 test-key: foo
  14.           - weight: 30
  15.             matchSelector:
  16.               matchLabels:
  17.                 test-key: bar
  • order: Pod 优先级是由 orderKey 的 value 决定，这里要求对应的 value 的结尾能解析为 int 值。比如 value “5” 的优先级是 5，value “sts-10” 的优先级是 10。
  1. apiVersion: apps.kruise.io/v1beta1
  2. kind: StatefulSet
  3. spec:
  4.   # ...
  5.   updateStrategy:
  6.     rollingUpdate:
  7.       unorderedUpdate:
  8.         priorityStrategy:
  9.           orderPriority:
  10.             - orderedKey: some-label-key

发布暂停

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

  1. apiVersion: apps.kruise.io/v1beta1
  2. kind: StatefulSet
  3. spec:
  4.   # ...
  5.   updateStrategy:
  6.     rollingUpdate:
  7.       paused: true

序号保留（跳过）

从 Advanced StatefulSet 的 v1beta1 版本开始（Kruise >= v0.7.0），支持序号保留功能。

通过在 reserveOrdinals 字段中写入需要保留的序号，Advanced StatefulSet 会自动跳过创建这些序号的 Pod。如果 Pod 已经存在，则会被删除。 注意，spec.replicas 是期望运行的 Pod 数量，spec.reserveOrdinals 是要跳过的序号。

  1. apiVersion: apps.kruise.io/v1beta1
  2. kind: StatefulSet
  3. spec:
  4.   # ...
  5.   replicas: 4
  6.   reserveOrdinals:
  7.   - 1

对于一个 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]）。