kubenerte启动_Kubenertes资源分配之Request和Limit解析
Kubernetes是一个容器集群管理平台,Kubernetes需要统计整体平台的资源使用情况,合理地将资源分配给容器使用,并且要保证容器生命周期内有足够的资源来保证其运行。 同时,如果资源发放是独占的,即资源已发放给了个容器,同样的资源不会发放给另外一个容器,对于空闲的容器来说占用着没有使用的资源比如CPU是非常浪费的,Kubernetes需要考虑如何在优先度和公平性的前提下提高资源的利用率。为了实现资源被有效调度和分配同时提高资源的利用率,Kubernetes采用Request和Limit两种限制类型来对资源进行分配。
一、kubenerters中Request和Limit限制方式说明
Request: 容器使用的最小资源需求,作为容器调度时资源分配的判断依赖。只有当节点上可分配资源量>=容器资源请求数时才允许将容器调度到该节点。但Request参数不限制容器的最大可使用资源。
Limit: 容器能使用资源的资源的最大值,设置为0表示使用资源无上限。
Request能够保证Pod有足够的资源来运行,而Limit则是防止某个Pod无限制地使用资源,导致其他Pod崩溃。两者之间必须满足关系: 0<=Request<=Limit<=Infinity (如果Limit为0表示不对资源进行限制,这时可以小于Request)
在腾讯云容器服务(CCS)中,可以在创建服务,在容器编辑栏中点击显示高级设置,在高级设置中进行CPU和Memory的Request和Limit设置。目前CPU支持设置Request和Limit,用户可以根据业务的特点动态的调整Request和Limit的比例关系。Memory目前只支持设置Request,Limit必须强制等于Request,这样确保容器不会因为内存的使用量超过了Request但没有超过Limit的情况下被意外的Kill掉。
二、kubenerters中Request和Limit使用示例
一个简单的示例说明Request和Limit的作用,测试集群包括一个4U4G的节点。已经部署的两个Pod(1,2),每个Pod的资源设置为(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 2U, 1G,1G).
节点上CPU和内存的资源使用情况如下图所示:
已经分配的CPU资源为:1U(分配Pod1)+1U(分配Pod2)=2U,剩余可以分配的CPU资源为2U
已经分配的内存资源为:1G(分配Pod1)+1G(分配Pod2)=2G,剩余可以分配的内存资源为2G
所以该节点可以再部署一个(CPU Requst, Memory Requst)=(2U,2G)的Pod部署,或者部署2个(CPU Requst, Memory Requst)=(1U,2G)的Pod部署
在资源限制方面,每个Pod1和Pod2使用资源的上限为(2U,1G),即在资源空闲的情况下,Pod使用CPU的量最大能达到2U,使用内存的最大量为1G。从CPU资源的角度,对于资源使用上线为2U的Pod,通过设置Request为1U,实现了2倍数量的Pod的部署,提高了资源的使用效率。
另外一个复杂一点的例子来进一步说明Request和Limit的作用,主要说明Request和Limit都为0的Pod对提高资源使用率的作用。测试集群仍然包含有一个4U4G的Pod。集群中已经部署了四个Pod(1~4),每个Pod的资源设置为(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 2U, 512M,512M)。
此时节点上CPU和内存的资源使用情况如下图所示:
此时按照Request的需求,已经没有可以供分配的CPU资源。但由于Pod1~4业务负载比较低,造成节点上CPU使用率较低,造成了资源的浪费。这的时候可以通过将Request设置为0来实现对资源使用率的进一步提高。在此节点上部署4个资源限制为(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (0U, 0U, 512M,512M)。资源的使用情况如下图所示:
Pod(5~8)能够在Pod(1~4)空闲时,使用节点上剩余的CPU资源,从而进一步提高资源的使用率。
三、kubenerters中资源的抢占
Kubernetes中资源通过Request和Limit的设置,能够实现容器对资源的更高效的使用。在如果多个容器同时对资源进行充分利用,资源使用尽量的接近Limit。这个时候Node节点上的资源总量要小于所有Pod中Limit的总会,就会发生资源抢占。
对于资源抢占的情况,Kubernetes根据资源能不能进行伸缩进行分类,分为可压缩资源和不可以压缩资源。CPU资源--是现在支持的一种可压缩资源。内存资源和磁盘资源为现在支持的不可压缩资源。
可压缩资源的抢占策略---按照Requst的比值进行分配
例如在示例一种,假设在部署了Pod(1,2)的基础上,又部署了资源限制和Pod1相同的两个容器Pod(3,4)。这个时候,节点上的资源模型为。
假设四个Pod同时负载变高,CPU使用量超过1U,这个时候每个Pod将会按照各自的Request设置按比例分占CPU调度的时间片。在示例中,由于4个Pod设置的Request都为1U,发生资源抢占时,每个Pod分到的CPU时间片为1U/(1U×4),实际占用的CPU核数为1U。在抢占发生时,Limit的值对CPU时间片的分配为影响,在本例中如果条件容器Limit值的设置,抢占情况下CPU分配的比例保持不变。
不可压缩资源的抢占策略---按照优先级的不同,进行Pod的驱逐
对于不可压缩资源,如果发生资源抢占,则会按照优先级的高低进行Pod的驱逐。驱逐的策略为: 优先驱逐Request=Limit=0的Pod,其次驱逐0
由于对于不可压缩资源,发生抢占的情况会出Pod被意外Kill掉的情况,所以建议对于不可以压缩资源(Memory,Disk)的设置成0
针对内存抢占,本文进行了一次小的测试,示例中依次部署了Pod(1~3)单个Pod。节点中资源的示例图为:
步骤1: 部署Pod1,资源参数为(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (2U, 2U, 2G,2G),此时Pod1中进程使用1.9G内存,Pod1运行依然正常。
步骤2: 部署Pod2,资源参数为(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 1U, 1G,2G),此时Pod2中进程使用0.9G内存,程序运行正常。超过1G,小于2G时程序运行正常,但超过2G程序异常。
步骤3: 部署Pod3,资源参数为(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 1U, 0G,0)。此时保持Pod1中进程使用内存为1.9G,Pod2中内存使用为0.9G,pod3抢占内存,抢占内存大小为2G。这时,Pod3最先会出现因内存不足异常的情况。同时Pod2有时也会出现内存不足异常的情况。但Pod1一直能够正常运行
步骤4:修改Pod2的参数为(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 1U, 1G,1G),仍然保持步骤3中资源的使用量。这时Pod3仍然最先出现内存不足而异常的情况,但Pod1和Pod2一直运行正常。
更多关于不可压缩资源抢占时的资源回收策略,可以参考:
kubenerte启动_Kubenertes资源分配之Request和Limit解析相关推荐
- weblogic Rejecting request since max request parameter limit exceeded 10000
weblogic Rejecting request since max request parameter limit exceeded 10000 这个问题是由于前端提交到后端的参数个数溢出web ...
- SpringCloud之Eureka客户端服务启动报Cannot execute request on any known server解决
项目场景: 在练习SpringCloud时,Eureka客户端(client)出现报错:Cannot execute request on any known server 问题描述 正常启动Spri ...
- ros 启动建图/导航-- Request for map failed; trying again...
问题描述:在启动ros建图导航时,经常遇到request map类似的报错 [ INFO] [1632648620.520173473]: Requesting the map... [ WARN] ...
- 织梦的if(!defined('DEDEINC')) exit("Request Error!");解析
1 if(!defined('DEDEINC')) exit("Request Error!"); 细细看看你就会发现,这句代码一般都是在 /include 路径下的php文件里边 ...
- python发送request请求并解析返回的json
安装request库 post: Response = requests.post(url='http://zaxy.zjjy.xyz/socket/equipment/subRegions',dat ...
- idea 启动shorten command line too long 错误解析
因为项目启动的命令行太长了经常是带一些vm参数或者一些依赖jar idea提供了三种方式 Select a method that will be used to shorten the comman ...
- Alian解读SpringBoot 2.6.0 源码(三):启动流程分析之命令行参数解析
目录 一.背景 1.1.run方法整体流程 1.2.本文解读范围 二.默认应用参数解析 2.1.接口ApplicationArguments 2.2.实现类DefaultApplicationArgu ...
- python爬取网站的某一句话,python正则爬取某段子网站前20页段子(request库)过程解析...
import requests import re import json class NeihanSpider(object): """内涵段子,百思不得其姐,正则爬取 ...
- 浅析安全启动(Secure Boot)附带EFUSE解析
https://bbs.pediy.com/thread-260399.htm 所有支持 Secure Boot 的 CPU 都会有一块很小的一次性编程储存模块,我们称之为 FUSE 或者 eFUSE ...
最新文章
- 装逼一步到位!GauGAN代码解读来了
- 201521123079 《Java程序设计》第1周学习总结
- android 怎么加链接地址,Android TextView添加超链接的方法示例
- mysql用户名长度_如何增加PhpMyAdmin / mysql用户帐户的用户名长度?
- C# WinForm开发系列 - TextBox
- 法语语言考试C1,法语考试大比拼:专八与Dalf C1,哪个更难?
- golang中创建logger时候踩过的坑
- 对Java的URL类支持的协议进行扩展的方法
- python 删除特定行数据_怎么用 Python 做数据分析实例
- ARM 编译 phddns
- java异常处理试题答案_java试题及答案
- ASP.NET Trick文章系列--使用State Server管理Session状态的另类经济用法
- MathType初体验——一款很好用的数学公式输入工具
- Euraka学习笔记
- 模式识别与机器学习的关系
- Python爬虫实战, QQ空间自动点赞
- 火山视频抖音版批量下载,一个脚本就够了,手把手教你批量下载抖音火山高清视频。
- C# 生成订单编号和取餐码
- 忍者安全渗透系统(NINJITSU OS V3)的安装详细过程,亲测新旧vm版本都可安装,附带下载来源
- 智能家居正进化成人们想要的样子