Kubernetes探针怎么配置？容器健康检查实践

Kubernetes探针配置决定了平台如何判断容器是否启动完成、是否还能继续运行、是否可以接收流量。很多团队把探针简单理解为“访问一个健康检查接口”，结果生产中出现两类问题：探针过松，应用已经异常却仍接收流量；探针过紧，短暂抖动就触发重启或从 Service 后端摘除，造成更大波动。

容器健康检查不是为了让 YAML 更完整，而是为了支撑滚动发布、故障恢复、自动扩缩容和流量调度。探针配置合理，平台才能知道什么时候放流量、什么时候重启容器、什么时候等待应用完成初始化。

三类探针分别解决什么问题

startupProbe 用于判断应用是否启动完成。它适合启动慢、初始化复杂或首次加载数据较久的应用。配置了 startupProbe 后，Kubernetes 会在启动探针成功前暂缓其他探针判断，避免应用还在初始化时被存活探针误杀。

readinessProbe 用于判断容器是否可以接收流量。就绪失败时，Pod 不会被 Service 作为可用后端，但容器不会因此自动重启。它适合表达应用依赖未准备好、预热未完成、临时不应接流量等状态。

livenessProbe 用于判断容器是否需要重启。存活失败会触发容器重启，因此它应只用于无法自恢复的状态，例如进程僵死、主循环卡死。不要把短暂依赖失败放进 liveness，否则会把外部依赖抖动放大成重启风暴。

探测方式怎么选

Kubernetes 常见探测方式包括 HTTP、TCP 和 exec。HTTP 探针适合 Web 服务和提供健康检查接口的应用，能够表达更丰富状态。TCP 探针只确认端口是否可连接，适合简单进程存活判断，但不能说明业务是否可用。exec 探针在容器内执行命令，适合检查本地文件、进程或特定脚本，但要注意命令耗时和资源开销。

对于多数在线服务，readinessProbe 建议使用 HTTP 接口，并区分浅层健康和深层依赖。livenessProbe 可以更保守，只检查进程主功能是否卡死。startupProbe 则应结合应用真实启动时间设置足够宽松的失败阈值。

健康检查接口应稳定、轻量、可解释。不要让探针接口执行复杂数据库查询或调用多个外部服务，否则健康检查本身会成为系统压力来源。

参数配置决定探针行为

探针常见参数包括 initialDelaySeconds、periodSeconds、timeoutSeconds、failureThreshold、successThreshold。它们共同决定探测频率、超时时间和失败多少次后触发动作。

例如一个服务启动需要 90 秒，如果 livenessProbe 在 10 秒后开始检查，连续失败几次就重启，应用可能永远无法启动成功。此时应使用 startupProbe 覆盖启动阶段，而不是简单把 liveness 的 initialDelaySeconds 设置得很大。

参数设置不能只靠经验。建议从应用启动耗时、依赖初始化、发布预热、GC 暂停、网络波动和高峰延迟中取合理范围。核心服务可以更谨慎，避免探针误杀；边缘服务可以适当加快故障摘除。

readiness不要等同于liveness

一个常见错误是 readinessProbe 和 livenessProbe 使用完全相同接口。这样外部依赖短暂异常时，readiness 失败本来只需要临时摘流，liveness 失败却会触发容器重启。如果多个副本同时因为同一依赖失败而重启，故障会被放大。

readiness 可以包含更贴近服务可用性的判断，例如核心依赖连接、配置加载、缓存预热状态；liveness 应更关注应用进程是否仍能自我恢复。二者职责不同，配置也应不同。

对于依赖数据库、消息队列或外部接口的应用，建议把依赖异常优先表达为不就绪，而不是不存活。只有应用内部状态损坏、线程池完全卡死、主循环无法恢复时，才适合作为 liveness 失败条件。

探针与滚动发布如何配合

滚动发布依赖 readiness 判断新 Pod 是否可以接流量。如果 readiness 过早成功，流量会进入尚未预热的实例，导致发布初期错误率升高；如果 readiness 过晚成功，发布速度会变慢，甚至因为超时被判断失败。

发布策略还要结合 minReadySeconds、maxUnavailable、maxSurge 和 PodDisruptionBudget。探针只是健康信号，发布控制器还需要用这些参数决定替换节奏。对于启动慢或预热明显的服务，应把 readiness 和发布窗口一起设计。

生产验证时，不要只看 Pod 最终是否 Running，而要看从创建到 Ready 的耗时、探针失败次数、发布期间错误率和流量切换是否平滑。

常见问题

livenessProbe失败一定会重启容器吗？

是的，达到失败阈值后会触发容器重启。因此 livenessProbe 应谨慎配置，只用于判断容器是否处于无法自恢复状态。短暂依赖异常、流量高峰或下游超时不一定适合作为 liveness 失败条件。

readinessProbe失败会影响什么？

readinessProbe失败后，Pod 会从 Service 可用后端中移除，不再接收普通服务流量，但容器不会因此自动重启。它适合表达应用暂时不能服务的状态，例如预热中、依赖不可用或内部限流。

startupProbe和initialDelaySeconds有什么区别？

initialDelaySeconds 只是延迟某个探针开始执行，startupProbe 则专门保护启动阶段。配置 startupProbe 后，启动成功前 liveness 和 readiness 不会按正常逻辑造成误判。对启动慢的应用，startupProbe 通常比把 liveness 延迟写得很大更清晰。

探针接口要不要检查数据库？

要看探针类型。readiness 可以检查核心依赖是否可用，但应轻量且有超时控制。liveness 通常不建议直接依赖数据库状态，否则数据库短暂抖动会导致应用重启。更好的做法是区分浅层存活和深层就绪。

结语

Kubernetes探针配置的关键，是让启动、就绪和存活三类信号各司其职。startupProbe 保护慢启动，readinessProbe 控制是否接流量，livenessProbe 处理不可恢复状态。探针设计越清晰，发布、扩缩容和故障恢复就越稳定。