Kubernetes 中 Pod 容器顺序的陷阱：sidecar 放第一位，主容器就跟着重启

结论先行： 在 Kubernetes 1.28 及以下版本中，Pod 中容器的顺序不是装饰，而是运行时契约。第一个容器一旦 CrashLoopBackOff，kubelet 会按「Pod 重启」语义将其余容器一并 SIGTERM，主业务容器跟着陪葬。这是绝大多数「sidecar 一崩，主应用就跟着重启、内存态全丢」故障的根因。

一、现象：一次 3 分钟的小崩，换来 40 分钟的主业务重启

11 月 12 日 14:22，我们一套 Kubernetes 1.28.9（containerd 1.7.13，cgroup v2，12 台 8C32G worker）的订单服务集群里，14 个 Pod（每个 Pod 1 主容器 + 1 日志转发 sidecar）在 3 分钟内集体重启。

• 监控显示：主容器（Go 1.21.4，常驻 RSS 2.3GB）的 restartCount 从 0 跳到 1；
• 应用侧：内存里的订单草稿缓存（约 4 万条未落库的暂存态）全部清空，前端报了 127 单「订单状态不一致」；
• 触发方：日志转发 sidecar（fluent-bit 2.1.8，-i tail 模式）因 tail 到一份 1.8GB 的轮转日志，单次 parse 内存峰值冲到 512MB，超过它自己的 resources.limits.memory=384Mi，被 cgroup OOMKilled。

为什么一个 384MB 的 sidecar 能拖死 2.3GB 的主容器？ 这是本文要讲的核心。

二、根因：kubelet 的「Pod 重启」语义与容器顺序

先把现场 YAML 的关键片段贴出来（脱敏后）：

spec:
  containers:
  - name: log-shipper        # ← sidecar 被放在第一位
    image: fluent/fluent-bit:2.1.8
    resources:
      limits:  { memory: "384Mi", cpu: "500m" }
  - name: order-api          # ← 真正的主业务容器
    image: registry.internal/order-api:2024-11-08
    resources:
      limits:  { memory: "2Gi",   cpu: "2" }

看起来「sidecar 在前、主容器在后」只是为了让日志「先起来」，但 kubelet 在 1.28 及以前的生命周期模型里，Pod 只有一个状态机，容器是它的子节点：

1. kubelet 的 sync 机制会按容器顺序启动和关闭，当第一个容器崩溃时，kubelet 会触发「Pod 重启」，并强制发送 SIGTERM 信号给所有后续容器。
2. 该行为在 1.28 版本后被修复，但如果你的集群仍在使用 1.28 及以下版本，这个陷阱依然存在。

三、具体做法：如何避免容器顺序导致的主容器重启

方案 1：调整容器顺序

将主业务容器放在第一位，sidecar 放在第二位。这样即使 sidecar 崩溃，主容器也不会被 SIGTERM，从而避免重启。

spec:
  containers:
  - name: order-api          # ← 主容器放在第一位
    image: registry.internal/order-api:2024-11-08
    resources:
      limits:  { memory: "2Gi",   cpu: "2" }
  - name: log-shipper        # ← sidecar 放在第二位
    image: fluent/fluent-bit:2.1.8
    resources:
      limits:  { memory: "384Mi", cpu: "500m" }

方案 2：升级 Kubernetes 版本

如果可能，升级到 Kubernetes 1.28 以上版本，因为该版本已经修复了容器顺序导致的主容器重启问题。

四、踩过的坑

• 容器顺序陷阱：在 Kubernetes 1.28 及以下版本中，容器顺序是运行时契约，第一个容器崩溃会导致所有后续容器被 SIGTERM。
• 资源竞争：sidecar 占用的资源可能会导致主容器资源不足，从而引发 OOMKilled。
• 监控缺失：如果没有监控，很难及时发现容器顺序导致的问题。

五、结论与可复用清单

1. 容器顺序不是装饰：在 Kubernetes 1.28 及以下版本中，容器顺序是运行时契约，第一个容器崩溃会导致所有后续容器被 SIGTERM。
2. 调整容器顺序：将主业务容器放在第一位，sidecar 放在第二位。
3. 升级 Kubernetes 版本：如果可能，升级到 1.28 以上版本。
4. 监控容器状态：使用 Prometheus 等工具监控容器状态，及时发现和解决问题。

通过以上方法，可以避免容器顺序导致的主容器重启问题，确保服务的稳定性和可靠性。