Kubernetes部署Python项目关键在于确保Pod稳定运行、可观测、可扩展，核心问题集中于端口绑定（必须0.0.0.0）、进程常驻（避免主进程退出）、资源限制（防OOMKilled）和健康检查（readiness/liveness合理分离）。
直接上结论：Kubernetes 部署 Python 项目，核心不是“能不能”，而是“怎么让 Pod 真的跑稳、可查、能扩”。很多失败案例不是 YAML 写错，而是容器启动后立刻 CrashLoopBackOff，或者服务暴露了但连不上——问题通常出在端口、进程模型、健康检查这三处。
为什么你的 Python Pod 一直 restart？看 CrashLoopBackOff 的真实原因
这不是 Kubernetes 在“抽风”，而是容器内主进程退出后，Kubernetes 按策略反复重启。常见触发点：
-
app.py启动后立即结束（比如没加app.run(host='0.0.0.0:5000', threaded=True)或用了debug=True导致单线程阻塞） - 监听地址写成
127.0.0.1:5000—— 容器内必须绑定0.0.0.0才能被 Service 转发 - 没设
containerPort，或设的值和代码里实际监听的端口不一致（如代码监听8000，YAML 却写containerPort: 5000） - 依赖缺失（如
ffmpeg二进制未装进镜像，但ffmpeg-python运行时报FileNotFoundError）
查法：先 kubectl logs -f <pod-name> 看最后一屏错误；再 kubectl describe pod <pod-name> 看 Events 里有没有 Failed to start container 或 Liveness probe failed。
Deployment 里 resources 不配会怎样？
不配 requests 和 limits，Pod 可能被调度到资源紧张的节点上，运行中被 OOMKilled（Exit Code 137），尤其 Python 服务内存增长不可控时更危险。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
-
requests是调度依据：Kubernetes 只会把memory: "128Mi"的 Pod 放到剩余内存 ≥128Mi 的节点上 -
limits是硬上限：一旦 Python 进程内存超"256Mi"，Linux cgroup 会直接 kill 掉它 - 建议起手值：
cpu: "100m"（0.1 核）、memory: "128Mi"；若用gunicorn多 worker，按 worker 数 × 单实例内存估算
Service 类型选 ClusterIP 还是 NodePort？别硬套教程
本地开发调试用 NodePort 最快（kubectl port-forward 也行，但不够“真”）；生产环境一律走 Ingress + TLS，NodePort 只用于临时验证或边缘场景。
-
ClusterIP：仅集群内部可访问，适合 Python 微服务间调用（如 Flask 服务调 FastAPI） -
NodePort：开放宿主机端口（默认 30000–32767），需确保防火墙放行，且不能多个服务抢同一个端口 - 关键细节：
service.spec.selector必须和deployment.spec.template.metadata.labels完全匹配，一个字母错就找不到 Pod
健康检查（liveness/readiness）怎么写才不误杀？
很多团队把 readinessProbe 和 livenessProbe 都指向 /healthz，结果服务刚启动还在加载模型，探针就超时，Kubernetes 直接删 Pod——这是最典型的自毁式配置。
-
readinessProbe应判断“是否准备好收流量”：比如检查 Redis 连通性、数据库连接池是否建好 -
livenessProbe应判断“是否还活着”：比如检查主线程是否卡死、GIL 是否异常阻塞 - 初上线建议：先只配
readinessProbe，initialDelaySeconds设大点（如 30s），periodSeconds设 10s；等稳定后再加livenessProbe - 避免用 HTTP 探针检查耗时操作（如
/healthz里执行一次 DB 查询），超时设置要留足余量
真正难的不是写完 YAML，而是让 Python 进程在容器里“活下来、说清楚、扛得住”。端口、进程模型、资源限制、探针逻辑，四者缺一不可，漏掉任意一个，都可能让部署变成一场定时重启游戏。
