Kubernetes Resource QoS Classes介绍

基本概念

Kubernetes根据Pod中Containers Resource的request和limit的值来定义Pod的QoS Class。其中，指定容器request，代表系统确保能够提供的资源下限值。指定容器limit，代表系统允许提供的资源上限值。

Pods需要保证长期稳定运行需要设定“确保运行的最少资源”，然而pod能够使用的资源经常是不能确保的。

通常，Kubernetes通过设置request和limit的值来指定超卖比例，进而提升资源利用率。K8S的调度基于request，而不是limit。Borg通过使用“non-guranteed”的资源，提升了20%的资源利用率。

在一个资源被“超卖”的系统(总limits > machine capacity)，容器在资源被耗尽的情况下会被kill。理想情况是那些“不重要”的容器先被kill。

对于每一种Resource都可以将容器分为3中QoS Classes: Guaranteed, Burstable, and Best-Effort，它们的QoS级别依次递减。K8S底层实际上是通过 limit和request值来实现不同等级QoS的划分。

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

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

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

 name: bar
 resources:
 limits:
 cpu: 100m
 memory: 100Mi
 requests:
 cpu: 100m
 memory: 100Mi

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

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

• Burstable 除了符合Guaranteed和Best-Effort的场景，其他场景的Pod QoS Class都属于Burstable。 当limit值未指定时，其有效值其实是对应Node Resource的Capacity。

Examples: 容器bar没有对Resource进行指定。

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

 name: bar

容器foo和bar对不同的Resource进行了指定。

containers:
 name: foo
 resources:
 limits:
 memory: 1Gi

 name: bar
 resources:
 limits:
 cpu: 100m

容器foo未指定limit，容器bar未指定request和limit。

containers:
 name: foo
 resources:
 requests:
 cpu: 10m
 memory: 1Gi

 name: bar

可压缩/不可压缩资源的区别

kube-scheduler调度时，是基于Pod的request值进行Node Select完成调度的。Pod和它的所有Container都不允许Consume limit指定的有效值(if have)。

request和limit如何生效，依赖于资源是否是压缩的

可压缩资源的保证

• 目前仅支持CPU。
• Pods确保可以获取请求的CPU总量，但并不能获得额外的CPU时间。这并不能完全确保容器能够用到设置的资源下限值，因为CPU隔离是容器级别的。之后会引入Pod级别的cgroups资源隔离来解决这个问题。
• 过量/竞争使用CPU资源，会基于CPU request设置。可通过cpu.share来分派不同比例的时间片来理解，如果某个容器A的request 设置为600 milli，容器B设置为300mili , 两者竞争CPU时间时，通过2：1的比例来分配。
• 如果达到Pod CPU资源limit上限，CPU会减速（throttled)，而不是kill pod。如果pod没有设置limit上限，pods可以使用超过CPU limit上限。

不可压缩资源的保证

• 目前仅支持内存。
• Pods可以拿到requests设置的内存总量。如果某个pod超过memory request值，当其他pod需要内存时，这个pod可能被kill掉。但是如果pods使用内存少于request值，它们不会被kill，除非系统任务或daemon需要更多资源。（说白了，还是要看触发oom killer时，遍历系统上所有进程打分的情况。）
• 当Pods使用内存超过了limit，某个在pod中容器内进程使用了大量内存，则该进程会被内核kill掉.

管理和调度策略

• Pods由kubelet 确认和 scheduler 调度，会基于分配给容器的requests值，确保所有容器的requests总量在Node可分配容量的范围之内。https://github.com/fabric8io/jenkinshift/blob/master/vendor/k8s.io/kubernetes/docs/proposals/node-allocatable.md

如何根据不同的QoS回收Resources

• CPU 当CPU使用不能达到request值，比如系统任务和daemons使用了大量CPU，则Pods不会被kill，CPU效率会下降（throttled）。
• Memory 内存是不可压缩资源，从内存管理的角度做如下区分：
  • Best-Effort pods 优先级最低。如果系统内存耗尽，该类型的pods中的进程最先被kill。这些容器可以使用系统上任意量的空闲内存。
  • Guaranteed pods 优先级最高。它们能够确保不达到容器设置的limit上限一定不会被kill。只有在系统存在内存压力且没有更低优先级容器时才被驱逐。
  • Burstable pods 有一些形式的最小资源保证，但当需要时可以使用更多资源。在系统存在内存瓶颈时，一旦内存超过他们的request值并且没有Best-Effort 类型的容器存在，这些容器就先被kill掉。

Node上的OOM Score 配置

Pod OOM 打分配置

mm/oom_kill.c 中的badness()给每个进程一个OOM score，更高OOM得分的进程更容易被kill。得分取决于：

• 主要是看进程的内存消耗情况，包括驻留内存、pagetable和swap的使用
  • 一般是内存耗费的百分比*10（percent-times-ten）
• 参考用户权限，比如root权限启动的进程，打分会减少30。
• OOM打分因子：/proc/pid/oom_score_adj (加减) 和 /proc/pid/oom_adj（乘除）
  • oom_adj： -15～ 15的系数调整
  • oom_score_adj：oom_score会加上oom_score_adj这个值
  • 最终oom score的值 还是在 0～1000

这里提供一个计算系统上oom_score分数TPO10进程（最容易被oom killer杀掉的进程）脚本：

# vim oomscore.sh #!/bin/bash for proc in $(find /proc -maxdepth 1 -regex '/proc/[0-9]+'); do printf "%2d %5d %s\n" \
 "$(cat $proc/oom_score)" \
 "$(basename $proc)" \
 "$(cat $proc/cmdline | tr '\0' ' ' | head -c 50)" done 2>/dev/null | sort -nr | head -n 10

以下是几种K8S QoS 等级的OOM score：

Best-effort

• Set OOM_SCORE_ADJ: 1000
• 所以best-effort容器的OOM_SCORE 值为1000

Guaranteed

• Set OOM_SCORE_ADJ: -998
• 所以guaranteed容器的OOM_SCORE 值为0 或 1

Burstable

• 如果总的memory request 大于 99.9%的可用内存，OOM_SCORE_ADJ设置为 2。否则， OOM_SCORE_ADJ = 1000 - 10 * (% of memory requested)，这确保了burstable的 POD OOM_SCORE > 1
• 如果memory request设置为0，OOM_SCORE_ADJ 默认设置为999。所以如果burstable pods和guaranteed pods冲突时，前者会被kill。
• 如果burstable pod使用的内存少于request值，那它的OOM_SCORE < 1000。如果best-effort pod和这些 burstable pod冲突时，best-effort pod会先被kill掉。
• 如果 burstable pod容器中进程使用比request值的内存更多，OOM_SCORE设置为1000。反之，OOM_SCORES少于1000。
• 在一堆burstable pod中，使用内存超过request值的pod，优先于内存使用少于request值的pod被kill。
• 如果 burstable pod 有多个进程冲突，则OOM_SCORE会被随机设置，不受“request & limit”限制。

Pod infra containers or Special Pod init process

• OOM_SCORE_ADJ: -998

Kubelet, Docker

• OOM_SCORE_ADJ: -999 (won’t be OOM killed)
• 系统上的关键进程，如果和guranteed 进程冲突，则会优先被kill 。将来会被放到一个单独的cgroup中，并且限制内存。

已知的issue和潜在优化点

• 支持swap: 当前QoS策略默认swap关闭。如果开启swap，那些guaranteed 容器资源使用达到limit值，还可以使用磁盘来提供内存分配。最终，当swap空间不够时，pod中的进程才会被kill.此时，node需要在提供隔离策略时，把swap空间考虑进去。
• 提供用户指定优先级：用户让kubelet指定哪些tasks可以被kill.

源码分析

QoS的源码位于：pkg/kubelet/qos，代码非常简单，主要就两个文件pkg/kubelet/qos/policy.go,pkg/kubelet/qos/qos.go。 上面讨论的各个QoS Class对应的OOM_SCORE_ADJ定义在：

pkg/kubelet/qos/policy.go:21 const (
 PodInfraOOMAdj int = -998
 KubeletOOMScoreAdj int = -999
 DockerOOMScoreAdj int = -999
 KubeProxyOOMScoreAdj int = -999
 guaranteedOOMScoreAdj int = -998
 besteffortOOMScoreAdj int = 1000
)

容器的OOM_SCORE_ADJ的计算方法定义在：

pkg/kubelet/qos/policy.go:40 func GetContainerOOMScoreAdjust(pod *v1.Pod, container *v1.Container, memoryCapacity int64) int {
 switch GetPodQOS(pod) {
 case Guaranteed:
 // Guaranteed containers should be the last to get killed. return guaranteedOOMScoreAdj
 case BestEffort:
 return besteffortOOMScoreAdj
 }

 // Burstable containers are a middle tier, between Guaranteed and Best-Effort. Ideally, // we want to protect Burstable containers that consume less memory than requested. // The formula below is a heuristic. A container requesting for 10% of a system's // memory will have an OOM score adjust of 900. If a process in container Y // uses over 10% of memory, its OOM score will be 1000. The idea is that containers // which use more than their request will have an OOM score of 1000 and will be prime // targets for OOM kills. // Note that this is a heuristic, it won't work if a container has many small processes.
 memoryRequest := container.Resources.Requests.Memory().Value()
 oomScoreAdjust := 1000 - (1000*memoryRequest)/memoryCapacity
 // A guaranteed pod using 100% of memory can have an OOM score of 10. Ensure // that burstable pods have a higher OOM score adjustment. if int(oomScoreAdjust) < (1000 + guaranteedOOMScoreAdj) {
 return (1000 + guaranteedOOMScoreAdj)
 }
 // Give burstable pods a higher chance of survival over besteffort pods. if int(oomScoreAdjust) == besteffortOOMScoreAdj {
 return int(oomScoreAdjust - 1)
 }
 return int(oomScoreAdjust)
}

获取Pod的QoS Class的方法为：

pkg/kubelet/qos/qos.go:50 // GetPodQOS returns the QoS class of a pod. // A pod is besteffort if none of its containers have specified any requests or limits. // A pod is guaranteed only when requests and limits are specified for all the containers and they are equal. // A pod is burstable if limits and requests do not match across all containers. func GetPodQOS(pod *v1.Pod) QOSClass {
 requests := v1.ResourceList{}
 limits := v1.ResourceList{}
 zeroQuantity := resource.MustParse("0")
 isGuaranteed := true for _, container := range pod.Spec.Containers {
 // process requests for name, quantity := range container.Resources.Requests {
 if !supportedQoSComputeResources.Has(string(name)) {
 continue
 }
 if quantity.Cmp(zeroQuantity) == 1 {
 delta := quantity.Copy()
 if _, exists := requests[name]; !exists {
 requests[name] = *delta
 } else {
 delta.Add(requests[name])
 requests[name] = *delta
 }
 }
 }
 // process limits
 qosLimitsFound := sets.NewString()
 for name, quantity := range container.Resources.Limits {
 if !supportedQoSComputeResources.Has(string(name)) {
 continue
 }
 if quantity.Cmp(zeroQuantity) == 1 {
 qosLimitsFound.Insert(string(name))
 delta := quantity.Copy()
 if _, exists := limits[name]; !exists {
 limits[name] = *delta
 } else {
 delta.Add(limits[name])
 limits[name] = *delta
 }
 }
 }

 if len(qosLimitsFound) != len(supportedQoSComputeResources) {
 isGuaranteed = false
 }
 }
 if len(requests) == 0 && len(limits) == 0 {
 return BestEffort
 }
 // Check is requests match limits for all resources. if isGuaranteed {
 for name, req := range requests {
 if lim, exists := limits[name]; !exists || lim.Cmp(req) != 0 {
 isGuaranteed = false break
 }
 }
 }
 if isGuaranteed &&
 len(requests) == len(limits) {
 return Guaranteed
 }
 return Burstable
}

PodQoS会在eviction_manager和scheduler的Predicates阶段被调用，也就说会在k8s处理超配和调度预选阶段中被使用。

本文转自开源中国-