k8s 详解之资源管理

资源模型

在 kubernetes 中，任何可以被申请、分配，最终被使用的对象，都是 kubernetes 中的资源，k8s 默认只支持 CPU 和内存的定义，后续可以通过 device plugin 来扩展其他资源的使用，比如 GPU。

可压缩资源和不可压缩资源

所有的资源类型，可以被划分为两大类：可压缩和不可压缩的。

可压缩：如果系统限制或者缩小容器对可压缩资源的使用的话，只会影响服务对外的服务性能，比如 CPU 就是一种非常典型的可压缩资源。如果容器的 CPU 使用草果了申请的上限， linux 会通过公平调度算法和 cgroups 对这个容器进行限速。限速行为并不会影响容器的运行，只是申请不到更多的 CPU 会让服务性能跟不上去。
对于不可压缩资源来说，资源的紧缺是有可能导致服务对外不可用的，比如内存就是一种非常典型的不可压缩资源。如果内存的使用超过了限制，就会触发 OOMKilled。因为它是不可压缩的资源，申请不到新的内存就会直接跪掉。
所以当资源超过了设置的值，会触发什么样的行为，都要看它属于什么资源类型以及 cgroups 如何对其进行处理。

资源申请

kubernetes 中 pod 对资源的申请是以容器为最小单位进行的，针对每个容器，它都可以通过如下两个信息指定它所希望的资源量：

resources:  
 requests:    
   cpu: 2.5   
   memory: "40Mi"  
 limits:     
   cpu: 4.0    
   memory: "99Mi"

request：可以理解为 k8s 为容器预留的资源量。即便容器没有实际使用到这些资源， k8s 也会为容器预留好这些资源，也就是说其他容器是无法申请这些资源的。
limit：可理解为 k8s 限制容器使用的资源上限。也就是限制容器在实际运行的时候不能超过的资源数值。如果容器使用的资源超过了这个值，就会触发后续对应的操作。对于 CPU 来说，由于 CPU 是可压缩资源，所以如果容器使用的 CPU 超过了 limit 设置的值，操作系统只会对其进行限速，不让容器的 cpu 使用量超过 limit。但对于内存这种不可压缩资源来说，如果内存的使用量超过了 limit 的值，则会触发 OOMKilled（我们在 k8s 中容器状态里有时候会看到容器的 last state 是 OOMKilled，表明上次重启是因为内存用超了）。

注意

k8s 在计算资源时是使用 request 字段进行计算的。一个 k8s 集群如果有 10 个 CPU 的资源。 POD A 申请 request：5，limit：10， POD B 申请 request 5，limit 10. 是可以申请成功的。而如果在启动一个 POD C 申请 request 5， limit 10. 就会失败（POD 处于 pending 状态，一直在等待资源释放）。因为 k8s 并不是按 limit 字段来计算资源用量而是使用 request 字段进行计算

request 字段的资源申请是一种逻辑概念上的申请。是 k8s 内部进行计算的，无法影响外部。比如还是上面的场景， A 和 B 申请的 request 已经把整个集群的 CPU 都沾满了，这时候通过 k8s 启动一个 POD 申请 CPU 肯定是不会成功的。但是不同过 k8s，比如使用原生 docker 命令或者通过 k8s 启动 pod 但是 request 和 limit 都设置为空（不申请资源，也就是这个 pod 可以使用当前节点的所有资源）去启动一个新的容器是可以成功的。所以 reqeust 字段的资源控制只存在于 k8s 中，并不是操作系统级别的资源申请。

limit 的资源限制是通过 cgroups 来进行限制的。每个 POD，每个容器都会在/sys/fs/cgroup 下留有对应的记录。

资源超卖

通过上面讲解的资源模型，我们就可以有一种常用的玩法：超卖。超卖的意思也就是说本来系统只有 10 个 CPU 的资源，但是容器 A，B，C，D 都各自需要申请 5 个 CPU 的资源，这明显不够用。但是我们又知道 A,B,C 不可能都在同一时刻都占满 5 个 CPU 的资源的，因为每个服务都是有它业务的高峰期和低谷期的。高峰期的时候可以占满 5 个 CPU，但是服务大部分都处于低谷期，可能只占用 1，2 个 CPU。所以如果直接写 request：5 的话，很多时候资源是浪费的（上面说过 k8s 里即便容器没有使用到那么多资源， k8s 也会为容器预留 request 字段的资源）。所以我们可以为容器申请这样的资源： request：2， limit：5. 这样上面 4 个容器加起来只申请了 8 个 CPU 的资源，而系统里有 10 个 CPU，是完全可以申请的到的。而每个容器的 limit 又设置成了 5，所以每个容器又都可以去使用 5 个 CPU 的资源。

注意

超卖的玩法赌的就是容器不会在同一时刻都处于高峰期，利用超卖来达到资源在进行限制的同时又能最大化的提高资源利用率。但是这种玩法比较容易玩脱，如果 request 的值设置的过于小，limit 的值设置的过于大，那么在业务高峰期把资源玩炸了的情况还是有可能的。毕竟我们经常能看到一个 k8s 节点上的 limit 资源总量超过 200%，甚至 300% 的。一旦这些容器的压力上来，这个节点就要炸了。所以在超卖场景中，对于 request 和 limit 具体要设置什么值是合理的，是需要一段时间的业务压测来验证并计算的。

一般设置 request 和 limit 的策略是，如果这个服务特别重要，容不得出半点闪失，那么 request 和 limit 的值要设置成一样的。保证这块资源一定会留给这个容器来使用（这里也涉及到驱逐策略，后面说）。如果这个服务不那么重要，可以 request 的值设置成这个服务的最小消耗量或者业务压力处于平稳期的资源用量，而 limit 设置为服务高峰期的值。如果这个服务本身占用的资源可以忽略不计，或者这个服务根本不重要，挂了就挂了。那可以把 reqeust 和 limit 都设置为 0，这样平时它可以肆意使用资源，但在资源紧俏的时候 k8s 的驱逐策略就会优先把这种服务驱逐掉节省资源。

ResourceQuota（资源配额）

k8s 有多种管理资源的策略，资源配合是其中一种，在 k8s 中 namespace 可以当做成一个租户。我们可以针对这个租户的资源用量进行限制。比如下面的配置定义。

apiVersion: v1
kind: Namespace
metadata:
  name: myspace
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: myspace
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

这个配置规定了在这个 namespace 下所有 pod 所能够使用的 reqeust 和 limit 的值的总和上线。一旦该 namespace 下所有 pod 申请的资源用量超过了这个值，部署 pod 的时候就会失败。当然 ResourceQuota 其实是比较复杂的，除了能够限制内存和 CPU，还可以限制 pod 的数量和 PV 的存储总量， PVC 的数量等等。比如：

requests.storage：所有 PVC，存储资源的需求总量不能超过该值。
persistentvolumeclaims：在该命名空间中所允许的 PVC 总量。
pods：在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 .status.phase in (Failed,Succeeded) 为真。
services：在该命名空间中允许存在的 Service 总数上限。

原文地址：https://blog.csdn.net/qq_49832677/article/details/129721399

k8s 详解之资源管理

目录

资源模型

ResourceQuota（资源配额）

相关推荐