Init Container 与 Sidecar 模式

摘要：本文面向需要在 Pod 内做“启动前准备”和“旁路增强”的工程师，讲解 Init Container 与原生 Sidecar 容器的语义差异、资源共享与生产模式。覆盖 Kubernetes v1.28+（原生 Sidecar 自 v1.33 稳定）。

适用版本与前提

Kubernetes：v1.28+（原生 Sidecar 容器自 v1.33 稳定，特性门控 SidecarContainers 自 v1.29 默认开启，v1.33 锁定）
工具：kubectl
前提：理解容器生命周期与探针

背景与问题

一个 Pod 内常有“主应用 + 辅助逻辑”：应用启动前要先等数据库就绪、要先拉配置；运行时需要日志收集、流量代理、配置同步。这些辅助逻辑若塞进主容器镜像，会让镜像臃肿、攻击面扩大、职责混乱。Kubernetes 提供两类专门容器：Init Container（启动前顺序执行、跑完即退）与 Sidecar Container（与主容器并行、长期运行）。弄清二者差异是用好它们的关键。

Init Container：启动前屏障

Init 容器在应用容器之前顺序运行，每个必须成功退出，下一个才能开始；全部成功后主容器才启动。

yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
    - name: myapp-container
      image: busybox:1.28
      command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
    - name: init-myservice
      image: busybox:1.28
      command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
    - name: init-mydb
      image: busybox:1.28
      command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

关键特性

顺序且必须成功：任一失败，kubelet 按 Pod restartPolicy 重试（若 restartPolicy=Never 则整个 Pod 判失败）。
不支持探针：init 容器不能定义 livenessProbe/readinessProbe/startupProbe/lifecycle（校验会拒绝），因为它“完成与否”即其就绪。
独立镜像：可放主镜像没有的工具（sed/awk/python），降低主镜像复杂度与攻击面。
共享卷交换数据：通过 emptyDir 等把配置/数据从 init 传给主容器（单向）。
资源取其高：调度按所有 init 容器资源请求的最大值预留，而非求和。

注意

Init 容器代码必须是幂等的——Pod 重启或 kubelet 重启会重跑全部 init 容器。写入 emptyDir 时要能处理“文件已存在”。自 v1.20 起，修改 init 容器镜像不会重启 Pod。

Sidecar Container：原生旁路容器

自 v1.33 起，Kubernetes 将 sidecar 实现为一种特殊 init 容器：在 initContainers 中把某容器的 restartPolicy 设为 Always，它便成为长期运行的 sidecar。

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always     # 关键：使其成为 sidecar
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}

Sidecar 的生命周期

启动时：sidecar 在 Pod 初始化阶段先启动并保持运行，之后主容器才启动；它可配 readinessProbe，其结果参与 Pod 的 Ready 判定。
终止时：kubelet 等主应用容器完全停止后才关闭 sidecar，且按出现顺序的逆序关闭，保证“辅助服务”在主容器需要时一直可用。
更新镜像会触发该 sidecar 容器重启，但不重启整个 Pod。

版本相关

原生 Sidecar 容器自 v1.33 稳定（v1.29 默认开启、v1.28 Alpha）。在老版本上只能用“普通多容器 + 进程管理”模拟 sidecar，缺乏独立的启动/停止顺序保证，且会被主容器退出影响。生产若用老集群，需评估该差异。

生产模式

Init 做依赖栅栏：等待数据库、注册中心、配置就绪再放行主容器，避免“启动即崩”。
Init 做配置/密钥准备：从远端拉取配置写入 emptyDir，主容器只读，二者镜像解耦。
Sidecar 做日志/代理/同步：日志采集、envoy 代理、配置热同步等长期旁路能力。
Job 中的 Sidecar：原生 sidecar 不会阻止 Job 在主容器完成后结束（区别于旧式多容器）。

建议

Sidecar 与主容器共享网络与（可选的）卷命名空间，能紧密协作；但 sidecar 的优雅终止优先级较低——当主容器耗尽全部宽限时间后，sidecar 会收到 SIGTERM 随即 SIGKILL。因此 sidecar 退出码非 0 在 Pod 终止时是正常的，外部工具应忽略。

生产危险

把“必须完成的初始化”放进 sidecar（而非 init）是常见错误：sidecar 与主容器并行，无法阻拦主容器提前启动。需要“先完成后放行”的语义，必须用 init 容器。反之亦然——长期运行的旁路逻辑放进 init 容器会因“不退”而永远阻塞 Pod 启动。

故障排查

现象	原因	处理
`Init:N/M` 卡住	某 init 容器未成功（如依赖不可达）	`kubectl logs <pod> -c <init名>`；放宽等待逻辑
Pod 永不 Ready	sidecar 的 readiness 一直失败	检查 sidecar 探针与依赖
主容器起来但 sidecar 没跑	未设 `restartPolicy: Always`	修正为 sidecar 写法
镜像改了没生效	init 镜像变更不重启 Pod（v1.20+）	删除重建 Pod

常见坑

混淆 init 与 sidecar：restartPolicy: Always 是 sidecar 的关键标识，漏写就退化成“阻塞型 init”。
在 init 中用 readinessProbe 被校验拒绝却不明白原因。
认为 sidecar 退出码非 0 是异常（实际 Pod 终止时很正常）。

替代方案与权衡

旧版本集群可用“主容器 + 普通辅助容器”模拟，但缺少独立启停顺序保证。
复杂的网格/可观测增强已由 Istio/Linkerd/OpenTelemetry 等以 sidecar/ambient 模式标准化，优先用成熟方案而非自研。

FAQ

Q：Init 容器和 Sidecar 能混用吗？ A：可以。Pod 的 initContainers 列表中可同时包含普通 init（无 restartPolicy）与 sidecar（restartPolicy: Always），按列表顺序，sidecar 启动后保持运行，其后普通 init 仍可顺序执行。

Q：Sidecar 支持探针吗？ A：支持，且它的 readinessProbe 结果参与整个 Pod 的 Ready 状态；普通 init 容器不支持探针。

参考资料

Init Containers - Kubernetes 官方文档，访问日期：2026-10-08。
Sidecar Containers - Kubernetes 官方文档，访问日期：2026-10-08。
Pod Lifecycle（含重启策略与 sidecar 终止）- Kubernetes 官方文档，访问日期：2026-10-08。

Init Container 与 Sidecar 模式 ​

适用版本与前提 ​

背景与问题 ​

Init Container：启动前屏障 ​

关键特性 ​

Sidecar Container：原生旁路容器 ​

Sidecar 的生命周期 ​

生产模式 ​

故障排查 ​

常见坑 ​

替代方案与权衡 ​

FAQ ​

参考资料 ​