1. 当你的Kubernetes集群开始"喘粗气"

最近我帮某电商团队优化他们的促销系统时，发现他们的订单服务Pod经常出现OOMKilled。这就好比给外卖小哥塞满包裹，结果跑到一半包裹掉了一地。我们通过监控发现关键问题：

  • 80%的Pod内存请求值高于实际使用量的3倍
  • 30%的节点CPU利用率长期低于40%
  • 每天产生1.2TB的监控数据却缺少深度分析

这种现象在快速迭代的开发团队中非常典型，就像买了全套健身器材却只用跑步机。接下来我们看看如何用监控数据开出"调理药方"。

2. 监控工具：集群的"听诊器"

（技术栈：Prometheus + Grafana）

在资源调优之前，我们需要先建立有效的监控系统。这里以最常用的Prometheus为例：

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_container_name]
        action: replace
        target_label: container

注释说明： • 第4行：自动发现集群中的所有Pod • 第6-8行：只抓取标注了prometheus.io/scrape=true的Pod • 第9-11行：将容器名称单独提取为标签

这个配置就像在医院做体检时选择检查项目，通过标签系统实现精准监控。记得配合Grafana使用这个仪表盘公式：

sum(rate(container_cpu_usage_seconds_total{namespace="$namespace"}[5m])) 
by (pod) / 
sum(kube_pod_container_resource_requests{namespace="$namespace", resource="cpu"}) 
by (pod)

该公式可计算每个Pod的实际CPU使用率与申请值的比例，比值长期低于0.3说明存在资源浪费。

3. Vertical Pod Autoscaler：给Pod"量体裁衣"

（技术栈：Kubernetes VPA）

Vertical Pod Autoscaler就像智能裁缝，能根据历史数据自动调整Pod的requests/limits。看这个电商系统的实战案例：

# vpa-recommendation.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: order-service-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: order-service
  updatePolicy:
    updateMode: "Off"  # 先查看建议值
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        minAllowed:
          cpu: "100m"
          memory: "128Mi"
        maxAllowed:
          cpu: "2"
          memory: "4Gi"

注释解析： • updateMode设为Off时只生成建议值不自动生效（生产环境推荐先采用这种安全模式） • min/maxAllowed设置安全边界，防止自动调整失控 • 通配符*表示应用于该Deployment的所有容器

运行一周后，我们得到这些关键数据：

  • 内存请求从2GB降至800MB
  • CPU限制从1核调整到0.75核
  • OOM发生率下降92%

但要注意：在调整内存时需预留至少20%缓冲空间，防止突发流量导致Pod重启。

4. 节点级优化：集群的"空间整理术"

（技术栈：Descheduler） 当发现节点资源碎片化严重时，Kubernetes原生的调度器可能无能为力。这就需要引入"空间整理专家"Descheduler：

# descheduler-policy.yaml
apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "LowNodeUtilization":
    enabled: true
    params:
      nodeResourceUtilizationThresholds:
        thresholds:
          "cpu" : 20
          "memory": 20
          "pods": 20
        targetThresholds:
          "cpu" : 50
          "memory": 50
          "pods": 50

配置解读： • 当节点资源使用率低于20%时视为"空置区域" • 目标是将节点资源使用率提升至50%以上 • 支持CPU、内存和Pod数量三个维度

某游戏公司在周五晚高峰前执行策略后：

  • 节点数量从58台缩减至42台
  • 平均CPU使用率从31%提升至55% • 每月节省云成本约$12,000

但要特别注意：在PodDisruptionBudget配置不当的情况下，频繁迁移可能影响服务可用性。

5. 黄金法则与避坑指南

应用场景：

  • 周期性流量波动明显的电商系统
  • 使用微服务架构的中大型应用
  • 混合云环境下的资源统筹

技术优点：

  • 资源成本平均可降低30-50%
  • 自动适应业务增长
  • 减少人工运维成本

注意事项：

① 生产环境调整requests/limits时需采用蓝绿部署

② 内存优化要预留GC所需空间

③ 避免同时启用HPA和VPA的自动模式

④ Descheduler的调度时间应避开业务高峰