Flask健康检查必须返回200且仅做内存级检查，/health和/ready应分离：前者验证进程存活，后者检查DB、Redis等依赖；路由需显式注册并避免异常、日志、外部调用。
因为默认的健康检查方式会让Kubernetes误判服务状态，轻则流量被切走，重则触发无限重启循环。
Flask健康接口返回非200或无响应就等于“不可用”
Kubernetes的readinessProbe和livenessProbe只认HTTP状态码：不是200，就认为服务挂了。常见错误包括：
- 路由没注册，比如写了
@app.route('/health')但忘了实际启动时加载该模块 - 函数体里漏了
return 'OK', 200，只写了return 'OK'——这会默认返回200吗？不会，Flask会返回200仅当显式指定或使用Response对象；否则可能因上下文缺失返回500 - 接口抛了未捕获异常（如配置项缺失、环境变量没设），直接500
- 用了
jsonify()但没配Content-Type: application/json，某些旧版Ingress或探针校验严格时会拒绝
在/health里查数据库或Redis = 自己给自己埋雷
健康检查必须是内存级、毫秒级完成的。一旦掺入外部依赖：
- DB连接池还没初始化完，
db.engine.execute("SELECT 1")就timeout，返回503 - Redis临时抖动，整个
/health变慢甚至失败，Kubernetes立刻摘流量 - 调用下游HTTP服务，对方延迟高或DNS解析卡住，探针超时（默认1秒），连续失败三次后重启Pod
- 日志刷盘、缓存预热等副作用操作塞进健康接口，导致首次请求巨慢，
initialDelaySeconds设小了就会被杀
livenessProbe和readinessProbe共用一个路径是最大陷阱
这两个探针语义完全不同，混用路径会导致“假活”或“假死”：
立即学习“Python免费学习笔记（深入）”；
-
livenessProbe失败 → 杀容器重来，它该检查“进程是否还在呼吸”，比如/healthz只返回{"status": "ok"} -
readinessProbe失败 → 摘流量但不杀进程，它该检查“能不能干活”，比如/readyz要确认model.is_loaded、redis_client.ping()、db.engine.connect() - 如果都指向
/health，而你的模型加载要45秒，readinessProbe在第10秒就开始报错，流量进不来；同时livenessProbe也报错，Pod反复重启，永远加载不完 - 更糟的是，有些团队把
failureThreshold设成10，一次GC停顿或网络抖动就永久失联
监听127.0.0.1或端口不匹配会让探针根本打不到
Kubelet从宿主机网络命名空间发起HTTP请求，不是从容器内部curl：
- Flask默认
app.run(host='127.0.0.1')→ 只接受本地回环，探针连不上，始终Connection refused - 应用监听8080，但Deployment里
containerPort写成8000，或者httpGet.port写错，探针发到空端口 - 用Gunicorn跑Flask，worker卡死或没preload，健康请求排队等待，超时返回失败
- 非root用户尝试绑定
port: 80，启动失败，Pod卡在CrashLoopBackOff，根本没机会暴露健康端点
真正难的不是写一个/health路由，而是让这个接口在冷启动、高负载、依赖故障等各种边界条件下，依然稳定返回200——这需要明确区分语义、隔离依赖、校准参数，并在Pod内手动验证过curl -v http://localhost:8080/healthz才行。
