OpenKruise v1.8版本解读：解锁云原生应用管理的无限可能-阿里云开发者社区

【阅读原文】戳：OpenKruise v1.8版本解读：解锁云原生应用管理的无限可能

OpenKruise[1]是阿里云开源的云原生应用自动化管理套件，也是当前托管在Cloud Native Computing Foundation(CNCF)下的孵化项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀，是阿里内部生产环境大规模应用的基于Kubernetes之上的标准扩展组件，也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。

OpenKruise在2025年2月发布了最新的1.8版本（ChangeLog[2]）。此版本带来了诸多重要的更新与增强，致力于进一步提升云原生应用管理的效率、弹性和可靠性。Kruise 1.8的主要亮点包括工作负载支持原地VPA、Advanced StatefulSet支持卷的原地扩容能力、WorkloadSpread对AI工作负载的支持以及PodProbeMarker扩展Serverless场景协议等。这些新特性将帮助用户更好地管理其在Kubernetes上的云原生应用，并提升整体的应用管理体验。

1. 率先拥抱原地VPA，释放资源管理新潜能

随着Kubernetes的不断发展，资源管理的灵活性和效率始终是用户关注的核心问题。在Kubernetes 1.27中，一个令人兴奋的新特性InPlacePodVerticalScaling（原地VPA）被引入。尽管目前仍处于Alpha阶段（截至Kubernetes 1.32），这一特性为Pod资源管理带来了革命性的变化：它允许用户在不重建Pod的情况下动态调整其资源配额。这不仅极大地提升了资源管理的灵活性，还为应对业务需求的变化提供了更快速、更高效的解决方案。

想象一下，在业务高峰期，您可以轻松增加Pod的CPU和内存资源以满足性能需求；而在低谷期，您又能迅速缩减资源以节省成本，这一过程无需Pod的重建或容器的重启，实现了服务无中断的资源管理实时响应。这种能力将显著优化资源利用率，并帮助企业在动态环境中保持竞争力。

然而，作为一个尚处于早期阶段的功能，InPlacePodVerticalScaling目前尚未被原生工作负载集成，距离生产环境的广泛应用还有一定的距离。如何让这一潜力巨大的特性更快地服务于用户？答案就在Kruise 1.8。

作为Kubernetes生态中的重要开源项目，Kruise始终站在技术前沿，致力于为用户提供更加灵活、高效的工作负载管理能力。在Kruise 1.8中，我们率先探索并集成了InPlacePodVerticalScaling特性，将其与Kruise的高级工作负载（如CloneSet、Advanced StatefulSet和Advanced DaemonSet）相结合，为用户带来前所未有的资源管理体验。

1.1. 启用方式

1. 确保Kubernetes集群开启InPlacePodVerticalScaling特性。

2. 安装/升级Kruise时启用InPlaceWorkloadVerticalScaling。

3. 配置更新策略为InPlaceIfPossible或InplaceOnly。

1.2. 当前能力与局限

• 资源类型：仅支持CPU和内存资源的调整。

• 环境限制：在Cgroupv1环境下，存在一定的限制。

• 调整限制：资源调整涉及Pod QoS变更时，会自动退化到Pod重建。

1.3. 示例配置

apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
  template:
    spec:
      containers:
      - name: example-container
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m" # 1 -> 500m / 2
  updateStrategy:
    type: InPlaceIfPossible

关键提示：

• Kubernetes InPlacePodVerticalScaling特性仍在持续演进，生产环境使用需谨慎评估

• 持续关注社区最新进展

2. 重新定义有状态工作负载的存储管理

在Kubernetes的发展历程中，卷扩展（Volume Expansion）[3]功能自1.8版本引入，并于1.24版本正式成为通用特性（GA）。然而，内置的StatefulSet管理的持久卷声明（PVC）却始终未能充分利用这一功能。用户不得不依赖手动批量更新PVC的方式来进行容量运维，而新增的PVC仍然保持原有的容量配置。这种局限性使得有状态工作负载的存储管理变得复杂且低效。

Kruise，作为Kubernetes生态中的重要开源项目，敏锐地捕捉到了这一需求，并致力于填补这一空白。从早期版本开始，Kruise就允许用户通过直接修改StatefulSet的卷模板来管理新增PVC的容量。而在最新的Kruise 1.8中，我们更进一步，推出了对StatefulSet卷的原地扩容支持，致力于革新有状态应用的存储管理方式。

2.1. 核心亮点：无缝扩展，极简运维

1. 原地扩容：无需重启Pod或迁移数据

对于有状态应用而言，存储容量的扩展往往伴随着高昂的运维成本和潜在的应用停机风险。Kruise 1.8的原地扩容功能允许用户直接增加由Advanced StatefulSet管理的PVC容量，而无需重启Pod或进行数据迁移。这不仅显著减少了应用的停机时间，还极大地简化了存储管理流程。

2. 灰度变更：结合滚动更新策略

Kruise 1.8还引入了与Pod滚动顺序相结合的灰度变更机制。通过这种方式，用户可以逐步、安全地将存储容量扩展应用于现有的PVC，确保变更过程平稳可靠，最大限度地降低对业务的影响。

3. 自动化管理：告别手动操作

过去，用户需要手动批量更新PVC配置，既繁琐又容易出错。现在，借助Kruise的自动化管理能力，您可以轻松实现对新增及现有PVC的统一管理，显著提升运维效率。

2.2. 功能限制

1. 使用的Kubernets集群需要开启Volume Expansion或者高于1.24版本。

2. 需要扩容的PVC对应的storage class必须是CSI管理的，且支持卷扩展。您可以通过查看对应的storage class对象allowVolumeExpansion字段来判断。

3. 要使用此功能，需要在安装或升级Kruise时启用 StatefulSetAutoResizePVCGate Feature Gate。

2.3. 使用示例

通过配置volumeClaimUpdateStrategy字段来控制卷的更新策略，包括OnPodRollingUpdate和OnDelete两种模式。OnPodRollingUpdate模式允许在Pod滚动更新期间自动调整PVC大小，而OnDelete模式则需要在手动删除旧PVC后才会使用新的卷模板重新创建PVC。这项功能极大地提升了管理有状态应用存储的灵活性和效率，使得在存储需求变化时能够更加便捷地进行调整。示例配置如下：

apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
spec:
  # ...
  volumeClaimUpdateStrategy:
    # 可选值有 OnPodRollingUpdate 和 OnDelete
    #   OnPodRollingUpdate ：controller 会在 pod 升级过程中自动扩容 pvc
    #   OnDelete ：controller 只会在 pvc 删除后使用新的 volume claim template 重建 pvc
    #             即 kruise 1.7 版本之前默认的 pvc 更新策略。
    type: OnPodRollingUpdate 
  volumeClaimTemplates:
    # ...
    spec:
      resources:
        requests:
          storage: 2Gi # 1Gi -> 2Gi
      storageClassName: allow-volume-expansion

在对advanced statuefulset spec进行修改后，你可以通过观察status中字段的变化来掌握pvc的变化情况：

status:
  #...
  volumeClaimTemplates:
    - compatibleReadyReplicas: 0 # 变配完成的pvc数量
      compatibleReplicas: 1 # 已经更新spec大小的pvc数量
      volumeClaimName: data0

3. 让AI工作负载也能享受WorkloadSpread的强大能力

在Kubernetes生态中，多区域管理和弹性调度一直是复杂工作负载的核心需求。自Kruise 0.10.0引入WorkloadSpread能力以来，这一特性为用户提供了无侵入性的方式，赋予工作负载跨区域、跨节点的精细化管理能力。无论是按主机、可用区等维度水平打散，还是按比例分配、带优先级的分区管理，WorkloadSpread都展现了其强大的灵活性和适应性。

然而，在实际应用中，我们发现并非所有工作负载都能完全满足 WorkloadSpread的假设条件。例如，AI工作负载（如KubeFlow中的TFJob）由于其多角色的设计，并未实现Kubernetes的Scale子接口，这使得它们无法直接使用WorkloadSpread提供的能力。而这些工作负载往往需要跨越专用硬件或不同可用区来获得更优的性能和弹性，因此对多区域管理的需求尤为迫切。

在Kruise 1.8中，我们针对这一痛点进行了重要升级——支持未实现Scale子接口的工作负载。通过新增的targetFilter配置，用户现在可以轻松将WorkloadSpread的能力应用于TFJob等复杂的AI工作负载，从而实现更高效的资源分配和管理。

WorkloadSpread targetFilter示例配置如下，更详细的使用文档可以查看WorkloadSpread文档[4]。

apiVersion: apps.kruise.io/v1alpha1
kind: WorkloadSpread
spec:
  #...
  targetRef:
    apiVersion: kubeflow.org/v1alpha1
    kind: TFJob
    name: tfjob-demo
  # 通过 targetFilter 来为未实现 Scale 子接口的工作负载提供支持
  targetFilter: 
    selector:
      # 通过 selector 来筛选 targetRef 管理的实例
      matchLabels:
        role: worker
    replicasPathList:
     # 通过 replicasPathList 指定 targetRef 需要管理的副本总数
    - spec.tfReplicaSpecs.Worker.replicas

4. 自定义探测：为Serverless场景注入全新活力

自Kruise 1.3引入PodProbeMarker自定义探测功能以来，它凭借灵活的扩展能力和广泛的应用场景，迅速成为众多开发者信赖的工具。特别是在游戏解决方案OKG (OpenKruise Game) 中，基于PodProbeMarker的服务质量探测能力，帮助无数游戏开发者实现了高效、稳定的服务管理，使其成为行业内的首选工具。

然而，在Serverless场景下，PodProbeMarker自定义探测能力曾一度面临挑战。在Kruise 1.8版本之前，PodProbeMarker的实现依赖于节点组件Kruise-Daemon，而Serverless环境中无法部署该组件，导致其探测能力受到限制。

如今，随着Kruise 1.8的发布，这一难题终于迎刃而解！Kruise团队针对Serverless场景进行了深度优化，将PodProbeMarker协议扩展到了Serverless Pod，为自定义探测提供了全新的可能性。现在，您可以在Serverless场景中充分利用资源，同时享受高质量的自定义服务探测能力，为您的服务运维保驾护航。

Serverless场景下PodProbeMarker协议扩展如下：

1. Kruise-manager通过annotation kruise.io/podprobe在Serverless Pod上添加需要进行的探测。

2. Serverless PodProbeMarker具体实现需要从annotation kruise.io/podprobe中读取探测信息、执行探测，并将结果写到Pod的.status.conditions[x]中。

3. Kruise-manager通过识别Serverless Pod的.status.conditions[x]中识别到Probe执行结果，并执行markerPolicy中定义的标记操作。

更详细的协议和支持的容器服务厂商列表可以查看PodProbeMarker文档[5]。

5. SidecarSet灰度注入：更精细的版本控制

在Kubernetes的云原生生态中，SidecarSet作为Kruise最受欢迎的功能之一，早已成为用户简化Sidecar容器管理与运维工作的强大工具。无论是日志采集、监控代理还是服务网格组件，SidecarSet都以其优雅的设计帮助用户轻松应对复杂的生产环境需求。然而，在过去的版本中，灰度注入场景的支持尚显不足，给需要精细化版本控制的用户带来了些许困扰。

如今，Kruise 1.8带来了全新的增强功能，通过引入灰度注入能力，为SidecarSet注入了前所未有的灵活性与控制力。无论您是希望逐步验证新版本的稳定性，还是需要实施复杂的发布策略，Kruise 1.8都能为您提供强有力的支持。示例配置如下：

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet 
metadata: 
  name: sidecarset 
spec:
  #...
  injectionStrategy:
    revision:
      # 指定注入的版本
      revisionName: revision-a
      # 可选值: Always 和 Partial
      #   Always: 总是注入指定的注入版本，本例为 revision-a
      #   Partial: 注入时结合 partition 的比例，控制注入指定版本的百分比
      policy: Partial 
  updateStrategy:
    partition: 70%

6. Helm Pre-delete Hook：Kruise误删保护

在Kruise 1.7.3之前的版本中，使用Helm卸载Kruise存在较高的风险，因为该操作会删除Kruise本身、其自定义资源定义（CRDs）以及相关的自定义资源（CRs）。

从Kruise 1.7.3版本开始，Helm卸载过程引入了一个pre-delete hook，用于在执行卸载操作之前检查集群中是否还存在由Kruise管理的自定义资源，如果存在，则会阻止卸载过程，从而有效防止因意外卸载导致的数据丢失和服务中断。这一改进显著提升了使用Helm管理Kruise的安全性。

总结与展望

Kruise 1.8版本通过在Advanced StatefulSet卷扩容、工作负载资源调整、Sidecar管理、UnitedDeployment调度策略以及WorkloadSpread等多个方面的增强，为云原生应用管理带来了显著的改进。这些新功能旨在提高应用的弹性、可伸缩性、运维效率和安全性。

如需更详细的升级和使用指南，请查阅Kruise官方文档[6]。我们期待Kruise 1.8能够帮助您更好地管理您的云原生应用，并提升您的整体应用管理体验。

持续演进的技术愿景

Kruise致力于为用户提供更加卓越的云原生解决方案。为了实现这一目标，我们规划了三个令人期待的未来版本：

release 1.9：推动LWS接入Advacned StatefulSet享受原地升级特性、原地升级重启次数解决方案、ConfigmapSet灰度变更解决方案等

release 2.0：Kruise api升级到v1beta1

release 2.1：Kruise组件最小化部署方案、新增Liveness Probe特性

加入我们

OpenKruise的成长离不开每一位开发者的贡献和支持。无论您是希望参与代码开发、提交Issue、撰写文档，还是仅仅想分享您的想法，我们都热切期待您的加入！非常欢迎你通过Github/Slack/钉钉/微信等方式加入我们来参与OpenKruise开源社区。你是否已经有一些希望与我们社区交流的内容呢？可以在我们的社区双周会[7]上分享你的声音，或通过以下渠道参与讨论：

• 加入社区Slack channel[8](English)

• 加入社区钉钉群：搜索群号23330762 (Chinese)

• 加入社区微信群（新）：添加用户openkruise并让机器人拉你入群 (Chinese)

相关链接：

[1] OpenKruise github仓库

https://github.com/openkruise/kruise

[2] ChangeLog

https://github.com/openkruise/kruise/blob/master/CHANGELOG.md

[3] Volume Expansion

https://kubernetes.io/zh-cn/blog/2022/05/05/volume-expansion-ga/

[4] WorkloadSpread文档

https://openkruise.io/zh/docs/user-manuals/workloadspread/#%E6%94%AF%E6%8C%81-ai-%E8%B4%9F%E8%BD%BD