简介
容器管理资源
当你定义 Pod 时可以选择性地为每个 容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。
当你为 Pod 中的 Container 指定了资源 请求 时，调度器就利用该信息决定将 Pod 调度到哪个节点上。 当你还为 Container 指定了资源 约束 时，kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 kubelet 还会为容器预留所 请求 数量的系统资源，供其使用
Requests & limits
request
- 容器使用的最小资源需求, 作为容器调度时资源分配的判断依赖。
- 只有当前节点上可分配的资源量 >= request 时才允许将容器调度到该节点。
- request参数不限制容器的最大可使用资源
limit
- 容器能使用资源的最大值
- 设置为0表示对使用的资源不做限制, 可无限的使用
Request能够保证Pod有足够的资源来运行，而Limit则是防止某个Pod无限制地使用资源，导致其他Pod崩溃。两者之间必须满足关系: 0<=Request<=Limit<=Infinity (如果Limit为0表示不对资源进行限制，这时可以小于Request)
Resource requests and limits of Pod and Container
Pod 中的每个容器都可以指定以下的一个或者多个值：
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-<size>
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-<size>
尽管请求和限制值只能在单个容器上指定，我们仍可方便地计算出 Pod 的资源请求和约束。 Pod 对特定资源类型的请求/约束值是 Pod 中各容器对该类型资源的请求/约束值的总和。
kubernetes中的资源单位
cpu的含义
CPU 资源的约束和请求以 cpu 为单位。
Kubernetes 中的一个 cpu 等于云平台上的 1 个 vCPU/核和裸机 Intel 处理器上的 **1 个超线程 **。
你也可以表达带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的 Container 肯定能够获得请求 1 CPU 的容器的一半 CPU 资源。表达式 0.1 等价于表达式 100m， 可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。 具有小数点（如 0.1）的请求由 API 转换为 100m；最大精度是 1m。 因此，或许你应该优先考虑使用 100m 的形式。
CPU 总是按绝对数量来请求的，不可以使用相对数量； 0.1 的 CPU 在单核、双核、48 核的机器上的意义是一样的。
内存的含义
内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点数字形式来表示内存： E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki
示例
apiVersion: v1
kind: Pod
metadata:
name: stress
namespace: default
spec:
containers:
- name: stress
image: ikubernetes/stress-ng
imagePullPolicy: IfNotPresent
command: ["/usr/bin/stress-ng", "-m 1","-c 1","--metrics-brief"]
resources:
requests:
memory: "128Mi"
cpu: "200m"
limits:
memory: "200Mi"
cpu: "500m"
登录pod中验证
/ # top
Mem: 1581188K used, 282036K free, 20356K shrd, 2104K buff, 914844K cached
CPU: 45% usr 9% sys 0% nic 45% idle 0% io 0% irq 0% sirq
Load average: 2.57 0.95 0.38 4/250 281
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
280 7 root R 262m 14% 0 31% {stress-ng-vm} /usr/bin/stress-ng -m 1 -c 1 --metrics-brief
6 1 root R 6888 0% 0 23% {stress-ng-cpu} /usr/bin/stress-ng -m 1 -c 1 --metrics-brief
7 1 root S 6244 0% 0 0% {stress-ng-vm} /usr/bin/stress-ng -m 1 -c 1 --metrics-brief
1 0 root S 6244 0% 0 0% /usr/bin/stress-ng -m 1 -c 1 --metrics-brief
155 0 root S 1508 0% 0 0% /bin/sh
281 155 root R 1500 0% 0 0% top
pod中的QoS Class:
QoS Class: 服务质量类别
在容器中设置限制资源后，容器会自动分配一个QoS Class
默认的QoS Class有三种类别：
Guaranteed： 每个容器的cpu资源设置了相同的值的request和limits属性定义了cpu资源需求量memory资源需求量两个都必须定义并且request都等于limits
cpu.limits=cpu.requests
memory.limits=memory.request
这样设置的pods会被自动归类到这一类别，这列pods就具有最高优先级，意思是如果现在又很多pods需要运行节点资源不够了，无法满足所有pods去运行那么这类pod是会被优先运行的
Burstable：一个pod中至少有一个容器设置了cpu或memory的requests属性，这类就具有中等优先级
BestEffort：没有任何一个设置了request属性或limits属性则优先级最低
注：当内存资源不够用是这种"QoS Class: BestEffort"这类容器会被最先终止来腾出资源确保另外的pod资源正常运行
Guaranteed
apiVersion: v1
kind: Pod
metadata:
name: stress
namespace: default
spec:
containers:
- name: stress
image: ikubernetes/stress-ng
imagePullPolicy: IfNotPresent
command: ["/usr/bin/stress-ng", "-m 1","-c 1","--metrics-brief"]
resources:
requests:
memory: "256Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: "500m"
[root@k8s-master ~]# kubectl describe pods stress|grep "QoS Class"
QoS Class: Guaranteed
Burstable
apiVersion: v1
kind: Pod
metadata:
name: stress
namespace: default
spec:
containers:
- name: stress
image: ikubernetes/stress-ng
imagePullPolicy: IfNotPresent
command: ["/usr/bin/stress-ng", "-m 1","-c 1","--metrics-brief"]
resources:
requests:
memory: "200Mi"
cpu: "200m"
limits:
memory: "256Mi"
cpu: "500m"
[root@k8s-master ~]# kubectl describe pods stress|grep "QoS Class"
QoS Class: Burstable
BestEffort
apiVersion: v1
kind: Pod
metadata:
name: stress
namespace: default
spec:
containers:
- name: stress
image: ikubernetes/stress-ng
imagePullPolicy: IfNotPresent
[root@k8s-master ~]# kubectl describe pods stress|grep "QoS Class"
QoS Class: BestEffort
