HTTP心跳探针不支持自定义状态码判定，但可通过服务端响应逻辑配合Kubernetes默认规则（200–399成功）实现等效语义；需区分/liveness与/ready路径、合理配置initialDelaySeconds、timeoutSeconds等参数。
HTTP心跳探针本身不支持“自定义状态码”作为成功判定标准，但可以通过设计服务端响应逻辑，配合Kubernetes默认的判定规则（200–399视为成功）实现等效的自定义健康语义。
HTTP探针的成功判定规则是固定的
Kubernetes的httpGet探针只认HTTP状态码范围：≥200 且 ＜400 的响应即为成功；其余（包括400、404、500、甚至自定义如299、301等）一律视为失败。你不能修改这个判断逻辑，也不能配置“只认201”或“忽略3xx”之类规则。
让服务端返回符合要求的自定义健康状态
真正可控的是你的应用暴露的健康接口行为。例如：
- 把
/healthz改成/health?mode=strict，后端根据参数动态决定检查深度，并在一切就绪时返回200 OK，否则返回503 Service Unavailable - 用
/live只做进程存活检查（轻量），返回200；用/ready做依赖检查（连DB、Redis），全部通过才返回200，否则返回503 - 返回
200的同时，在响应体中写入{"status":"degraded","reason":"cache_warmup_in_progress"}——虽然kubelet不读响应体，但运维和监控系统可以采集它
关键配置参数要匹配业务实际
避免因超时或频率不当导致误判：
-
initialDelaySeconds：必须大于应用冷启动耗时（比如Spring Boot可能需15–30秒），否则探针一上来就失败，反复重启 -
timeoutSeconds：设为略大于健康接口P95响应时间（建议2–5秒），防止网络抖动或瞬时慢请求被当故障 -
failureThreshold：对关键服务建议设为3–5，避免单次抖动触发重启；对高可用服务可适当提高 -
periodSeconds：生产环境通常设为10–30秒；太密增加kubelet压力，太疏延迟发现故障
不要混淆Liveness和Readiness的用途
同一个HTTP路径不能同时承担两种语义：
- Liveness探针应只检查“进程是否卡死”，比如
GET /live只返回200，不做DB连通性检查 - Readiness探针应检查“能否收流量”，比如
GET /ready必须验证所有依赖就绪，未满足则返回503 - 两者共用一个路径+相同逻辑，容易造成“服务没准备好就被重启”或“已崩溃却还在接流量”
