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