LivenessProbe 的核心目标是让 Kubernetes 在容器“假活”时主动重启它，需根据场景选择 HTTP GET、Exec 或 TCP Socket 探测方式，并合理设置 initialDelaySeconds、periodSeconds、timeoutSeconds 和 failureThreshold 参数，健康接口应仅检查本地状态、避免外部依赖和耗时操作。
LivenessProbe 的核心目标是让 Kubernetes 在容器“假活”时主动重启它——比如进程还在，但应用已卡死、死锁或内存泄漏无法响应。配置的关键不在于写得多，而在于选对方式、设对参数、避开常见陷阱。
选对探测方式
Kubernetes 支持三种探测机制，按场景选择：
-
HTTP GET：适用于 Web 服务，最常用。需应用暴露轻量健康端点（如
/health），返回 2xx/3xx 即视为成功。 -
Exec 命令：适合无网络服务或需判断内部状态的场景，例如检查临时文件是否存在、验证关键进程是否运行：
pgrep myapp || exit 1。 -
TCP Socket：仅验证端口是否可连通，不校验业务逻辑，适合数据库、消息队列等非 HTTP 服务（如检查
port: 5432）。
必须合理设置基础参数
每个探针都依赖几个关键字段，缺一不可：
-
initialDelaySeconds：容器启动后延迟多久开始探测。Java 应用建议 ≥30 秒；Go/Node.js 可设为 5–10 秒。 -
periodSeconds：探测间隔，默认 10 秒。高敏感服务可缩至 5 秒，稳定服务可放宽至 30 秒。 -
timeoutSeconds：单次探测超时时间，默认仅 1 秒，容易误判，建议设为 2–5 秒。 -
failureThreshold：连续失败多少次才触发重启。默认 3 次，网络波动多的环境可设为 5，避免误杀。
健康接口设计要克制
存活探针只回答一个问题：“应用还能跑吗？”
- ✅ 允许检查本地状态（如内存占用、goroutine 数量、主线程是否阻塞）
- ❌ 禁止调用外部依赖（如数据库、Redis、下游 HTTP 服务），否则依赖抖动会引发连锁重启
- ❌ 避免耗时操作（如加载大模型、扫描磁盘），否则探针本身成为性能瓶颈
一个实用的 HTTP 方式示例
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
livenessProbe:
httpGet:
path: /health
port: 8080
httpHeaders:
- name: User-Agent
value: kube-probe
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3不复杂但容易忽略
