容器 的 cpu request limit 与 linux cgroups 的关系

Kubernetes 通过对 Cgroups 的精细控制来实现其requests和limits机制。

简单来说：

• requests-> 主要对应cpu.shares
• limits-> 主要对应cpu.cfs_quota_us和cpu.cfs_period_us

下面我们进行详细的分解和解释。

核心概念对应关系

1. CPU Request (requests.cpu) ->cpu.shares

• 作用：requests.cpu在 Kubernetes 中表示容器请求的、保证的最小 CPU 资源量。它主要影响 Pod 的调度——调度器会确保节点上有足够的可用资源（CPU 和内存）才会将 Pod 分配上去。
• Cgroups 实现：Kubernetes 通过设置 Cgroup v1 的cpu.shares属性来实现这一点。
• 工作原理：
  • cpu.shaes是一个相对权重，而不是一个绝对的 CPU 核心数。
  • 它的默认值是 1024。
  • Kubernetes 的计算公式大致为：容器申请的 cpu.shares = 1024 * requests.cpu
  • 例如：如果一个容器设置了requests.cpu: 1.5，那么它的cpu.shares将被设置为1024 * 1.5 = 1536。
• 行为：
  • 当节点上的 CPU 资源充足时，一个设置了requests.cpu的容器可以使用的 CPU可以超过其请求值，它几乎可以使用任何空闲的 CPU。
  • 当节点上的 CPU 资源紧张（多个容器竞争 CPU）时，CFS（完全公平调度器）会根据每个容器的cpu.shares比例来分配 CPU 时间。
  • 再例如：假设一个节点上只有两个 Pod：
    • Pod A:requests.cpu: 1->cpu.shares = 1024
    • Pod B:requests.cpu: 2->cpu.shares = 2048
    • 当两者都全力使用 CPU 时，它们将按照1024:2048（即1:2）的比例分配 CPU 时间。Pod A 大约获得 33% 的 CPU，Pod B 大约获得 66% 的 CPU。

总结：requests.cpu通过cpu.shares确保在资源竞争时获得最低保证份额，是一种“软”限制。

2. CPU Limit (limits.cpu) ->cpu.cfs_quota_us&cpu.cfs_period_us

• 作用：limits.cpu在 Kubernetes 中表示容器能使用的 CPU 资源的绝对硬性上限，无论节点上的 CPU 是否空闲，它都不能超过这个限制。
• Cgroups 实现：Kubernetes 通过设置 Cgroup v1 的CPU 带宽控制（CPU bandwidth control）子系统来实现，即cpu.cfs_quota_us和cpu.cfs_period_us这两个文件。
  • cpu.cfs_period_us：定义了一个时间周期（单位：微秒），通常固定设置为100,000 μs（即 100毫秒）。
  • cpu.cfs_quota_us：定义了在以上一个周期内，该容器最多可以使用的 CPU 时间（单位：微秒）。
• 工作原理：
  • 计算公式为：cpu.cfs_quota_us = limits.cpu * cpu.cfs_period_us
  • 例如：如果一个容器设置了limits.cpu: 1，那么：
    • cpu.cfs_period_us = 100000
    • cpu.cfs_quota_us = 1 * 100000 = 100000
    • 这意味着在每 100ms 的时间内，该容器最多可以使用 100ms 的 CPU 时间，即相当于独占 1 个 CPU 核心。
  • 再例如：如果一个容器设置了limits.cpu: 1.5，那么：
    • cpu.cfs_quota_us = 1.5 * 100000 = 150000
    • 这意味着在每 100ms 的时间内，该容器最多可以使用 150ms 的 CPU 时间，即相当于独占 1.5 个 CPU 核心。
  • 如果容器在周期内耗尽了它的配额（cpu.cfs_quota_us），它就会被节流（Throttled），必须等待下一个周期才能继续运行。

总结：limits.cpu通过cpu.cfs_quota_us和cpu.cfs_period_us设置一个严格的“天花板”，是一个“硬”限制。

综合示例与实践意义

一个 Pod 的配置可以同时包含requests和limits：

apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:

• name: example-container
  image: nginx
  resources:
  requests:
  memory: “64Mi”
  cpu: “0.5” # 请求 0.5 核
  limits:
  memory: “128Mi”
  cpu: “1” # 限制最多使用 1 核

在这个例子中：

1. 调度：调度器会寻找至少有 0.5 核空闲 CPU 和 64MiB 空闲内存的节点。
2. Cgroups 设置：
   • CPU:
     • cpu.shares = 1024 * 0.5 = 512
     • cpu.cfs_quota_us = 1 * 100000 = 100000
     • cpu.cfs_period_us = 100000
   • 内存：也会设置对应的memory.limit_in_bytes为 128MiB。

实践意义：

• 设置requests而不设置limits：容器可以弹性使用尽可能多的空闲 CPU，但在竞争时享有保证的最低份额。适用于可以充分利用空闲资源但不需要严格限制的应用。
• 设置limits而不设置requests：requests会默认等于limits。这保证了 Pod 的资源，但缺乏弹性。通常不建议，除非你明确希望如此。
• 同时设置requests和limits：这是最常见和推荐的做法。它既保证了 Pod 的调度和最小资源，又防止 bug 或异常导致单个 Pod 耗尽整个节点的资源（ noisy neighbor 问题）。

因此，Kubernetes 通过将高级别的requests和limits概念映射到 Cgroups 底层的不同控制机制，实现了既灵活又严格的混合资源管理策略。