K8s Pod 资源调优实战手册（K8s 1.28 / cgroup v2）

一、配比调优方法：从监控数据反推 requests/limits

1.1 核心公式

| 维度 | 公式 | 经验值 | 说明 | |------|------|--------|------| | CPU requests | requests_cpu = P95(24h) × 1.2 | 不低于 0.25C | 用 7 天 P95 而非均值，留 20% 突发余量 | | CPU limits | limits_cpu = P99(7d) × 2.0 | requests 的 2–4 倍 | 允许短时突发，但不超过节点单核上限 | | Memory requests | requests_mem = P95(24h) + 64Mi | 不低于 128Mi | 64Mi 覆盖 cgroup page cache 开销 | | Memory limits | limits_mem = P99(7d) × 1.3 | requests 的 1.2–1.5 倍 | 内存不建议给过大 headroom，防 OOM 风暴 | | JVM -Xmx | Xmx ≤ limits_mem × 0.75 | 预留 25% 给 Metaspace/Thread/OS | 超 75% 则 cgroup OOM 先于 JVM OOM 触发 | | Go GOMAXPROCS | GOMAXPROCS = min(runtime.NumCPU(), limits_cpu) | cgroup v2 下自动感知 | Go 1.22 已默认读 cgroup v2 quota |

1.2 反推步骤（Prometheus + metrics-server）

# Step 1: 拉取 7 天 CPU 使用率 P95/P99
kubectl get pod -n prod -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'
# 用 PromQL 导出（Grafana 或 promtool）:
# P95: histogram_quantile(0.95, sum(rate(container_cpu_usage_seconds_total{namespace="prod"}[24h])) by (pod))
# P99: histogram_quantile(0.99, sum(rate(container_cpu_usage_seconds_total{namespace="prod"}[7d])) by (pod))

# Step 2: 拉取内存 P95/P99
# P95: histogram_quantile(0.95, sum(container_memory_working_set_bytes{namespace="prod"}) by (pod))

# Step 3: 用公式算出建议值，与当前 requests/limits 对比
kubectl describe pod -n prod <pod-name> | grep -A2 "Limits\|Requests"
kubectl top pod -n prod --sort-by=cpu | head -20

二、HPA vs VPA 选型决策树

开始
│
├─ 负载可预测？（定时批处理 / 可预知峰值）
│   ├─ 是 → HPA（cron 联动 + 指标驱动）
│   └─ 否 ↓
│
├─ 单 Pod 资源利用率长期 <60%？
│   ├─ 是 → VPA（自动调 requests/limits）
│   └─ 否 ↓
│
├─ 突发流量明显（尖刺型）？
│   ├─ 是 → HPA（快速扩副本）+ VPA（调单 Pod 规格）
│   └─ 否 → 静态 limits + 定期 review
│
└─ 关键路径服务（P0）？
    └─ 是 → HPA + PDB + priorityClass，VPA 仅用 updateMode=Off（只建议不自动改）

HPA 与 VPA 共存前提

1. VPA updateMode 必须设为 Off（只出建议，不自动 patch Pod spec），否则 HPA 扩出的新 Pod 会被 VPA 立刻改规格 → 滚动重启风暴；
2. HPA 的 minReplicas ≥ 2，避免 VPA 调规格时单副本不可用；
3. 两者操作不同维度（HPA 改副本数，VPA 改 requests/limits），但都改 Pod spec → 必须错峰：VPA 在低峰窗口运行，HPA 实时响应。

三、3 个线上案例复盘

案例 A：Java 17 Spring Boot 服务 OOMKilled

现象：Pod 每 4h 左右被 OOMKilled，kubectl describe 显示 OOMKilled (exitCode 137)，Grafana 看到容器内存曲线在 limit 处断崖。

定位命令：

# 1. 确认 OOM 事件
kubectl describe pod -n prod java-svc-7d4f8-x2k9p | grep -A5 "Events"
# 输出: Last State: Terminated / Reason: OOMKilled / Exit Code: 137

# 2. 看 JVM 实际使用 vs 容器 limit
kubectl exec -it java-svc-7d4f8-x2k9p -- \
  jcmd 1 VM.native_memory summary 2>/dev/null || \
  jstat -gcutil 1 1000 5

# 3. 看 cgroup 视角的内存使用
kubectl exec -it java-svc-7d4f8-x2k9p -- cat /sys/fs/cgroup/memory.current
kubectl exec -it java-svc-7d4f8-x2k9p -- cat /sys/fs/cgroup/memory.max
# 输出: memory.current = 983040000 (≈938MiB)
#       memory.max = 1073741824 (1GiB limit)
# 差值仅 36MiB → 几乎无 headroom

# 4. 确认 -Xmx 设置
kubectl exec -it java-svc-7d4f8-x2k9p -- env | grep JAVA_OPTS
# 输出: JAVA_OPTS=-Xmx1024m -Xms512m

根因：-Xmx=1024m 等于容器 limit 1GiB，JVM 堆用满后，Metaspace（~80MiB）+ Thread Stack（~40MiB）+ Direct Memory + CGroup page cache 超出 limit → 内核 OOM Killer 直接杀进程。JVM 没来得及触发 GC。

修复：

# 调整 JVM 参数（通过 ConfigMap 或 Deployment env）
env:
- name: JAVA_OPTS
  value: "-Xmx768m -Xms512m -XX:MaxMetaspaceSize=128m -XX:MaxDirectMemorySize=64m"

# 调整资源（768m + 128m + 64m + 64m(OS) ≈ 1024m，留 10% headroom）
resources:
  requests:
    memory: "768Mi"
  limits:
    memory: "1Gi"

验证：

# 部署后观察 24h
kubectl top pod -n prod -l app=java-svc --sort-by=memory
# 目标: memory usage < 850Mi（limit 1Gi 的 85%）
# 无 OOMKilled 事件
kubectl get events -n prod --field-selector reason=OOMKilled --sort-by='.lastTimestamp'
# 输出: No resources found

案例 B：Go 1.22 服务 CPU Throttle → P99 飙到 800ms+

现象：Go 微服务 P99 延迟从 80ms 飙到 850ms，持续 10min 后恢复。kubectl describe 无 OOM，但 Grafana CPU Throttle 指标（container_cpu_cfs_throttled_periods_total）在故障窗口暴增。

定位命令：

# 1. 确认 throttle 事件
kubectl get events -n prod --field-selector reason=Throttled
# 或 PromQL:
# rate(container_cpu_cfs_throttled_periods_total{pod=~"go-svc.*"}[5m])

# 2. 看 cgroup v2 配额
kubectl exec -it go-svc-8f2c1-mn4pq -- cat /sys/fs/cgroup/cpu.max
# 输出: 200000 100000  → quota=200ms/period=100ms → 等效 2C

# 3. 看 GOMAXPROCS 实际值
kubectl exec -it go-svc-8f2c1-mn4pq -- env | grep GOMAXPROCS
# 输出: 未设置（Go 1.22 默认 = NumCPU）

# 4. 确认节点核数
kubectl exec -it go-svc-8f2c1-mn4pq -- nproc
# 输出: 8 → GOMAXPROCS=8，但 quota 只给 2C
# 8 个 goroutine 并发抢 2C quota → 频繁 throttle

根因：节点 8C，Go runtime 默认 GOMAXPROCS=8 启动 8 个 P（逻辑核），但 cgroup v2 cpu.max 限制为 2C。当 8 个 P 同时运行时，CFS quota 周期（100ms）内只能用 200ms CPU 时间 → 平均每个 P 只能跑 25ms → 大量 goroutine 被强制 sleep → P99 延迟飙升。

修复：

# 方案 1: 显式设置 GOMAXPROCS = limits_cpu
env:
- name: GOMAXPROCS
  value: "2"  # 与 cpu.max quota 对齐

# 方案 2: 提升 limits（如果业务确实需要 >2C）
resources:
  limits:
    cpu: "4"
  requests:
    cpu: "2"

# 推荐: 方案 1（限制并发度）+ 方案 2 中的 HPA 扩副本

验证：

# 部署后观察 1h
# PromQL: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{service="go-svc"}[5m]))
# 目标: P99 < 150ms
# Throttle 指标归零:
# rate(container_cpu_cfs_throttled_periods_total{pod=~"go-svc.*"}[5m]) ≈ 0

案例 C：Node.js 20 事件循环阻塞 + Memory 泄漏 → VPA 建议值震荡

现象：开启 VPA（updateMode=Auto）后，Node.js 服务的 limits 在 512Mi ↔ 1Gi 之间反复震荡，每 2h 触发一次 Pod 滚动重启，业务 P99 抖动。

定位命令：

# 1. 看 VPA 建议历史
kubectl get vpat -n prod node-svc -o jsonpath='{.spec.resources.limits.memory}'
kubectl logs vpa-recommender-xxx -n kube-system --tail=100 | grep node-svc

# 2. 确认事件循环延迟
kubectl exec -it node-svc-6c9d8-k2lmn -- node -e "
  const {EventLoopMonitor} = require('node:inspector');
  const m = new EventLoopMonitor();
  m.enable(100, 100);
  m.on('inspector', d => console.log('avg:', d.mean.toFixed(0)+'ms', 'max:', d.max.toFixed(0)+'ms'));
  setTimeout(()=>m.disable(), 10000);
"

# 3. 看内存增长趋势（确认泄漏）
kubectl exec -it node-svc-6c9d8-k2lmn -- node -e "
  setInterval(() => {
    const m = process.memoryUsage();
    console.log(new Date().toISOString(), 'rss:', (m.rss/1024/1024).toFixed(0)+'MiB', 'heapUsed:', (m.heapUsed/1024/1024).toFixed(0)+'MiB');
  }, 5000);
"
# 输出: 5min 内 rss 从 480MiB → 720MiB（+240MiB/5min）→ 确认泄漏

# 4. 看 VPA 操作日志
kubectl logs vpa-updater-xxx -n kube-system | grep "node-svc" | tail -20
# 看到: updateMode=Auto → patch limits 1Gi → Pod restart → 新 Pod 从 512Mi 起步
#       泄漏累积 → 触发 OOM → VPA 建议上调 → 循环

根因：VPA 看到 OOM → 建议上调 limits → 重启后新 Pod 内存从低值起步 → VPA 看到低使用率 → 建议下调 → 再次 OOM。本质是内存泄漏导致 VPA 无法收敛，VPA 假设"稳定工作集"不成立。

修复：

# 1. 关闭 VPA 自动更新，改为手动 review
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: node-svc
  namespace: prod
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: node-svc
  updatePolicy:
    updateMode: Off   # ← 关键：只建议不自动改
  resourcePolicy:
    containerPolicies:
    - containerName: node
      minAllowed:
        memory: "512Mi"
      maxAllowed:
        memory: "2Gi"

// 2. 修复泄漏（代码层面）：排查未关闭的 interval / 未释放的 Buffer / 连接池泄漏
// 3. 用 HPA 替代 VPA 做弹性
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: node-svc-hpa
  namespace: prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: node-svc
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  // 防震荡
      policies:
      - type: Pods
        value: 1
        periodSeconds: 120

验证：

# 1. 确认 VPA 不再自动 patch
kubectl get events -n prod --field-selector involvedObject.name=node-svc --sort-by='.lastTimestamp'
# 无 "UpdatedPodReplicaSet" 事件

# 2. 确认 HPA 扩缩容正常
kubectl get hpa node-svc-hpa -n prod -w
# 观察: REPLICAS 在 3-6 间波动，无频繁扩缩

# 3. 内存稳定（泄漏修复后）
kubectl top pod -n prod -l app=node-svc --sort-by=memory
# 目标: 所有 Pod memory < 800Mi，无持续增长趋势

四、可复现 kubectl 命令集（≥10 条）

# 1. 查看 Pod 资源使用率（CPU + Memory）
kubectl top pod -n prod --sort-by=memory | head -20

# 2. 查看 Pod 资源限制与请求
kubectl describe pod -n prod <pod> | grep -A4 "Limits\|Requests"

# 3. 查看节点整体资源分配
kubectl describe node <node> | grep -A5 "Allocated resources"

# 4. 查看 OOMKilled 事件（全命名空间）
kubectl get events -A --field-selector reason=OOMKilled --sort-by='.lastTimestamp' | head -10

# 5. 查看 CPU Throttle 指标（需 Prometheus）
# PromQL: sum(rate(container_cpu_cfs_throttled_periods_total[5m])) by (pod) > 0

# 6. 查看 cgroup v2 CPU 配额
kubectl exec -it <pod> -n prod -- cat /sys/fs/cgroup/cpu.max

# 7. 查看 cgroup v2 内存当前使用
kubectl exec -it <pod> -n prod -- cat /sys/fs/cgroup/memory.current
kubectl exec -it <pod> -n prod -- cat /sys/fs/cgroup/memory.max

# 8. 查看 HPA 状态
kubectl get hpa -n prod -o wide
kubectl describe hpa <hpa-name> -n prod

# 9. 查看 VPA 建议
kubectl get vpat -n prod -o wide
kubectl describe vpat <vpat-name> -n prod

# 10. 查看驱逐阈值配置
kubectl get node <node> -o jsonpath='{.status.allocatable}'
kubectl get node <node> -o jsonpath='{.status.conditions[?(@.type=="MemoryPressure")].message}'

# 11. 查看 LimitRange
kubectl get limitrange -n prod -o yaml

# 12. 查看 ResourceQuota
kubectl get resourcequota -n prod -o wide

# 13. 查看 PodDisruptionBudget
kubectl get pdb -n prod

# 14. 手动触发 HPA 扩缩容测试
kubectl scale deployment <name> -n prod --replicas=5
kubectl get hpa -n prod -w

五、HPA + VPA YAML 示例（≥2 份，含逐行注释）

示例 1：HPA（指标驱动 + 防震荡）

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: go-svc-hpa
  namespace: prod
  labels:
    app: go-svc
spec:
  # 目标 Deployment
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: go-svc
  # 副本范围：最少 3（保 PDB），最多 12（节点容量上限）
  minReplicas: 3
  maxReplicas: 12
  metrics:
  # CPU 利用率目标 70%
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  # QPS 目标 5000 req/s（自定义指标，需 prometheus-adapter）
  - type: External
    external:
      metric:
        name: http_requests_per_second
        selector:
          matchLabels:
            service: go-svc
      target:
        type: AverageValue
        averageValue: "5000"
  # 防震荡行为
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30        # 扩容：30s 内确认
      policies:
      - type: Pods
        value: 3                             # 每次最多扩 3 个
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300       # 缩容：5min 确认（防抖）
      policies:
      - type: Percent
        value: 25                            # 每次最多缩 25%
        periodSeconds: 120

示例 2：VPA（只建议模式 + 资源边界）

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: java-svc-vpa
  namespace: prod
  labels:
    app: java-svc
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: java-svc
  updatePolicy:
    # 关键：Off = 只出建议，不自动改 Pod spec
    # 与 HPA 共存时必须用 Off，否则滚动重启风暴
    updateMode: Off
  resourcePolicy:
    containerPolicies:
    - containerName: java-svc
      # 边界：不低于 512Mi（JVM 最小需求），不高于 2Gi（节点容量）
      minAllowed:
        cpu: 250m
        memory: 512Mi
      maxAllowed:
        cpu: "4"
        memory: 2Gi
      # 模式：Initial = 新 Pod 用建议值，已有 Pod 不改
      controlPolicy:
        containers:
        - containerName: java-svc
          controlledResources:
          - cpu
          - memory
      # 审计：只记录不执行
      mode: Initial

共存前提总结：

• VPA updateMode=Off（或 mode=Initial 仅影响新 Pod）
• HPA minReplicas ≥ 2
• 两者操作不同维度（副本数 vs 单 Pod 规格），无直接冲突
• 定期（周级）review VPA 建议，手动 patch 后重启

六、落地 Checklist（≥10 项）

| # | 检查项 | 通过标准 | 常见反例 | |---|--------|----------|----------| | 1 | ResourceQuota 已设置 | kubectl get resourcequota -n <ns> 存在且 cpu/memory 有上限 | 未设 quota → 单命名空间可耗尽节点资源 | | 2 | LimitRange 已设置 | 每个 Pod 必须有 requests 和 limits（默认值兜底） | 只设 limits 不设 requests → 调度不可预测 | | 3 | requests/limits 比值合理 | CPU: 1:2~1:4；Memory: 1:1.2~1:1.5 | requests=limits → 无突发余量，P99 抖动 | | 4 | JVM -Xmx ≤ 75% of memory limit | 确认 JAVA_OPTS 与 limits 一致 | -Xmx=limit → 必然 OOM（Metaspace 等超 limit） | | 5 | GOMAXPROCS ≤ cpu limit | env 或 runtime 确认 | 默认=NumCPU → throttle（案例 B） | | 6 | priorityClass 已分配 | P0 服务用 high-priority（value=1000000） | 无 priorityClass → 驱逐时 P0 先被杀 | | 7 | PodDisruptionBudget 已设置 | minAvailable ≥ 1（P0 服务 ≥ 2） | 无 PDB → 节点维护时全部 Pod 同时驱逐 | | 8 | 驱逐阈值联动 | eviction-hard: memory.available<100Mi,nodefs.available<10% 与 Pod requests 匹配 | 驱逐阈值过松 → 节点 OOM 后大量 Pod 同时被杀 | | 9 | HPA 行为防震荡 | scaleDown stabilizationWindow ≥ 300s | 无 stabilization → 频繁扩缩（案例 C） | | 10 | VPA 与 HPA 不冲突 | VPA updateMode=Off 或 mode=Initial | VPA=Auto + HPA → 规格震荡（案例 C） | | 11 | 监控告警覆盖 | OOMKilled / CPU Throttle / Memory > 85% 有告警 | 无告警 → OOM 后才发现 | | 12 | 定期 review（周级） | VPA 建议 + 实际使用率对比，偏差 > 20% 则调整 | 一次设置后永不调整 → 业务变化后失配 |

七、总结

资源调优的核心原则：requests 保调度公平，limits 保突发余量，弹性策略保可用性。三者配合才能既不过度分配（浪费）也不过度限制（OOM/Throttle）。具体数值没有银弹，必须从监控数据反推 + 持续迭代。本手册给出的公式和案例可直接用于 3 节点 4C/8G 的 K8s 1.28 集群，核心思路适用于任意规模的自建/云集群。