1. Kubernetes资源配置核心挑战

在容器化部署成为主流的今天，Kubernetes作为事实上的编排标准，其资源配置管理直接影响着集群的稳定性和资源利用率。我在金融行业和互联网公司的实践中发现，超过70%的Kubernetes生产问题都源于资源配置不当——要么是资源请求(request)设置不合理导致节点过载，要么是限制(limit)过高造成资源浪费。

2. 资源模型深度解析

2.1 可压缩与不可压缩资源

Kubernetes将资源分为两类：

• 可压缩资源 ：CPU等可以被节流的资源
• 不可压缩资源 ：内存等无法被节流的资源

这直接决定了Kubernetes的调度和驱逐策略。例如当节点内存不足时，kubelet会按照优先级驱逐Pod，而CPU资源紧张时则会通过CFS配额进行节流。

2.2 资源请求与限制的黄金比例

经过上百个生产Pod的调优实践，我总结出以下配置原则：

资源类型	请求(request)	限制(limit)	适用场景
CPU	平均负载的70%	峰值负载的120%	有突发流量的服务
内存	常驻内存的110%	OOM阈值的90%	Java/Python应用
GPU	全量请求	等于请求量	机器学习任务

重要提示：Java应用务必设置内存limit，并配合-XX:MaxRAMPercentage使用，避免容器被杀

3. 实战配置策略

3.1 基于HPA的动态资源配置

当配合Horizontal Pod Autoscaler使用时，需要特别注意：

resources:
  requests:
    cpu: "500m"  # 必须设置才能触发HPA
  limits:
    cpu: "2000m" # 不超过节点可用核数的80%

实测案例：某电商服务在618期间通过以下配置实现了自动扩容：

• 初始request：0.5核
• limit：2核
• HPA触发阈值：CPU利用率60%

3.2 内存敏感型应用配置技巧

对于Redis等内存敏感服务，必须配置：

resources:
  requests:
    memory: "8Gi"
  limits:
    memory: "8Gi"  # 请求与限制设为相同
livenessProbe:
  failureThreshold: 3
  periodSeconds: 10

关键点：禁用swap，设置vm.overcommit_memory=1，并配置合理的内存驱逐阈值。

4. 高级资源管理方案

4.1 使用ResourceQuota进行多租户隔离

团队级别的资源配额示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    pods: "100"

4.2 通过LimitRange设置默认值

集群级别的默认资源配置：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "256Mi"
    type: Container

5. 监控与调优实战

5.1 关键监控指标

使用Prometheus需要关注的黄金指标：

• container_cpu_usage_seconds_total
• container_memory_working_set_bytes
• kube_pod_container_resource_limits
• kube_pod_container_resource_requests

5.2 资源利用率优化案例

某支付网关的优化过程：

1. 初始配置：2核4G
2. 通过pprof分析发现CPU峰值在1.3核
3. 调整request为1.5核，limit为2核
4. 内存常驻2.1G，设置request为2.5G
5. 最终节省了35%的节点资源

6. 常见问题排查指南

6.1 Pod处于Pending状态

检查步骤：

1. kubectl describe pod 查看事件
2. kubectl get nodes -o json | jq '.items[].status.allocatable'
3. 检查是否有ResourceQuota限制

6.2 OOMKilled问题分析

内存问题排查流程：

1. 检查dmesg日志
2. 分析heapster/prometheus历史数据
3. 考虑添加Sidecar进行内存分析
4. 调整limit或优化应用内存使用

7. 最佳实践总结

经过多个生产集群的验证，我建议：

1. 所有Pod必须设置requests和limits
2. Java应用配置-XX:MaxRAMPercentage
3. 重要服务设置priorityClassName
4. 定期使用kube-resource-report分析资源利用率
5. 开发环境配置更严格的LimitRange

最后分享一个实用命令，可以快速查看集群资源分配情况：

kubectl get pods --all-namespaces -o json | jq '[.items[] | {name: .metadata.name, cpu: .spec.containers[].resources.requests.cpu, memory: .spec.containers[].resources.requests.memory}]'