Kuberntes 服务质量保证(QoS)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: Kubernetes做为目前主流的容器集群管理平台,需要整体统筹平台资源使用情况、公平合理的将资源分配给相关pod容器使用,并且要保证容器生命周期内有足够的资源来保证其运行。 与此同时,由于资源发放的独占性,即资源已经分配给了某容器,同样的资源不会在分配给其他容器,对于资源利用率相对较低的容器来说,占用资源却没有实际使用(比如CPU、内存)造成了严重的资源浪费,Kubernetes需从优先级与公平性等角度提高资源的利用率。

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


设置资源限制的原因

如果未做过节点 nodeSelector,亲和性(node affinity)或pod亲和、反亲和性(pod affinity/anti-affinity)等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, BurstableBest-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:requestslimit均指定且值相等。

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中只要有一个容器的requestslimits的设置不相同,该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 requestslimits均未设置。

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

name: bar

Best-Effort:如果对于全部的resources来说requestslimits均未设置,该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,而其他服务根据重要程度可分别设置为BurstableBest-Effort,例如filebeat。

已知问题

不支持Swap

本文转自中文社区-Kuberntes 服务质量保证(QoS)

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
3月前
|
监控 负载均衡 算法
如何确保网络的服务质量 (QoS)
【8月更文挑战第24天】
60 0
|
缓存 网络协议 网络性能优化
QOS(服务质量)
QOS(服务质量)
413 0
|
存储 缓存 安全
服务访问质量(QoS)介绍与技术 一
1、QoS(Quality of Service,服务质量)指一个网络能够利用各种基础技术,为指定的网 络通信提供更好的服务能力,是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题 的一种技术。 2、QoS的保证对于容量有限的网络来说是十分重要的,特别是对于流多媒体应用,例如Vo IP和IPTV等,因为这些应用常常需要固定的传输率,对延时也比较敏感
441 1
服务访问质量(QoS)介绍与技术 一
|
网络协议 算法 应用服务中间件
服务访问质量(QoS)介绍与技术 二
一 QoS服务的重点 网络拥塞的产生 数据从高高速端口进入 低速端口出去 流量汇聚 网络拥塞的影响 报文延迟 抖动和丢包 增加网络负担 降低网络吞吐量
336 0
服务访问质量(QoS)介绍与技术 二
EMQ
|
存储 消息中间件 传感器
MQTT QoS 设计:车联网平台消息传输质量保障
在本篇文章中,我们将借助 MQTT 协议的 QoS 特性,介绍车联网场景中的 MQTT 消息 QoS 设计,保障数据传输质量。
EMQ
384 0
MQTT QoS 设计:车联网平台消息传输质量保障
|
缓存 数据挖掘 网络性能优化
QOS技术
在晋通的网络甲,当用尸将数据发问网络设备后,网络设备都是尽最大努力传输数据,直到超出自己的最大负荷为止。当设备达到最大负荷后,如果还有用户发来的数据,那么这些数据将因为网络设备不能提供服务而被丢弃。这样的提供最大化服务的网络被称为尽力而为服务的网络。在尽力而为服务的网络中,所有的数据都被看成是同等重要的,用户的数据有时无法得到保证,所以在某些时候,必须让网络通过放弃传输相对不重要的数据来保证用户的重要数据和传输。因此,就需要在网络中实施QualityofService,即QOS。实施了QOS的网络中,可以为特定数据保证带宽,同时也可以限制宽带,可以避免网络拥塞和管理拥塞,甚至可以为数据设置不同
225 0
|
网络性能优化 调度
|
网络性能优化 调度 网络架构