Kubernetes中请求的确切用途是什么

Question

我对两个参数之间的关系感到困惑： requests和 cgroup 的cpu.shares ，一旦部署 Pod，就会更新。 根据我到目前为止所做的读数， cpu.shares在尝试获得消耗 CPU 的机会时反映了某种优先级。 这是一个相对值。

所以我的问题是为什么kubernetes在调度的时候会考虑CPU的request值是一个绝对值？ 当涉及到 CPU 进程时，将根据它们的优先级（根据 CFS 机制）获得一个时间片来执行。 据我所知，没有所谓的提供如此数量的 CPU（1CPU、2CPU 等）。 那么，如果考虑cpu.share值来确定任务的优先级，为什么 kubernetes 会考虑确切的请求值（例如：1500m、200m）来找出节点？

如果我错了，请纠正我。 谢谢 ！！

Answer 1

从主要问题和评论中回答您的问题：

所以我的问题是为什么kubernetes在调度的时候会考虑CPU的request值是一个绝对值？

据我所知，没有所谓的提供如此数量的 CPU（1CPU、2CPU 等）。 那么，如果考虑cpu.share值来确定任务的优先级，为什么 kubernetes 会考虑确切的请求值（例如：1500m、200m）来找出节点？

这是因为请求中的十进制 CPU 值总是被转换为以毫秒为单位的值，例如 0.1 等于 100m，可以读作 "一百毫普" 或 "一百毫核" 。 这些单位特定于 Kubernetes：

允许小数请求。 spec.containers[].resources.requests.cpu为0.5的容器保证 CPU 是要求 1 个 CPU 的容器的一半。 表达式0.1等价于表达式100m ，可以读作“一百毫普”。 有人说“一百毫核”，这被理解为同一个意思。 API 将带小数点的请求（如0.1 ）转换为100m ，不允许小于1m的精度。 出于这个原因，可能首选100m形式。

CPU 总是作为绝对数量被请求，而不是相对数量； 0.1 与单核、双核或 48 核机器上的 CPU 数量相同。

基于上述，请记住，您可以通过指定cpu: 1.5或cpu: 1500m来指定使用节点的 1.5 CPU。

只是想知道降低 cgroups 中的cpu.share值（在部署后由 k8s 修改）会影响进程的 cpu 功耗。 例如，假设 A、B 容器分配了 1024、2048 个共享。 因此可用资源将被拆分为 1:2 的比例。 那么如果我们为两个容器配置 cpu.share 为 10, 20 会不会一样。 仍然是1：2的比例

让我们说清楚 - 比率是相同的，但值是不同的。 cpu.shares 中的 1024 和 2048 表示在cpu.shares资源中定义的cpu: 1000m和cpu: 2000m ，而 10 和 20 表示cpu: 10m和cpu: 20m 。

假设集群节点基于 Linux 操作系统。 那么，kubernetes 如何确保将请求值赋予容器？ 最终，操作系统将使用 cgroup 中可用的配置来分配资源，对吗？ 它修改 cgroup 的cpu.shares值。 所以我的问题是，k8s 修改了哪些文件来告诉操作系统给容器100m或200m ？

是的，你的想法是正确的。 让我更详细地解释一下。

一般在 Kubernetes 节点上，根 cgroup 下有 3 个 cgroup ，命名为slices ：

k8s 使用cpu.share文件来分配 CPU 资源。 在这种情况下，根 cgroup 继承了 4096 个 CPU 份额，即 100% 的可用 CPU 功率（1 个核心 = 1024；这是固定值）。 根 cgroup 根据孩子的cpu.share按比例分配其份额，他们对孩子做同样的事情等等。 在典型的 Kubernetes 节点中，根 cgroup 下有三个 cgroup，分别是system.slice 、 user.slice和kubepods 。 前两个用于为关键系统工作负载和非 k8s 用户空间程序分配资源。 最后一个， kubepods是由 k8s 创建的，用于将资源分配给 Pod。

要检查哪些文件被修改，我们需要 go 到/sys/fs/cgroup/cpu目录。 在这里，我们可以找到名为kubepods的目录（它是上述切片之一），其中所有 pod 的cpu.shares文件都在这里。 在kubepods目录中，我们可以找到另外两个文件夹 - besteffort和burstable 。 这里值得一提的是 Kubernetes 有三个QoS 等级：

• 保证
• 可爆破
• 最大的努力

每个 pod 都有一个分配的 QoS class，根据它是哪个 class，pod 位于相应的目录中（除了保证，具有此 class 的 pod 是在kubepods目录中创建的）。

例如，我正在创建一个具有以下定义的 pod：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
spec:
  selector:
    matchLabels:
      app: test-deployment
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: test-deployment
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 300m
      - name: busybox
        image: busybox
        args:
        - sleep
        - "999999"
        resources:
          requests:
            cpu: 150m

根据前面提到的定义，这个 pod 将分配 Qos class Burstable ，因此它将在/sys/fs/cgroup/cpu/kubepods/burstable目录中创建。

现在我们可以检查这个 pod 的cpu.shares集：

user@cluster /sys/fs/cgroup/cpu/kubepods/burstable/podf13d6898-69f9-44eb-8ea6-5284e1778f90 $ cat cpu.shares
460

这是正确的，因为一个吊舱占用 300m，第二个吊舱占用 150m，它是通过乘以 1024 计算得出的。 对于每个容器，我们也有子目录：

user@cluster /sys/fs/cgroup/cpu/kubepods/burstable/podf13d6898-69f9-44eb-8ea6-5284e1778f90/fa6194cbda0ccd0b1dc77793bfbff608064aa576a5a83a2f1c5c741de8cf019a $ cat cpu.shares
153
user@cluster /sys/fs/cgroup/cpu/kubepods/burstable/podf13d6898-69f9-44eb-8ea6-5284e1778f90/d5ba592186874637d703544ceb6f270939733f6292e1fea7435dd55b6f3f1829 $ cat cpu.shares
307

如果您想了解更多有关 Kubrenetes CPU 管理的信息，我建议您阅读以下内容：

• Kubernetes 中的 CPU 限制和激进节流
• 控制节点上的 CPU 管理策略
• Kubernetes 资源限制和 kernel cgroups
• 如何演进 Kubernetes 资源管理 Model