存活探针配置不当会导致容器频繁重启

存活探针（livenessProbe）是Kubernetes内置的容器健康检查机制，它直接决定容器何时被强制重启。存活探针的配置失误是生产环境中容器频繁重启的首因，据云原生计算基金会（CNCF）发布的《Kubernetes 生产环境应用现状报告》显示：超过70%的Kubernetes平台团队曾因探针配置问题导致线上服务异常。存活探针的核心价值在于自动恢复死锁或内存泄漏等不可恢复故障，但错误的阈值设置和探测逻辑反而会让健康容器被反复杀掉。

存活探针与就绪探针的分工差异

存活探针和就绪探针（readinessProbe）都用于容器健康检查，但它们解决的问题完全不同。存活探针回答的是"这个容器还活着吗"，如果探测失败Kubelet会杀掉容器并按照restartPolicy重启；就绪探针回答的是"这个容器可以接收流量吗"，探测失败时Pod会被摘除出Service后端但容器不会重启。

一个典型的判断准则是：如果应用能处理请求但暂时无法响应，用就绪探针；如果应用已经进入死循环或死锁状态且无法恢复，用存活探针。混用这两类探针是常见的配置错误，例如有人用存活探针检查依赖数据库是否可达，数据库抖动时探针失败导致整个容器重启，而重启并不能解决数据库问题，反而加剧了故障。

livenessProbe核心字段配置要点

存活探针的配置集中在initialDelaySeconds、periodSeconds、timeoutSeconds、failureThreshold和successThreshold五个字段上，其中initialDelaySeconds是导致误杀最多的参数。initialDelaySeconds表示容器启动后多久开始第一次探测，如果设置过短，应用还在加载依赖或预热的阶段就被判定死掉，然后无限重启。

推荐的初始延迟设置方式是：先观察应用在真实环境下的启动耗时，然后加上20%-30%的安全余量。例如应用平均需要25秒完成初始化，initialDelaySeconds可以设为30-35秒。periodSeconds表示探测频率，默认是10秒，对于非关键业务可放宽到15-20秒以降低探针带来的额外负载。timeoutSeconds是单次探测的超时时间，默认1秒但很多HTTP服务在瞬时高负载下响应会超过1秒，建议设置为3-5秒。

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: liveness-probe
  initialDelaySeconds: 30
  periodSeconds: 15
  timeoutSeconds: 5
  failureThreshold: 3
  successThreshold: 1

failureThreshold是连续失败多少次后才重启容器，默认值为3。如果设置成1，一次网络抖动或瞬时慢请求就会杀掉容器，在生产环境中非常危险。建议至少为3，在对稳定性要求极高的核心链路可以设置为4-5，给短暂波动留出缓冲空间。

存活探针探测方式选择

Kubernetes提供三种存活探针探测方式：HTTP请求、TCP连接和Exec命令，选择错误会直接导致探针失效。HTTP探针适合提供HTTP服务的应用，通过访问特定路径获取状态码判断健康程度；TCP探针只验证端口能否连接，适合四层协议服务如Redis或MySQL；Exec探针在容器内执行命令并通过退出码判断，适合无法暴露端口的批处理或临时任务。

多数Spring Boot项目天然提供/actuator/health端点用于探针，但直接使用这个端点作为存活探针的检测路径存在隐患。Actuator的health端点默认包含磁盘空间、数据库连接等组件健康状态，当数据库连接池暂时耗尽时health返回DOWN，存活探针判定失败并重启容器，重启后数据库连接池依然面临同样问题。

业界推荐的做法是拆分探针端点：存活探针使用一个不依赖外部组件的轻量级自定义端点，只检查JVM本身的存活状态；就绪探针才使用完整health端点来评估是否具备对外服务能力。Netflix的工程师在《Kubernetes探针设计模式》一文中的实践总结是：存活探针检测的应该是"进程是否陷入不可恢复状态"，而不是"当前业务组件是否全部就绪"。

exec探针的退出码陷阱

Exec类型的存活探针通过命令退出码判定健康状态，退出码为0表示健康，非0表示不健康，但Shell管道和脚本判断很容易产生误报告。一个常见错误是使用grep加管道查询进程信息，例如探测命令为pgrep -f myapp，当进程不存在时grep返回1，探针判定失败，但某些Shell实现中信号干扰也会导致非正常退出码。

livenessProbe:
  exec:
    command:
    - /bin/sh
    - -ec
    - |
      if [ -f /tmp/healthy ];
      then
        exit 0
      fi
      exit 1

另一个陷阱是探针命令本身又去访问外部网络或依赖其他进程，导致健康检查引入额外故障点。最佳实践是Exec探针只做本地进程级的轻量检查，比如检查关键线程是否存在，读取本地状态文件，或者是解析内部状态变量缓存内容。生产环境中尽量避免在Exec探针中执行curl、wget这类需要网络栈支持的命令。

误杀健康容器的典型场景

存活探针误杀健康容器的最常见场景是延迟和超时设置与真实负载不匹配。高并发流量到来时，应用线程池被打满，HTTP探测请求排队等待，响应时间拉长至超过timeoutSeconds，探针连续失败触发重启。重启后的冷启动阶段应用无法处理任何请求，流量继续堆积，形成"探测失败→重启→冷启动触发延迟→再次探测失败"的雪崩循环。

针对这个问题，Google云平台（Google Cloud）在《SRE工作手册》中给出的建议是：当应用已处于高负载状态时，应先将请求摘除至其他实例以降低压力，而不是依赖存活探针直接重启。正确做法是将资源压力信号（如线程池饱和度、队列长度）映射到就绪探针，让Kubelet先把异常的Pod从负载均衡池中摘除，同时保留存活探针检测真正的进程级故障。

JVM类型应用的启动阶段存在特殊风险。Java应用在Class加载和JIT编译时期CPU占用极高，如果存活探针在此时发起健康检查请求，请求响应会非常慢甚至超时。美团技术团队在一次内部故障复盘中提到：他们将Java服务的存活探针initialDelaySeconds从25秒调整到60秒后，因启动阶段误杀导致的重启次数下降了一个数量级。

合理配置存活探针的检查规范

生产环境存活探针配置应该遵循一套基线规范来避免常见陷阱。首先必须明确：存活探针只用于检测不可自动恢复的致命故障，任何外部依赖或业务性波动都不应触发容器重启。其次要保证探针接口本身具备异常处理能力，即使内部逻辑出错也应返回200状态码，确保探针只反映进程健康状况。

• initialDelaySeconds必须大于应用最大启动时间，实测数据后再加20%-30%缓冲
• timeoutSeconds不小于应用P99响应时间，一般取3-5秒
• periodSeconds取10-15秒，避免过于频繁的探测增加系统开销
• failureThreshold取3-5次，容忍瞬态网络抖动和GC暂停
• 探针接口必须无锁、无IO阻塞、不依赖外部服务

配置完成后建议通过故障注入验证探针有效性：手动kill容器内主进程验证重启行为，模拟线程死锁验证进程是否能被恢复，压测期间观察探针是否产生误报。只有经过这些验证的探针配置才能在真实故障来临时做到既及时恢复又不误伤健康服务。

正确处理存活探针和内存保护的关系也值得注意。在Linux内核的OOM Killer机制中，系统内存不足时会按照oom_score来优先杀掉内存占用较大的进程，容器重启并不一定是因为探针发现异常。如果容器频繁被Cool退出但探针日志正常，需要检查系统级的dmesg输出，区分是OOM导致的重启还是探针触发的重启，避免排查方向在错误层级上打转。

存活探针是Kubernetes集群自治能力的基石，把探针配置从"能跑就行"提升到"可量化的健康保障"，会直接减少线上故障的恢复时间。真正的问题是探测标准与业务真实状态脱节——探针必须理解应用的生命周期和故障模型，而不仅仅是一个返回200的HTTP端点。在配置任何存活探针之前，先梳理清楚应用有哪些不可自愈的故障模式，设计专门针对这些模式的检测指标，才是探针配置的正确打开方式。