Kubernetes探针如何区分启动、就绪与存活检查

☸️ Kubernetes探针：区分启动、就绪和存活检查

Kubernetes探针不仅报告状态，还会影响工作负载控制行为。启动探针用于保护初始化过程；就绪探针决定Pod是否参与服务流量；存活探针失败可能使容器重启。若把所有情况都映射到同一个探针，平台可能在应用正常初始化时重启它，或把无法处理请求的实例继续放进服务端点。🚦

一、启动探针处理慢启动和初始化

应用启动耗时可能受到缓存预热、数据加载、密钥获取或JIT编译影响。启动探针为初始化提供一个明确窗口；在它成功之前，存活和就绪探针不会执行。窗口可由探测间隔、超时和失败阈值共同形成，应该覆盖正常慢启动的高分位耗时，并考虑冷启动和资源紧张时的差异。

启动探针过短会把合法初始化当成故障；过长则会推迟发现真正卡死的时间。应从启动日志中的阶段时间和实际启动耗时分布推导窗口，并在低资源条件下验证。启动探针只保护启动阶段，并不意味着初始化逻辑可以无限等待外部依赖。📦

二、就绪探针决定Pod能否接收请求

就绪失败通常让Pod暂时不参与Service流量，但容器继续运行。探针应验证应用是否完成必要初始化、是否能够处理目标请求类型，以及关键本地资源是否可用。若服务具备降级能力，某个非关键依赖不可用时不一定应判为未就绪；若所有请求都必须依赖它，则应明确地从流量路径中摘除实例。

就绪端点应轻量且与服务真实行为一致。只检查端口监听会产生“探针绿、请求失败”的情况；每次都查询多个外部依赖则可能让依赖抖动造成全体实例同时未就绪。检查依赖的深度要与业务容错方式相符，并通过请求错误率验证探针的判断是否有效。🔌

三、存活探针只识别需要重启的状态

存活探针用于发现无法自行恢复的进程状态，例如关键事件循环停滞或内部工作线程永久卡死。探针失败可导致容器重启，因此不应把所有外部依赖不可用都作为存活失败条件。否则，一个数据库故障就可能引发大量Pod重启，重建连接并进一步加重依赖压力。

参数periodSeconds控制探测间隔，timeoutSeconds限制单次响应时间，failureThreshold决定连续失败多少次才采取动作。失败阈值和间隔共同决定检测延迟；设置过紧会把瞬时负载尖峰或调度抖动误判为卡死，过宽则延长故障恢复时间。应结合事件循环延迟、重启次数和应用响应能力校准。💓

四、探针失败的诊断顺序

先看Pod事件和探针最近失败记录，确认失败类型是超时、连接拒绝、状态码错误还是命令不存在；再对照容器重启次数、日志中的初始化阶段、CPU节流、内存压力和依赖错误。若只有启动期间失败，检查启动窗口；若Pod未重启但不在服务端点中，检查就绪状态；若连续重启，检查存活探针和容器退出原因。

也要核对探针执行环境与端口配置。HTTP探测可能使用错误端口或路径；命令探测可能缺少执行文件；TLS和主机名假设也可能与应用监听方式不同。单看Pod最终状态无法解释探针为何失败，事件时间线通常更有诊断价值。📊

五、分别验证三种动作

1. 在隔离环境制造较慢但正常的初始化，确认启动探针在允许窗口内通过，期间容器没有被存活探针提前重启。
2. 让实例完成启动后暂时失去处理请求的能力，确认就绪失败会停止接收新流量，但不会因此反复重启。
3. 模拟进程内部不可自愈的卡死，确认存活探针在预期时间内触发重启，且恢复后Pod重新就绪。
4. 短暂断开外部依赖，观察探针是否符合服务降级策略，并确认不会引起重启风暴。
5. 对照事件、端点流量、错误率和重启次数，记录实际检测与恢复时间。

容易误判：探针失败不是修复动作。它只会触发平台规定的流量或重启行为；如果应用没有恢复能力，重启也可能重复相同故障。🛡️