Cuizhy Tech

Appearance

Requests vs Limits 的区别 ​

Requests（请求）：

  • 容器启动时保证分配的最小资源量
  • 用于调度决策，确保节点有足够资源
  • 影响 Pod 的调度和服务质量等级

Limits（限制）：

  • 容器能使用的最大资源量
  • 防止容器过度消耗资源影响其他容器
  • CPU 限制会被限流，内存限制会导致容器被杀死

设置原则 ​

1. 基于实际监控数据设置

yaml
resources:
  requests:
    cpu: 100m        # 基于平均使用量
    memory: 128Mi    # 基于最小需求
  limits:
    cpu: 500m        # 基于峰值使用量
    memory: 512Mi    # 留有一定余量

2. 不同环境的策略

  • 开发环境：较宽松的限制，便于调试
  • 测试环境：接近生产环境的设置
  • 生产环境：严格的资源控制

3. 应用类型考虑

  • Web 应用：通常 CPU 密集，内存相对稳定
  • 数据库：内存需求较高，CPU 波动大
  • 批处理任务：可能需要更高的 CPU 限制

具体建议 ​

CPU 设置：

  • Requests：设置为平均使用量的 80-90%
  • Limits：设置为峰值使用量的 1.2-1.5 倍
  • 使用毫核（millicores）单位，如 100m = 0.1 core

内存设置：

  • Requests：设置为应用启动所需的基础内存
  • Limits：考虑内存泄漏和突发需求，通常是 requests 的 1.5-2 倍
  • 注意 JVM 应用需要额外的堆外内存

监控和调优： 定期检查资源使用情况，使用 kubectl top pods 或监控工具如 Prometheus 来收集数据，根据实际使用情况调整配置。

QoS 类别考虑：

  • Guaranteed：requests = limits，获得最高优先级
  • Burstable：设置了 requests 但 limits > requests
  • BestEffort：未设置任何资源要求，优先级最低

建议从保守的设置开始，逐步根据监控数据进行优化调整。