关于阿里云开发者:OpenKruise-v0100-版本发布新增应用弹性拓扑管理应用防护等能力

110次阅读

共计 5206 个字符，预计需要花费 14 分钟才能阅读完成。

简介： 阿里云开源的云原生利用自动化治理套件、CNCF Sandbox 我的项目 — OpenKruise，明天公布 v0.10.0 新版本，这也会是 OpenKruise v1.0 之前的最初一个 minor 版本。本文将带你一览 v0.10.0 的新变动，其中新增的 WorkloadSpread、PodUnavailableBudget 等大颗粒个性后续还将有转文具体介绍其设计实现原理。

作者 | 酒祝

背景 **

阿里云开源的云原生利用自动化治理套件、CNCF Sandbox 我的项目 — OpenKruise，明天公布 v0.10.0 新版本，这也会是 OpenKruise v1.0 之前的最初一个 minor 版本。

本文将带你一览 v0.10.0 的新变动，其中新增的 WorkloadSpread、PodUnavailableBudget 等大颗粒个性后续还将有转文具体介绍其设计实现原理。

在利用部署运维的场景下，有着多种多样的拓扑打散以及弹性的诉求。其中最常见、最根本的，就是按某种或几种拓扑程度打散，比方：

利用部署须要按 node 维度打散，防止重叠（进步容灾能力）
利用部署须要按 AZ（available zone）维度打散（进步容灾能力）

这些根本的诉求，通过 Kubernetes 原生提供的 pod affinity、topology spread constraints 等能力目前都可能满足了。但在理论的生产场景下，还有着太多更加简单的分区与弹性需要，以下举一些理论的例子：

按 zone 打散时，须要指定在不同 zone 中部署的比例数，比方某个利用在 zone a、b、c 中部署的 Pod 数量比例为 1 : 1 : 2 等（因为一些事实的起因比方该利用在多个 zone 中的流量不平衡等）
存在多个 zone 或不同机型的拓扑，利用扩容时，优先部署到某个 zone 或机型上，当资源有余时再部署到另一个 zone 或机型上（往后以此类推）；利用缩容时，要按反向程序，优先缩容前面 zone 或机型上的 Pod（往前以此类推）
存在多个根底的节点池和弹性的节点池，利用部署时须要固定数量或比例的 Pod 部署在根底节点池，其余的都扩到弹性节点池

对于这些例子，过来个别只能将一个利用拆分为多个 Workload（比方 Deployment）来部署，能力解决利用在不同拓扑下采纳不同比例数量、扩缩容优先级、资源感知、弹性抉择等场景的根本问题，但还是须要 PaaS 层深度定制化，来反对对一个利用多个 Workload 的精细化治理。

针对这些问题，在 Kruise v0.10.0 版本中新增了 WorkloadSpread 资源，目前它反对配合 Deployment、ReplicaSet、CloneSet 这些 Workload 类型，来治理它们上司 Pod 的分区与弹性拓扑。

以下是一个简化的例子：

apiVersion: apps.kruise.io/v1alpha1
kind: WorkloadSpread
metadata:
  name: workloadspread-demo
spec:
  targetRef:
    apiVersion: apps/v1 | apps.kruise.io/v1alpha1
    kind: Deployment | CloneSet
    name: workload-xxx
  subsets:
  - name: subset-a
    requiredNodeSelectorTerm:
      matchExpressions:
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - zone-a
    maxReplicas: 10 | 30%
  - name: subset-b
    requiredNodeSelectorTerm:
      matchExpressions:
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - zone-b

创立这个 WorkloadSpread 能够通过 targetRef 关联到一个 Workload 对象上，而后这个 Workload 在扩容 pod 的过程中，Pod 会被 Kruise 按上述策略注入对应的拓扑规定。这是一种旁路的注入和治理形式，自身不会干预 Workload 对 Pod 的扩缩容、公布治理。

留神：WorkloadSpread 对 Pod 缩容的优先级管制是通过 Pod Deletion Cost 来实现的：

如果 Workload 类型是 CloneSet，则曾经反对了这个 feature，能够实现缩容优先级
如果 Workload 类型是 Deployment/ReplicaSet，则要求 Kubernetes version >= 1.21，且在 1.21 中要在 kube-controller-manager 上开启 PodDeletionCost 这个 feature-gate

应用 WorkloadSpread 性能，须要在装置 / 降级 Kruise v0.10.0 的时候关上 WorkloadSpread 这个 feature-gate。

上述例子仅为最简化配置，更多应用阐明请参考官网文档，具体的实现原理咱们将会在后续的文章中与大家分享。

在诸多 Voluntary Disruption 场景中 Kubernetes 原生提供的 Pod Disruption Budget（PDB）通过限度同时中断的 Pod 数量，来保障利用的高可用性。

但还有很多场景中，即使有 PDB 防护仍然将会导致业务中断、服务降级，比方：

利用 owner 通过 Deployment 正在进行版本升级，与此同时集群管理员因为机器资源利用率过低正在进行 node 缩容
中间件团队利用 SidecarSet 正在原地降级集群中的 sidecar 版本（例如：ServiceMesh envoy），同时 HPA 正在对同一批利用进行缩容
利用 owner 和中间件团队利用 CloneSet、SidecarSet 原地降级的能力，正在对同一批 Pod 进行降级

这其实很好了解 — PDB 只能防控通过 Eviction API 来触发的 Pod 驱赶（例如 kubectl drain 驱赶 node 下面的所有 Pod），然而对于 Pod 删除、原地降级等很多操作是无奈防护的。

在 Kruise v0.10.0 版本中新增的 PodUnavailableBudget（PUB）性能，则是对原生 PDB 的强化扩大。它蕴含了 PDB 本身的能力，并在此基础上减少了对更多 Voluntary Disruption 操作的防护，包含但不限于 Pod 删除、原地降级等。

apiVersion: apps.kruise.io/v1alpha1
kind: PodUnavailableBudget
metadata:
  name: web-server-pub
  namespace: web
spec:
  targetRef:
    apiVersion: apps/v1 | apps.kruise.io/v1alpha1
    kind: Deployment | CloneSet | StatefulSet | ...
    name: web-server
  # selector 与 targetRef 二选一配置
# selector:
#   matchLabels:
#     app: web-server
  # 保障的最大不可用数量
  maxUnavailable: 60%
  # 保障的最小可用数量
# minAvailable: 40%

应用 PodUnavailableBudget 性能，须要在装置 / 降级 Kruise v0.10.0 的时候关上 feature-gate（两个能够抉择关上一个，也能够都关上）：

PodUnavailableBudgetDeleteGate：拦挡防护 Pod 删除、驱赶等操作
PodUnavailableBudgetUpdateGate：拦挡防护 Pod 原地降级等更新操作

更多应用阐明请参考官网文档，具体的实现原理咱们将会在后续的文章中与大家分享。

在 CloneSet 缩容（调小 replicas 数量）的时候，抉择哪些 Pod 删除是有一套固定算法排序的：

未调度 < 已调度
PodPending < PodUnknown < PodRunning
Not ready < ready
较小 pod-deletion cost < 较大 pod-deletion cost
较大打散权重 < 较小
处于 Ready 工夫较短 < 较长
容器重启次数较多 < 较少
创立工夫较短 < 较长

其中，“4”是在 Kruise v0.9.0 中开始提供的个性，用于反对用户指定删除程序（WorkloadSpread 就是利用这个性能实现缩容优先级）； 而“5”则是以后 v0.10.0 提供的个性，即在缩容的时候会参考利用的拓扑打散来排序。

如果利用配置了 topology spread constraints，则 CloneSet 缩容时会依照其中的 topology 维度打散来抉择 Pod 删除（比方尽量打平多个 zone 上部署 Pod 的数量）
如果利用没有配置 topology spread constraints，则默认状况下 CloneSet 缩容时会依照 node 节点维度打散来抉择 Pod 删除（尽量减少同 node 上的重叠数量）

为了防止在一个新 Advanced StatefulSet 创立后有大量失败的 pod 被创立进去，从 Kruise v0.10.0 版本开始引入了在 scale strategy 中的 maxUnavailable 策略：

apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
spec:
  # ...
  replicas: 100
  scaleStrategy:
    maxUnavailable: 10% # percentage or absolute number

当这个字段被设置之后，Advanced StatefulSet 会保障创立 pod 之后不可用 pod 数量不超过这个限度值。

比如说，下面这个 StatefulSet 一开始只会一次性创立 10 个 pod。在此之后，每当一个 pod 变为 running、ready 状态后，才会再创立一个新 pod 进去。

留神：这个性能只容许在 podManagementPolicy 是 \`Parallel\` 的 StatefulSet 中应用。

除了上述内容外，还有一些变动如：

SidecarSet 新增 imagePullSecrets、injectionStrategy.paused 等字段反对配置 sidecar 镜像拉取 secret 以及暂停注入
Advanced StatefulSet 反对配合原地降级的镜像提前预热

详见 ChangeLog 文档。

本次的 v0.10.0 会是 OpenKruise v1.0 之前的最初一个 minor 版本，在年底之前 Kruise 将会公布首个 v1.0 大版本，敬请期待！

另外，OpenKruise 社区开始组织定期的双周会，从本周四（9 月 9 日）早晨 19:00（GMT+8 Asia/Shanghai）首次开始，本次周会将会解说 v0.10.0 新版本的个性以及 demo 演示。参加形式：

Zoom 会议链接（见文末链接）
退出 OpenKruise 社区交换群（钉钉搜群号 23330762），将会有群直播

更多内容

OpenKruise

https://github.com/openkruise/kruise

topology spread constraints

https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/

Pod Deletion Cost

https://kubernetes.io/docs/reference/labels-annotations-taints/#pod-deletion-cost

官网文档

https://openkruise.io/zh-cn/docs/workloadspread.html

ChangeLog 文档

https://github.com/openkruise/kruise/blob/v0.10.0/CHANGELOG.md

Zoom 会议链接

https://us02web.zoom.us/j/87059136652?pwd=NlI4UThFWXVRZkxIU0dtR1NINncrQT09

Zoom 记录文档

https://shimo.im/docs/gXqmeQOYBehZ4vqo

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

正文完