十四. k8s资源需求和限制, 以及pod驱逐策略

╰半橙微兮° 2023-08-17 16:33 138阅读 0赞

*  容器的资源需求和资源限制
 *  QoS Classes分类
    
     *  Guaranteed
     *  Burstable
     *  Best-Effort
 *  kubernetes之node资源紧缺时pod驱逐机制
    
     *  Qos Class优先级排名
     *  可压缩资源与不可压缩资源
     *  存储资源不足
        
         *  举例
     *  内存资源不足
        
         *  举例
     *  Node OOM (Out Of Memory)
     *  总结
 *  参考链接

# 容器的资源需求和资源限制 #

*  requests：需求，最低保障, 保证被调度的节点上至少有的资源配额
 *  limits：限制，硬限制, 容器可以分配到的最大资源配额

![1120683-20190925221419705-1306269431.png][]

apiVersion: v1
    kind: Pod
    metadata:
        name: pod-demo
        labels:
            app: myapp
            tier: fronted
    spec:
        containers:
        - name: myapp
          image: ikubernetes/stress-ng
          command: ["/usr/bin/stress-ng", "-m 1", "-c 1", "--metrics-brief"]
          resources:
            requests:
              cpu: "200m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "200Mi"

kubectl exec pod-demo -- top

![1120683-20190925221500097-1302501517.png][]

这是一个CPU为2核的节点, 分配给容器500m的CPU, 也就是0.5个CPU, 所以看到的进程CPU占用率约为`26%`

# QoS Classes分类 #

## Guaranteed ##

如果Pod中所有Container的所有Resource的`limit`和`request`都相等且不为0，则这个Pod的QoS Class就是Guaranteed。

> 注意，如果一个容器只指明了limit，而未指明request，则表明request的值等于limit的值。

containers:
        name: foo
            resources:
                limits:
                    cpu: 10m
                    memory: 1Gi
        name: bar
            resources:
                limits:
                    cpu: 100m
                    memory: 100Mi
                requests:
                    cpu: 100m
                    memory: 100Mi

## Burstable ##

至少有一个容器设置CPU或内存资源的requests属性

## Best-Effort ##

如果Pod中所有容器的所有Resource的request和limit都没有赋值，则这个Pod的QoS Class就是Best-Effort.

containers:
        name: foo
            resources:
        name: bar
            resources:

# kubernetes之node资源紧缺时pod驱逐机制 #

## Qos Class优先级排名 ##

Guaranteed > Burstable > Best-Effort

## 可压缩资源与不可压缩资源 ##

Pod 使用的资源最重要的是 CPU、内存和磁盘 IO，这些资源可以被分为`可压缩资源（CPU）`和`不可压缩资源（内存，磁盘 IO）`。

*  可压缩资源`(CPU)`不会导致pod被驱逐
    
    因为当 Pod 的 CPU 使用量很多时，系统可以通过重新分配权重来限制 Pod 的 CPU 使用
 *  不可压缩资源`(内存)`则会导致pod被驱逐
    
    于不可压缩资源来说，如果资源不足，也就无法继续申请资源（内存用完就是用完了），此时 Kubernetes 会从该节点上驱逐一定数量的 Pod，以保证该节点上有充足的资源。

## 存储资源不足 ##

下面是 kubelet 默认的关于节点存储的驱逐触发条件：

*  nodefs.available<10%（容器 volume 使用的文件系统的可用空间，包括文件系统剩余大小和 inode 数量）
 *  imagefs.available<15%（容器镜像使用的文件系统的可用空间，包括文件系统剩余大小和 inode 数量）

当 `imagefs` 使用量达到阈值时，kubelet 会尝试删除不使用的镜像来清理磁盘空间。

当 `nodefs` 使用量达到阈值时，kubelet 就会拒绝在该节点上运行新 Pod，并向 API Server 注册一个 DiskPressure [condition][]。然后 kubelet 会尝试删除死亡的 Pod 和容器来回收磁盘空间，如果此时 `nodefs` 使用量仍然没有低于阈值，kubelet 就会开始驱逐 Pod。kubelet 驱逐 Pod 的过程中`不会参考 Pod 的 QoS`，只是根据 Pod 的 nodefs 使用量来进行排名，并选取使用量最多的 Pod 进行驱逐。所以即使 QoS 等级为 `Guaranteed` 的 Pod 在这个阶段也有可能被驱逐（例如 nodefs 使用量最大）。如果驱逐的是 `Daemonset`，kubelet 会阻止该 Pod 重启，直到 nodefs 可用量超过阈值。

> 如果一个 Pod 中有多个容器，kubelet 会根据 Pod 中所有容器的 nodefs 使用量之和来进行排名。即所有容器的 `container_fs_usage_bytes` 指标值之和。

### 举例 ###

<table> 
 <thead> 
  <tr> 
   <th style="text-align:left;">Pod Name</th> 
   <th style="text-align:left;">Pod QoS</th> 
   <th style="text-align:left;">nodefs usage</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:left;">A</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">800M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">B</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">1.3G</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">C</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">1.2G</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">D</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">700M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">E</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">500M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">F</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">1G</td> 
  </tr> 
 </tbody> 
</table>

当 nodefs 的使用量超过阈值时，kubelet 会根据 Pod 的 nodefs 使用量来对 Pod 进行排名，首先驱逐使用量最多的 Pod。排名如下图所示：

<table> 
 <thead> 
  <tr> 
   <th style="text-align:left;">Pod Name</th> 
   <th style="text-align:left;">Pod QoS</th> 
   <th style="text-align:left;">nodefs usage</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:left;">B</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">1.3G</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">C</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">1.2G</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">F</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">1G</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">A</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">800M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">D</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">700M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">E</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">500M</td> 
  </tr> 
 </tbody> 
</table>

## 内存资源不足 ##

下面是 kubelet 默认的关于节点内存资源的驱逐触发条件：

*  memory.available<100Mi

当内存使用量超过阈值时，kubelet 就会向 API Server 注册一个 MemoryPressure condition，此时 kubelet 不会接受新的 QoS 等级为 `Best Effort` 的 Pod 在该节点上运行，并按照以下顺序来驱逐 Pod：

*  Pod 的内存使用量是否超过了 `request` 指定的值
 *  根据 priority 排序，优先级低的 Pod 最先被驱逐
 *  比较它们的内存使用量与 `request` 指定的值之差。

按照这个顺序，可以确保 QoS 等级为 `Guaranteed` 的 Pod 不会在 QoS 等级为 `Best Effort` 的 Pod 之前被驱逐，但不能保证它不会在 QoS 等级为 `Burstable` 的 Pod 之前被驱逐。

> 如果一个 Pod 中有多个容器，kubelet 会根据 Pod 中所有容器相对于 request 的内存使用量与之和来进行排名。即所有容器的 （`container_memory_usage_bytes` 指标值与 `container_resource_requests_memory_bytes` 指标值的差）之和。

### 举例 ###

<table> 
 <thead> 
  <tr> 
   <th style="text-align:left;">Pod Name</th> 
   <th style="text-align:left;">Pod QoS</th> 
   <th style="text-align:left;">Memory requested</th> 
   <th style="text-align:left;">Memory limits</th> 
   <th style="text-align:left;">Memory usage</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:left;">A</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">700M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">B</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">1.9G</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">C</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">1Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">1.8G</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">D</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">1Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">800M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">E</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">300M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">F</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">1G</td> 
  </tr> 
 </tbody> 
</table>

当节点的内存使用量超过阈值时，kubelet 会根据 Pod 相对于 `request` 的内存使用量来对 Pod 进行排名。排名如下所示：

<table> 
 <thead> 
  <tr> 
   <th style="text-align:left;">Pod Name</th> 
   <th style="text-align:left;">Pod QoS</th> 
   <th style="text-align:left;">Memory requested</th> 
   <th style="text-align:left;">Memory limits</th> 
   <th style="text-align:left;">Memory usage</th> 
   <th style="text-align:left;">内存相对使用量</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:left;">C</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">1Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">1.8G</td> 
   <td style="text-align:left;">800M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">A</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">700M</td> 
   <td style="text-align:left;">700M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">E</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">0</td> 
   <td style="text-align:left;">300M</td> 
   <td style="text-align:left;">300M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">B</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">1.9G</td> 
   <td style="text-align:left;">-100M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">D</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">1Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">800M</td> 
   <td style="text-align:left;">-200M</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">F</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">2Gi</td> 
   <td style="text-align:left;">1G</td> 
   <td style="text-align:left;">-1G</td> 
  </tr> 
 </tbody> 
</table>

> 当内存资源不足时，kubelet 在驱逐 Pod 时只会考虑 requests 和 Pod 的内存使用量，不会考虑 limits。

## Node OOM (Out Of Memory) ##

因为 kubelet 默认每 `10` 秒抓取一次 cAdvisor 的监控数据，所以有可能在 kubelet 驱逐 Pod 回收内存之前发生内存使用量激增的情况，这时就有可能触发内核 OOM killer。这时删除容器的权利就由kubelet 转交到内核 OOM killer 手里，但 kubelet 仍然会起到一定的决定作用，它会根据 Pod 的 QoS 来设置其 `oom_score_adj` 值：

<table> 
 <thead> 
  <tr> 
   <th style="text-align:left;">QoS</th> 
   <th style="text-align:left;">oom_score_adj</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">-998</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">pod-infra-container</td> 
   <td style="text-align:left;">-998</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">kubelet, docker daemon, systemd service</td> 
   <td style="text-align:left;">-999</td> 
  </tr> 
 </tbody> 
</table>

如果该节点在 kubelet 通过驱逐 Pod 回收内存之前触发了 OOM 事件，OOM killer 就会采取行动来降低系统的压力，它会根据下面的公式来计算 `oom_score` 的值：

容器使用的内存占系统内存的百分比 + oom\_score\_adj = oom\_score>

OOM killer 会杀掉 `oom_score_adj` 值最高的容器，如果有多个容器的 `oom_score_adj` 值相同，就会杀掉内存使用量最多的容器（其实是因为内存使用量最多的容器的 oom\_score 值最高）。关于 OOM 的更多内容请参考：[Kubernetes 内存资源限制实战][Kubernetes]。

假设某节点运行着 4 个 Pod，且每个 Pod 中只有一个容器。每个 QoS 类型为 `Burstable` 的 Pod 配置的内存 requests 是 `4Gi`，节点的内存大小为 `30Gi`。每个 Pod 的 `oom_score_adj` 值如下所示：

<table> 
 <thead> 
  <tr> 
   <th style="text-align:left;">Pod Name</th> 
   <th style="text-align:left;">Pod QoS</th> 
   <th style="text-align:left;">oom_score_adj</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:left;">A</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">1000</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">B</td> 
   <td style="text-align:left;">Guaranteed</td> 
   <td style="text-align:left;">-998</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">C</td> 
   <td style="text-align:left;">Burstable</td> 
   <td style="text-align:left;">867（根据上面的公式计算）</td> 
  </tr> 
  <tr> 
   <td style="text-align:left;">D</td> 
   <td style="text-align:left;">Best Effort</td> 
   <td style="text-align:left;">1000</td> 
  </tr> 
 </tbody> 
</table>

当调用 OOM killer 时，它首先选择 `oom_score_adj` 值最高的容器（1000），这里有两个容器的 `oom_score_adj` 值都是 1000，OOM killer 最终会选择内存使用量最多的容器。

## 总结 ##

*  因为 kubelet 默认`每 10 秒抓取一次` cAdvisor 的监控数据，所以可能在资源使用量低于阈值时，kubelet 仍然在驱逐 Pod。
 *  kubelet 将 Pod 从节点上驱逐之后，Kubernetes 会将该 Pod 重新调度到另一个资源充足的节点上。但有时候 Scheduler 会将该 Pod 重新调度到与之前相同的节点上，比如设置了节点亲和性，或者该 Pod 以 Daemonset 的形式运行。

# 参考链接 #

[https://www.yangcs.net/posts/kubernetes-eviction/][https_www.yangcs.net_posts_kubernetes-eviction]

[https://cloud.tencent.com/developer/article/1097431][https_cloud.tencent.com_developer_article_1097431]

转载于:https://www.cnblogs.com/peitianwang/p/11588003.html

[1120683-20190925221419705-1306269431.png]: /images/20230810/3242008ece324311aa0bbfe0c17cab65.png
[1120683-20190925221500097-1302501517.png]: /images/20230810/e59ea587dc3e4235971fceab5275f2ca.png
[condition]: https://kubernetes.io/docs/concepts/architecture/nodes/#condition
[Kubernetes]: https://www.yangcs.net/posts/memory-limit-of-pod-and-oom-killer/
[https_www.yangcs.net_posts_kubernetes-eviction]: https://www.yangcs.net/posts/kubernetes-eviction/
[https_cloud.tencent.com_developer_article_1097431]: https://cloud.tencent.com/developer/article/1097431