Kubernetes资源管理：Requests、Limits与QoS的精细化配置策略

一、引言

Kubernetes资源管理中最常见的两类事故：一是Pod因OOMKilled被反复驱逐，二是节点资源充足但调度器拒绝放置Pod。两者的根因通常指向同一个问题——requests和limits配置不当。

本文将深入分析CPU/内存requests和limits的计算方法论、三种QoS等级的调度与驱逐优先级、OOMKilled的排查路径和预防手段，以及VPA与HPA协同工作的设计模式。

graph TB subgraph 资源请求与限制 REQ[Requests<br/>调度保证资源] LIM[Limits<br/>运行时硬上限] QoS[QoS等级判定] end subgraph 三类QoS G[Guaranteed<br/>requests == limits<br/>最低驱逐优先级] B[Burstable<br/>requests < limits<br/>中等驱逐优先级] BE[BestEffort<br/>无requests/limits<br/>最高驱逐优先级] end subgraph 调度与驱逐 SCHED[Scheduler<br/>基于requests调度] KUBELET[Kubelet驱逐<br/>基于实际使用量] OOM[OOM Killer<br/>基于oom_score_adj] end subgraph 自动伸缩 HPA[Horizontal Pod Autoscaler<br/>基于CPU/Memory使用率] VPA[Vertical Pod Autoscaler<br/>基于历史使用推荐] end REQ --> SCHED REQ --> QoS LIM --> QoS QoS -->|Guaranteed| G QoS -->|Burstable| B QoS -->|BestEffort| BE G --> OOM B --> OOM BE --> OOM KUBELET -->|资源压力| OOM HPA -->|副本数调整| SCHED VPA -->|推荐值更新| REQ style G fill:#27ae60,color:#fff style B fill:#f39c12,color:#fff style BE fill:#e74c3c,color:#fff

二、Requests与Limits的计算方法论

2.1 基于历史数据的科学设定

凭经验拍脑袋设定requests和limits是资源浪费或OOM的根源。推荐基于Prometheus历史数据的统计分析：

# PromQL查询：获取过去7天P99 CPU使用量 # container_cpu_usage: max_over_time(rate(container_cpu_usage_seconds_total{namespace="prod",pod=~"myapp-.*"}[5m])[7d:5m]) # PromQL查询：获取过去7天P99 Memory使用量（working set） # container_memory_usage: max_over_time(container_memory_working_set_bytes{namespace="prod",pod=~"myapp-.*"}[7d:5m])

基于以上数据，推荐的计算公式：

/** * Kubernetes资源推荐计算器 * 基于历史用量数据给出requests/limits建议 */ public class ResourceRecommendationCalculator { /** * 根据P50/P95/P99历史数据计算推荐值 */ public ResourceRecommendation calculate(ResourceUsageStats stats) { ResourceRecommendation rec = new ResourceRecommendation(); // CPU requests = P50（保证基本调度，不浪费资源） // CPU limits = P99 * 1.5（允许突发但设置硬上限，留50%缓冲） rec.setCpuRequest(roundCpu(stats.getCpuP50())); rec.setCpuLimit(roundCpu(stats.getCpuP99() * 1.5)); // Memory requests = P80（内存不像CPU可以突发，需要充足保障） // Memory limits = P99 * 1.3（内存超过limit直接OOMKill，buffer不必太大） rec.setMemoryRequest(roundMemory(stats.getMemoryP80())); rec.setMemoryLimit(roundMemory(stats.getMemoryP99() * 1.3)); // 安全检查：limits不能低于requests if (rec.getMemoryLimit().compareTo(rec.getMemoryRequest()) < 0) { rec.setMemoryLimit(rec.getMemoryRequest()); } if (rec.getCpuLimit().compareTo(rec.getCpuRequest()) < 0) { rec.setCpuLimit(rec.getCpuRequest()); } // 推荐QoS等级 boolean requestEqualsLimit = rec.getCpuRequest().equals(rec.getCpuLimit()) && rec.getMemoryRequest().equals(rec.getMemoryLimit()); rec.setRecommendedQoS(requestEqualsLimit ? "Guaranteed" : "Burstable"); rec.setConfidence(calculateConfidence(stats)); return rec; } private double calculateConfidence(ResourceUsageStats stats) { // 置信度基于数据变异系数（CV） double cpuCv = stats.getCpuStdDev() / Math.max(stats.getCpuMean(), 0.001); double memCv = stats.getMemoryStdDev() / Math.max(stats.getMemoryMean(), 0.001); // CV越低（波动越小），推荐值越可信 return 1.0 - Math.min((cpuCv + memCv) / 2.0, 1.0); } private String roundCpu(double cores) { // CPU：以0.1核为最小粒度 double rounded = Math.round(cores * 10) / 10.0; return Math.max(rounded, 0.1) + ""; // 最低0.1核 } private String roundMemory(long bytes) { // Memory：以Mi为最小粒度，最低64Mi long mib = Math.max(bytes / (1024 * 1024), 64); return mib + "Mi"; } }

2.2 典型应用场景的配置模板

# 场景1：核心API服务（Guaranteed QoS，稳定性优先） apiVersion: v1 kind: Pod metadata: name: core-api-guaranteed spec: containers: - name: app image: myapp:1.0 resources: requests: cpu: "2" memory: "4Gi" limits: cpu: "2" # requests == limits → Guaranteed memory: "4Gi" --- # 场景2：批处理Job（Burstable QoS，性价比优先） apiVersion: v1 kind: Pod metadata: name: batch-job-burstable spec: containers: - name: worker image: batch-worker:1.0 resources: requests: cpu: "500m" # 调度保证0.5核 memory: "512Mi" limits: cpu: "4" # 允许突发到4核 memory: "2Gi" # 内存上限2Gi（超出OOMKill） --- # 场景3：开发环境（不推荐BestEffort，此处仅示例） # BestEffort：没有指定任何requests和limits # 风险极高——生产环境严禁使用 apiVersion: v1 kind: Pod metadata: name: dev-debug-pod spec: containers: - name: debug image: busybox command: ["sleep", "3600"] # 未指定resources → BestEffort QoS

三、QoS等级与驱逐优先级

3.1 OOM Score计算机制

Kubernetes通过oom_score_adj控制OOM Killer的选择顺序。三类QoS的oom_score_adj值固定：

Burstable Pod的oom_score_adj计算公式：

# 查看Pod的实际oom_score_adj kubectl exec <pod-name> -- cat /proc/1/oom_score_adj # 对于Burstable Pod： # oom_score_adj = 1000 - 1000 * (memory_request / node_memory_capacity) # 内存requests占比越小的Pod，oom_score_adj越大，越容易被kill

3.2 OOMKilled排查流程

flowchart TD OOM[Pod状态: OOMKilled] --> CHECK1{是否为OOMKilled?} CHECK1 -->|kubectl describe| STATE[查看Reason: OOMKilled] STATE --> CHECK2{Exit Code?} CHECK2 -->|137| OOM_CONFIRM[确认OOM Signal] CHECK2 -->|其他| OTHER[非OOM问题] OOM_CONFIRM --> CHECK3{是否超出Limit?} CHECK3 -->|是| LIMIT_EXCEED[内存使用 > limits<br/>→ 提高limits或优化内存] CHECK3 -->|否| NODE_PRESSURE[节点内存压力<br/>→ 查看节点驱逐事件] LIMIT_EXCEED --> ACTION1[分析内存使用曲线] ACTION1 --> IS_LEAK{持续增长不回落?} IS_LEAK -->|是| MEM_LEAK[内存泄漏<br/>→ HeapDump分析] IS_LEAK -->|否| SPIKE[峰值流量触发<br/>→ 调整limits或HPA] NODE_PRESSURE --> ACTION2[查看节点内存分配] ACTION2 --> OVERCOMMIT{超卖严重?} OVERCOMMIT -->|是| FIX_REQ[提高Pod requests<br/>降低节点超卖比例] OVERCOMMIT -->|否| NODE_ISSUE[节点级问题<br/>→ 排查系统进程] style OOM fill:#e74c3c,color:#fff style MEM_LEAK fill:#e74c3c,color:#fff style FIX_REQ fill:#f39c12,color:#fff

四、VPA与HPA的协同

HPA（水平伸缩）和VPA（垂直伸缩）看似互补，但直接同时启用会导致冲突——VPA修改requests会干扰HPA的利用率计算。推荐采用"VPA推荐 + HPA执行"的协同模式：

# VPA：仅推荐模式（不自动更新），生成资源建议 apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: myapp-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: myapp updatePolicy: updateMode: "Off" # 仅推荐，不自动更新 resourcePolicy: containerPolicies: - containerName: app minAllowed: cpu: "100m" memory: "128Mi" maxAllowed: cpu: "4" memory: "8Gi" controlledResources: ["cpu", "memory"] --- # HPA：基于CPU/内存使用率自动扩缩容 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU使用率超70%触发扩容 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 # 内存使用率超80%触发扩容 behavior: scaleDown: stabilizationWindowSeconds: 300 # 缩容冷静期5分钟 policies: - type: Percent value: 10 periodSeconds: 60 # 每分钟最多缩10%

协同策略的核心：VPA设为updateMode: Off，通过CRD将推荐值输出到监控面板。运维人员定期Review VPA推荐，审批后手动更新Deployment的requests/limits——这是一个半自动化的安全流程，避免VPA在生产环境中自动调整引发不可预期的行为。

五、总结

资源管理的核心原则可以归纳为三条：

Requests决定调度——设低了Pod可能无法调度或成为被驱逐的高危目标，设高了导致节点碎片化和资源浪费。以历史P50-P80作为requests的参考基线是工程上的最佳实践。

Limits决定存亡——CPU limits是柔性的（超过后限流不杀进程），内存limits是刚性的（超过后立即OOMKill）。因此内存limits必须留有足够的安全边际（P99×1.3），同时通过JVM的-XX:MaxRAMPercentage等参数将应用的实际内存使用控制在limits之内。

QoS决定生死优先级——核心服务必须使用Guaranteed QoS，确保在节点内存压力下成为最后被驱逐的Pod。批处理任务使用Burstable以获得性价比。BestEffort只适合非关键的调试工具，永远不要用于生产流量。