Kubernetes readinessProbe启动时阻断Pod间通信？是否正常及解决方案

1. 失败的ReadinessProbe是否会影响同一Deployment内其他Pod的流量？ #

不会。Kubernetes Service仅会将流量转发至处于就绪状态的Pod，未通过ReadinessProbe的Pod只会被排除在Service的端点列表之外，同一Deployment内的其他就绪Pod仍能正常接收Service流量，不受影响。

2. 你遇到的情况是否符合预期？ #

• 关于「未就绪Pod的集群成员端口无法被其他就绪Pod访问」：若无额外配置网络策略限制，这不符合Kubernetes默认行为。ReadinessProbe仅控制Pod是否被Service纳入路由范围，不限制Pod之间的直接网络通信。
• 关于「ReadinessProbe检查集群加入后的端点导致Pod永远无法就绪」：这属于探针配置逻辑的问题——你设置的探针依赖Pod先加入应用集群，但Pod加入集群可能又需要其他Pod能访问它的集群端口，形成了循环依赖，自然会导致Pod始终无法进入就绪状态。

3. 可行的解决办法 #

• 调整ReadinessProbe检查逻辑：不要依赖应用集群加入后的端点，改用基础检查项，比如检查应用基础服务端口是否启动，或通过exec探针执行应用内置的集群状态查询命令（确认成员身份已建立），避免循环依赖。
• 拆分探针职责：用LivenessProbe保障应用进程存活，给ReadinessProbe设置合理的initialDelaySeconds和failureThreshold，给应用足够时间完成集群加入，再进行就绪检查。
• 修改应用集群加入逻辑：让应用在未加入集群时也开放集群成员端口，允许其他Pod访问，打破循环依赖，待集群加入完成后再满足ReadinessProbe的条件。
• 使用生命周期钩子辅助：通过Pod的postStart钩子执行集群加入逻辑，或自定义脚本监控集群状态，当确认加入成功后再标记Pod就绪（配合自定义的ReadinessProbe脚本）。

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