requests与limits
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
containers:
- image: xxx
resources:
requests:
cpu: 200m
memory: 10Mi
limits:
cpu: 500m
memory: 50Mi
requests会作为调度的一个考虑因素。调度器只会将节点上已调度的pod的request资源总和作为消耗的资源,不会考虑节点当前的资源使用情况。若节点剩余的资源能满足新pod的资源要求,则新pod可以被调度到该节点。
若pod申请的内存资源超过limit的限制,将会OOM,从而导致pod失败。另外,从容器内获取到的系统cpu和内存量,都是节点的资源使用情况,需要谨慎使用,尤其是在通过查询系统CPU核心数来决定启动的线程数量时。此时,可以通过Downward API传递CPU限额,或者通过cgroup系统直接获取配置的CPU限额,查看
/sys/fs/cgroup/cpu/cpu.fs_quota_us和/sys/fs/cgroup/cpu/cpu.fs_period_us
pod的QoS等级
根据pod所包含的容器的资源requests和limits的配置计算得到。
- BestEffort: 优先级最低,会分配给那些没有设置任何requests和limits的pod。它可以使用所用cpu时间,也可能获取不到cpu时间,在需要杀掉pod时,会第一批被杀死。
- Burstable: 除BestEffort和Guaranteed外,其他都是这种等级
- Guaranteed: CPU和内存都要设置requests和limits,每个容器都要设置资源量,requests和limits必须相等。
当需要杀掉pod时,BestEffort先于Burstable先于Guaranteed。
若相同等级的pod,则会考虑OOM分数值,它与两个因素有关:
- 进程已消耗内存占request内存的百分比
- 一个基于pod QoS等级和容器内存申请量固定的OOM分数调节因子。
系统会首先杀掉内存实际使用量占内存申请量比例更高的pod。
容器的QoS等级计算表
CPU requests vs. limits | 内存的requests vs. limits | 容器的QoS等级 |
未设置 | 未设置 | BestEffort |
未设置 | Requests < Limits | Burstable |
未设置 | Requests = Limits | Burstable |
Requests < Limits | 未设置 | Burstable |
Requests < Limits | Requests < Limits | Burstable |
Requests < Limits | Requests = Limits | Burstable |
Requests = Limits | Requests = Limits | Guaranteed |
pod的QoS等级计算表
容器1的QoS等级 | 容器2的QoS等级 | pod的QoS等级 |
BestEffort | BestEffort | BestEffort |
BestEffort | Burstable | Burstable |
BestEffort | Guaranteed | Burstable |
Burstable | Burstable | Burstable |
Burstable | Guaranteed | Burstable |
Guaranteed | Guaranteed | Guaranteed |
命名空间级的资源限制
为命名空间中的pod设置默认的requests和limits
apiVersion: v1
kind: LimitRange
metadata:
name: example
spec:
limits:
- type: Pod
min:
cpu: 50m
memory: 5Mi
max:
cpu: 1
memory: 100Mi
- type: Container
defaultRequest: # 默认requests
cpu: 50m
memory: 5Mi
default: # 默认limits
cpu: 500m
memory: 50Mi
min:
cpu: 50m
memory: 5Mi
max:
cpu: 1
memory: 100Mi
maxLimitRequestRatio: # request与limits的最大比值
cpu: 4
memory: 10
- type: PersistentVolumeClaim
min:
storage: 10Gi
max:
storage: 100Gi
为命名空间设置资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
name: resource-test
spec:
scopes: # 可以配置该ResourceQuota对象应用的范围
- BestEffort
- NotTerminating
hard:
requests.cpu: 400m
requests.memory: 200Mi
limits.cpu: 1
limits.memory: 500Mi
requests.storage: 500Gi
ssd.storageclass.storage.k8s.io/requests.storage: 300Gi # 为单独的StorageClass设置存储配额
pods: 10 # 可以配置对象的创建个数限制
replicationcontrollers: 5
secrets:10
services: 20
services.loadbalancers: 1
services.nodeports:5
Quota可以被一组quota scopes限制,当前有如下4种范围:BestEffort, NotBestEffort, Terminating, NotTerminating.
BestEffort和NotBestEffort决定配额是否应用于BestEffort等级或者其他两种等级。
Terminating和NotTerminating: 实际上并不应用于处在(或不处在)停止过程中的pod,而是指pod中有没有配置activeDeadlineSeconds,Terminating应用于配置了该参数的pod。activeDeadlineSeconds定义了一个pod从开始尝试停止到真正停止之前,允许其在节点上继续运行的秒数。