flask健康检查失败主因是服务未正确响应/healthz：需显式返回200状态码、监听0.0.0.0而非127.0.0.1、避免外部依赖和挂载文件读取，并合理配置探针参数与gunicorn启动选项。
健康检查失败不是探针配置问题，而是Flask服务本身没响应——先确认/healthz路径是否真能返回200。
Flask路由没注册或返回值不对
很多Flask应用写了@app.route('/healthz')，但函数里漏了return 'OK', 200，或者用了jsonify()却没设Content-Type，Kubernetes探针只认HTTP状态码200 + 可读响应体。
- 必须显式返回状态码：
return 'OK', 200或return jsonify({'status': 'ok'}), 200 - 避免在健康接口里调用
db.session.execute()、requests.get()等外部依赖，它们可能超时或抛异常 - 用
kubectl exec -it <pod-name> -- curl -v http://localhost:8000/healthz</pod-name>在Pod内直连验证，排除网络层干扰
Flask监听地址和端口不匹配
Flask默认只监听127.0.0.1:5000，而Kubernetes探针是从宿主机网络空间发起请求，127.0.0.1根本收不到。
- 启动时必须指定
host="0.0.0.0"：app.run(host="0.0.0.0", port=8000) - 确认容器
containerPort和Flask实际监听端口一致（比如代码写port=8000，YAML里就得写containerPort: 8000） - 在Pod里执行
netstat -tuln | grep :8000，输出应含*:8000，不是127.0.0.1:8000
探针参数与Python启动慢不匹配
带SQLAlchemy初始化的Flask应用常需10–20秒才真正就绪，但initialDelaySeconds: 10会让探针在应用还没listen时就开始打，直接失败。
-
initialDelaySeconds至少设为30，给ORM、缓存连接、模型加载留足时间 -
timeoutSeconds别设太大（如30），否则一次卡顿拖慢整个探针周期；2秒足够 -
failureThreshold设为3，避免GC停顿或DNS抖动导致误杀
Gunicorn worker卡死导致健康请求排队
用Gunicorn部署时，如果所有worker都在处理长请求，健康检查请求会被堵在队列里，直到超时。
- 加
--preload参数，让应用逻辑在worker fork前就加载完毕，减少启动延迟 - 调大
--timeout（比如30），防止worker因慢查询被kill后无法响应探针 - 检查
accesslog或errorlog里是否有Worker timeout记录
最常被忽略的是：健康端点逻辑里偷偷读了ConfigMap挂载的文件，而该文件在Pod启动时尚未就绪——这种“看似简单”的IO操作，会直接让/healthz返回500。务必只做内存级判断。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
