4. 健康检查机制：TCP/HTTP/gRPC探针、启动探针、存活探针、就绪探针的设计原则
在弹性伸缩与发布流程中，健康检查是质量门禁的第一道防线。Kubernetes 提供了三种探针（Probe）和三种检查协议，组合使用才能准确判断实例状态，避免误杀或误流。本章从探针类型、协议选择、参数调优三个维度给出设计原则。
4.1 三种探针的职责与协作
| 探针类型 | 检测时机 | 失败后果 | 典型用途 |
|---|---|---|---|
| 启动探针（startupProbe） | 容器启动后，存活/就绪探针之前 | 重启容器（与存活探针相同） | 保护慢启动应用，避免存活探针在初始化期间误杀 |
| 存活探针（livenessProbe） | 容器运行期间持续检测 | 重启容器 | 检测死锁、内存泄漏、进程挂起等不可恢复故障 |
| 就绪探针（readinessProbe） | 容器运行期间持续检测 | 从 Service Endpoint 中移除，不接收新流量 | 检测依赖服务是否就绪、缓存是否预热、负载是否过高 |
设计原则：启动探针优先于存活探针执行。如果定义了启动探针，存活探针会在启动探针成功后才开始工作。对于启动时间超过 30 秒的应用，必须配置启动探针，否则存活探针可能在初始化阶段反复重启容器。
4.2 三种检查协议：TCP、HTTP、gRPC
每种协议适用于不同的应用场景，选择错误会导致误判或性能开销。以下从检测原理、适用场景、关键参数三个维度对比。
| 协议 | 检测原理 | 适用场景 | 关键参数 |
|---|---|---|---|
| TCP Socket | 尝试建立 TCP 连接，成功即视为健康 | 四层负载均衡、非 HTTP 服务（Redis、MySQL、gRPC 纯 TCP） | port、host |
| HTTP GET | 发送 HTTP GET 请求，2xx/3xx 状态码视为健康 | Web 服务、REST API、需要业务逻辑验证的场景 | path、port、httpHeaders、scheme |
| gRPC | 调用预定义的 gRPC Health/Check 服务 | 微服务架构中的 gRPC 服务、需要协议级健康反馈 | service（可选，默认检查整个服务） |
避坑提示：不要对 HTTP 探针使用
/ 根路径，除非你的根路径不依赖任何下游服务。建议为健康检查设计专用端点（如 /healthz），该端点应轻量、无鉴权、不查询数据库，仅验证进程存活和必要依赖的连通性。
4.3 探针参数调优原则
错误的参数配置会导致频繁重启或流量损失。以下参数需要根据应用启动时间、响应延迟、故障恢复时间进行调优。
- initialDelaySeconds：容器启动后等待多久开始第一次探测。对于 Java 应用建议 10-30 秒，对于 Go 应用可设为 2-5 秒。
- periodSeconds：探测间隔。默认 10 秒，对于高吞吐服务可延长至 15-30 秒以减少开销。
- timeoutSeconds：单次探测超时。默认 1 秒，对于慢响应服务可设为 3-5 秒。
- successThreshold：连续成功次数后认为健康。默认 1，对于启动探针建议保持 1。
- failureThreshold：连续失败次数后认为不健康。默认 3，对于网络抖动频繁的环境可设为 5。
推荐配置模板（Java 微服务）：
startupProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 30 # 允许最长 150 秒启动
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 15
timeoutSeconds: 3
failureThreshold: 3
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 24.4 设计原则总结
- 分离职责：启动探针只关心进程是否完成初始化；存活探针只检测不可恢复的故障；就绪探针检测是否具备服务能力。不要用同一个端点承担所有职责。
- 轻量优先：健康检查端点不应包含复杂业务逻辑。避免在探针路径中查询数据库、调用外部 API 或执行耗时计算。
- 协议匹配：gRPC 服务优先使用 gRPC 探针；HTTP 服务使用 HTTP 探针；非 HTTP 服务使用 TCP 探针。不要用 HTTP 探针检测 TCP 服务。
- 容忍抖动：failureThreshold 和 periodSeconds 的乘积应大于应用故障恢复的平均时间，避免因瞬时抖动导致频繁重启。
- 发布期间特殊处理：在滚动更新或蓝绿发布期间，就绪探针的 failureThreshold 可临时降低，以加速对新版本流量的切断。
4.5 常见误区与排查方法
| 误区 | 现象 | 解决方案 |
|---|---|---|
| 存活探针依赖外部数据库 | 数据库抖动导致容器频繁重启 | 存活探针只检测进程本身，数据库依赖放在就绪探针 |
| 所有探针使用同一个端点 | 启动阶段就绪探针失败导致流量无法接入 | 启动探针用 /healthz，就绪探针用 /readyz |
| HTTP 探针未配置 scheme | HTTPS 服务返回 400 导致误判 | 显式设置 scheme: HTTPS |
| gRPC 探针未实现 Health 协议 | 探针始终返回 UNKNOWN | 确保服务实现了 grpc.health.v1.Health 接口 |
快速排查命令：使用
kubectl describe pod <pod-name> 查看 Events 字段，确认探针失败原因。使用 kubectl get events --field-selector involvedObject.name=<pod-name> 过滤探针相关事件。