Sidecar 容器生命周期变化解决什么部署问题

Sidecar 容器生命周期的变化，真正解决的是“辅助服务既要先于主程序可用，又不能在任务结束后拖住 Pod”的部署协调问题。Kubernetes 原生 Sidecar 把这类容器放在 initContainers 中，并设置容器级 restartPolicy: Always：它会按初始化顺序启动，但不会像普通 init container 那样启动后退出；主容器完成后，它也能按 Kubernetes 规定的顺序收尾。

官方地址：https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/

这意味着日志转发、网络代理、文件同步等辅助能力不必再用脚本猜测“什么时候启动、什么时候停止”。下面从几个常见部署现场看它到底改变了什么。

先看普通 init container 为什么不够

普通 init container 的规则是：前一个容器必须成功退出，后一个 init container 才能启动，所有 init container 完成后，Pod 才进入主容器阶段。这个模型很适合准备目录、生成配置或执行一次性迁移，却不适合需要持续提供服务的辅助进程。

例如，一个日志采集器需要在应用写入日志前就已经运行；一个本地代理需要在应用启动前准备好监听端口；一个同步进程则要在应用存活期间持续工作。如果把它们写成普通 init container，它们要么无法持续运行，要么会一直占住初始化阶段。

原生 Sidecar 的判断点很简单：它仍然位于 initContainers，但增加了容器级 restartPolicy: Always。Sidecar 启动后，kubelet 会把它视为已启动，然后继续处理后面的 init container；如果配置了 startupProbe，则以探针成功作为“可以继续”的信号。

第一个部署问题：辅助服务必须先准备好

原生 Sidecar 首先解决的是启动顺序。它可以先于主容器启动，同时保留 init container 的顺序保证。这样，部署描述里不需要额外写一个“后台启动代理后 sleep 几秒”的脚本，也不需要让应用自己轮询一个不可靠的时间窗口。

下面的片段用一个共享目录演示日志采集场景。主容器写入文件，Sidecar 持续读取；注释只解释关键字段，不把静态示例当成真实运行结果。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-log-sidecar
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: app
          image: alpine:3.20
          command: ["sh", "-c"]
          # 主容器持续写入共享卷，模拟应用日志。
          args: ["while true; do echo application-log >> /var/log/app.log; sleep 2; done"]
          volumeMounts:
            - name: shared-log
              mountPath: /var/log
      initContainers:
        - name: log-sidecar
          image: alpine:3.20
          restartPolicy: Always
          command: ["sh", "-c"]
          # Always 让这个 init container 变成持续运行的原生 Sidecar。
          args: ["tail -F /var/log/app.log"]
          volumeMounts:
            - name: shared-log
              mountPath: /var/log
      volumes:
        - name: shared-log
          emptyDir: {}

这里的关键不是 tail 本身，而是生命周期声明：Sidecar 会先启动，应用容器随后启动；Sidecar 退出时也会按自身的 Always 规则处理。若辅助服务必须真正完成健康检查后才能让后续初始化继续，可以给它增加 startupProbe，把“进程已启动”和“服务已可用”区分开。

第二个部署问题：Job 不能被 Sidecar 拖到永远

批处理 Job 是原生 Sidecar 最容易体现价值的场景。主容器可能只做一次导出、计算或迁移，完成后就应让 Job 结束；日志采集器或代理却通常会持续运行。如果它是普通并列容器，Job 的完成判断可能被这个长生命周期进程干扰。

使用原生 Sidecar 时，Sidecar 不会阻止主容器完成后 Job 结束。部署设计因此可以把“主任务是否成功”和“辅助服务是否持续运行”拆开：主容器的退出码负责任务结果，Sidecar 只负责在任务存活期间提供支持。

apiVersion: batch/v1
kind: Job
metadata:
  name: export-with-sidecar
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: export
          image: alpine:3.20
          command: ["sh", "-c"]
          # 主任务完成后退出，Job 以它的执行结果为主要判断依据。
          args: ["echo export-finished > /work/result.txt"]
          volumeMounts:
            - name: work
              mountPath: /work
      initContainers:
        - name: log-sidecar
          image: alpine:3.20
          restartPolicy: Always
          command: ["sh", "-c"]
          # Sidecar 可在主任务期间工作，主任务结束后不会永久阻塞 Job。
          args: ["tail -F /work/result.txt"]
          volumeMounts:
            - name: work
              mountPath: /work
      volumes:
        - name: work
          emptyDir: {}

这类写法仍然要考虑实际采集系统的退出信号和数据落盘策略。Sidecar 不再拖住 Job，不等于它可以忽略最后一批数据；需要保留完整日志时，应让主任务或采集器有明确的 flush、重试和外部存储策略。

第三个部署问题：Pod 终止时谁先退出

传统做法经常把优雅退出交给所有容器各自处理，结果是应用已经停止，代理还在等待；或者 Sidecar 先退出，主容器最后几秒的日志、指标和同步动作没有接收者。原生 Sidecar 对这个顺序给出了明确规则：

• Pod 终止时，主应用容器先完成停止。
• Sidecar 的终止会被推迟到主容器全部停止之后。
• 多个 Sidecar 按它们在 initContainers 中出现的相反顺序关闭。

这让声明顺序本身成为一种设计工具。靠近主应用的收尾辅助服务可以放在后面，使它更晚退出；更早启动的 Sidecar 则会更早进入关闭阶段。实际使用时还要给主容器和 Sidecar 设置合理的终止时间，并让应用能够响应信号。

什么时候应该采用原生 Sidecar

可以用下面的判断表快速筛选：

原生 Sidecar 不是把所有辅助容器都搬到 initContainers 的通用写法。它最有价值的前提是：辅助进程需要和主容器共享网络或卷，并且启动、重启、完成或终止顺序会影响部署结果。

落地前的五项检查

1. 确认集群版本和控制面行为支持容器级 restartPolicy，不要只看 YAML 能否提交。
2. 确认 Sidecar 只使用允许的 restartPolicy: Always，不要把它当成普通 init container 的失败重试开关。
3. 如果“进程存在”不等于“服务可用”，为 Sidecar 配置 startupProbe 或 readinessProbe。
4. 为共享卷、资源请求和日志落盘设置边界；Sidecar 的资源也会影响 Pod 的调度与 QoS 判断。
5. 分别设计主容器成功、主容器失败、Sidecar 重启和 Pod 终止四条路径，避免只测试启动成功。

总结

Sidecar 容器生命周期变化解决的不是“多写一个容器”的问题，而是部署中辅助进程的时序问题：它可以先启动、持续工作、独立重启，并在主容器结束后按规则退出。需要一次性准备时仍用普通 init container；需要伴随主任务运行且不能拖住 Job 或破坏终止顺序时，原生 Sidecar 才是更清晰的声明方式。

相关问题

• Sidecar 为什么要写在 initContainers 而不是普通 containers？
• Sidecar 配置 readinessProbe 后会如何影响 Pod Ready 状态？
• 旧版本 Kubernetes 不支持原生 Sidecar 时怎么兼容？