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

不复杂但容易忽略