Kubernetes Pod 显示 1/1，Ready 仍为 False：检查 readinessGates

kubectl get pods 显示 1/1 Running，Deployment 却仍等待这个 Pod 就绪，EndpointSlice 中的端点也可能是 ready: false。容器就绪数量与整个 Pod 的 Ready 条件不是同一项；如果 Pod 配了 readinessGates，还必须满足这些额外条件。

这里针对容器本身已就绪，但额外 gate 缺失或未为 True 的场景。readinessProbe 仍失败、初始化没有完成时，应先处理相应条件，不能把所有 rollout 等待都归到 gate。

用 wide 输出展开额外条件

先查实际失败 Pod，而不是只看模板。下面的名称都是占位值：

kubectl -n app get pod api-pod -o wide
kubectl -n app describe pod api-pod

wide 输出中的 READINESS GATES 可以显示类似 0/1：容器可能已经是 1/1，但一项额外 gate 还没有通过。没有 gate 的 Pod 则不按这个比例判断。

进一步核对 spec.readinessGates 中每个 conditionType，与 status.conditions 里的同名条件，连同 Ready、ContainersReady、reason、message 和时间一起看。某个 gate 在 conditions 中完全缺失时，也会按 False 处理；没有记录不表示无需等待。

必要时在受控终端读取 Pod YAML，避免把其中的环境配置未经处理发到公开日志。要精确比较 gate 名称，不能只因为存在一个相似前缀的 True 条件就算通过。

找到负责写这个条件的控制器

自定义 readiness gate 由应用或相应控制器维护。kubelet 会判断条件，却不会凭空完成外部系统的注册或健康检查。先查 conditionType 所属组件，再把当前 reason、message 与该组件日志、权限和外部状态对应起来。

例如 AWS Load Balancer Controller 使用 target-health.elbv2.k8s.aws 前缀的条件，表示相应 IP target 在 ALB/NLB 目标组中的就绪情况。容器的本地就绪探针已经成功，而外部目标仍处于注册或健康检查过程中，是可能的正常等待阶段。

如果等待持续异常，检查预期 TargetGroupBinding、目标注册、健康检查路径与端口，以及控制器是否正常更新状态。具体修正应依据错误：目标未注册与目标健康检查失败，不能用同一个“重启应用”处理。

不是所有 gate 都属于 AWS，也不是所有 AWS 后端模式都会注入这项条件。对于已经核对的控制器 2.14.0，自动注入涉及 namespace 标签、匹配 Service、TargetGroupBinding 与 IP target，且发生在 Pod 创建时。其他版本、控制器和手工 gate 要按实际配置判断。

不要为了 rollout 完成伪造就绪

给自定义条件强行写 True，或从模板中删掉 gate，可能让旧 Pod 在新目标尚未能接流量时被替换。这会改变发布可用性判断，不能当作条件更新失败的普通修复。

如果 gate 确实是过期配置、对应组件已撤除，需要由部署设计明确新的健康与发布条件，再调整原模板。应检查流量入口、更新策略和可用副本，在隔离环境验证；不靠逐个编辑受控制器管理的 Pod 留下临时状态。

正常配置中的 gate 未通过时，先修其所属组件的具体失败，再等待它按真实状态更新。修改前保存工作负载、相关服务与控制器配置，保留仍可用的后端，避免为诊断同时重启全部副本。

以 Pod 条件和真实入口验收

修复后应确认所需自定义条件全部为 True、Pod Ready 符合预期，工作负载更新能够继续，以及实际入口确实能到达新后端。普通带选择器 Service 还需核对EndpointSlice 就绪状态，不能只以列表的 1/1 验收。

涉及外部负载均衡时，也要在目标组与访问路径上验证，Pod Ready 不是所有网络层均无故障的保证。回退需恢复配套模板、控制器和目标注册设置；外部系统的状态不会只因 Deployment 回滚就自动撤销。