★ FEATURED ARTICLE 1. 为什么需要存活探测机制在Kubernetes集群中Pod是最小的可部署单元。但现实情况是任何运行中的进程都可能因为各种原因进入非健康状态——比如内存泄漏导致进程僵死、线程阻塞造成服务无响应或者更常见的死锁情况。这时候容器本身可能还在运行但已经无法正常提供服务了。传统运维模式下我们通常通过外部监控系统来检测服务状态发现问题后手动重启服务。这种做法的响应延迟往往以分钟计而且需要额外部署监控组件。Kubernetes的Liveness Probe机制则将这个能力内置到了平台层面实现了秒级的问题检测和自动恢复。我曾在生产环境遇到过典型的案例一个Java应用因为GC配置不当导致周期性Full GC每次停顿长达30秒。虽然进程没有崩溃但在此期间所有请求都会超时。通过配置合理的Liveness Probe我们让Kubernetes自动重启了问题实例将故障影响从每次几分钟缩短到了几秒钟。2. Liveness Probe的工作原理2.1 探测机制的类型Kubernetes提供了三种基本的探测方式HTTP GET向容器内指定端口和路径发送HTTP请求根据响应状态码判断2xx/3xx表示健康livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: Custom-Header value: AwesomeTCP Socket尝试与指定端口建立TCP连接能建立连接则认为健康livenessProbe: tcpSocket: port: 8080Exec在容器内执行指定命令返回值为0表示健康livenessProbe: exec: command: - cat - /tmp/healthy2.2 探测过程的时间参数每个探测行为都有一组关键时间参数控制livenessProbe: initialDelaySeconds: 30 # 容器启动后等待多长时间开始第一次探测 periodSeconds: 10 # 每次探测的间隔时间 timeoutSeconds: 5 # 探测请求的超时时间 successThreshold: 1 # 连续几次成功才算真的成功 failureThreshold: 3 # 连续几次失败才会重启容器这些参数的设置需要根据应用特性仔细调整。比如一个需要长时间初始化的应用initialDelaySeconds就应该设置得比应用启动时间长。我曾经见过因为initialDelaySeconds设置过短导致应用还没完成初始化就被不断重启的案例。3. 生产环境配置实践3.1 HTTP探测的最佳实践对于HTTP服务/healthz是最常用的健康检查端点。这个端点应该只做轻量级检查避免数据库查询等耗时操作返回包含依赖服务状态的复合信息设置适当的缓存控制头一个Spring Boot应用的示例实现RestController public class HealthController { GetMapping(/healthz) public ResponseEntityMapString, String healthCheck() { MapString, String status new HashMap(); status.put(status, UP); status.put(timestamp, Instant.now().toString()); return ResponseEntity.ok() .cacheControl(CacheControl.maxAge(Duration.ofSeconds(10))) .body(status); } }对应的Probe配置livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 45 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 23.2 有状态服务的特殊处理对于数据库等有状态服务直接重启可能导致数据不一致。这时可以采用更保守的策略livenessProbe: exec: command: - sh - -c - [[ $(ps aux | grep [m]ysqld) ]] mysqladmin ping -uroot -p$MYSQL_ROOT_PASSWORD initialDelaySeconds: 120 periodSeconds: 30 timeoutSeconds: 10 failureThreshold: 5这个配置检查mysqld进程是否存在检查是否能正常执行ping命令设置了较长的初始延迟和失败阈值使用环境变量而非硬编码密码4. 常见问题与排查技巧4.1 探测导致的频繁重启症状Pod不断重启kubectl describe pod显示Liveness probe failed排查步骤检查容器日志是否有异常kubectl logs pod-name --previous手动执行探测命令验证kubectl exec pod-name -- curl http://localhost:8080/healthz检查资源限制是否过小kubectl describe pod pod-name | grep -A 5 Limits常见原因initialDelaySeconds设置过短健康检查端点响应慢导致超时容器资源不足导致进程卡顿4.2 与Readiness Probe的配合Liveness Probe和Readiness Probe经常被混淆它们的核心区别是特性Liveness ProbeReadiness Probe失败后的动作重启容器从Service摘除典型检查频率较低(10-30s)较高(1-5s)检查内容深度健康检查基本可用性检查生产环境中通常同时配置两者ports: - name: http containerPort: 8080 readinessProbe: httpGet: path: /ready port: http periodSeconds: 5 livenessProbe: httpGet: path: /healthz port: http periodSeconds: 205. 高级场景与优化5.1 渐进式健康检查对于启动时间不固定的应用可以使用动态initialDelaySecondslivenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 3 successThreshold: 2 startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 5这种配置下startupProbe允许应用有最多150秒(30×5)的启动时间一旦startupProbe成功就切换到常规的livenessProbe避免了为所有Pod设置过长的initialDelaySeconds5.2 基于gRPC的健康检查对于gRPC服务可以使用专门的grpc-health-probelivenessProbe: exec: command: - /bin/grpc_health_probe - -addr:50051 - -tls - -tls-ca-cert/etc/ssl/certs/ca.crt initialDelaySeconds: 10 periodSeconds: 5需要预先将grpc_health_probe二进制文件打包到容器镜像中或者使用sidecar模式。6. 监控与告警配置合理的监控可以帮助发现探测机制本身的问题。建议监控以下指标Pod重启次数sum(kube_pod_container_status_restarts_total{namespaceproduction}) by (pod)探测延迟分布histogram_quantile(0.95, sum(rate(kubelet_prober_probe_duration_seconds_bucket{probe_typeliveness}[5m])) by (le))探测失败率sum(rate(kubelet_prober_probe_total{probe_typeliveness, resultfailed}[5m])) / sum(rate(kubelet_prober_probe_total{probe_typeliveness}[5m]))对应的告警规则示例- alert: HighPodRestartRate expr: increase(kube_pod_container_status_restarts_total[1h]) 3 for: 15m labels: severity: warning annotations: summary: Pod {{ $labels.pod }} has restarted {{ $value }} times in the last hour在配置Liveness Probe时一个常被忽视但非常重要的点是考虑应用本身的特性。比如对于批处理作业可能根本不需要Liveness Probe对于有状态服务过于激进的探测配置可能导致数据损坏。每次调整探测参数后都应该在预发布环境充分验证观察至少一个完整的业务周期比如24小时的行为。
阅读完成 · 觉得有帮助？
