为什么执行kubectl get pods时会出现Pod状态为NotReady的情况？

首先澄清认知误区：NotReady并非节点专属状态。Kubernetes的Pod就绪状态由Pod内所有普通业务容器的运行状态、就绪探针结果共同判定：只有所有容器都满足就绪条件时，Pod才会标记为Ready，只要有任意一个容器不满足要求，Pod整体就会显示NotReady，对应kubectl get pods输出中READY列的格式为「就绪容器数/总容器数」，你当前的two-containers Pod显示为1/2，即2个容器中仅1个就绪。

通用排查步骤 #

遇到Pod NotReady问题可按以下步骤定位：

• 查看kubectl get pods输出的READY列，确认未就绪的容器数量
• 执行kubectl describe pod <Pod名称>查看容器事件、运行状态，定位异常容器
• 执行kubectl logs <Pod名称> -c <异常容器名>查看容器运行日志，确认异常原因

你的场景具体根因 #

从你提供的Pod YAML配置可直接定位问题：

• 该Pod包含两个普通业务容器，其中debian-container的启动逻辑仅为执行echo Hello from the debian container > /pod-data/index.html命令，命令执行完成后容器无常驻进程，会直接进入退出完成状态
• 你配置的Pod重启策略为restartPolicy: Never，因此debian-container退出后不会被重启，始终处于非运行状态，不满足就绪要求
• 另一个nginx-container正常运行处于就绪状态，最终Pod整体就绪数为1/2，状态标记为NotReady

可选修复方案 #

• 如果debian-container的作用仅为初始化写入共享文件，无需常驻运行：将其调整到initContainers字段下定义为初始化容器，初始化容器执行完成后退出不会影响Pod的就绪判定
• 如果需要两个容器都常驻运行：修改debian-container的启动参数，增加常驻进程逻辑，示例如下：

args: ["-c", "echo Hello from the debian container > /pod-data/index.html && tail -f /dev/null"]

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