Kubernetes Sidecar 生命周期变化后怎样安排应用启动顺序

Kubernetes 原生 sidecar 的关键变化，不是“多放一个容器”这么简单，而是把依赖容器的启动、存活和退出顺序纳入 Pod 生命周期。需要代理、日志采集器或同步服务先于应用进入运行态时，可以把它写在 spec.initContainers 中，并设置容器级 restartPolicy: Always。这样 sidecar 会先启动，后面的初始化容器和应用容器再继续；Pod 终止时，主应用先停，sidecar 再按声明顺序的反方向停止。

官方资料入口：https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/

判断标准可以压缩成一句话：必须先启动且要陪伴应用运行的依赖，用原生 sidecar；只做一次准备工作的依赖，用普通 init 容器；不要求先后顺序的并行容器，继续放在 containers 中。

这次生命周期变化解决了什么

过去常见的 sidecar 写法是把代理、日志采集器和业务进程都放在 containers 数组里，再用脚本、preStop 或应用自身的重试逻辑“猜”启动顺序。普通容器之间没有这种由 containers 数组提供的严格先后关系，因此应用可能先于代理启动；退出时，多个容器也可能收到终止信号而没有业务上的顺序保证。

原生 sidecar 使用的是 init 容器语义：它仍然位于 initContainers，但容器级 restartPolicy: Always 让它启动后继续运行。Kubelet 把它标记为已启动后，才会处理数组中的下一个 init 容器。功能在 Kubernetes v1.28 首次提供，文档当前标记为 v1.33 稳定能力；集群是否能接受下面的字段，仍应以实际版本文档和发行版说明为准。

先把三种容器放到正确位置

这三个位置不要混用。普通 init 容器适合生成配置、迁移文件或准备共享卷；它如果一直运行，会阻塞后续容器。原生 sidecar 适合代理和日志采集；它可以持续运行，但不会因为自己还活着而阻止 Job 的主任务完成。

最小配置：让代理先于应用进入运行态

下面的片段展示一个“代理在前、业务在后”的静态配置关系。startupProbe 表示代理何时算作已经启动；它不是业务请求探活，也不代替应用自己的 readinessProbe。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 1
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      initContainers:
        - name: mesh-proxy
          image: example/mesh-proxy:1.0
          # Always 让这个 init 容器成为持续运行的原生 sidecar。
          restartPolicy: Always
          # 只有代理完成自身启动检查，后面的容器才继续。
          startupProbe:
            httpGet:
              path: /startup
              port: 15021
            periodSeconds: 2
            failureThreshold: 30
      containers:
        - name: checkout
          image: example/checkout:2.4
          # 应用的就绪探针只决定是否接收流量，不负责启动 sidecar。
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 5

这个排列表达了两个独立事实：代理必须在应用之前达到“已启动”状态，应用是否接收 Service 流量则由自己的就绪探针决定。不要把代理的端口探测误写成应用就绪条件，也不要只依赖进程已经存在就推断代理能处理请求。

多个依赖怎样安排启动顺序

initContainers 是有序数组。可以把“先建立网络代理、再生成配置、最后启动应用”写成清晰的声明顺序：

spec:
  initContainers:
    - name: network-proxy
      image: example/proxy:1.0
      # 代理保持运行，后面的初始化器和应用可以共享 Pod 网络。
      restartPolicy: Always
      startupProbe:
        tcpSocket:
          port: 15001
        periodSeconds: 2
    - name: render-config
      image: example/config-renderer:1.2
      # 这个容器只负责一次性写入共享卷，成功退出后才继续。
      command: ["sh", "-c", "render --out /work/config.yaml"]
      volumeMounts:
        - name: work
          mountPath: /work
  containers:
    - name: app
      image: example/app:3.1
      # 应用读取前两个容器准备好的网络和共享文件。
      volumeMounts:
        - name: work
          mountPath: /work
  volumes:
    - name: work
      emptyDir: {}

这里的顺序不是“建议顺序”，而是配置要表达的依赖：network-proxy 先进入 started，render-config 成功完成，随后应用容器才有机会启动。如果配置渲染器并不依赖代理，也可以把它改成普通 init 容器放在前面；排列时应以真实依赖为准，而不是按团队或镜像名称排序。

退出时为什么是主容器先停、sidecar 反向停

Pod 终止时，Kubelet 会延后 sidecar 的终止，让主应用先完成退出。多个 sidecar 则按它们在 initContainers 中出现的反向顺序停止。比如数组中先是网络代理、后是日志采集器，退出时日志采集器先停，网络代理后停。

这正适合“应用产生数据，采集器负责收尾”的场景，也适合应用在退出期间仍需访问代理的场景。它同时意味着主应用的优雅退出会占用整个 Pod 的终止宽限期；如果应用迟迟不结束，sidecar 也会继续等待。宽限期耗尽时，剩余容器可能被强制终止，不能把 sidecar 的退出码简单当成业务失败。

和旧方案相比，哪些代码可以删掉

如果旧方案只用 preStop 让某个 sidecar 等待应用退出，或者让应用启动脚本反复轮询代理端口，可以先重新检查这些控制逻辑是否仍有必要。原生 sidecar 已经提供了两类平台级顺序：

• 启动：sidecar 位于有序的 initContainers，自身达到 started 后才推进后续项。
• 退出：主应用完成后，sidecar 按声明的反向顺序被终止。

但这不代表所有等待脚本都能直接删除。应用仍可能需要等待业务依赖的健康状态，sidecar 的 startupProbe 也必须准确表达“可以让后续容器开始”的条件。探针只检查端口是否打开，却不检查代理配置是否加载完成，仍然可能导致应用过早启动。

Job 和旧集群的采用风险

原生 sidecar 对 Job 很有价值：日志采集器可以陪伴主任务运行，但不会因为自己持续运行而阻止 Job 完成。对于长期运行的 Deployment，收益主要是减少自定义启动脚本和退出钩子的耦合。

迁移前要看四件事：

1. 集群版本是否支持容器级的 restartPolicy，以及发行版是否按预期开启该能力。
2. 清单是否把 sidecar 写在 initContainers，而不是继续放在普通 containers 中等待“自然并行”。
3. sidecar 的 startup、readiness 和应用退出时间是否符合真实依赖；不要用过短的终止宽限期掩盖慢退出。
4. 资源请求是否把 sidecar 的长期运行成本算进去；init 与 sidecar 的资源计算还会影响 Pod 的有效资源需求。

如果必须兼容不支持原生 sidecar 的旧集群，就继续使用旧的并行容器或显式等待方案，并把启动失败、退出延迟和日志收尾写进回滚预案。不要把一份含有 restartPolicy: Always 的清单直接推给所有版本的集群。

最后用一张表做决定

相关官方资料还包括：

• https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
• https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
• https://kubernetes.io/blog/2023/08/25/native-sidecar-containers/

常见追问

sidecar 一定要写在 initContainers 吗？

要使用 Kubernetes 原生 sidecar 生命周期，需要在 initContainers 中设置容器级 restartPolicy: Always。如果不需要顺序控制，普通容器仍然可以并行运行。

startupProbe 和 readinessProbe 能互相替代吗？

不能。sidecar 的 startup 条件决定后续 init 容器何时推进；readiness 更适合表达 Pod 或容器是否应接收流量。两者服务的生命周期判断不同。

sidecar 会让 Job 永远运行吗？

按原生 sidecar 语义不会。Job 的主容器完成后，sidecar 会被安排停止，Job 不会因为 sidecar 仍在运行而无限等待。