Kuberntes 服务质量保证(QoS)
Kubernetes做为目前主流的容器集群管理平台,需要整体统筹平台资源使用情况、公平合理的将资源分配给相关pod容器使用,并且要保证容器生命周期内有足够的资源来保证其运行。 与此同时,由于资源发放的独占性,即资源已经分配给了某容器,同样的资源不会在分配给其他容器,对于资源利用率相对较低的容器来说,占用资源却没有实际使用(比如CPU、内存)造成了严重的资源浪费,Kubernetes需从优先级与公平性等角度提高资源的利用率。为了实现资源被有效调度和分配的同时提高资源利用率,Kubernetes针对不同服务质量的预期,通过QoS来对pod进行服务质量管理,提供了个采用requests和limits两种类型对资源进行分配和使用限制。对于一个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, 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
本文转自中文社区-Kuberntes 服务质量保证(QoS)
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
kubernetes落地 |不捧不踩,国外公司向Kubernetes迁移实践
Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。 1 Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。 这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。 那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。 The Problem 问题 今年早些时候,我们开始对Sematext云进行...
- 下一篇
Kubernetes 的证书认证
今天让我们聊聊 Kubernetes 的公私钥和证书认证。 本文内容会提及如何根据需要对 CA、公私钥进行组织并对集群进行设置。 Kubernetes 的组件中有很多不同的地方可以放置证书之类的东西。在进行集群安装的时候,我感觉有一百多亿个不同的命令参数是用来设置证书、密钥的,真不明白是怎么弄到一起工作的。 当然了,没有一百亿那么多的参数,不过的确很多的。比如 API Server 的参数吧,有大概 16 个参数是跟这些东西有关的(下面是节选): --cert-dir string The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes") --client-ca-file string If set, any request presenting a client certificate signed by one ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2全家桶,快速入门学习开发网站教程