探针的四种执行方式
探针只描述「怎么判断」，方式由执行器决定：httpGet 向容器端口发 HTTP 请求，健康语义最清晰；exec 在容器内执行命令，灵活但每次探测都要起进程；tcpSocket 只尝试建立 TCP 连接，最轻但只能证明端口在听；gRPC 面向实现了标准健康检查服务的 gRPC 应用。同一个探针可以配给 liveness、readiness、startup 三种用途，选错方式会出现「明明重启了还是不通」或「探不出假死」。
四种方式对比
| 方式 | 判定成功的条件 | 代价与盲区 |
|---|---|---|
| httpGet | 返回码 200-399 | 需要应用提供 HTTP 端点；重定向需留意 |
| exec | 命令退出码为 0 | 每次探测都起进程，高频探测会与业务抢 CPU |
| tcpSocket | TCP 三次握手成功 | 端口在听即通过，进程假死同样能过 |
| gRPC | 健康检查服务返回 SERVING | 需要应用实现标准健康服务，1.27 起为稳定特性 |
典型使用场景
- Web 服务：httpGet 指向 /healthz，能同时验证路由与依赖是否就绪
- 后台工作进程：没有监听端口，用 exec 检查进程存活或本地状态文件
- 数据库与中间件：tcpSocket 检查端口就绪，避免在启动阶段被误杀
- gRPC 微服务：用 grpc 探针指向标准健康服务，避免为探针额外开 HTTP 端口
- 慢启动应用：把耗时启动检查交给 startupProbe，让 liveness 在启动完成前不介入
三种基础写法
三种基础写法
livenessProbe:
httpGet: {path: /healthz, port: 8080} # 200-399 视为成功
readinessProbe:
exec:
command: ['/bin/sh', '-c', 'test -f /tmp/ready'] # 退出码 0 为成功
startupProbe:
tcpSocket: {port: 5432} # 端口可连接即成功
failureThreshold: 30 # 慢启动应用放宽失败次数gRPC 探针
gRPC 探针
startupProbe:
grpc: {port: 50051, service: health.Health} # 应用需实现标准健康检查服务
periodSeconds: 5
failureThreshold: 20
# Kubernetes 1.27 起 gRPC 探针为稳定特性，更早版本属于 beta参数组合与核对
参数组合与核对
kubectl get pod web-x -o jsonpath='{.spec.containers[0].livenessProbe}' # 看实际生效的探针
kubectl describe pod web-x | sed -n '/Liveness:/,/Environment:/p' # 事件里会记录探测失败原文
kubectl logs web-x --previous | tail -20 # 被探针杀掉的上一次容器日志关键参数读法
| 参数 | 含义 | 设置建议 |
|---|---|---|
| initialDelaySeconds | 容器启动后多久开始探测 | 有 startupProbe 时可设小甚至不设 |
| periodSeconds | 探测间隔 | 过密会增加开销与抖动 |
| timeoutSeconds | 单次探测超时 | 应小于 periodSeconds |
| failureThreshold | 连续失败几次判定失败 | 与重启策略配合，避免瞬时抖动触发重启 |
| successThreshold | 连续成功几次判定恢复 | readiness 可大于 1，liveness 固定为 1 |
HTTP 探针把 200 到 399 都视为成功，因此把探针打到需要鉴权的接口上会得到 401/403 而被判失败；探针路径应专门设计，不要复用业务接口，也不要让它承担依赖检查的全部职责，否则下游抖动会连锁引发整批 Pod 重启。
exec 探针在容器内执行命令，distroless 等没有 shell 的镜像需要直接调用二进制；gRPC 探针需要应用实现标准健康检查服务，未实现时会一直失败，Kubernetes 1.27 起该方式为稳定特性，更早版本属于 beta。