K8s 资源请求和限制怎么设才合理：别再拍脑袋了

K8s 的 resource requests 和 limits 怎么设？我见过太多团队的做法是"拍脑袋"——CPU 给个 500m，内存给个 512Mi，不够了就翻倍。结果要么资源浪费，要么服务被 OOM Kill。 ## 先搞清楚概念 - **Requests**：调度器用来决定 Pod 放在哪个节点上。设太高 = 节点放不下几个 Pod = 浪费 - **Limits**：运行时限制。CPU 超了会被限流（throttle），内存超了会被 OOM Kill 关键认知：**Requests 决定成本，Limits 决定稳定性**。 ## 错误示范 ```yaml # 典型的拍脑袋配置 resources: requests: cpu: "1" memory: "1Gi" limits: cpu: "2" memory: "2Gi" ``` 这个服务实际可能只用了 100m CPU 和 200Mi 内存，但你 request 了 1 CPU + 1Gi，白白浪费了 90% 的资源。 ## 科学的设置方法 ### 第一步：收集监控数据 先跑至少一周，收集 Prometheus 指标： ```promql # CPU P95 使用量（过去 7 天） quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{pod=~"myapp.*"}[5m])[7d:]) # 内存 P95 使用量 quantile_over_time(0.95, container_memory_working_set_bytes{pod=~"myapp.*"}[7d:]) ``` ### 第二步：设置 Requests Requests 设为 P95 使用量（或 P99，取决于你的风险偏好）： - 如果 CPU P95 = 150m，request 设 200m（留 30% 余量） - 如果内存 P95 = 300Mi，request 设 400Mi ### 第三步：设置 Limits - **CPU Limits**：建议设为 requests 的 2-4 倍，或者干脆不设。CPU 是可压缩资源，超了只是变慢不会挂 - **内存 Limits**：必须设！设为 requests 的 1.5-2 倍。内存是不可压缩资源，超了直接 OOM Kill ```yaml resources: requests: cpu: "200m" memory: "400Mi" limits: # cpu: 不设，让它能 burst memory: "800Mi" ``` ### 第四步：持续监控和调整 用 VPA（Vertical Pod Autoscaler）的 recommend 模式自动给出建议： ```yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: myapp-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: myapp updatePolicy: updateMode: "Off" # 只推荐，不自动调整 ``` VPA 会根据历史数据推荐合理的 requests 值。 ## 一个真实案例 我们集群有 50 个服务，按上面的方法重新设置 requests 之后： - 集群整体 CPU 利用率：15% → 45% - 节点数量：20 → 12 - 每月云费用：省了约 40% 大部分服务都是 request 设得太高了。很多服务 request 了 1 CPU 但实际只用 50-100m。 ## 总结 不要拍脑袋设资源，用数据说话。最简单的方法：先不设 limits（或设很大），跑一周收集数据，然后根据 P95 来设 requests。