如何在代码中获取Readiness Probe结果 能否用容器存在状态作为就绪探针判定指标

问题核心误解澄清 #

• 首先纠正两个认知偏差：
  1. 就绪探针检测不通过不会阻止容器创建：容器会正常拉取镜像、启动运行，只是K8s不会将该Pod加入对应Service的后端端点列表，不会把流量转发给它而已。你观察到的"容器不会被创建"是错误结论，大概率是把存活探针（Liveness Probe）的效果和就绪探针混淆了，或者是容器本身启动失败退出导致的重建，和就绪探针无关。
  2. 你找错了状态字段的存储位置：k8s.io/api/core/v1.Container是容器的静态规约结构体，仅存储你声明的容器配置，自然没有运行时的就绪状态。运行时的容器就绪状态存在于v1.PodStatus的containerStatuses数组中，每个元素都有明确的Ready布尔字段，直接标识该容器的就绪探针是否通过。

核心问题回答 #

绝对不能将容器存在状态作为Readiness Probe通过的判定指标。
容器存在仅代表容器的进程被操作系统拉起，完全不代表容器内的服务可以正常响应请求：绝大多数服务进程都有初始化流程，比如加载配置、建立数据库连接、预热缓存等，这个阶段容器已经存在，但服务完全不可用，此时A容器如果发起调用必然会报错。

同Pod容器启动依赖的正确实现方案 #

如果需要A容器必须等B容器就绪后再启动，推荐两种实现方式：

1. 使用Init容器：给Pod配置一个Init容器，在Init容器中轮询探测B容器的服务端口/健康接口，探测成功后Init容器退出，K8s才会启动A容器。示例探测命令可以用curl或者nc，比如while ! nc -z localhost 8080; do sleep 1; done（同Pod内容器共享网络命名空间，可以直接用localhost访问B的端口）。
2. A容器启动脚本前置探测：修改A容器的启动入口脚本，在启动A的主进程之前，先执行和上面一样的探测逻辑，确认B服务可用后再启动主进程。

如果你使用K8s 1.29及以上版本，还可以将B容器声明为Sidecar容器，K8s会保证Sidecar容器就绪后再启动普通业务容器，无需额外写探测逻辑。

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