云南大学做行测的网站,视频运营管理平台,数据图表展示网站,app下载安装官方免费关于资源管理#xff0c;我们会从计算机资源管理#xff08;Computer Resources#xff09;、服务质量管理#xff08;Qos#xff09;、资源配额管理#xff08;LimitRange、ResourceQuota#xff09;等方面来进行说明 Kubernetes集群里的节点提供的资源主要是计算机资源… 关于资源管理我们会从计算机资源管理Computer Resources、服务质量管理Qos、资源配额管理LimitRange、ResourceQuota等方面来进行说明 Kubernetes集群里的节点提供的资源主要是计算机资源计算机资源是可计量的能被申请、分配和使用的基础资源这使之区别于API资源API Resources例如Pod和Services等。当前计算机资源主要包括CPU、GPU及Memory重点介绍CPU和Memory资源管理GPU除非是一些需要用到算力的服务否则对这个GPU性能需求不大。 场景我们在之前的实验中是没有对CPU和Memory进行定义的yaml文件如下
[rootk8s-master k8s-yaml]# cat nginx-deployment.yaml
apiVersion : apps/v1
kind: Deployment
metadata:name: nginx-deployment
spec:selector:matchLabels:app: nginxreplicas: 2template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.7.9ports:- containerPort: 80这样的话Kubernetes会认为该Pod所需要的资源很少可以调度到任何可用的Node这样一来当集群中的计算机资源不是很充足的时候例如集群的Pod负载突然增大就会使得某得节点的资源严重不足。此时为了避免系统挂掉该节点会杀掉某些用户进程来释放资源避免操作系统崩溃加入系统崩溃的话所有的Pod也会被牺牲掉所以Kubernetes有自己的一套资源配额限制以及对应的Pod服务等级机制。 1.可以全面的限制一个应用及其中的Pod所能占用的资源配额。 1定义每个Pod上资源配额相关的参数比如CPU/Memory Request/Limit 2自动为每个没有定义资源配额的Pod添加资源配额模版LimitRange); 3从总量上限制一个租户Namespace层级或者应用所能使用的资源配额的ResourceQuota。 2.允许集群的资源被超额分配以提高集群的资源利用率同时允许用户根据业务的优先级为不同的Pod定义相应的保障等级QoSQos就是Pod生存的优先级当系统资源不足的时候低等级的Pod会被优先干掉以确保高等级的Pod稳定运行。 一个程序所使用的CPU和Memory是一个动态的量会根据负载情况变化因此最准确的说法是某个进程的CPU使用量为0.1个CPURequest~1个CPULimit内存占用则为500MBRequest~1GBLimit。对应到Pod容器上就是如下的4个参数 spec.container[].resources.requests . cpu:容器初始要求的CPU数量 spec.container[].resources.limits.cpu容器所能使用最大的CPU数量 spec.container[].resources.requests.memory:容器初始要求的内存大小 spec.container[].esources.limits.memory:容器所能使用最大的内存大小
其中limit是对应资源上限最多允许使用这么大的资源由于CPU的资源是可压缩的进程无论如何都不可能突破上限因此设置起来比较容易。对于Memory这种不可压缩的资源它的Limit值设置起来就有点复杂如果设置得小了则进程在业务繁忙期视图请求超过Limit限制的Memory值时会被操作系统kill掉因此Memory额Request和Limit值需要结合进程实际的需求或者结合压测结果来谨慎设置。例如 Pod A 的 Memory Request 袚设置为 1GB, Node A 当时空闲的 Memory 为 1.2GB, 符合 Pod A 的需求因此 Pod A 被调度到 Node A 上 。 运行 3 天后 Pod A 的访问讨求大增内存需要增加到 1.5GB, 此时 Node A 的剩余内存只有 200MB, 由于 Pod A 新增的内存已经超出系统资源范围所以 Pod A 在这种情况下会被 Kubernetes“ 杀掉 。 没有设置Limit的Pod 或者只设置了CPU Limit或者Memory Limit两者之一的Pod,看起来都是很有弹性的但实际上与4个参数都被设置了的Pod相比它们处于一种不稳定状态只是稳定一点儿而已。理解了这一点就很容易理解Resource QoS问题了。如果我们有成百上千个不同的 Pod, 那么先手动设置每个Pod的这4个参数再检查并确保这些参数的设置都是合理的。比如不能出现内存超过2GB或者CPU占据两个核心的Pod。最后还得手工检查不同租户命名空间下的 Pod 资源使用量是否超过限额 。为此 Kubernetes 提供了另外两个相关对象LimitRange及ResourceQuota, 前者解决了没有设置配额参数的Pod的默认资源配额问题同时是Pod资源配额设置的合法性校验参考后者则约束租户的资源总量配额问题。 后面我们会分别从计算机资源管理Computer Resources、服务质量管理Qos、资源配额管理LimitRange、ResourceQuota来分析。
