Kubernetes对资源的限制

2023-10-04 21:14:04

配置容器资源限制

对于一个pod来说，资源最基础的2个的指标就是：CPU和内存。
Kubernetes提供了个采用requests和limits 两种类型参数对资源进行预分配和使用限制。
limit 会限制pod的资源利用：

当pod 内存超过limit时，会被oom。
当cpu超过limit时，不会被kill，但是会限制不超过limit值。

其中，CPU 有2个限制：

requests：相对限制，是容器的最低申请资源，这个限制是相对的，无法做到绝对严格。
limits：绝对限制，这个是限制的绝对的，不可能超越。

举例：

apiVersion: v1
kind: Pod
metadata:
name: cpu-overload
namespace: default
spec:
containers:
- name: cpu-overload
image: nginx
resources:
limits:
cpu: "2"
memory: 1000Mi
requests:
cpu: "1"
memory: 500Mi

注：limits是对资源的总限制、requests是最低分配的资源。requests一般要比limits要小一些。

对容器 cpu-overload 的 CPU 的限制，是，申请1个核的运算资源，最多可以使用2个核。

这里需要特别说明一点，所谓的最多2个核，其实是均摊的，如果这个容器真的触发了计算瓶颈，在docker中看，CPU使用率是200%，但在宿主机去看，其实并非是将2个核占满了，而是将压力分摊到了多个CPU的核上。

查看资源情况
kubectl describe pod cpu-overload

容器服务质量（QoS）

Kubernetes 提供服务质量管理，根据容器的资源配置，将pod 分为Guaranteed, Burstable, BestEffort 3个级别。当资源紧张时根据分级决定调度和驱逐策略，这三个分级分别代表：

Guaranteed： pod中所有容器都设置了limit和request，并且相等（设置limit后假如没有设置request会自动设置为limit值）
Burstable： pod中有容器未设置limit，或者limit和request不相等。这种类型的pod在调度节点时，可能出现节点超频的情况。
BestEffort： pod中没有任何容器设置request和limit。

当节点内存不足时，QoS为Guaranteed 的pod 最后被kill。而BestEffort 级别的pod优先被kill。其次是Burstable，根据计算公式 oom_score_adj 值范围2到999，设置的request越大，oom_score_adj越低，oom时保护程度越高。

pod 驱逐：

当节点的内存和cpu资源不足，开始驱逐节点上的pod时。QoS同样会影响驱逐的优先级。顺序如下：

kubelet 优先驱逐 BestEffort的pod 和实际占用资源大于requests的Burstable pod。

接下来驱逐实际占用资源小于request的Burstable pod。
QoS为Guaranteed的pod最后驱逐， kubelet 会保证Guaranteed的pod 不会因为其他pod的资源消耗而被驱逐。
当QoS相同时，kubelet 根据Priority计算驱逐的优先级

ResourceQuota

Kubernetes提供ResourceQuota对象，用于配置限制namespace内的每种类型的k8s对象数量和资源（cpu，内存）。

一个namespace中可以创建一个或多个ResourceQuota
如果namespace中配置了ResourceQuota，部署时必须设置request和limit，否则会拒绝创建请求。
可以通过这是limitRange配置每个pod默认的requests和limits避免上述问题

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
  namespace: example
spec:
  hard:
    requests.cpu: "3"
    requests.memory: 1Gi
    limits.cpu: "5"
    limits.memory: 2Gi
    pods: "5"

LimitRange

LimitRange 是用来设置 namespace 中 Pod 的默认的资源 request 和 limit 值，以及大小范围。

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
  namespace: example
spec:
  limits:
  - default:  # default limit
      memory: 512Mi
      cpu: 2
    defaultRequest:  # default request
      memory: 256Mi
      cpu: 0.5
    max:  # max limit
      memory: 800Mi
      cpu: 3
    min:  # min request
      memory: 100Mi
      cpu: 0.3
    maxLimitRequestRatio:  # max value for limit / request
      memory: 2
      cpu: 2
    type: Container # limit type, support: Container / Pod / PersistentVolumeClaim

limitRange支持的参数如下：

default 代表默认的limit
defaultRequest 代表默认的request
max 代表limit的最大值
min 代表request的最小值
maxLimitRequestRatio 代表 limit / request的最大值。由于节点是根据pod request 调度资源，可以做到节点超卖，maxLimitRequestRatio 代表pod最大超卖比例。

总结

Kubernetes 提供request 和 limit 两种方式设置容器资源。
为了提高资源利用率，k8s调度时根据pod 的request值计算调度策略，从而实现节点资源超卖。
k8s根据limit限制pod使用资源，当内存超过limit时会触发oom。且限制pod的cpu 不允许超过limit。
根据pod的 request和limit，k8s会为pod 计算服务质量，并分为Guaranteed, Burstable, BestEffort 这3级。当节点资源不足时，发生驱逐或者oom时， Guaranteed 级别的pod 优先保护， Burstable 节点次之（request越大，使用资源量越少保护级别越高）， BestEffort 最先被驱逐。
Kubernetes提供了RequestQuota和LimitRange 用于设置namespace 内pod 的资源范围和规模总量。 RequestQuota 用于设置各种类型对象的数量， cpu和内存的总量。 LimitRange 用于设置pod或者容器 request和limit 的默认值，最大最小值，以及超卖比例（limit / request）。
对于一些重要的线上应用，我们应该合理设置limit和request，limit和request 设置一致，资源不足时k8s会优先保证这些pod正常运行。
为了提高资源利用率。对一些非核心，并且资源不长期占用的应用，可以适当减少pod的request，这样pod在调度时可以被分配到资源不是十分充裕的节点，提高使用率。但是当节点的资源不足时，也会优先被驱逐或被oom kill。

码农公寓

配置容器资源限制

容器服务质量（QoS）

pod 驱逐：

ResourceQuota

LimitRange

总结

相关文章