Kubernetes 健康检查与探针（Probes）详解
K8s 三种探针详解：liveness（要不要重启）、readiness（能不能接流量）、startup（启动完没有）；HTTP/TCP/exec/gRPC 四种实现方式、参数调优与避坑指南。
K8s 探针（Probe）是 kubelet 对容器做的定期健康检查，检查结果直接驱动 K8s 的自动化动作：重启容器、摘除流量、推迟判定。可以把探针理解为 K8s 集群的"反射神经"——不等人工介入，先把显而易见的故障处理掉。
三种探针的分工
1. Liveness Probe：这个容器还值得留着吗？
失败后果：重启容器。用来捕捉"进程还在但已经死了"的状态——死锁、内部崩溃、假死。
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 3
铁律：liveness 里不要检查外部依赖（数据库、下游 API）。依赖挂了重启你的容器毫无用处，只会引发滚动重启雪崩——数据库故障 → 所有 Pod liveness 失败 → 全部重启 → 恢复更慢。
2. Readiness Probe：这个实例能接流量吗？
失败后果：从 Service 的 Endpoints 里摘除（不重启），恢复后自动加回。这里才该检查依赖：数据库连接池、缓存、必需配置是否加载完成。
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 2
典型用途：应用启动时需要预热（加载缓存、建立连接池），就绪前不接流量；依赖故障时优雅摘除而不是返回 500。
3. Startup Probe：慢启动应用的救星
老应用（如大型 Java 服务）启动可能要几分钟。liveness 的 initialDelaySeconds 给太短会误杀启动中的容器，给太长又降低故障响应速度。startup probe 解决这个两难：启动完成前，liveness 和 readiness 都被抑制。
startupProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 10
failureThreshold: 30 # 最多等 10s×30 = 5 分钟启动
四种探测方式
| 方式 | 配置 | 适用 |
|---|---|---|
| HTTP GET | httpGet: {path, port} |
最常用，200-399 视为成功 |
| TCP | tcpSocket: {port} |
非 HTTP 服务（数据库、MQ），能建连即健康 |
| exec | exec: {command: [...]} |
容器内执行命令，退出码 0 为健康，最灵活但有进程开销 |
| gRPC | grpc: {port, service} |
gRPC 服务的原生健康检查协议 |
关键参数怎么调
initialDelaySeconds：容器启动后多久开始探测（有 startup probe 就不用它硬扛了）；periodSeconds：探测间隔。liveness 建议 10-30s，readiness 可以更密（5-10s）；timeoutSeconds：单次探测超时，默认 1s 常常太短，高负载服务建议 3-5s；failureThreshold：连续失败几次才动作——防瞬时针刺误杀的关键，建议 ≥2；successThreshold：失败后连续成功几次算恢复（readiness 有意义）。
平衡示例：
livenessProbe:
httpGet: {path: /healthz, port: 8080}
periodSeconds: 15
timeoutSeconds: 3
failureThreshold: 3 # 连续 3 次失败才重启，容忍抖动
看懂 CrashLoopBackOff
Pod 状态出现 CrashLoopBackOff = 容器反复崩溃、K8s 按退避策略反复重启。常见根因：应用启动即 panic（配置缺失、依赖连不上）、liveness 配得太激进误杀、资源 limits 太小被 OOMKill。排查三板斧：
kubectl describe pod <pod> # 看事件：探针失败还是 OOM？
kubectl logs <pod> --previous # 看上一个实例的临终日志
kubectl get events --sort-by=.lastTimestamp
观测云对照
探针是 K8s 的自愈机制，但"自愈了多少次"本身是要监控的——频繁重启的 Pod 是应用问题的信号。观测云容器监控采集 Pod 重启次数、探针失败事件、OOMKill 记录，对"某 Deployment 重启率突增"设告警；配合 APM 看应用在重启前后的错误分布，探针策略是否合理（误杀还是太松）用数据回答。
常见问题（FAQ）
Q：liveness 和 readiness 能用同一个端点吗？
A：小服务可以，但语义不同最好别——liveness 端点要极简（只查进程自身），readiness 端点可以重（查依赖）。共用一个端点容易把依赖检查带进 liveness，埋下雪崩隐患。
Q：exec 探针有什么坑？
A：它在容器里 fork 进程，高频率下是实打实的开销；命令hang住也会占用 timeout 全程。能用 HTTP/TCP 就不用 exec。
Q：探针失败会记录在哪里？
A：kubectl describe pod 的 Events 里；K8s 事件默认只保留 1 小时，要长期分析需要把事件采集到观测云这类平台。
