K8s多容器Pod场景下部分容器存活探针异常时的行为机制

核心结论：K8s只会重启存活探针检测失败的单个容器，不会重启整个Pod

具体执行逻辑 #

• 每个容器的存活、就绪探针检测是完全独立的运行逻辑，不存在同Pod容器的联动触发机制，节点上的kubelet会对每个容器单独开展周期检测，不会把单个容器的探针结果和同Pod其他容器的状态做绑定。
• 当检测到某一个容器的存活探针连续失败达到预设阈值时，kubelet仅会对该容器执行终止、重建操作：同Pod内其他已经通过存活探针检测的容器会保持原有运行状态，Pod的网络命名空间、存储卷挂载、容器共享的IPC资源等Pod级配置全程不会发生变化。
• 重启失败容器的全过程，不会触发Pod重新调度，Pod的对象标识、分配的IP、挂载的存储卷都保持不变，属于Pod运行时的内部容器状态调整，不是整个Pod的生命周期重建。
• 注意区分不同探针的处理差异：
  • 存活探针失败达到阈值后，触发单容器重启
  • 就绪探针失败的处理仅为将对应容器从Service的可访问端点列表中移除，不会触发任何重启操作

常见认知误区 #

• 不少人会把Pod作为最小调度单元的特性，误判单容器探针失败会触发整个Pod重建：实际上只有Pod对象本身需要被重建的场景（比如节点故障、Pod配置被修改触发更新、被驱逐、所有容器全部终止后被判定需要拉起），才会重新创建整个Pod的资源。
• 单容器重启的过程中，同Pod的其他容器完全无感知，不会出现流量中断、连接重置的连带影响。

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