一、资源治理不是把限制写满Kubernetes 常见线上事故不是 Pod 起不来而是流量上来后把节点拖慢。很多团队一开始只写replicas等 CPU 飙高、内存吃满、Pod 被驱逐才补requests和limits。资源治理的目标是让调度器、kubelet 和业务进程在同一套边界里工作。requests决定调度预留资源limits决定运行上限。CPU limit 过低会导致 CFS throttle接口延迟变长内存 limit 过低会触发 OOMKilled。常驻服务应从观测数据倒推配置而不是批量套模板。参数作用常见风险requests.cpu预留 CPU太高会降低利用率limits.cpuCPU 上限太低会 throttleresources.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:300mmemory:512Milimits:cpu:1000mmemory:1024MireadinessProbe:httpGet:{path:/ready,port:8080}initialDelaySeconds:10发布后看三类指标Pod 是否频繁重启、CPU 是否长期 throttle、内存工作集是否贴近 limit。接口服务还要看 P95/P99 延迟和错误率。kubectl-nprod get pod-lapporder-api kubectl-nprodtoppod-lapporder-api kubectl-nprod describe pod order-api-xxxx kubectl-nprod rollout status deploy/order-api三、HPA 要和业务指标一起看HPA 不是自动扩容的万能开关。如果瓶颈在数据库连接、下游接口或消息堆积单纯扩 Pod 可能只是把压力更快打到后端。CPU 型服务可以先用 CPU HPAIO 型服务建议补充 QPS、队列长度或请求延迟指标。kubectl-nprod autoscale deploy order-api\--min3--max12--cpu-percent65kubectl-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--tail200实践建议先给线上服务补齐 requests、readinessProbe、滚动发布策略和基础 HPA再按监控数据调整数值。不要一次性把所有服务都调成高 limit也不要把 HPA 当成容量规划的替代品稳定集群依赖资源边界、发布节奏和监控告警。