一句话定义：存活探针（Liveness Probe）和就绪探针（Readiness Probe）是 Kubernetes 定期对容器发起的健康检查——前者决定「要不要把你重启」，后者决定「要不要把流量给你」。
打个比方。把 Pod 想成餐厅后厨的一位厨师。存活探针是老板隔几分钟推门看一眼：这人还醒着吗？喊不醒，直接换人——也就是重启容器。就绪探针是门口的服务员看后厨备好没有：灶没热、菜没切，就先别放客人进来，但厨师本人不用被换掉。
两种探针的检查手段一样，都可以是：发一个 HTTP GET、建一个 TCP 连接，或在容器里执行一条命令。区别只在失败之后发生什么：
| 维度 | 存活探针 Liveness | 就绪探针 Readiness |
|---|---|---|
| 回答的问题 | 进程还活着吗 | 现在能接流量吗 |
| 失败后果 | 容器被重启，重启计数 +1 | 从 Service 的可用端点中摘除 |
| 进程受影响吗 | 会被杀掉重来 | 不受影响，继续运行 |
| 典型检查内容 | 主循环是否卡死、是否死锁 | 依赖的下游是否可用、模型是否加载完 |
| 常见误用 | 把下游依赖写进去，导致级联重启 | 一直不通过，导致服务永远不上线 |
所以「K8s 反复重启我的 Pod」这件事，几乎总是存活探针在背锅。最常见的原因是探针太急：应用冷启动要 60 秒，探针第 10 秒就开始判定，连失败几次就重启，重启后又重来一遍，形成崩溃循环（CrashLoopBackOff）。另一个隐形杀手是把「依赖检查」塞进存活探针——数据库抖一下，所有 Pod 一起判定自己「不健康」，一起重启，本来只是慢，现在彻底挂了。
需要区分的是启动探针（Startup Probe）：它专门给慢启动应用用，在它成功之前，存活和就绪探针都不生效。这对加载大模型的推理服务尤其重要。
对从业者的实际意义：探针写得好不好，直接决定故障是「抖动一下自愈」还是「雪崩式重启」。几条实用原则——就绪探针负责表达「我现在能不能干活」，可以包含依赖状态；存活探针只表达「我还没死透」，尽量只检查自身进程，别碰外部依赖。模型推理服务加载权重慢、显存预热慢，用启动探针兜住，不要靠把 initialDelaySeconds 调大硬扛，那是猜出来的数字。
最后提醒：健康检查是 K8s 的自动自愈机制，和监控告警不是一回事——探针负责动手，监控负责喊人。具体字段与默认值以 Kubernetes 官方文档为准。