Kubernetes 资源管理实战：合理配置 CPU 与内存请求和限制

---

Kubernetes 资源管理实战：合理配置 CPU 与内存请求和限制

在使用 Kubernetes 部署应用时，资源管理是一个至关重要的话题。合理配置容器的 CPU 与内存的 requests 和 limits，不仅能确保应用稳定运行，还能避免资源浪费和系统宕机。本文将结合一个实际案例——在一台 20GB 内存的服务器上部署两个服务，每个服务配置 15000Mi 内存限制，来探讨这一问题。

理解 Kubernetes 中的资源请求与限制

资源请求（Requests）

• 定义：容器启动时所需预留的最小资源。调度器会根据这些请求值来判断节点是否能够满足容器的最低需求。
• 作用：
  • 确保容器启动后有足够的资源运行。
  • 提高系统调度的精准度，避免节点超载。
• 示例：

  requests:
    cpu: "200m"      # 至少 0.2 个 CPU
    memory: "200Mi"  # 至少 200 MiB 内存
  

资源限制（Limits）

• 定义：容器可以使用的最大资源量。超过这一数值时，容器会被限制，甚至可能被系统杀掉。
• 作用：
  • 避免单个容器消耗过多资源，从而影响其他服务。
  • 防止因资源超载导致的节点不稳定问题。
• 示例：

  limits:
    cpu: "7"           # 最多 7 个 CPU 核心
    memory: "15000Mi"   # 最多 15000 MiB 内存
  

单位解析

• CPU：
  • 1 表示 1 个 CPU 核心（可能是虚拟 CPU）。
  • 200m 表示 0.2 个 CPU 核心，m 代表“毫”，1000m = 1 个 CPU。
• 内存：
  • Mi 表示 Mebibyte（约 1.05 MB）。
  • Kubernetes 推荐使用二进制单位，比如 200Mi 或 15000Mi。

---

案例分析：20GB 服务器与两个服务的内存配置

假设服务器总内存为 20GB（约 20480MiB），而两个服务都设置了 15000Mi 的内存限制。那么：

• 两个服务的内存限制总和：15000Mi × 2 = 30000Mi
• 实际可用内存：20480Mi
• 问题：
  • 如果两个服务都在满负荷使用其内存限制的情况下运行，总需求会远超服务器的实际内存，导致资源竞争，甚至系统出现 OOM（内存不足错误）。

是否有必要设置如此高的内存限制？

• 实际需求评估：

  • 服务实际可能远远不需要 15000Mi 内存。建议根据应用的内存使用情况（通过监控工具如 Prometheus、Grafana）动态调整。

• 峰值使用时间：

  • 如果两个服务的高峰期不重叠，理论上可以设置较高的限制，但依然不建议将两个服务的内存上限相加超过物理服务器内存。

• 系统预留：

  • Kubernetes 和操作系统需要预留一部分内存（通常建议预留 1-2GB），防止因资源耗尽导致系统不稳定。

如何合理配置？

1. 资源合理分配：

   • 假设预留 2GB 内存给系统，那么剩余可用内存约 18432Mi。
   • 两个服务的内存限制总和不宜超过 18432Mi，可以根据实际业务分配不同的内存配额，比如均分或按重要程度分配。

2. 调整建议：

   • 如果两个服务均衡，可以设置：

     limits:
       memory: "9000Mi"   # 每个服务 9000Mi，总和 18000Mi
     requests:
       memory: "3000Mi"   # 根据实际需求设定合适的 requests
     

   • 如果服务需求不同：
     • 服务 1：limits: 12000Mi，requests: 6000Mi
     • 服务 2：limits: 6000Mi，requests: 3000Mi

---

补充知识点：监控与自动扩缩容

监控工具

在生产环境中，建议结合以下工具来实时监控资源使用情况：

• Prometheus 与 Grafana：
  • 监控 CPU、内存、网络等指标，及时调整配置。
• Kubernetes Metrics Server：
  • 提供节点和 Pod 的资源使用数据，辅助调度器决策。

自动扩缩容（Autoscaling）

• Horizontal Pod Autoscaler (HPA)：
  • 根据 CPU 或其他自定义指标自动增加或减少 Pod 数量，保持系统稳定。
• Vertical Pod Autoscaler (VPA)：
  • 动态调整 Pod 的资源请求和限制，适应实际负载变化。

通过监控与自动扩缩容，可以有效避免资源配置不合理导致的性能瓶颈或资源浪费。

---

总结

在 Kubernetes 中合理配置 requests 与 limits 是保证集群稳定、高效运行的关键。本文通过「20GB 服务器部署两个服务」的案例，说明了如何根据物理资源、应用需求以及系统预留来调整内存限制。建议大家在生产环境中：

• 根据实际监控数据不断调整资源配置。
• 考虑系统预留和容器可能的峰值使用，避免资源过度承诺。
• 利用自动扩缩容机制来动态应对流量波动。

希望本文能为你在 Kubernetes 资源管理方面提供一些有益的参考和启发！