Kubernetes多容器Pod终止流程及preStop钩子执行逻辑咨询

终止流程明确结论 #

K8s多容器Pod的终止流程为你提到的第二种：

并行处理所有容器，对配置了preStop钩子的容器触发钩子执行，未配置的容器直接发送SIGTERM信号。

所有容器的终止流程是并行触发的，不存在全局等待所有容器preStop执行完成后，再统一给所有容器发SIGTERM的逻辑。每个容器的终止链路独立执行：先执行自身配置的preStop钩子（无配置则跳过该步骤），钩子执行完成后，再向容器主进程发送SIGTERM信号，达到优雅终止超时时间后还未退出的进程会被SIGKILL强制终止。

现有方案问题 #

你仅给A容器配置preStop的方案无法实现A先于B终止的需求：B容器如果没有配置preStop，Pod终止指令触发后B会立即收到SIGTERM信号开始退出，完全不会等A的preStop执行完成，会导致A的下线过程中依赖的B服务已经不可用。

正确实现A先于B终止的方案 #

要保证A终止完成后B再开始终止，需要通过preStop钩子配合共享存储实现，具体操作如下：

• 给Pod新增一个emptyDir类型的共享卷，挂载到A、B两个容器的相同路径下
• A容器保留preStop钩子，逻辑调整为：先完成自身的优雅下线全流程，再向共享卷写入终止完成标记文件，示例钩子配置：

lifecycle:
  preStop:
    exec:
      command:
      - /bin/sh
      - -c
      - |
        # 这里写A自身的优雅下线逻辑，比如等待请求处理完成、通知注册中心下线等
        # 下线完成后写标记
        touch /shared/pod-terminate-flag

• 给B容器新增preStop钩子，逻辑为循环检测共享卷下的终止标记文件，检测到标记后再退出preStop，示例钩子配置：

lifecycle:
  preStop:
    exec:
      command:
      - /bin/sh
      - -c
      - |
        # 等待A的终止标记，最多等待时间不要超过Pod的优雅终止超时时间
        while [ ! -f /shared/pod-terminate-flag ]; do sleep 0.2; done

• 调整Pod的terminationGracePeriodSeconds参数，取值要大于A的优雅终止时长 + B的preStop等待时长 + B自身的优雅终止时长，避免进程被强制杀掉。

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