Kubernetes Pod关闭时Sidecar容器是否立即终止？实际场景确认

问题背景 #

我在Kubernetes Pod中运行一个Java服务容器与heapdump-sidecar容器，该Sidecar的作用是当Java服务因OOM崩溃重启时，将堆转储文件上传至GCP存储桶。Sidecar的配置如下：

- name: heapdump-sidecar
  image: google/cloud-sdk:latest
  command:
    - /bin/sh
    - -c
    - |
      while true; do
        heap_dump_file="/appdata/java/heapdumps/heapdump.hprof";
        gs_bucket="gs://namespace-non-prod/heap-dump-{{ .Values.environment }}-bucket/";
        if [ -f "$heap_dump_file" ]; then
          echo "Heap dump file found. Uploading to GCS...";
          gsutil cp "$heap_dump_file" "$gs_bucket{{ .Chart.Name }}-$(date +%Y-%m-%d-%H-%M-%S).hprof";
          if [ $? -eq 0 ]; then
            echo "Heap dump uploaded successfully.";
            rm -rf /appdata/java/heapdumps/*;
          else
            echo "Heap dump upload failed";
          fi;
        else
          echo "Heap dump file not found. Waiting...";
        fi;
        sleep 5;
      done

现有两种假设场景：

• 场景1：Pod收到SIGTERM信号开始关闭流程，Sidecar容器立即终止，Pod等待Java服务容器关闭（10秒），最终Pod在10秒后被销毁。
• 场景2：Pod收到SIGTERM信号开始关闭流程，Sidecar容器不立即终止。Java服务容器10秒后关闭，但Pod需等待未终止的Sidecar，30秒优雅期结束后Pod被强制销毁，总耗时30秒。

请问实际会是哪种场景？

结论 #

实际会是场景2。

原因分析 #

1. Kubernetes Pod终止逻辑：当Pod收到SIGTERM信号时，会同时向Pod内所有容器发送SIGTERM信号，随后启动默认30秒的优雅终止倒计时。只有当所有容器都主动退出后，Pod才会被销毁；若倒计时结束仍有容器未退出，Kubernetes会向这些容器发送SIGKILL强制终止。
2. Sidecar的信号处理缺陷：该Sidecar通过/bin/sh -c执行循环脚本，默认情况下sh进程不会将收到的SIGTERM信号转发给其启动的子进程（循环逻辑、sleep命令等），且脚本本身未添加捕获SIGTERM并主动退出的逻辑。因此，当SIGTERM发给Sidecar的sh进程时，它不会立即终止，会继续执行完当前循环的sleep 5，甚至重复循环，直到优雅期结束被强制杀死。
3. Java服务容器的行为：假设Java服务容器正确处理了SIGTERM信号，会在10秒内完成优雅关闭，但此时Sidecar仍在运行，Pod会继续等待，直到30秒优雅期结束，最终被强制销毁，总耗时30秒。

内容的提问来源于stack exchange，提问作者rishav