ToB企服应用市场:ToB评测及商务社交产业平台

标题: Kubernetes的资源模型与资源管理(20250219) [打印本页]
作者: 农民    时间: 2025-2-19 14:26
标题: 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



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4