Python Web应用在Kubernetes中必须暴露语义化HTTP健康端点，livenessProbe和readinessProbe需分离设计、不同逻辑与阈值，否则将导致假活或503事故；tcpSocket探测无效因其仅验证端口可达，不校验业务就绪；慢启动须配startupProbe，且探针端口须与containerPort一致。
直接说结论：Python Web应用在Kubernetes里不能只靠端口通断判断健康，必须暴露语义化HTTP健康端点，并为livenessProbe和readinessProbe设置不同逻辑、不同延迟、不同失败阈值——否则你会遇到“服务明明卡死却没人重启”或“流量刚进来就503”的生产事故。
为什么tcpSocket探测对Python Web服务基本无效
很多团队图省事，在Deployment里写tcpSocket: { port: 8000 }，以为端口能连上就代表FastAPI/Uvicorn活得好好的。但现实是：
- Uvicorn主进程启动后立刻监听端口，此时模型加载、数据库连接池初始化、缓存预热等后台任务可能还在阻塞中；
- 用户发请求，Web服务器收得到，但内部调用
model.generate()卡住10秒以上，最终超时返回504； -
tcpSocket全程成功，livenessProbe永不触发，Pod持续“假活”，错误请求不断涌入。
根本原因：TCP探针只验证网络层可达性，不验证应用业务层是否真正可服务。Python Web服务（尤其含LLM、大文件处理、外部依赖的）必须走httpGet方式，且端点要返回真实运行态信号。
livenessProbe和readinessProbe必须分离设计
这两个探针不是复制粘贴改个路径就行，它们职责不同、触发后果不同、容忍度也不同：
立即学习“Python免费学习笔记（深入）”；
-
livenessProbe是“急救按钮”：失败=容器已不可恢复，必须杀掉重来。它应检查最轻量、最稳定的内部状态，比如/healthz只返回{"status": "ok"}，不查DB、不调下游、不碰GPU显存； -
readinessProbe是“上岗许可”：失败=暂时不让流量进来，但别动我进程。它必须覆盖启动关键依赖，比如/readyz需确认model.is_loaded == True、redis.ping() == True、db.engine.connect()成功； - 常见错误：两个探针共用同一个
/health端点，导致模型加载慢时readinessProbe失败，livenessProbe也跟着失败，结果还没等加载完就被反复重启。
示例配置片段（FastAPI + Uvicorn）：
livenessProbe:
httpGet:
path: /healthz
port: 8000
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /readyz
port: 8000
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 6Python端点实现要注意三个硬约束
探针端点不是随便写个@app.get("/health")就行，必须满足Kubernetes调度器和kubelet的底层行为逻辑：
- 响应必须快：
livenessProbe默认超时1秒，若你的/healthz里做了time.sleep(2)或同步DB查询，会直接被判定失败； - 禁止副作用：探针是只读检查，不能在
/healthz里触发模型卸载、清理缓存、写日志文件等操作，否则可能引发竞态； - 区分环境：开发环境可返回详细信息（如内存使用率），但生产环境
livenessProbe端点应只返回200/503，避免暴露内部结构； - 推荐写法（FastAPI）：
@app.get("/healthz", status_code=200)
def healthz():
return {"status": "ok"}
<p>@app.get("/readyz", status_code=200)
def readyz():
if not model_ready_flag:
raise HTTPException(status_code=503, detail="model not loaded")
if not redis_client.ping():
raise HTTPException(status_code=503, detail="redis unreachable")
return {"status": "ready"}慢启动场景下必须加startupProbe
如果你的应用启动耗时超过30秒（比如Qwen2.5-0.5B加载模型权重、Django迁移数据、PyTorch初始化CUDA上下文），光靠initialDelaySeconds不够用——因为livenessProbe和readinessProbe一旦开始执行，失败次数达到failureThreshold就会触发动作，而启动期本就该“失败”。
-
startupProbe是唯一能解决这个问题的机制：它先独占检查窗口，成功后才启用其他探针； - 配置要点：把
failureThreshold * periodSeconds设为略大于最大预期启动时间，例如预计最长45秒启动，则设failureThreshold: 10、periodSeconds: 5； - 注意：Kubernetes 1.16+ 才支持，旧集群需升级或改用
initialDelaySeconds硬扛，但风险极高。
示例：
startupProbe:
httpGet:
path: /readyz
port: 8000
failureThreshold: 12
periodSeconds: 5
# 总容忍时间 = 12 × 5 = 60秒，覆盖慢启动窗口最容易被忽略的一点：探针配置里的port必须和容器内实际监听端口一致，且该端口必须在Pod的containerPort中显式声明——否则httpGet会因端口未暴露而始终超时，无论你的Python端点写得多完美。
