Kubernetes 生产集群的资源治理：从 requests 到 HPA 的可执行清单
一、资源治理不是把限制写满
Kubernetes 常见线上事故不是 Pod 起不来，而是流量上来后把节点拖慢。很多团队一开始只写replicas，等 CPU 飙高、内存吃满、Pod 被驱逐，才补requests和limits。资源治理的目标是让调度器、kubelet 和业务进程在同一套边界里工作。
requests决定调度预留资源，limits决定运行上限。CPU limit 过低会导致 CFS throttle，接口延迟变长；内存 limit 过低会触发 OOMKilled。常驻服务应从观测数据倒推配置，而不是批量套模板。
| 参数 | 作用 | 常见风险 |
|---|---|---|
requests.cpu | 预留 CPU | 太高会降低利用率 |
limits.cpu | CPU 上限 | 太低会 throttle |
resources.requests.memory | 预留内存 | 写太低容易被挤压 |
resources.limits.memory | 内存上限 | 太低会 OOMKilled |
二、给 Deployment 写一份能落地的基线
下面是一份 Web API 服务基线配置。它把滚动发布、健康检查和资源边界放在同一个文件里。实际项目里，镜像 tag 应由流水线注入。
apiVersion:apps/v1kind:Deploymentmetadata:name:order-apinamespace:prodspec:replicas:3revisionHistoryLimit:5strategy:type:RollingUpdaterollingUpdate:maxUnavailable:0maxSurge:1selector:matchLabels:app:order-apitemplate:metadata:labels:app:order-apispec:containers:-name:order-apiimage:registry.example.com/order-api:2026.07.07ports:-containerPort:8080resources:requests:cpu:"300m"memory:"512Mi"limits:cpu:"1000m"memory:"1024Mi"readinessProbe:httpGet:{path:/ready,port:8080}initialDelaySeconds:10发布后看三类指标：Pod 是否频繁重启、CPU 是否长期 throttle、内存工作集是否贴近 limit。接口服务还要看 P95/P99 延迟和错误率。
kubectl-nprod get pod-lapp=order-api kubectl-nprodtoppod-lapp=order-api kubectl-nprod describe pod order-api-xxxx kubectl-nprod rollout status deploy/order-api三、HPA 要和业务指标一起看
HPA 不是自动扩容的万能开关。如果瓶颈在数据库连接、下游接口或消息堆积，单纯扩 Pod 可能只是把压力更快打到后端。CPU 型服务可以先用 CPU HPA；IO 型服务建议补充 QPS、队列长度或请求延迟指标。
kubectl-nprod autoscale deploy order-api\--min=3--max=12--cpu-percent=65kubectl-nprod get hpa order-api扩容速度要保守。scaleUp太慢扛不住突发流量，太快会造成冷启动和数据库连接暴涨。scaleDown更不能激进，否则低峰刚缩容，下一波请求又要重新拉起 Pod。
四、排查顺序要固定下来
资源问题要有固定排查顺序：先看事件，再看重启，再看节点，再看应用指标。事件会直接提示调度失败、镜像拉取失败、探针失败、OOMKilled、驱逐等信息。
kubectl-nprod get events --sort-by=.metadata.creationTimestamp|tail-40kubectl-nprod get pod-owide kubectl-nprod logs deploy/order-api--tail=200实践建议：先给线上服务补齐 requests、readinessProbe、滚动发布策略和基础 HPA，再按监控数据调整数值。不要一次性把所有服务都调成高 limit，也不要把 HPA 当成容量规划的替代品；稳定集群依赖资源边界、发布节奏和监控告警。