资源管理:
https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits
https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-memory-resource/
https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-cpu-resource/
QOS:
https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/
k8s resources配置
一、使用
要知道具体的资源限制是通过系统的Cgroup。 k8s只是做资源统计来管理调度,以及传递资源参数给容器runtime程序, 如docker。docker再为容器创建具体的Cgroup对象, 然后系统对容器进程实现资源限制。
1、资源单位
cpu
时间片。
cpu
有两种方式表示:
- 带小数的数字或整数,如:1 表示一个CPU的计算资源, 0.1表示0.1个CPU的的计算资源。
- 单位是小写m的表示,如:1000m表示一个CPU的计算资源, 100m表示0.1个CPU的计算资源。
0.1这种表达方式的请求最终会转换成100m这种方式,所以最好还是使用100m这种方式。
500m 有人叫做500毫, 不是500毫秒, 时间片具体是如何计算的不太清楚。
1000m或者1 不是一个CPU,而是1个CPU的计算资源,毕竟资源不是上来就分配的,而是最大可以使用的,并不是独占cpu。
配置的值是绝对的表示,跟cpu的多少没有关系。 100m不管在一个cpu还是多个cpu的节点上,都是表示0.1个cpu的计算量。
内存
内存有两种单位:
- K, M, T... 这种是以1000为倍数计算的,不是通常计算机上的单位。
- Ki, Mi, Ti... 以1024为倍数的,一般是使用这种单位。
存储
跟内存的单位一样
临时性存储的限制还是beta阶段。
2、关键字
spec:
containers:
- image: harbor.atest.pub/system/centos:7
name: centos
command: ['/bin/bash', '-c', 'while true;do echo hello world;sleep 2;done']
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 300m
memory: 512Mi
在containers
的配置项里. 一个pod所需要的资源是所有containers
的相加。
resources
主关键字。
requests
表示最小资源限制。
limits
最大资源限制。
requests
最小资源限制,就是保障服务正常运行需要的资源。
这个没有具体的资源限制,只是一个占位预留, K8S调度会使用。
K8S的统计调度
配置最小资源限制,就是告诉k8s这些pod正常运行所需要的资源,k8s就能调度到有这些资源的节点。
判断节点有没有足够的资源也是通过该节点上已经在运行的所有pod的requests需要的资源与总的资源计算的。
注意:request只是一种配置,并不是一定会消耗这么多的资源。
比如:节点总的内存是32G, 一个pod的requests
是10G, 那么这个节点只能跑3个这种pod, 就算是实际内存的使用才100Mi。
通过这种方式调度,而不是直接通过获取节点可用资源的方式,就是因为服务是有高峰和低峰的, 这个值的判断由我们自己来才是最精确的。
其它
requests.cpu
: 在使用docker时,会传递到--cpu-shares
参数。
不同的pod的cpu使用都很高,已经发生抢占的情况,这个参数就是一个权重,表示能抢多少,默认情况下是平分。
limits
最大资源限制,实际存在的限制,资源的使用不能超过这个限制。
cpu是可压缩资源, 直接限制不能超出就行。
但是内存的使用一旦超出限制,系统就会触发OOM, kill -9 进程。
limits.cpu
: 这个还不清楚会传递docker的哪个参数,测试了--cpus
,发现有点不对。可能传递了多个关于cpu的参数。
limits.memory
: 传递docker的--memory
参数。
二、一些情况
只有limits
如果只设置了limits, 没有设置request,Kubernetes会自动为其设置一样的值。
甚至文件里都能看出变化:
文件里的yaml:
resources:
limits:
cpu: 100m
memory: 256Mi
运行里的yaml:
resources:
limits:
cpu: 100m
memory: 256Mi
requests:
cpu: 100m
memory: 256Mi
注意,在已经配置了limitrange
资源的情况下,不会去查找limitrange
里面的默认值配置。 request
直接就是与limits
一样。
只有requests
如果只设置了requests
,一般情况下也就这样了, 没有limits
。
如果配置了limitrange
,并且有limits
的默认值,会填充默认值。
在运行的文件里也可以看到。
同样的,如果requests
与limits
都没有配置, 也就没有配置了。还是要看limitrange
里有没有默认值。
三、服务质量QOS类
QoS类来决定 Pod 的调度和驱逐策略。
Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类:
Guaranteed
Burstable
BestEffort
Guaranteed
Pod 中的每个容器,包括初始化容器,必须指定内存与cpu的requests
与limits
, 并且两者要相等。
如:
[root@k8smaster1 ~]# kubectl get pods/centos7-56d784d4cd-lbzt5 -o yaml
......
resources:
limits:
cpu: 100m
memory: 256Mi
requests:
cpu: 100m
memory: 256Mi
......
qosClass: Guaranteed
注意:
只要
requests
与limits
都配置了内存
与cpu
, 并且都一样就是Guaranteed
,
无论是不是默认值。 如下面的情况也同样是Guaranteed
。
- 只配置了
limits
,request
就会跟limits
一样。 - 只配置了
request
,limits
通过limitrange
的配置默认值,跟request
一样。 - 什么也没有配置,
limitrange
里面有requests
与limits
的默认值,并且都一样。
Burstable
Pod 不符合 Guaranteed QoS 类的标准, Pod 中至少一个容器具有内存或 CPU
requests
。
总的来说就是随便有一个限制就行,无论是limits
还是requests
,因为limits
有了,requests
也就有了。 然后不要符合Guaranteed
的标准。
BestEffort
Pod 中的容器必须没有设置内存和 CPU
requests
或limits
。
就是所有容器都没有配置资源限制,干干净净。
驱逐方面的:
https://kubernetes.io/zh/docs/tasks/administer-cluster/out-of-resource/