Kubernetes Pod重启时Init容器未重新执行如何强制触发

部署Init容器用于执行主容器运行所需的前置准备工作，例如创建必要运行目录；主容器配置liveness探针，若前述目录被删除则探针探测失败。预期Pod因liveness探针失败触发重启时Init容器会同步重启，但实际未触发该行为。

Kubernetes官方文档对应描述为：

If the Pod restarts, or is restarted, all init containers must execute again.

基于官方文档的Pod示例新增始终返回失败的liveness探针做复现验证，预期Pod重启时Init容器会重新执行，实际表现仍不符合预期。

测试配置 #

测试使用的Pod配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  restartPolicy: Always
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo "App started at $(date)" && tail -f /dev/null']
    livenessProbe:
      exec:
        command:
        - sh
        - -c
        - exit 1
      initialDelaySeconds: 1
      periodSeconds: 1
  initContainers:
  - name: myapp-init
    image: busybox:1.28
    command: ['/bin/sh', '-c', 'sleep 5 && echo "Init container started at $(date)"']

配置中添加sleep和date命令，用于通过日志输出确认Init容器是否发生重启。

复现观测结果 #

集群状态显示Pod RESTARTS计数持续上涨：

NAME            READY   STATUS    RESTARTS   AGE
pod/myapp-pod   1/1     Running   4          2m57s

但容器日志显示Init容器仅执行过一次，未随主容器重启重新运行：

$ k logs pod/myapp-pod myapp-init
Init container started at Thu Jun 16 12:12:03 UTC 2022

$ k logs pod/myapp-pod  myapp-container
App started at Thu Jun 16 12:14:20 UTC 2022

上述现象已在v1.19.5、v1.24.0版本Kubernetes集群完成验证。

该现象是对文档中「Pod重启」的定义理解偏差导致，并非功能异常：

• kubectl get pod输出中RESTARTS字段统计的是Pod内容器的重启次数，不是Pod本身的重建次数。liveness探针失败仅会触发对应业务容器的重启，不会销毁整个Pod实例，Pod的UID、创建时间、网络命名空间、挂载的存储卷都保持不变，这种场景下不会重新执行Init容器。
• 文档中提到的会触发Init容器重跑的「Pod重启」，指的是Pod实例被完全销毁后重新创建的场景，例如节点故障导致Pod漂移、手动删除Pod后被工作负载控制器重建、Pod沙箱环境被完全销毁重建，这类场景下才会重新执行所有Init容器。

• 优先方案：将运行时初始化逻辑下沉到主容器启动流程
  目录创建、权限修正这类和主容器生命周期强绑定、可能在运行时被破坏的初始化逻辑，不要放在Init容器中，直接作为主容器启动命令的前置步骤执行，每次主容器重启都会自动重跑这部分逻辑。示例配置修改如下：

  command: ['sh', '-c', 'mkdir -p /your/required/runtime/path && echo "App started at $(date)" && tail -f /dev/null']
  

  该方案无额外依赖，稳定性最高，完全匹配liveness探针触发重启的场景。
• 备选方案：通过控制器触发Pod整体重建
  如果初始化逻辑必须放在Init容器中，可以搭配额外的检测逻辑，当发现主容器异常退出/重启时，主动标记Pod状态异常，删除，触发工作负载控制器创建全新Pod实例，此时Init容器会随新Pod创建重新执行。该方案会带来额外的调度、网络分配开销，配置复杂度高，非必要不推荐使用。

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