k8s中的资源配置

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分数值，它与两个因素有关：

1. 进程已消耗内存占request内存的百分比
2. 一个基于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从开始尝试停止到真正停止之前，允许其在节点上继续运行的秒数。