OpenKruise v0.10.0 版本发布:新增应用弹性拓扑管理、应用防护等能力

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
函数计算FC,每月15万CU 3个月
可观测监控 Prometheus 版,每月50GB免费额度
简介: 阿里云开源的云原生应用自动化管理套件、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 等大颗粒特性后续还将有转文详细介绍其设计实现原理。



新功能概览


1.  WorkloadSpread:旁路的应用弹性拓扑管理能力


在应用部署运维的场景下,有着多种多样的拓扑打散以及弹性的诉求。其中最常见、最基本的,就是按某种或几种拓扑水平打散,比如:


  • 应用部署需要按 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。


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


2.  PodUnavailableBudget:应用可用性防护


在诸多 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 原地升级等更新操作


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


3.  CloneSet 支持按拓扑规则缩容


在 CloneSet 缩容(调小 replicas 数量)的时候,选择哪些 Pod 删除是有一套固定算法排序的:

  1. 未调度 < 已调度
  2. PodPending < PodUnknown < PodRunning
  3. Not ready < ready
  4. 较小 pod-deletion cost < 较大 pod-deletion cost
  5. 较大打散权重 < 较小
  6. 处于 Ready 时间较短 < 较长
  7. 容器重启次数较多 < 较少
  8. 创建时间较短 < 较长


其中,“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 上的堆叠数量)


4.  Advanced StatefulSet 支持流式扩容


为了避免在一个新 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 中使用。


5.  其他


除了上述内容外,还有一些变动如:

  • 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

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
0
0
0
12605
分享
相关文章
OpenKruise v1.6 版本解读:增强多域管理能力
OpenKruise 在 2024.3 发布了最新的 v1.6 版本(ChangeLog),本文对新版本的核心特性做整体介绍。
165018 7
阿里云 EMR 发布托管弹性伸缩功能,支持自动调整集群大小,最高降本60%
阿里云开源大数据平台 E-MapReduce 重磅推出托管弹性伸缩功能,基于 EMR 托管弹性伸缩功能,您可以指定集群的最小和最大计算限制,EMR 会持续对与集群上运行的工作负载相关的关键指标进行采样,自动调整集群大小,以获得最佳性能和资源利用率。
阿里云服务网格ASM多集群实践(二):高效按需的应用多环境部署与全链路灰度发布
介绍服务网格ASM提出的一种多集群部署下的多环境部署与全链路灰度发布解决方案。
云原生网关部署新范式丨 Higress 发布 1.1 版本,支持脱离 K8s 部署
基于 Nacos 的注册中心/配置中心能力,实现了无需依赖 K8s,也能使用 Ingress API 管理网关路由。
阿里云 Serverless 容器服务全面升级:新增组件全托管、AI 镜像秒级拉取能力
阿里云 Serverless 容器服务全面升级:新增组件全托管、AI 镜像秒级拉取能力
PrometheusOperator云原生监控:基于operator部署的资源内部链路分析
PrometheusOperator云原生监控:基于operator部署的资源内部链路分析
221 0
OpenKruise v1.3:新增自定义 Pod Probe 探针能力与大规模集群性能显著提升
在版本 v1.3 中,OpenKruise 提供了新的 CRD 资源 PodProbeMarker,改善了大规模集群的一些性能问题,Advanced DaemonSet 支持镜像预热,以及 CloneSet、WorkloadSpread、Advanced CronJob、SidecarSet 一些新的特性。
Serverless Kubernetes 再升级 | 全新的网关能力增强
这里给大家介绍一下如何在 Serverless Kubernetes 中提供网关能力增强。
Serverless Kubernetes 再升级 | 全新的网关能力增强
阿里云服务网格 ASM 发布新功能:提供更精细化的服务治理能力
服务网格作为服务间通信的基础设施层,吸引了越来越多的用户使用。阿里云服务网格 ASM 将继续为开发者带来便利。9月1日,阿里云服务网格( ASM )产品经理问思为大家解读近期 ASM 发布的一些新功能。

云原生

+关注
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等