Deployment用于长时无状态服务，Job用于短时批处理任务；横向扩展需结合HPA与合理指标（如队列长度）、Pod内多进程配置及资源限制，避免仅依赖CPU利用率。
Deployment 控制副本数，但光靠它没法让任务真正“横向扩展”——你得让每个 Pod 能独立处理分片任务，且调度器知道怎么分发。
用 Job 还是 Deployment？先看任务类型
短时、有明确终点的任务（比如批量清洗 1000 条日志）用 Job；长时、持续接收请求的服务（比如 Flask API）才用 Deployment。混用会出问题：Deployment 不会自动终止已完成的 Pod，Job 又没法响应 HTTP 请求。
- 定时批处理（如每小时跑一次数据聚合）→
CronJob，别硬套Deployment - 消息驱动型任务（从 RabbitMQ 或 Kafka 拉取任务）→
Deployment+ 并发消费者逻辑，每个 Pod 自主拉取、处理、确认 - HTTP 触发型任务（如用户上传后触发转码）→
Deployment+ 前置Service+ 后端加任务队列（Celery + Redis），避免请求阻塞
HorizontalPodAutoscaler 的触发条件别只盯 CPU
CPU 利用率对 Python 任务经常失灵：GIL 会让单个进程 CPU 占用高但实际吞吐没上去；IO 密集型任务（如爬虫、文件解析）CPU 可能一直低于 30%，但队列已堆积。直接依赖 cpu utilization 容易扩不起来或扩过头。
- 优先用自定义指标：比如 Prometheus 抓取的
task_queue_length或pending_requests - 若用内置指标，至少配
averageUtilization: 60，别设 20 —— Python 进程空转时 CPU 也低 -
minReplicas至少设为 2，避免单点故障；maxReplicas要结合任务队列容量和资源配额设上限
Python 进程模型直接影响扩缩效果
默认的 gunicorn --workers=1 或纯 Flask.run() 是单线程单进程，再多副本也扛不住并发请求。K8s 扩的是 Pod 数量，不是进程数 —— 每个 Pod 内部还得能压榨资源。
立即学习“Python免费学习笔记（深入）”；
- Web 类服务：用
gunicorn，worker 数设为2 * CPU_LIMIT + 1（例如容器resources.limits.cpu: "2"→--workers=5） - 异步任务类（如 FastAPI + httpx）：用
uvicorn --workers=2，别用--workers=1配async def - 避免在代码里写
time.sleep(10)或无超时的requests.get()—— 这类阻塞会让 Pod 看似“活着”，实则无法处理新任务
nodeSelector 和容忍度要匹配真实节点能力
你写了 nodeSelector: {cloud.google.com/gke-accelerator: nvidia-tesla-k80}，但集群里没 GPU 节点？那所有 Pod 会卡在 Pending 状态，HPA 再灵敏也没用。
- 边缘场景（如
node-role.kubernetes.io/edge）必须提前打 label，用kubectl label node xxx edge=true，别只改 YAML - 容忍度（
taints/tolerations）要和节点 taint 对齐，否则调度失败；常见漏配：key: "node.kubernetes.io/unreachable"的 toleration 缺失导致节点临时失联时 Pod 被驱逐 - 资源 request/limit 必须合理：Python 任务内存泄漏常见，
limits.memory: "512Mi"但实际用到 700Mi → OOMKilled，扩再多副本也白搭
真实扩缩慢、扩不起来、扩了没效果——八成不是 K8s 配置问题，而是 Python 进程没跑对、指标没选对、资源没算准。盯着 kubectl get hpa 输出前，先确认你的 Pod 里到底跑着几个 worker、有没有在等锁、Prometheus 是否真抓到了队列长度。
