Kubernetes 原生 Sidecar 与 OpenKruise Sidecar对比与实践

希里安近日见闻

一转眼九月最后一天了，马上国庆放假休息了，今天应该有很多朋友已经请假忙起来了，是准备回老家还是来一趟计划很久的旅行，亦或只是在家休息呢？欢迎和希里安交流！

最近工作以及生活上比较忙（主要是晚上回去看马大帅电视剧停不下来，又像范德彪一样幻想着自己永远29岁！），所以有一段时间没有更新文章了，不过没事，这不今天又想起来了写一篇。

之前K8s 1.33以及1.34版本发布的时候，我都介绍了相关的更新文章，其中有一项1.33版本中成为原生功能的Sidecar，以及1.33版本之前很多人用来增强Sidecar 管理的开源软件OpenKruise，就是我接下来要给大家介绍的内容。

Kubernetes 原生 Sidecar 与 OpenKruise SidecarSet 全解析

在实际企业业务场景下，Sidecar（边车容器） 一直是个热门话题。无论是日志采集、配置热更新、还是服务代理，Sidecar 的应用场景非常广泛。今天，我们来聊聊 Kubernetes 原生 Sidecar 和 OpenKruise SidecarSet，它们的区别、使用方式以及适用场景。

一、什么是 Sidecar？

简单来说，Sidecar 就像摩托车的边车：

• • 主容器（Main Container）跑你的业务逻辑
• • 边车容器（Sidecar Container）负责辅助功能，比如日志、监控、代理
• • Sidecar与主业务容器（Main Container）运行在同一个 Pod 里

这是一种经典的 Pod 内多容器协作模式，在微服务架构里非常常见。

二、Kubernetes 原生 Sidecar 的演进

Kubernetes 一直以来支持多容器 Pod，但 边车容器的生命周期问题一直困扰着大家：

• • 以前：Sidecar 容器通常作为普通容器或者 initContainer 启动，容易出现 Pod 卡住 或 Sidecar 还在跑但主容器已经结束 的情况
• • 现在：Kubernetes 从 v1.28 引入 Alpha → v1.29 进入 Beta 并默认开启 → v1.33 稳定（Stable/GA），终于提供了官方的原生支持Sidecar Containers[1]

📌 官方定义： 在 Pod 的 YAML 中，只要在容器里设置 restartPolicy: Always 并标记为 Sidecar，Kubernetes 就会按照如下规则运行：

• • Sidecar 容器 最先启动，保证主容器依赖就绪
• • Sidecar 容器在 Pod 生命周期中一直运行
• • 当主容器全部退出后，Sidecar 容器会自动退出，Pod 状态进入 Completed

👉 示例（K8s 1.33+）：

apiVersion: v1
kind: Pod
metadata:
  name: native-sidecar-demo
spec:
  containers:
  - name: sidecar
    image: busybox
    args: ["sh", "-c", "while true; do echo '[sidecar] collecting logs...'; sleep 5; done"]
    restartPolicy: Always   # 声明为 sidecar
  - name: main
    image: busybox
    args: ["sh", "-c", "echo '[main] running app...'; sleep 20; echo '[main] finished'"]

三、OpenKruise 的 SidecarSet

OpenKruise[2] 是阿里巴巴开源的 Kubernetes 扩展项目，功能非常强大。其中的 SidecarSet 专门解决了 大规模 Sidecar 注入与管理 的问题。

• • 定义方式：在集群里创建一个 SidecarSet CRD
• • 作用：所有符合 selector 条件的 Pod 会自动被注入 Sidecar 容器
• • 管理：集中化管理 Sidecar，可以灰度更新、滚动升级，而无需修改每个 Pod 的 YAML

👉 示例：

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: kruise-demo
  containers:
  - name: sidecar
    image: busybox
    command: ["sh", "-c", "while true; do echo '[sidecar] collecting logs...'; sleep 5; done"]

当你新建一个业务 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: kruise-sidecar-demo
  labels:
    app: kruise-demo
spec:
  containers:
  - name: main
    image: busybox
    args: ["sh", "-c", "echo '[main] running app...'; sleep 20; echo '[main] finished'"]

Kruise 控制器会自动给它加上 sidecar 容器，而开发者完全不需要关心 Pod YAML 内的改动。

咱们再多了解一下，OpenKruise 自身从较早版本就支持 Sidecar 管理（通过 SidecarSet 等 CRD），其设计思路是将 sidecar 容器的注入、生命周期、升级等与应用业务容器解耦。

当 Kubernetes 引入原生 sidecar 之后，OpenKruise 在 v1.7 开始对其进行支持，使得 SidecarSet 能够使用 Kubernetes 原生 sidecar 的能力。

OpenKruise SidecarSet 的传统方式是将 sidecar 容器“像普通容器”那样注入到 Pod 的 .spec.containers 部分，或者在 Pod 模板里以某种方式注入（通过 webhook 注入、mutating webhook）

• • Pod 重启/Job 完成： 对于 Job 类型 Pod，主容器完成退出后，sidecar 容器若仍然在运行（restartPolicy 为 Always 或随 Pod 生命周期），就会阻止 Pod 进入 Completed 状态。为了解决这个问题，OpenKruise 提供了 Job Sidecar Terminator 控制器，能在主容器退出后终止 sidecar
• • 启动顺序／先后保证： 在传统方式中，sidecar 与主容器的启动顺序不保证。若 sidecar 提供代理或网络初始化服务，主容器可能启动时还没准备好。为了改善，OpenKruise 有 “Container Launch Priority”（容器启动优先级）机制来控制 Pod 内多个容器启动顺序
• • 注入解耦: 使用 SidecarSet，用户可以只写 SidecarSet CRD 定义 sidecar，而不必修改每个应用 Deployment/Pod 模板。OpenKruise 通过 webhook 在创建 Pod 时注入 sidecar 容器

在 Kubernetes ≥1.29（开启 SidecarContainers 特性）环境下，OpenKruise 的 SidecarSet 能利用原生 sidecar（即 initContainers + restartPolicy: Always）方式注入 sidecar。

四、原生 Sidecar vs OpenKruise SidecarSet

五、适用场景举例

1. 1. 原生 Sidecar
   • • 适合 单个应用 Pod 的辅助场景
   • • 比如：在一个 ETL 任务中，主容器跑数据处理，Sidecar 负责把日志同步到存储系统，任务结束 Pod 自动完成
2. 2. OpenKruise SidecarSet
   • • 适合 平台级统一 Sidecar 注入
   • • 比如：你要在所有业务 Pod 里统一加上 日志采集代理 / 服务网格代理，只需要维护一个 SidecarSet 即可

想用最简单、Kubernetes 原生的“sidecar”能力（例如保证 sidecar 启动顺序、Job 执行完能正常结束、支持探针等）——优先用 Kubernetes 原生 sidecar（需要 K8s ≥1.28/1.29 或 FeatureGate 支持）。 想在集群中统一、自动为很多 Deployment 注入 sidecar、并需要 in-place 升级/热升级、灰度注入、启动优先级等增强能力 ——用 OpenKruise SidecarSet（它还可以在支持的集群上用“原生 sidecar”模式注入）

总结

• • Kubernetes 原生 Sidecar：在 v1.33 GA，终于解决了 Sidecar 生命周期的问题，简单清晰，适合小规模使用
• • OpenKruise SidecarSet：更偏向平台级运维，自动批量注入和升级，适合大规模、统一 Sidecar 管理
• • 在实际场景中，两者并不是替代关系，而是互补关系：
  • • 小规模应用 → 用原生 Sidecar
  • • 平台/企业级统一治理 → 用 SidecarSet

未来随着 原生 Sidecar GA，越来越多的项目会直接使用官方特性，但在大规模应用场景下，OpenKruise 的能力依然不可替代

各位读者你是更喜欢 轻量原生 的 Sidecar，还是 平台级批量管理 的 SidecarSet 呢？欢迎在评论区聊聊～

最后

好了以上就是今天的内容，对于k8s感兴趣的小伙伴，可以添加希里安(cillianops)，进入技术交流群！交流更多关于k8s的技术信息。

关注公众号“希里安”，获取最新前沿动态和技术分享！

引用链接

[1] Sidecar Containers: https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers [2] OpenKruise: https://openkruise.io