概述先聊个场景。你有一个 Web 应用启动前需要等数据库 ready、跑完迁移脚本还要在运行期间持续采集日志推送到中心存储。传统做法是把这些逻辑全塞进主容器——镜像臃肿、职责不清、出了问题还不好排查。Kubernetes 多容器 Pod 就是专门解决这个问题的。一个 Pod 里可以跑多个容器它们共享同一个网络命名空间和存储卷。这里面有两个核心模式Init 容器在主容器启动前按顺序执行跑完就退出。适合做前置检查、配置初始化、数据迁移。Sidecar 容器跟主容器并肩运行提供辅助能力。日志采集、流量代理、监控采集这些都是典型场景。适用环境Kubernetes 1.28原生 Sidecar 自 v1.28 作为 Alpha 特性引入v1.29 升级为 Beta 并默认启用v1.33 正式 GA。本文所有 YAML 示例基于Kubernetes v1.33验证。前置条件在继续之前你需要一个可用的 Kubernetes 集群版本 ≥ 1.29以便原生 Sidecar 默认启用kubectl命令行工具已配置基本的 Pod、Deployment 操作经验目标读者具备 Kubernetes 基础操作能力的初级 SRE⚠️ 如果你的集群版本低于 v1.29需要确认SidecarContainers特性门控是否开启。v1.28 是 Alpha 状态v1.29 起默认启用。该特性门控已在 v1.33 中锁定为默认值并将在 v1.36 中移除。一、Init 容器启动前的“守门员”先说 Init 容器。它在spec.initContainers字段中定义跟spec.containers平级。核心规则就三条Init 容器在主容器之前启动多个 Init 容器按顺序执行前一个成功退出后下一个才开始任何一个失败整个 Pod 就不会启动主容器典型场景等待数据库就绪apiVersion: v1 kind: Pod metadata: name: myapp-with-init spec: initContainers: - name: wait-for-db image: busybox:1.36 command: [sh, -c, until nc -z mysql-service 3306; do echo waiting for mysql; sleep 2; done] containers: - name: myapp image: nginx:1.25这个 Init 容器会一直重试连接 MySQL直到成功才退出然后主容器才会启动。我踩过的坑Init 容器里千万别做长时间运行的事。它跑多久主容器就等多久Pod 启动时间直接拉长。生产环境里我见过有人把 Init 容器搞成死循环Pod 一直卡在Init:0/1状态排查了半天才发现是脚本里少了个break。二、原生 Sidecar 容器Kubernetes v1.29 后的正确打开方式在 Kubernetes v1.29 之前Sidecar 只能通过在spec.containers里多加一个容器来实现。这种方式有个致命问题Job 场景下主容器退出了Sidecar 还在跑Pod 永远无法变成 Completed 状态。原生 Sidecar 解决了这个问题。它的定义方式有点“反直觉”——放在initContainers里加上restartPolicy: Always。apiVersion: v1 kind: Pod metadata: name: myapp-with-sidecar spec: initContainers: - name: log-shipper image: fluent/fluent-bit:3.2 restartPolicy: Always # 这一行让它变成 Sidecar volumeMounts: - name: logs mountPath: /var/log containers: - name: myapp image: nginx:1.25 volumeMounts: - name: logs mountPath: /var/log/nginx volumes: - name: logs emptyDir: {}关键语义Sidecar 在主容器之前启动Sidecar 在主容器之后终止在 Job 场景下主容器退出后 Sidecar 会被强制终止退出码为 0Sidecar 可以独立重启不影响主容器如果给 Sidecar 配置了readinessProbe它的就绪状态会影响整个 Pod 的Ready状态Job 场景下Sidecar 不阻塞 Pod 完成Sidecar vs 普通多容器特性原生 SidecarinitContainers restartPolicy: Always普通多容器containers启动顺序在主容器之前未定义并行启动终止顺序在主容器之后同时收到 SIGTERM无先后保证Job 兼容性✅ 不阻塞 Pod 完成❌ 会导致 Job 永不完成重启独立性✅ 可独立重启✅ 可独立重启三、组合使用Init 容器 Sidecar 容器一个 Pod 里可以同时有常规 Init 容器和 Sidecar 容器。执行顺序是常规 Init 容器按顺序执行跑完退出Sidecar 容器启动保持运行主容器启动apiVersion: apps/v1 kind: Deployment metadata: name: full-example spec: replicas: 1 selector: matchLabels: app: full-example template: metadata: labels: app: full-example spec: # 第一步常规 Init 容器——等待依赖 initContainers: - name: wait-for-db image: busybox:1.36 command: [sh, -c, until nc -z mysql-service 3306; do sleep 2; done] # 第二步Sidecar 容器——日志采集 - name: log-shipper image: fluent/fluent-bit:3.2 restartPolicy: Always volumeMounts: - name: logs mountPath: /var/log # 第三步主容器 containers: - name: app image: myapp:1.0 volumeMounts: - name: logs mountPath: /var/log/app volumes: - name: logs emptyDir: {}四、多容器通信共享网络和存储同一个 Pod 里的容器天然共享两样东西1. 网络命名空间—— 容器间通过localhost直接通信。比如主容器监听 8080Sidecar 可以通过localhost:8080访问它。2. 存储卷—— 通过volumes和volumeMounts共享文件。apiVersion: v1 kind: Pod metadata: name: shared-volume-pod spec: containers: - name: writer image: alpine:3.19 command: [sh, -c, while true; do echo $(date) /shared/data.txt; sleep 5; done] volumeMounts: - name: shared mountPath: /shared - name: reader image: alpine:3.19 command: [sh, -c, tail -f /shared/data.txt] volumeMounts: - name: shared mountPath: /shared volumes: - name: shared emptyDir: {}小彩蛋如果你需要容器间共享进程命名空间比如一个容器给另一个容器发信号可以在 Pod spec 里加shareProcessNamespace: true。但这个特性在生产环境用得不多我一般不建议轻易开启可能带来安全隐患。五、验证方法1. 查看 Pod 状态和容器状态kubectl get pod pod-name kubectl describe pod pod-namedescribe输出的Init Containers和Containers部分会分别显示各容器的状态。2. 查看特定容器的日志# 查看 Init 容器日志Pod 启动后仍可查看 kubectl logs pod-name -c wait-for-db # 查看 Sidecar 容器日志 kubectl logs pod-name -c log-shipper # 查看主容器日志 kubectl logs pod-name -c app3. 验证 Sidecar 在 Job 中正常退出创建一个测试 Job观察 Pod 是否能正常进入Completed状态kubectl get pod -l job-nametest-sidecar # 预期输出STATUS 为 Completed六、常见问题Q1Init 容器一直卡住Pod 无法启动现象Pod 状态一直显示Init:0/1或Init:0/2。说明Init:N/M表示 Pod 包含 M 个 Init 容器其中 N 个已经运行完成。如果一直卡在Init:0/1说明第一个 Init 容器还没完成——可能正在运行也可能已经失败但在重启。如果 Init 容器失败状态会变为Init:Error—— Init 容器已执行失败Init:CrashLoopBackOff—— Init 容器执行总是失败解决方法检查 Init 容器日志kubectl logs pod-name -c init-container-name给 Init 容器加超时逻辑避免无限等待确认依赖的服务地址和端口是否正确Q2把 Sidecar 写在initContainers里但忘了加restartPolicy: Always现象社区真实案例The problem youre having here: if you use an initContainer as a sidecar, you must set restartPolicy: Always for that initContainer, or youll get the problem youre having. So that is the likely fix.解决方法在initContainers条目中显式添加restartPolicy: Always。Q3传统多容器 Pod 在 Job 中永不完成场景你在 Job 的spec.containers里塞了一个日志采集容器Job 的主任务跑完后Pod 一直卡在Running状态永远不会变成Completed。原因普通容器没有“主容器退出后自动终止”的机制。解决方法将辅助容器改为原生 Sidecar放在initContainers里 restartPolicy: Always。Q4Init 容器与 Istio CNI 的兼容性问题场景集群启用了 Istio 且使用了 CNI 插件Init 容器发出的请求被重定向到尚未启动的 Sidecar 上导致流量丢失。解决方法参考 Istio 官方文档通过注解或配置调整流量拦截策略。Q5Sidecar 的readinessProbe影响整个 Pod 的就绪状态场景你给 Sidecar 配置了readinessProbe但探针一直失败结果整个 Pod 的Ready状态一直是FalseService 不转发流量。解决方法确认 Sidecar 的readinessProbe配置是否合理如果 Sidecar 的就绪状态不应该影响 Pod 整体就绪考虑移除readinessProbe或调整探针参数七、限制说明使用原生 Sidecar 时有几个重要的限制需要了解仅适用于initContainers原生 Sidecar 必须定义在spec.initContainers中并设置restartPolicy: Always不能直接放在spec.containers里。特性门控依赖如果集群版本低于 v1.29需要手动开启SidecarContainers特性门控。该特性门控将在v1.36 被移除因为特性已稳定不再需要门控。ReadinessProbe 会影响 Pod Ready 状态如果为 Sidecar 设置了readinessProbe探针失败会导致整个 Pod 的Ready状态为False。Sidecar 不适用于所有场景官方文档明确说“除非用例有必要否则通常不是首选方案”。内置库或共享基础设施可能是更简单的替代方案。八、生产环境建议默认用单容器 Pod除非有明确的 Sidecar 或 Init 容器需求。每多一个容器就多一份复杂度和资源开销。Init 容器要保持轻量和快速。跑得越久Pod 启动越慢发布效率越差。Kubernetes 版本 ≥ 1.29 时优先用原生 Sidecar替代传统多容器方式尤其是在 Job 场景下。给 Sidecar 和 Init 容器都设置 resource limits防止它们抢占主容器的资源。慎重评估是否真的需要 Sidecar。添加 Sidecar 会增加复杂性、资源消耗和潜在的网络延迟。如果觉得有用欢迎分享给更多踩坑的战友。互动问题你在生产环境里用过多容器 Pod 吗有没有遇到过 Job 场景下 Sidecar 导致 Pod 无法完成的坑欢迎在评论区分享你的经历。