先记住这个答案
Ready 是 Pod condition 之一，由 kubelet 周期性检查所有容器是否就绪（由 readiness 探针判定），并叠加用户声明的 readinessGates（每个必须为 True），全部为 True 时 Pod.Ready 才为 True。当 Ready 为 True 时，该 Pod 的 IP 才会被纳入对应 Service 的 Endpoints；否则会被摘除。这一机制将应用的就绪感知与流量调度解耦，便于实现金丝雀发布、优雅下线等控制。
- Ready 由容器就绪和 readinessGates 共同决定
- Ready=True 时 Pod 才进入 Service 端点
- Ready 与 phase 无关，Running 不代表 Ready
从容器就绪到 Pod Ready 的合成逻辑
kubelet 在每次状态同步周期内，会汇总每个容器由其 readiness 探针（若未定义则默认容器启动即就绪）得到的就绪布尔值。只有 Pod 里所有容器都处于就绪，kubelet 才把内置的 ContainersReady 条件置为 True。此外，kubelet 还需检查用户通过 spec.readinessGates 声明的自定义条件，这些条件名称符合 DNS label 格式，且必须出现在 status.conditions 中，否则视为不满足。
Pod 的 Ready 条件是上述两组的逻辑与运算：ContainersReady=True 且所有 readinessGates 都为 True 时，Ready 才为 True。若有任一 gate 缺失或为 False，即便容器全就绪，Ready 仍为 False。kubelet 仅负责维护内置条件，自定义 gate 的状态由外部控制器通过 API 子资源或客户端库更新，这一设计允许业务方将外部依赖（如配置中心、许可证）纳入就绪判定。
用 readinessGate 控制灰度接入流量
某账号系统主容器已启动并响应 healthz，但需等待每条租户配额同步完成后才能承接流量。平台在 Pod 上定义 readinessGate: example.com/quotas-ready，由配额控制器监听租户变更，在数据同步完成后将该 condition 置为 True。在条件为 False 期间，kubelet 会将 Ready 置为 False，Pod 的 IP 不会出现在对应 Service 的 Endpoints 列表。
当所有租户数据同步完成，控制器将 gate 翻转为 True，kubelet 在下一轮同步中检测到满足，才把 Pod 标记为 Ready，流量随 EndpointSlice 更新被引入。由于同步是异步过程，从 gate 翻转至端点生效往往有几秒延迟，适合平滑上线。若部分租户同步失败，条件保持 False，Pod 被隔离在流量外，相比修改探针逻辑，这种方式更显式且不侵入应用代码。
Ready 状态失效与运维边界
当 Pod 内容器崩溃并触发重启时，kubelet 会临时把对应容器就绪置为 False，Ready 随之变为 False，Service 端点移除该 Pod IP。但重启间隙可能很短，kubelet 的状态同步周期与端点传播存在延迟，极端情况下请求仍可能到达正在重启的 Pod，应用需依靠客户端重试来容忍。若节点网络不通，kubelet 无法上报状态，控制平面得不到更新，Ready 可能短暂保留旧值。
要准确判断 Pod 的就绪状态，应直接读取 status.conditions 中 type=Ready 的 status 字段，而不是依赖 kubectl get pods 的 READY 列——该列仅汇总容器就绪数，未反应 gate。遇到自定义 gate 时，需逐一检查每个 gate 条件是否已定义且为 True。运维若想主动摘除流量，可通过客户端库更新 status.conditions，但 kubectl patch 不支持直接修改 status，需用 kubectl replace 或 API 调用。
容易答错的地方
- 把 phase 等同于就绪
- Pod 进入 Running 只代表至少一个容器在运行，不保证容器已就绪。例如容器启动但 readiness 探针失败时 phase 仍为 Running，但 Ready 是 False。应以 conditions.Ready 作为流量池依据。
- 忽略 readinessGates
- 若定义了 readinessGates，但外部控制器从不更新这些条件，Pod 的 Ready 将永远为 False，即使容器全健康。这不是 bug，而是设计；因此新增 gate 时必须配套实现条件控制器。
面试官还会怎么问？
就绪探针失败时，Pod 会重启吗？
不会。readiness 探针只影响 Ready 条件，不触发重启；liveness 探针失败才会重启容器。因此将临界操作放在 liveness 会导致循环失败。
readinessGates 适合什么场景？
当容器进程存活但应用还需外部依赖（如配置、存储、手动审批）才可接收流量时，用自定义条件挂载到 Pod，使流量决策与进程解耦。
如果容器都已就绪但某个 gate 一直为 False，Service 端点会怎样？
Pod 的 Ready 为 False，因此该 Pod IP 会被移出 EndpointSlice。直到 gate 被外部置 True，流量才会重新导入。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。