Kubernetes的资源模型与资源管理(20250219)

Kubernetes的资源模型与资源管理(20250219)

​        Pod 是最小的原子调度单位。这也就意味着，所有跟调度和资源管理相关的属性都应该是属于 Pod 对象的字段。而这其中最重要的部分，就是 Pod 的 CPU 和内存配置

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   name: frontend
5. spec:
6.   containers:
7.   - name: db
8.     image: mysql
9.     env:
10.     - name: MYSQL_ROOT_PASSWORD
11.       value: "password"
12.     resources:
13.       requests:
14.         memory: "64Mi"
15.         cpu: "250m"
16.       limits:
17.         memory: "128Mi"
18.         cpu: "500m"
19.   - name: wp
20.     image: wordpress
21.     resources:
22.       requests:
23.         memory: "64Mi"
24.         cpu: "250m"
25.       limits:
26.         memory: "128Mi"
27.         cpu: "500m"

复制代码

​        在 Kubernetes 中，像 CPU 这样的资源被称作“可压缩资源”（compressible resources）。它的典型特点是，当可压缩资源不足时，Pod 只会“饥饿”，但不会退出。
​        而像内存这样的资源，则被称作“不可压缩资源（incompressible resources）。当不可压缩资源不足时，Pod 就会因为 OOM（Out-Of-Memory）被内核杀掉。

​        CPU是可压缩资源，当CPU不足时POD只会饥饿不会退出。内存和硬盘是不可压缩资源，当不可压缩资源不足时，POD就会因为OOM等被内核杀掉

​        Kubernetes 里为 CPU 设置的单位是“CPU 的个数”。比如，cpu=1 指的就是，这个 Pod 的 CPU 限额是 1 个 CPU。当然，具体“1 个 CPU”在宿主机上如何解释，是 1 个 CPU 核心，还是 1 个 vCPU，还是 1 个 CPU 的超线程（Hyperthread），完全取决于宿主机的 CPU 实现方式。Kubernetes 只负责保证 Pod 能够使用到“1 个 CPU”的计算能力。
环境cpu=1 的等效资源性能特点物理机（无超线程）1 物理核心稳定，独占物理资源物理机（有超线程）1 超线程（逻辑 CPU）可能受同核心其他超线程负载影响云虚拟机（通用实例）1 vCPU（通常为超线程或部分物理核心）共享物理资源，性能可能波动容器运行时（cgroups）100ms/100ms 的 CPU 时间片算力隔离，但依赖宿主机的 CPU 调度机制​        此外，Kubernetes 允许你将 CPU 限额设置为分数，比如在我们的例子里，CPU limits 的值就是 500m。所谓 500m，指的就是 500 millicpu，也就是 0.5 个 CPU 的意思。这样，这个 Pod 就会被分配到 1 个 CPU 一半的计算能力。
​        你也可以直接把这个配置写成 cpu=0.5。但在实际使用时，我还是推荐你使用 500m 的写法，毕竟这才是 Kubernetes 内部通用的 CPU 表示方式。
Pod 里的 requests 和 limits

​        Kubernetes 里 Pod 的 CPU 和内存资源，实际上还要分为 limits 和 requests 两种情况

1. spec.containers[].resources.limits.cpu
2. spec.containers[].resources.limits.memory
3. spec.containers[].resources.requests.cpu
4. spec.containers[].resources.requests.memory

复制代码

​        Kubernetes 的 requests+limits 的做法，其实就是上述思路的一个简化版：用户在提交 Pod 时，可以声明一个相对较小的 requests 值供调度器使用，而 Kubernetes 真正设置给容器 Cgroups 的，则是相对较大的 limits
​        当 Pod 里的每一个 Container 都同时设置了 requests 和 limits，并且 requests 和 limits 值相等的时候，这个 Pod 就属于 Guaranteed 类别

k8s 三种 QoS 等级： Guaranteed（可保证的）、Burstable（突发的）、BestEffort（尽力而为的）

如下所示：

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   name: qos-demo
5.   namespace: qos-example
6. spec:
7.   containers:
8.   - name: qos-demo-ctr
9.     image: nginx
10.     resources:
11.       limits:
12.         memory: "200Mi"
13.         cpu: "700m"
14.       requests:
15.         memory: "200Mi"
16.         cpu: "700m"

复制代码

​        需要注意的是，当 Pod 仅设置了 limits 没有设置 requests 的时候，Kubernetes 会自动为它设置与 limits 相同的 requests 值，所以，这也属于 Guaranteed 情况。
​        而当 Pod 不满足 Guaranteed 的条件，但至少有一个 Container 设置了 requests。那么这个 Pod 就会被划分到 Burstable 类别

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   name: qos-demo-2
5.   namespace: qos-example
6. spec:
7.   containers:
8.   - name: qos-demo-2-ctr
9.     image: nginx
10.     resources:
11.       limits
12.         memory: "200Mi"
13.       requests:
14.         memory: "100Mi"

复制代码

只要有一个 container 设置了 requests 就行

​        而如果一个 Pod 既没有设置 requests，也没有设置 limits，那么它的 QoS 类别就是 BestEffort。比如下面这个例子：

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   name: qos-demo-3
5.   namespace: qos-example
6. spec:
7.   containers:
8.   - name: qos-demo-3-ctr
9.     image: nginx

复制代码

​        那么，Kubernetes 为 Pod 设置这样三种 QoS 类别，具体有什么作用呢？
​        实际上，QoS 划分的主要应用场景，是当宿主机资源紧张的时候，kubelet 对 Pod 进行 Eviction（即资源回收）时需要用到的。
Eviction 的默认阈值

​        当 Kubernetes 所管理的宿主机上不可压缩资源短缺时，就有可能触发 Eviction。比如，可用内存（memory.available）、可用的宿主机磁盘空间（nodefs.available），以及容器运行时镜像存储空间（imagefs.available）

注意，是“不可压缩资源”的短缺。

​        Kubernetes 为你设置的 Eviction 的默认阈值如下所示
[code]memory.available