K8s中Python服务高可用依赖Deployment副本、健康检查、资源限制与依赖解耦，而非追求单进程永不崩溃；因Python容器本质单进程，OOMKilled、启动卡住、无就绪流量等问题必须由K8s探针和调度机制协同解决。
直接说结论：K8s 里 Python 服务的高可用不靠“单个容器更稳”，而靠 Deployment 的副本数 + 健康检查 + 合理资源限制 + 外部依赖解耦。硬堆一个“永不崩溃”的 Python 进程反而会掩盖真实问题。
为什么不能只靠 Python 进程自身做高可用
Python 应用（比如 Flask/FastAPI）在容器中本质是单进程，即使加了 supervisord 或多线程，也无法规避以下事实：
-
OOMKilled：内存超limits会被 cgroup 强杀，supervisor 无法拦截 - 启动卡住：
app.py里连不上数据库或 Redis，进程 hang 住但状态仍是 Running - 无就绪流量：Pod 已 Running，但应用还没初始化完中间件，
livenessProbe误判为健康，流量进来就 502
所以高可用的第一道防线，是让 K8s 能准确感知“这个 Pod 真的能干活”。
必须配置的三个 Probe
缺一不可，且参数要匹配 Python 实际启动行为：
立即学习“Python免费学习笔记（深入）”；
-
readinessProbe：用 HTTP 检查/health/ready，初始延迟initialDelaySeconds: 10（等 DB 连上、缓存预热完），失败阈值failureThreshold: 3，避免抖动误踢 -
livenessProbe：同样走 HTTP，但路径是/health/live，initialDelaySeconds: 30（给慢启动留足时间），periodSeconds: 10，超时设为timeoutSeconds: 2（防阻塞） -
startupProbe（K8s 1.16+）：对 Python 这类冷启动长的服务特别关键，设failureThreshold: 30、periodSeconds: 10，确保 Pod 有足够时间完成初始化再开始 health check
示例片段：
librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。
livenessProbe:
httpGet:
path: /health/live
port: 8000
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
startupProbe:
httpGet:
path: /health/startup
port: 8000
failureThreshold: 30
periodSeconds: 10
资源请求与限制必须严格配对
很多团队只设 limits，不设 requests，结果调度器乱塞 Pod，导致节点 CPU 抢占严重，Python GIL 下响应毛刺明显：
-
requests.cpu至少设100m，否则在高密度节点上可能被调度到已满载的 CPU 核 -
requests.memory必须 ≥ Python 进程常驻内存（含依赖库），建议用ps aux --sort=-%mem | head -5在镜像里实测 -
limits.memory不能只比 requests 高一点——比如只高 32Mi，Gunicorn worker fork 时易触发 OOM；推荐按实际压测峰值上浮 20%
错误示范：requests: {memory: "128Mi"} + limits: {memory: "160Mi"} → 一压测就 OOMKilled
Python 运行时选型直接影响容错能力
别用 python app.py 直接跑，它没有进程管理、无 graceful shutdown、不支持多 worker：
- Web 类服务：固定用
gunicorn（同步）或uvicorn（异步），必须加--preload（避免每个 worker 重复加载模块）和--graceful-timeout（配合 K8s terminationGracePeriodSeconds） - 非 Web 类（如 Celery worker）：用
celery -A tasks worker，但需在 SIGTERM 信号里显式调用app.control.cancel_consumer()，否则消息可能丢失 - 禁止在容器里起 cron：用 K8s
CronJob替代，避免多个副本同时触发
关键点：所有 Python 进程必须能响应 SIGTERM 并在 terminationGracePeriodSeconds（默认 30s）内干净退出，否则 K8s 会发 SIGKILL 强杀。
最常被忽略的是 startupProbe 和 terminationGracePeriodSeconds 的协同——前者保启动，后者保退出，两者缺一，高可用就是纸糊的。
