Kubernetes健康检查探针配置与生产实践

1. Kubernetes健康检查探针的本质解析

在容器化应用的管理中，单纯判断Pod是否运行远远不够。去年我们线上就发生过一个典型案例：某个微服务Pod虽然处于Running状态，但实际上已经无法处理请求，导致流量持续分配到故障节点。这正是Kubernetes设计健康检查机制的初衷——它通过三种探针（Probe）来全方位监控应用健康状态：

• 存活探针（Liveness Probe）：相当于应用的"心跳检测"，当检测失败时kubelet会重启容器。比如你的Java应用发生OOM后线程死锁，虽然进程还在但已丧失服务能力，这时存活探针就能触发恢复机制。

• 就绪探针（Readiness Probe）：像机场的登机口安检，只有通过检查的Pod才会被加入Service的Endpoint列表。当你的MySQL容器需要30秒完成启动和初始化时，就绪探针可以避免流量过早打入。

• 启动探针（Startup Probe）：这是Kubernetes 1.16引入的新机制，专门解决慢启动应用的痛点。像传统Spring Boot应用启动可能需要2分钟，如果直接用存活探针检测，可能在启动过程中就被误杀。

2. 探针配置的魔鬼细节

2.1 三种检测方式的选择策略

yaml复制livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: X-Custom-Header
      value: Awesome
  initialDelaySeconds: 15 
  periodSeconds: 20

• HTTP GET：最适合Web服务，比如检测/health接口返回200。我们团队曾踩过坑——直接使用根路径/做检测，当主页加载慢时导致频繁重启。后来专门设计了轻量的/healthz接口，只做基础依赖检查。

• TCP Socket：适用于非HTTP协议的服务，如Redis、MySQL。但要注意，端口可连接不代表服务就绪。我们补充了mysqladmin ping的exec检测确保数据库真正可用。

• Exec：最灵活也最危险，比如执行`pg_isready -d