探针

Startup 探针为容器提供单独的初始化契约。在已经配置的启动探针成功之前，Kubernetes 不会执行这个容器的 liveness 或 readiness 探针。这比“宽限期内忽略一些存活失败”更具体：另外两种检查根本还没有开始。启动检查成功之后，后续健康和就绪判断才按各自规则接管，不能把三个名称理解成同一个接口的不同标签。 阈值乘周期可辅助规划，不是精确重启时刻。启动成功不强迫就绪成功，也不保证持续健康。本轮没有重跑原文保留的 Kubernetes 集成实验。 为每个阶段定义可观察条件 应用进程必须先运行，启动探针才可能成功。因此，容器已经 Running 时，container status 中的 started 仍可能为 false，所在 Pod 也可能尚未 Ready。运行状态描述进程正在执行，启动成功则描述配置的检查条件已经满足。提前开放的 HTTP 监听端可以报告进度，但不应该因此自动声称全部准备已经完成。 启动条件应代表必要的本地准备，例如加载索引或验证初始状态。只有打开端口确实就是所需前置条件时，单纯检查端口才足够。如果监听器先出现，昂贵的初始化稍后才结束，过早成功的检查就会提前解除存活保护，再次造成原本想避免的重启循环。接口名称不会替应用定义初始化完成的真实含义。 启动检查一旦成功，kubelet 就停止当前容器实例的 startup 探针，并按独立配置运行存活与就绪检查。启动成功不是永久健康证明：应用稍后仍可能变成未就绪，或者需要重启。新的容器实例还要重新完成自己的启动检查，不能继承上一实例已经成功的结论。把实例身份和状态变化一起记录，才能解释重复启动的原因。 坏掉的样子 启动探针如果一直不成功，最终会达到失败阈值。Kubelet 随后终止容器，并根据对应重启策略处理。因此，启动保护不是允许初始化无限等待。周期、超时和失败阈值应依据真实初始化耗时设置，同时考虑环境中可能发生的资源争用与可以接受的恢复时间，避免只按开发机器的一次快速启动选择参数。 failureThreshold 与 periodSeconds 的乘积可用于规划启动预算，但不能把它写成所有实际重启都严格遵守的秒表。初始延迟、探针执行与调度、终止宽限和重启退避也影响完整时间线。排查慢发布时，应记录真实尝试和状态变化，而不是仅根据两个配置数字推断容器应该已经重启，或断定平台行为错误。 除非通过 startup 明确建立依赖，否则不应认为 liveness 会等 readiness 成功才开始。就绪与存活原本回答两个持续运行阶段的问题。反过来，启动成功也不会强迫就绪成功：后续 readiness 可能因为另一个条件拒绝流量资格，而进程仍然正常存活。把这些结果分开，才能选择正确恢复动作，避免用反复重启处理暂时不可服务。 ...

慢启动不等于进程已死。readiness 与 liveness 分别决定普通 Service 流量是否应该进入这个 Pod，以及终止容器是否有助于恢复，两项决策相互独立。readiness 失败不会暂停 liveness；需要配置 startup 探针，才能在启动阶段抑制另外两种检查。只把接口分成两个名字，不能自动解决这个时序问题。 本文关注健康信号的选择与接线错误的诊断。关键是每次检查实际测到了什么，而不是 URL 名称。共用一个接口可以合理；共用会因下游抖动而失败的检查，并据此触发不必要的重启，却可能扩大故障。设计时应验证具体故障模式与预期恢复动作，不能假定有两个接口就天然安全，也不能把“还没准备好”直接解释成“需要杀死重来”。 普通 Service 路由异步收敛；已有连接与 Pod 直连需要另行考虑。 Readiness 把流量挡在门外 连续 readiness 失败达到阈值，会让 Pod 失去普通 Service 路由资格，但 Pod 仍在运行，好让进程完成热身或自行恢复。端点条件与数据路径在失败、恢复两个方向都异步收敛；已有连接和 Pod 直连需要分别考虑。就绪失败不直接触发探针重启，却可能移除全部服务容量，不能无条件称为安全：缓存可以慢慢热，迁移可以跑完，下游依赖可以回来，全程不丢 Pod 的内存状态，也不付重启的代价。 ...

Readiness 与 liveness 回答不同的运维问题。就绪探针判断当前容器是否应该参与一个能够接收普通 Service 流量的 Pod，存活探针则判断是否应该执行预先配置的容器重启恢复。两者都可以使用 HTTP，但协议相同不代表语义相同。应先确定希望平台采取什么动作，再设计触发该动作的条件，否则一个健康接口可能同时承担互相冲突的责任。 Kubernetes 1.34.11 观察属于历史记录，本次未重跑。直接 HTTP 检查仅从同一 Pod 访问自身地址。就绪状态不是网络访问控制；样例不证明优雅排空或生产可用性。执行仍为受阻。 同时观察响应和平台动作 就绪探针失败会让容器变成未就绪，并影响 Pod 的 Ready 条件。对于普通带选择器的 Service，端点协调随后改变哪些后端可以参加正常路由。Pod 可以保持 Running，同时处于未就绪状态，应用进程也可能继续运行。重启次数、Pod 标识和 Ready 条件回答的是不同问题，排查时不能只看其中一个状态就推导全部行为。 存活探针连续失败达到配置阈值后，kubelet 会终止容器并按相应重启规则处理。普通 Always 策略应用 Pod 会在原 Pod 中获得替换容器，而不是必然创建一个新 Pod 对象，也不是发布另一版应用。应在比较 Pod 身份的同时查看容器重启次数与终止状态，避免把一次进程恢复误报为完整工作负载替换。 ...