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/
