Kuberntes 服务质量保证（QoS）

我就是我 2022-06-08 08:46 241阅读 0赞

【编者的话】Kubernetes做为目前主流的容器集群管理平台，需要整体统筹平台资源使用情况、公平合理的将资源分配给相关pod容器使用，并且要保证容器生命周期内有足够的资源来保证其运行。 与此同时，由于资源发放的独占性，即资源已经分配给了某容器，同样的资源不会在分配给其他容器，对于资源利用率相对较低的容器来说，占用资源却没有实际使用（比如CPU、内存）造成了严重的资源浪费，Kubernetes需从优先级与公平性等角度提高资源的利用率。为了实现资源被有效调度和分配的同时提高资源利用率，Kubernetes针对不同服务质量的预期，通过QoS来对pod进行服务质量管理，提供了个采用requests和limits两种类型对资源进行分配和使用限制。对于一个pod来说，服务质量体现在两个为2个具体的指标： CPU与内存。实际过程中，当NODE节点上内存资源紧张时，kubernetes会根据预先设置的不同QoS类别进行相应处理。

## 设置资源限制的原因 ##

如果未做过节点 nodeSelector，亲和性（node affinity）或pod亲和、反亲和性（pod affinity/anti-affinity）等[Pod高级调度策略][Pod] 设置，我们没有办法指定服务部署到指定机器上，如此可能会造成cpu或内存等密集型的pod同时分配到相同Node，造成资源竞争。另一方面，如果未对资源进行限制，一些关键的服务可能会因为资源竞争因OOM等原因被kill掉，或者被限制CPU使用。

## 资源需求（Requests）和限制（ Limits） ##

对于每一个资源，container可以指定具体的资源需求（requests）和限制（limits），requests申请范围是0到node节点的最大配置，而limits申请范围是requests到无限，即0 <= requests <=Node Allocatable, requests <= limits <= Infinity。  
对于CPU，如果pod中服务使用CPU超过设置的limits，pod不会被kill掉但会被限制。如果没有设置limits，pod可以使用全部空闲的cpu资源。  
对于内存，当一个pod使用内存超过了设置的limits，pod中container的进程会被kernel因OOM kill掉。当container因为OOM被kill掉时，系统倾向于在其原所在的机器上重启该container或本机或其他重新创建一个pod。

## QoS分类 ##

Kubelet提供QoS服务质量管理，支持系统级别的OOM控制。在Kubernetes中，pod的QoS级别：Guaranteed, Burstable与 Best-Effort。下面对各级别分别进行相应说明：  
Guaranteed：pod中所有容器都必须统一设置limits，并且设置参数都一致，如果有一个容器要设置requests，那么所有容器都要设置，并设置参数同limits一致，那么这个pod的QoS就是Guaranteed级别。  
注：如果一个容器只指明limit而未设定request，则request的值等于limit值。  
Guaranteed举例1：容器只指明了limits而未指明requests）。

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

Guaranteed举例2：requests与limit均指定且值相等。

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

Burstable: pod中只要有一个容器的requests和limits的设置不相同，该pod的QoS即为Burstable。举例如下：  
Container bar没有指定resources

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

Burstable举例2：对Container foo与bar不同的resources（foo为memory，而bar为cpu）设置了limits。

containers:
    name: foo
    resources:
      limits:
        memory: 1Gi
    
    name: bar
    resources:
      limits:
        cpu: 100m

Burstable举例3：Container foo没有设置limits，而bar requests与 limits均未设置。

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

Best-Effort：如果对于全部的resources来说requests与limits均未设置，该pod的QoS即为Best-Effort。举例如下：

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

## 可压缩资源与不可压缩资源 ##

Kubernetes根据资源能否伸缩进行分类，划分为可压缩资源和不可以压缩资源2种。CPU资源是目前支持的一种可压缩资源，而内存资源和磁盘资源为目前所支持的不可压缩资源。

## QoS优先级 ##

3种QoS优先级从有低到高（从左向右）：

Best-Effort pods -> Burstable pods -> Guaranteed pods

## 静态pod ##

在Kubernetes中有一种DaemonSet类型pod，此类型pod可以在某个节点上长期运行，由该节点上的kubelet服务直接管理，无需api server介入，静态pod也无需关联任何RC，完全是由kubelet服务来监控，当kubelet发现静态pod停止时，kubelet会重新启动静态pod。

## 资源回收策略 ##

当kubernetes集群中某个节点上可用资源比较小时，kubernetes提供了资源回收策略来保证节点以此pod中服务正常运行。当节点上的内存或者CPU资源耗尽时，调度到该节点上运行的pod服务可能会不稳定。Kubernetes通过kubelet来进行回收策略控制，保证节点上POD在节点资源比较小时可以稳定运行。

可压缩资源CPU：在压缩资源部分已经提到CPU属于可压缩资源，当pod使用超过设置的limits值，pod中进程使用cpu会被限制，但不会被kill。

不可压缩资源内存：当Node 内存资源不足时，那么就会有进程因OOM会被kernel kill掉，3种QoS pods被kill掉的顺序与场景如下：

*  Best-Effort 类型的pods：系统用完了全部内存时，该类型pods会最先被kill掉。
 *  Burstable类型pods：系统用完了全部内存，且没有Best-Effort container可以被kill时，该类型pods会被kill掉。
 *  Guaranteed pods：系统用完了全部内存、且没有Burstable与Best-Effort container可以被kill，该类型的pods会被kill掉。

注：如果pod进程因使用超过预先设定的limites而非Node资源紧张情况，系统倾向于在其原所在的机器上重启该container或本机或其他重新创建一个pod。

## 使用建议 ##

*  如果资源充足，可将QoS pods类型均设置为Guaranteed。用计算资源换业务性能和稳定性，减少排查问题时间和成本。
 *  如果想更好的提高资源利用率，业务服务可以设置为Guaranteed，而其他服务根据重要程度可分别设置为Burstable或Best-Effort，例如filebeat。

### 已知问题 ###

不支持Swap

## 参考资料 ##

Resource Quality of Service in Kubernetes: [https://github.com/kubernetes/ … os.md][https_github.com_kubernetes_ _ os.md]  
Introduction to Quality Of Service and Service Level Agreement: [http://www.loriotpro.com/Produ … N.htm][http_www.loriotpro.com_Produ _ N.htm]  
Kubelet pod level resource management: [https://github.com/kubernetes/ … nt.md][https_github.com_kubernetes_ _ nt.md]

Kubelet – Eviction Policy: [https://github.com/kubernetes/ … on.md][https_github.com_kubernetes_ _ on.md]

作者：[FreeWheel Lead Engineer 张夏][FreeWheel Lead Engineer]

[Kuberntes 服务质量保证（QoS）][Kuberntes _QoS]

[Pod]: https://www.kubernetes.org.cn/2614.html
[https_github.com_kubernetes_ _ os.md]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md
[http_www.loriotpro.com_Produ _ N.htm]: http://www.loriotpro.com/Products/On-line_Documentation_V5/LoriotProDoc_EN/T20-Quality_of_Service/T20-A1_Quality_of_Service_EN.htm
[https_github.com_kubernetes_ _ nt.md]: https://github.com/kubernetes/community/blob/72f87813b4c64d5ee8ac829f70edee2159871b6b/contributors/design-proposals/pod-resource-management.md
[https_github.com_kubernetes_ _ on.md]: https://github.com/kubernetes/community/blob/72f87813b4c64d5ee8ac829f70edee2159871b6b/contributors/design-proposals/kubelet-eviction.md
[FreeWheel Lead Engineer]: https://www.kubernetes.org.cn/author/summer
[Kuberntes _QoS]: https://www.kubernetes.org.cn/2545.html