OpenKruise云原生应用自动化引擎正式开源发布

2019 年 6 月 24 日至 26 日，由 Cloud Native Computing Foundation（CNCF）主办的云原生技术大会 KubeCon + CloudNativeCon + Open Source Summit（上海）将在中国上海隆重举行。大会期间，阿里云将面向全球用户分享阿里巴巴在超大规模场景下的云原生落地实践、云原生前沿技术与典型应用，内容涵盖 OpenKruise 开源项目、开放云原生应用中心（Cloud Native App Hub），并将重磅发布边缘容器、云原生应用管理与交付体系等产品与服务。接下来，我们将深入了解 OpenKruise 这一源自阿里经济体云原生转型历程的宝贵经验与最佳实践。

OpenKruise Github 地址：https://github.com/openkruise/kruise

“云原生应用自动化引擎”加持下的阿里“云原生”

随着云原生理念快速普及，越来越多的企业和应用开始探索在云原生体系中构建、部署和运行。那么，什么是云原生？简而言之，云原生是一套充分利用“云”能力，高效构建、交付与运维应用的方法论集合。它帮助应用容器化用户更好地利用云的弹性能力、“不可变基础设施”等优势，从而把更多精力聚焦在核心业务创新上。

当前，阿里巴巴基础设施的云原生演进与升级也在持续加速推进。在阿里巴巴整体上云过程中，阿里内部已在超大规模互联网业务场景中进行了大量云原生实践。例如轻量级容器化，阿里巴巴经济体正在大规模推动应用轻量级容器化，借助容器敏捷、一致、标准化的特性，快速构建符合云原生理念的电商站点交付能力，以应对类似“双十一”大促这样的高强度技术挑战；再如云原生应用管理，阿里巴巴经济体正将 Kubernetes 等开源项目的应用编排与自动化能力进一步延伸到上层运维框架中，驱动电商应用按照云原生技术体系完成编排、交付与运行。

在阿里巴巴经济体整体云原生化的进程中，阿里技术团队逐步沉淀出一套紧贴上游社区标准、适配互联网规模化场景的技术理念与最佳实践。其中，最关键的一点就是如何实现应用的自动化发布、自动化运行和自动化管理。

OpenKruise：来自阿里经济体云原生化历程的宝贵经验与最佳实践

在 KubeCon 上海大会上，阿里云容器平台团队正式宣布重量级开源项目——OpenKruise（以下简称 Kruise）开源。

Kruise 是 cruise 的谐音，'k' 代表 Kubernetes。其字面含义有巡航、豪华游艇之意，寓意 Kubernetes 平台上的应用能够实现自动巡航式运维，同时承载阿里巴巴多年应用部署与管理经验。

Kruise 的目标是 automate everything on Kubernetes！Kruise 项目源于阿里巴巴经济体过去多年在大规模应用部署、发布和管理中的最佳实践，源于容器平台团队在集团级应用规模化运维、规模化建站中的能力沉淀，也源于阿里云 Kubernetes 服务数千客户的真实需求反馈。Kruise 依托云原生社区，融合阿里巴巴云原生实践精华，持续反哺社区，帮助行业在云原生落地过程中借鉴最佳实践、少走弯路。

Kruise 的核心价值在于自动化。它将从多个维度提升 Kubernetes 之上应用的自动化能力，包括部署、升级、弹性扩缩容、QoS 调节、健康检查、迁移修复等。本次 Kruise 开源的重点主要集中在应用部署与升级，即一套增强版 controller 组件，用于应用的部署、升级和运维管理。后续，Kruise 还将逐步开源智能化弹性扩缩容组件，以及应用 QoS 自调节能力相关组件等。

Kruise Controllers：将 Kubernetes 的“控制器模式”进行到底

以下内容主要介绍 Kruise Controllers——一套用于 Kubernetes 应用自动化部署与管理的 controller 组件。众所周知，Kubernetes 项目的核心机制就是“控制器模式”。目前，Kubernetes 已默认提供了一系列 Controller 组件，例如 Deployment、StatefulSet、DaemonSet 等，这些控制器提供了较为丰富的应用部署与管理能力。

但是，随着 Kubernetes 的应用范围不断扩大，企业级场景和大规模业务场景中的真实诉求，与上游原生 Controller 功能不完全匹配的情况也越来越普遍。以阿里巴巴为例，阿里巴巴内部的 Kubernetes 集群需要服务 50 多个 BU、上万种应用，规模十分庞大，这对系统的规模性与高可用能力提出了极高要求。与此同时，阿里云 Kubernetes 服务也已接入上千家企业客户，积累并支撑了多种多样的客户需求。正是这些实际业务诉求，加上阿里经济体长期沉淀的实践经验，最终促成了 Kruise 开源项目的诞生。

Kruise 第一期开源主要包含以下 Controller，后续还会持续加入更多能力。

Advanced StatefulSet - 具备丰富发布策略、支持原地升级的 StatefulSet

Advanced StatefulSet 在原生 StatefulSet 的基础上进行了增强，加入了两个关键特性：

• 1）原地升级（In-place update strategy）：原生 StatefulSet 在执行 rolling update 时，会先销毁再重建 Pods。在阿里巴巴这种超大规模场景下，这样的代价非常高。
  • a) 首先，所有被删除的应用 Pods 都需要重新调度。由于 Pod 数量巨大，这会给调度系统带来额外且不必要的压力。更复杂的是，重新调度的 Pod 可能因为资源占用、亲和性约束等原因而无法顺利落位。Pod 一旦被调度到新的 node 上，还会丢失原有本地 state，虽然通常可以重建，但依然会产生额外成本。
  • b) 重调度后的 Pods 很可能分布到不同机器上。由于网络拓扑发生变化，需要重新申请 IP，一些依赖 IP 保持不变的应用可能因此无法正常运行。此外，这也会给网络流量路径带来不确定性。
  • c) 对于多容器 Pod 而言，仅仅升级 sidecar 容器却导致主容器一起重建，通常是业务上难以接受的。

Advanced StatefulSet 引入了 原地升级功能，允许在不销毁 Pod 的情况下直接更新容器 image。其带来的核心收益主要体现在效率和稳定性两个方面。效率方面非常直观：Pod 无需重新调度，仍然运行在原有 node 上，一些本地存储 state 也可以保留。稳定性方面则体现在 IP 可保持不变，网络拓扑和流量路径基本稳定。在阿里巴巴及阿里云经济体中，稳定性始终是极其重要的关键指标。

• 2）允许最大不可用实例的配置 (MaxUna vailable)：社区原生 StatefulSet 在升级过程中通常不允许同时升级多个实例，这主要是为了满足某些有状态应用需要按顺序逐个升级的需求。但是，从阿里巴巴自身场景以及阿里云容器平台客户实践来看，很多应用并不需要这种严格的顺序升级语义，因此原生方式会带来升级效率过低的问题。尤其在应用实例数量巨大的场景中，这一问题更加突出。MaxUna vailable 功能正是为解决这一痛点而设计，它允许应用实例并行升级，同时确保始终保持最大不可用实例数不超过 MaxUna vailable 的限制。

小提示： 原地升级功能尤其适合对 IP 保持、网络拓扑稳定性要求较高的应用场景，例如数据库、中间件等核心服务。

Broadcast Job - 像 DaemonSet 那样运行的一次性 Job

Broadcast Job 会在集群中的每个 node 上运行一个 Pod，直至任务结束。它与社区中的 DaemonSet 类似，不同之处在于 DaemonSet 会始终在每个 node 上维持一个长期运行的 Pod，而 BroadcastJob 中的 Pod 在任务完成后会退出。相比 DaemonSet，Broadcast Job 执行完成后不再占用集群资源，因此在特定场景下非常实用，例如批量升级 node 中的某些组件、检查 node 上的配置是否正确等。

适用场景： 批量在所有节点上执行一次性任务，例如节点合规性检查、节点安全补丁安装、节点配置更新等节点级运维操作。

SidecarSet - 大规模场景下 Sidecar 管理利器

Sidecar 是 Kubernetes 中辅助容器的一种典型模式，与主容器共同运行在同一个 Pod 中。Sidecar 容器通常承担一些基础服务能力，例如 monitoring 容器、log collection 容器等。在企业内部，主业务容器和基础组件容器通常由不同团队分别开发与维护。多个团队同时操作和修改同一份 yaml 文件、同一个 API 资源对象，往往容易产生冲突，也不利于统一管理。

SidecarSet 的核心理念在于 将主业务容器和辅助容器的运维模式解耦。当业务用户提交应用时，无需显式声明 sidecar 容器，而是由负责 sidecar 的团队通过预设规则自动完成注入。并且在容器运维和升级时，可以借助 Advanced StatefulSet 的原地升级能力，让业务团队与基础架构团队按照各自定义的策略分别升级对应容器，无需耦合为一次统一升级，从而减少不必要的影响。Istio 其实也采用了类似思路，为业务容器自动注入 sidecar 容器，但它缺少 sidecar 容器后续升级与持续运维的能力。SidecarSet 则有效地将 Sidecar 容器的部署、升级和管理能力进一步抽象出来。

小提示： 使用 SidecarSet 能显著降低基础架构团队与业务团队之间的协作成本，实现双方独立迭代、分工清晰的容器管理模式。

特色功能总结

• 高效原地升级： 避免 Pod 重建，显著提升 Kubernetes 应用升级效率与稳定性，同时保持 IP 和网络拓扑基本不变。
• 灵活并行升级： 通过 MaxUna vailable 配置，在保证服务可用性的前提下支持并行升级，大幅提升大规模集群的发布效率。
• 一次性任务支持： Broadcast Job 提供类似 DaemonSet 的节点级运行能力，但任务完成后自动释放资源，特别适合节点运维任务。
• Sidecar 管理解耦： SidecarSet 将 Sidecar 容器生命周期与主容器解耦，实现独立部署、自动注入与独立升级。
• 开放社区协作： OpenKruise 是一个 Umbrella 项目，欢迎全球开发者、合作伙伴和贡献者共同参与建设。

常见问题

Q1: OpenKruise 与 Kubernetes 原生控制器有什么不同？

A1: OpenKruise 提供了比 Kubernetes 原生控制器更强的自动化能力，尤其面向大规模、企业级和复杂运维场景。例如，原地升级 是原生控制器通常不具备的能力，它可以显著提升升级效率与服务稳定性。此外，OpenKruise 还提供了 Broadcast Job 和 SidecarSet 等原生 Kubernetes 中没有的控制器，用于解决特定场景下的应用发布与运维难题。

Q2: 如何开始使用 OpenKruise？

A2: 你可以按照以下步骤快速开始使用 OpenKruise：

• 第 1 步： 访问 OpenKruise Github 仓库。
• 第 2 步： 阅读官方文档，了解安装方式与使用说明。
• 第 3 步： 使用 Helm 或 kubectl 将 OpenKruise 一键安装到你的 Kubernetes 集群中。
• 第 4 步： 根据业务场景开始使用 Advanced StatefulSet、Broadcast Job、SidecarSet 等控制器能力。

Q3: 原地升级适用于所有类型的应用吗？

A3: 原地升级适用于大多数 Kubernetes 应用场景，但仍存在一定限制。例如，如果应用依赖文件系统中的特定文件或配置，原地升级仅更新镜像，可能无法同步更新这些文件。对于需要修改 Pod 元数据（如标签、注解）或资源请求与限制的场景，依然需要重建 Pod。因此，建议在生产环境使用前，先在测试环境中验证是否满足自身业务需求。

Q4: SidecarSet 与 Istio 的自动注入有何区别？

A4: Istio 的自动注入通常只在 Pod 创建阶段注入 Sidecar 容器，后续若要升级 Sidecar，往往需要手动重建 Pod。而 SidecarSet 不仅支持自动注入，还具备 Sidecar 容器后续升级与持续管理能力。结合 Advanced StatefulSet 的原地升级特性，SidecarSet 可以实现 Sidecar 的独立热更新，而无需重启主容器。

OpenKruise 正在面向开源社区招募合作伙伴与子项目！

Kruise 社区的核心准则，是基于 Kubernetes 的核心技术理念，持续构建更强大的自动化能力。目前，Kruise 正在规划发布更多 Controller，以覆盖更丰富的业务场景和功能需求，例如更完善的发布策略、金丝雀发布、蓝绿发布、分批发布等。

更重要的是，OpenKruise 是一个 Umbrella 项目。OpenKruise 的维护者们正以开放姿态面向全球招募合作伙伴和贡献者。我们非常期待您能够为 OpenKruise 贡献并共建新的自动化能力，也欢迎一起推动 Kubernetes 云原生应用编排与自动化运维能力的持续演进与发展。

更多信息，请移步 Kruise Github：https://github.com/openkruise/kruise