[Kubernetes]资源模型与资源管理

作为 Kubernetes 的资源管理与调度部分的基础,需要从它的资源模型说起.

资源管理模型的设计

我们知道,在 Kubernetes 里面, Pod 是最小的原子调度单位,这就意味着,所有和调度和资源管理有关的属性,应该都是属于 Pod 对象的字段,而在这些字段中,最重要的部分就是 Pod 的 CPU 和内存配置.

在 Kubernetes 中,像 CPU 这样的资源被称作"可压缩资源"( compressible resources ).它典型特点是,当可压缩资源不足时, Pod 只会"饥饿",但是不会退出.

但是内存这样的资源,被称作"不可压缩资源"( incompressible resources ).当不可压缩资源不足时, Pod 就会因为 OOM( Out-Of-Memory )被内核杀掉.

还记得吗, Pod 可以由多个 Container 组成,所以 CPU 和内存资源的限额,是要配置在每个 Container 的定义上的.这样, Pod 整体的资源配置,就由这些 Container 的配置值累加得到.

来个例子:

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

在上面,我们能够看到, cpu limits 的值是 500m ( 500m 指的就是 500 millicpu ,也就是 0.5 个 cpu 的意思),所以这个 Pod 会被分配到 1 个 CPU 一半的计算能力.

对于内存资源来说,它的单位是 bytes . Kubernetes 支持使用 Ei , Pi , Ti , Gi , Mi , Ki (或者 E , P , T , G , M , K )的方式来作为 bytes 的值.在上面的例子中,我们能够看到, Memory requests 的值就是 64MiB ( 2 的 26 次方 bytes ).所以, Kubernetes 中的 Pod 中 CPU 和内存资源,实际上还要分为 limits 和 requests 两种情况,如下所示:

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory

limits 和 requests 的区别其实很简单:在调度的时候, kube-scheduler 只会按照 requests 的值进行计算,但在真正设置 Cgroups 限制的时候, kubelet 则会按照 limits 的值来进行设置.

说的再确切一点儿就是:当指定 requests.cpu=250m 之后,相当于将 Cgroups 的 cpu.shares 的值设置为 ( 250/1000)×1024 .如果没有设置 reques.cpu 的时候,默认是 1024 .如果指定了 limits.cpu=500m ,就相当于将 Cgroups 的 cpu.cfs_quota_us 的值设置为 (500/1000)×100ms , cpu.cfs_period_us 的值始终是 100ms .这个时候, Kubernetes 就设置了这个容器只能用到 CPU 的 50& .

对于内存来说,当指定了 limits.memory=128Mi 之后,相当于将 Cgroups 的 memory.limit_in_bytes 设置为 128×1024×1024 .但是在调度的时候,调度器只会使用 requests.memory=64Mi 来进行判断.

以上就是 Kubernetes 资源管理模型的设计.

QoS模型

在上面说到, Kubernetes 会有不同的 requests 和 limits 的设置方式, Kubernetes 接下来会将这个 Pod 划分到不同的 QoS 级别当中.所以,接下来咱们来说说, Kubernetes 中的 QoS 模型.

如果 Pod 中的每一个 Container 都同时设置了 requests 和 limits ,并且 requests 和 limits 值相等的时候,这个 Pod 就属于 Guaranteed 类别.如果 Pod 只是设置了 limits 的值,而没有设置 requests 的值, Kubernetes 会自动为它设置和 limits 相同的 requests 的值,此时这也属于 Guaranteed 情况.

如果 Pod 不满足以上的情况,但是至少有一个 Container 设置了 requests ,那么这个 Pod 就会被划分为 Burstable 类别.

如果一个 Pod 既没有设置 requests ,也没有设置 limits ,那么它的 QoS 类型就是 BestEffort .

为什么 Kubernetes 要为 Pod 设置这三种 QoS 类别呢?这样设置有什么作用呢?

那么我们就要知道, QoS 划分的主要应用场景:当宿主机资源紧张的时候, kubelet 对 Pod 进行 Eviction (即资源回收)时需要用到的.

也就是说,当 Kubernetes 所管理的宿主机上不可压缩资源短缺时,就有可能触发 Eviction .比如,可用内存,可用的宿主机磁盘空间等资源短缺时,就会触发 Eviction .

那么当 Eviction 发生的时候, kubelet 就会开始挑选 Pod 进行删除操作,来释放不可压缩资源,这个时候,就需要参考这些 Pod 的 QoS 类别了.

要进行删除的时候

• 首先考虑删掉的,肯定是 BestEffort 类别的 Pod
• 如果不可压缩资源还是短缺,则会删除 Burstable 类别,而且发生"饥饿"的资源使用量已经超出 requests 的 Pod
• 如果资源还是短缺,会考虑 Guaranteed 类别.并且, Kubernetes 会保证只有当 Guaranteed 类别的 Pod 的资源使用量超过了 limits 的限制,或者宿主机本身正处于 Memory Pressure 状态时, Guaranteed 的 Pod 才可能被选中进行 Eviction 操作.

所以呢,在实际的使用过程中,建议将 DaemonSet 的 Pod 都设置为 Guaranteed 的 QoS 类型.否则,一旦 DaemonSet 的 Pod 被回收,它又会立即在原宿主机上被重建出来,这就使得资源回收变得没有意义了.

要分享的内容,到这里就差不多了.

以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.

感谢您的阅读~