资源类型

在 Kubernetes 中，Node 提供资源，而 Pod 使用资源。其中资源分为计算（CPU、Memory、GPU）、存储（Disk、SSD）、网络（Network Bandwidth、IP、Ports）。这些资源提供了应用运行的基础，正确理解这些资源以及集群调度如何使用这些资源，对于大规模的 Kubernetes 集群来说至关重要，不仅能保证应用的稳定性，还可以提高资源的利用率。在日常工作中，我们一般比较关心其中的计算资源，包括CPU和内存。CPU 的单位是 core，memory 的单位是 byte。

可压缩资源

目前kubernetes支持的可压缩资源是CPU。它的特点是，当可压缩资源不足时，Pod 只会饥饿少用，但不会退出。CPU 资源的限制和请求以cpu为单位。Kubernetes 中的一个 cpu 就是一个核，就是一个逻辑CPU。一个核相当于1000个微核，即1=1000m，0.5=500m。

不可压缩资源

目前kubernetes支持的不可压缩资源是内存。它的特点是，当不可压缩资源不足时，Pod 就会因为 OOM被内核杀掉。内存的限制和请求以字节为单位。可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。

POD中的资源请求和资源限制

requests 资源请求 pod最低需求（表示Pod对资源的最小需求，因此在调度的时候会如果Node剩余的资源不能满足Pod的需求，则不会调度到对应的Node上。Scheduler调度的时候并不关注在调度时具体的资源使用情况，而是根据现存Pod的资源请求情况来进行调度。调度器首先将不符合请求的Node排除在外，然后在执行优选策略最后在选定pod）

由于 Pod 可以由多个 Container 组成，所以 CPU 和内存资源的限额，是要配置在每个Container的定义上的。这样，Pod 整体的资源配置，就由这些 Container的配置值累加得到。

示例

执行下面yaml的内容：

[root@k8s-m1 k8s-resource]# cat resource-limit-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: resource-limit-podnamespace: defaultlabels:name: myapp
spec:containers:- name: myappimage: ikubernetes/stress-ngcommand: ["/usr/bin/stress-ng","-c 1","--metrics-brief"]ports:- name: httpcontainerPort: 80resources:requests:memory: "128Mi"cpu: "200m"limits:memory: "512Mi"cpu: "500m"
[root@k8s-m1 k8s-resource]# kubectl apply  -f resource-limit-pod.yaml 
pod/resource-limit-pod created

查看结果：

[root@k8s-m1 k8s-resource]# kubectl exec -it resource-limit-pod -- top
Mem: 7805096K used, 202092K free, 6444K shrd, 2104K buff, 4575292K cached
CPU:   3% usr   1% sys   0% nic  88% idle   6% io   0% irq   0% sirq
Load average: 0.14 0.55 0.71 3/1509 33PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND6     1 root     R     6892   0%  15   2% {stress-ng-cpu} /usr/bin/stress-ng -c 1 --metrics-brief1     0 root     S     6244   0%   9   0% /usr/bin/stress-ng -c 1 --metrics-brief29     0 root     R     1500   0%   9   0% top

我们看到CPU占用是3%，为什么呢？因为我的集群node都是是16个core。我们最大限制是0.5核。所以应该是0.5/16≈3.1%。

Request和Limits

基于Requests和Limits的Pod调度机制

调度器在调度时，首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和，不超过该节点能提供给Pod使用的CPU和Memory的最大容量值；
即使某节点上的实际资源使用量非常低，但是已运行Pod配置的Requests值的总和非常高，再加上需要调度的Pod的Requests值，会超过该节点提供给Pod的资源容量上限，这时Kubernetes仍然不会将Pod调度到该节点上。如果Kubernetes将Pod调度到该节点上，之后该节点上运行的Pod又面临服务峰值等情况，就可能导致Pod资源短缺；

Requests和Limits的背后机制

kubelet在启动Pod的某个容器时，会将容器的Requests和Limits值转化为相应的容器启动参数传递给容器执行器。如果是docker 容器：

spec.container[].resources.requests.cpu: 转化为docker 的–cpu-share；
spec.container[].resources.limits.cpu: 转为docker的–cpu-quota；
spec.container[].resources.requests.memory: 提供给Kubernetes调度器作为调度和管理的依据，不会作为任何参数传递给Docker；
spec.container[].resources.limits.memory：会转为–memory；

QoS（服务质量等级）

Kubernetes是根据Pod的Requests和Limits配置来实现针对Pod的不同级别的资源服务质量控制。当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级。

QoS分类

Guaranteed：pod里的每一个container都同时设置了CPU和内存的requests和limits 而且值必须相等。（这类的pod是最高优先级）
Burstable：pod至少有一个container设置了cpu或内存的requests和limits，且不满足 Guarantee 等级的要求。即内存或CPU的值设置的不同。（中等优先级）
BestEffort：没有任何一个容器设置了requests或limits的属性。（最低优先级）

应用场景：当宿主机资源紧张的时候，kubelet会根据服务质量等级对pod进行eviction，即驱逐pod进行资源回收。

Requests和Limits资源配置特点

如果Pod配置的Requests值等于Limits值，那么该Pod可以获得的资源是完全可靠的；
如果Pod的Requests值小于Limits值，那么该Pod获得的资源可分成两部分；

完全可靠的资源，资源量的大小等于Requests值；
不可靠的资源，资源量最大等于Limits与 Requests的差额，这份不可靠的资源能够申请到多少，取决于当时主机上容器可用资源的余量；通过这种机制，Kubernetes可以实现节点资源的超售（Over Subscription），超售机制能有效提高资源的利用率，同时不会影响容器申请的完全可靠资源的可靠性。

调度策略的影响

Kubernetes的kubelet通过计算Pod中所有容器的Requests的总和来决定对Pod的调度；
不管是CPU还是内存，Kubernetes调度器和kubelet都会确保节点上所有Pod的Requests的总和不会超过在该节点上可分配给容器使用的资源容量上限；

示例

https://www.cnblogs.com/wtzbk/p/15816291.html

Guaranteed样例

[root@k8s-m1 k8s-resource]# cat   guaranteed-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: guaranteed-podlabels:name: nginx
spec:containers:- name: myappimage: nginxports:- name: httpcontainerPort: 80resources:requests:memory: "512Mi"cpu: "500m"limits:memory: "512Mi"cpu: "500m"
[root@k8s-m1 k8s-resource]# kubectl apply -f guaranteed-pod.yaml 
pod/guaranteed-pod created

结果：

[root@k8s-m1 k8s-resource]# kubectl describe po guaranteed-pod 
......
Volumes:default-token-glxls:Type:        Secret (a volume populated by a Secret)SecretName:  default-token-glxlsOptional:    false
QoS Class:       Guaranteed
Node-Selectors:  <none>
.....

更详细检查
1）查看该pod被分配到的节点

[root@k8s-m1 k8s-resource]# kubectl get pod -o wide
NAME                 READY   STATUS    RESTARTS   AGE     IP              NODE     NOMINATED NODE   READINESS GATES
guaranteed-pod       1/1     Running   0          8s      10.244.11.39    k8s-m3   <none>           <none>

2）然后到k8s-m3上去查看这个pod里面启动的容器的资源限制是否生效

[root@k8s-m3 ~]# docker ps |grep guaranteed
434a95e67849   nginx                                               "/docker-entrypoint.…"   6 minutes ago   Up 6 minutes             k8s_myapp_guaranteed-pod_default_7095c77a-7c31-4a0a-ba1c-c347c690cfe8_0
32a0053da67b   registry.aliyuncs.com/google_containers/pause:3.2   "/pause"                 6 minutes ago   Up 6 minutes             k8s_POD_guaranteed-pod_default_7095c77a-7c31-4a0a-ba1c-c347c690cfe8_0#查看主容器的信息
[root@k8s-m3 ~]# docker inspect  434|egrep -i 'cpu|mem'"CpuShares": 512,"Memory": 536870912,"NanoCpus": 0,"CpuPeriod": 100000,"CpuQuota": 50000,"CpuRealtimePeriod": 0,"CpuRealtimeRuntime": 0,"CpusetCpus": "","CpusetMems": "","KernelMemory": 0,"KernelMemoryTCP": 0,"MemoryReservation": 0,"MemorySwap": 536870912,"MemorySwappiness": null,"CpuCount": 0,"CpuPercent": 0,
关注Memory、CpuPeriod、CpuQuota这三个值

3）通过cgroup的相关信息查看
从上面的结果实际上我们就可以看到这个容器的一些资源情况，Pod 上的资源配置最终也还是通过底层的容器运行时去控制 CGroup 来实现的，我们可以进入如下目录查看 CGroup 的配置，该目录就是 CGroup 父级目录，而 CGroup 是通过文件系统来进行资源限制的，所以我们上面限制容器的资源就可以在该目录下面反映出来：
##查看CPU的限制##

[root@k8s-m3 ~]# docker exec -it 434 /bin/bash
root@guaranteed-pod:/# cd /sys/fs/cgroup/cpu/
root@guaranteed-pod:/sys/fs/cgroup/cpu# cat cpu.cfs_period_us 
100000
root@guaranteed-pod:/sys/fs/cgroup/cpu# cat cpu.cfs_quota_us  
50000
root@guaranteed-pod:/sys/fs/cgroup/cpu# 
#反向计算出--cpus参数
#cpu.cfs_quota_us / cpu.cfs_period_us = cpu的限制
50000/100000=0.5核（也就是500m）##查看内存的限制##
root@guaranteed-pod:/sys/fs/cgroup/cpu# cd /sys/fs/cgroup/memory/
root@guaranteed-pod:/sys/fs/cgroup/memory# cat memory.limit_in_bytes 
536870912
root@guaranteed-pod:/sys/fs/cgroup/memory# 内存的计算方法为：536870912÷1024÷1024÷1024 = 0.5（G）

Burstable样例

[root@k8s-m1 k8s-resource]# cat  burstable-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: burstable-podlabels:name: nginx
spec:containers:- name: myappimage: nginxports:- name: httpcontainerPort: 80resources:requests:memory: "256Mi"cpu: "200m"limits:memory: "512Mi"cpu: "500m"[root@k8s-m1 k8s-resource]# kubectl apply  -f burstable-pod.yaml 
pod/burstable-pod created

结果：

[root@k8s-m1 k8s-resource]# kubectl describe po burstable-pod 
......
Volumes:default-token-glxls:Type:        Secret (a volume populated by a Secret)SecretName:  default-token-glxlsOptional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
......

上面Burstable的示例中，可以看到limit和Request都设置了的，且limit大于Request。大家可以自行测试只设置其中一个的Qos等级。当只设置Request时，系统是不会补全limit的相关配置，也是Burstable。而当只设置limit时，系统会自动补全Request的相关配置和limit一样，Qos是Guaranteed类型。

BestEffort样例

[root@k8s-m1 k8s-resource]# cat  besteffort-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: besteffort-podlabels:name: myapptier: appfront
spec:containers:- name: httpimage: nginxports:- name: httpcontainerPort: 80[root@k8s-m1 k8s-resource]# kubectl apply -f besteffort-pod.yaml 
kupod/besteffort-pod created

结果：

[root@k8s-m1 k8s-resource]# kubectl describe po besteffort-pod 
......
Volumes:default-token-glxls:Type:        Secret (a volume populated by a Secret)SecretName:  default-token-glxlsOptional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
.....

总结：
CPU是可以压缩资源，所以在CPU不够的时候会压缩限流。而内存是不可压缩资源，所以QoS主要用于内存限制。

BestEffort Pod的优先级最低，在这类Pod中运行的进程会在系统内存紧缺时被第一优先杀掉。当然，从另外一个角度来看，BestEffort Pod由于没有设置资源Limits，所以在资源充足时，它们可以充分使用所有的闲置资源;
Burstable Pod的优先级居中，这类Pod初始时会分配较少的可靠资源，但可以按需申请更多的资源。当然，如果整个系统内存紧缺，又没有BestEffort容器可以被杀掉以释放资源，那么这类Pod中的进程可能会被杀掉;
Guaranteed Pod的优先级最高，而且一般情况下这类Pod只要不超过其资源Limits的限制就不会被杀掉。当然，如果整个系统内存紧缺，又没有其他更低优先级的容器可以被杀掉以释放资源，那么这类Pod中的进程也可能会被杀掉;

OOM计分系统

在这里插入图片描述
如果kubelet无法在系统OOM之前回收足够的内存，则oom_killer 会根据内存使用比率来计算oom._score, 将得出的结果和oom_score_adj相加，最后得分最高的Pod会被首先驱逐。这个策略的思路是，QoS最低且相对于调度的Request来说消耗最多内存的Pod会被首先清除，来保障内存的回收。这意味着与Burstable或Guaranteed QoS类别的容器相比，BestEffort这种类别的容器被杀死的可能性更高。
与Pod驱逐不同，如果一个Pod的容器被oom杀掉，是可能被 kubelet根据restartpolicy重启的。

容器中的JVM资源限制

在Kubernetes环境中部署Java程序不一会就重启了，这意味着你的pod是不健康的。然后我们可以通过describe去查看一下重启的原因。发现是因为Pod超出了资源限制被kill掉，在日志最后一行会出现一个kill的字段。为什么Kubernetes会kill掉，因为它超出了Kubernetes对Pod的资源限制。默认情况下Docker容器会使用宿主机所有的资源，但如果不做资源限制，会影响整个宿主机。然后整个宿主机资源不够会实现飘移，会转移到其他主机上，然后再异常，可能会起到一种雪崩的效应，所以一般我们都是要做Pod资源限制。如果Java容器中未设置JVM的-Xmx（最大的堆内存使用）参数，一旦这个Pod的使用内存超出Kubernetes的limits限制，Kubernetes就会把它杀掉并重启一个新的Pod。所以在实际使用中，JVM中的这个值建议要比limits要小一点，小个10%左右，因为超过这个limits限制就可能会被杀死掉再重新起一个Pod。

更多关于kubernetes的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出