December 4, 2017
什么是资源
在Kubernetes中，资源指的是可以被pod或容器“请求”,“分配”,“消费”的那些东西。例如：CPU，内存，硬盘。资源又分为可压缩资源和不可压缩资源，目前CPU是唯一支持的可压缩资源，内存和硬盘是不可压缩资源。对于CPU这种可压缩资源，如果pod中服务使用CPU超过限额，该pod不会被kill掉但会被限制，而对于内存这种不可压缩资源，如果pod中服务使用内存超过限额，该pod中容器的进程会因OOM（Out of Memory）被kernel kill掉。
资源限制
如果未做过节点nodeSelector、亲和性（node affinity）或pod亲和、反亲和性（pod affinity/anti-affinity）等Pod高级调度策略设置，我们无法指定pod部署到指定机器上，这可能会造成CPU或内存等密集型的pod同时分配到相同节点，造成资源竞争。另一方面，如果未对资源进行限制，一些关键的服务可能会因为资源竞争因OOM等原因被kill掉，或者被限制使用CPU。
CPU、内存资源
在部署pod时，可以指定每个容器的资源请求和资源限额。分别由requests和limits控制：
- requests：资源请求，表示需要多少资源。
- limits： 资源限制，表示最多可以使用多少资源。
注：requests设置范围是0到节点最大配置，即0 <= request <= Node Allocatable，而limits设置范围是requests到无穷大，即requests <= limits <= Infinity。
当给一个容器指定了resource requests时，调度器可以更好地决定将pod放在哪个node上，目前容器仅支持CPU和内存资源的requests和limits。
内存溢出示例
下面是一个测试内存溢出的示例，启动一个可以不断申请内存的应用，测试一个容器使用内存超过限额后，kubernetes将如何处理。Deployment配置如下：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: test-oom
spec:
replicas: 3
template:
metadata:
labels:
app: test-oom
spec:
containers:
- name: test-oom
image: test-oom
resources:
requests:
memory: 60Mi
cpu: 1
limits:
memory: 200Mi
cpu: 2
该配置表示应用有3个pod，每个容器请求60MB内存、1颗CPU，限额1GB内存、2颗CPU
创建deployment：
[root@docker22 kubernetes]# kubectl create -f test-oom.yml
deployment "test-oom" created
查看各个pod的状态：
[root@docker22 kubernetes]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
test-oom-85b67d8699-mwwbt 1/1 Running 0 6s 10.244.2.120 docker24
test-oom-85b67d8699-nzjw2 1/1 Running 0 6s 10.244.0.134 docker22
test-oom-85b67d8699-tsdcp 1/1 Running 0 6s 10.244.1.88 docker23
打开一个新的终端窗口A，随便进入一台节点服务器，比如docker22，先找到test-oom容器id，通过docker stats查看该节点的test-oom容器的资源占用情况，发现一切正常。
[root@docker22 kubernetes]# docker ps|grep test-oom
69f66c496f69 test-oom@sha256:5ac78c8c3ee39798a75507608f9815892b43e73051fb9580210471b1b624a242 "sh -c /tmp/test-oom" 2 minutes ago Up 2 minutes k8s_test-oom_test-oom-85b67d8699-nzjw2_default_1dac89e0-dcaa-11e7-8280-001517872530_0
75f63eff0507 gcr.io/google_containers/pause-amd64:3.0 "/pause" 2 minutes ago Up 2 minutes
[root@docker22 kubernetes]# docker stats|grep 69f66c496f69
69f66c496f69 0.00% 1.406 MiB / 200 MiB 0.70% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.406 MiB / 200 MiB 0.70% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.406 MiB / 200 MiB 0.70% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.406 MiB / 200 MiB 0.70% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.406 MiB / 200 MiB 0.70% 0 B / 0 B 0 B / 0 B 6
然后在原来的终端执行curl http://10.244.0.87:8080/kill（该接口是一个不断申请内存的死循环程序），并返回终端A再次查看资源占用情况，会发现内存占用在飙升，而且docker stats很快就停止刷新了。结果如下：
[root@docker22 kubernetes]# docker stats|grep 69f66c496f69
69f66c496f69 0.00% 1.414 MiB / 200 MiB 0.71% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.414 MiB / 200 MiB 0.71% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.414 MiB / 200 MiB 0.71% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.414 MiB / 200 MiB 0.71% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.414 MiB / 200 MiB 0.71% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 0.00% 1.414 MiB / 200 MiB 0.71% 0 B / 0 B 0 B / 0 B 6
69f66c496f69 71.59% 26.91 MiB / 200 MiB 13.45% 0 B / 0 B 242 kB / 0 B 11
69f66c496f69 71.59% 26.91 MiB / 200 MiB 13.45% 0 B / 0 B 242 kB / 0 B 11
69f66c496f69 243.48% 83.75 MiB / 200 MiB 41.88% 0 B / 0 B 242 kB / 0 B 12
69f66c496f69 243.48% 83.75 MiB / 200 MiB 41.88% 0 B / 0 B 242 kB / 0 B 12
69f66c496f69 131.74% 137.5 MiB / 200 MiB 68.75% 0 B / 0 B 242 kB / 0 B 12
69f66c496f69 131.74% 137.5 MiB / 200 MiB 68.75% 0 B / 0 B 242 kB / 0 B 12
这是因为该pod被kill掉了，然后pod重启，所以容器也重启了。查看pod状态，发现该pod的RESTART变为1了，说明该pod重启过一次，如下：
[root@docker22 kubernetes]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
test-oom-85b67d8699-mwwbt 1/1 Running 0 8m 10.244.2.120 docker24
test-oom-85b67d8699-nzjw2 1/1 Running 1 8m 10.244.0.134 docker22
test-oom-85b67d8699-tsdcp 1/1 Running 0 8m 10.244.1.88 docker23
硬盘资源
emptyDir
卷，该类型的挂载卷可以使用宿主机全部的硬盘空间，要注意的是，emptyDir类型的挂载卷生命周期持续到Pod终止，即使Pod内的容器重启或终止，只要Pod存活，该挂载卷也会一直存在。只有当Pod终止时，挂载卷的数据才会被清除。
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: gcr.io/google_containers/test-webserver
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
PersistentVolume
持久卷，缩写为PV，是集群中的一块存储，跟Node一样，也是集群的资源。PV跟Volume(卷)类似，不过它有独立于Pod的生命周期，该类型挂载卷是永久存在于宿主机的。
kind: PersistentVolume
apiVersion: v1
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/tmp/data"
上面定义了一个PersistentVolume资源，挂载宿主机的/tmp/data目录，容量为10GB，访问模式为读写，其中定义的storageClassName=manual用于将PersistentVolumeClaim的requests绑定到这个PV。 其中，accessModes可选三种访问模式：
- ReadWriteOnce：该卷能够以读写模式被加载到一个节点上。
- ReadOnlyMany：该卷能够以只读模式加载到多个节点上。
- ReadWriteMany：该卷能够以读写模式被多个节点同时加载。
PersistentVolumeClaim
持久卷申请，缩写为PVC，是用户对PV的一个请求，跟Pod类似。Pod消费Node的资源，PVC消费PV的资源。Pod 能够申请特定的资源（CPU和内存）；PVC能够申请特定的尺寸和访问模式（例如可以加载一个读写，或多个只读实例）。
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
示例
在Pod中使用PVC，yaml配置文件如下：
kind: Pod
apiVersion: v1
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
这里创建了一个PVC类型的资源，PVC创建后，k8s的controller会去查找匹配的PV，一旦找到，则通过storageClassName与其绑定，申请PV 3GB硬盘空间，实际上就是宿主机3GB硬盘空间。
注意：PVC绑定是独占的，即一旦PVC与某个PV绑定，其他的PVC就不能再绑定到这个PV了。
Resource Quotas
资源配额（Resource Quotas）是用来限制用户资源用量的一种机制。
它的工作原理为：
- 资源配额应用在Namespace上，并且每个Namespace最多只能有一个ResourceQuota对象
- 开启计算资源配额后，创建容器时必须配置计算资源请求或限制（也可以用LimitRange设置默认值）
- 用户超额后禁止创建新的资源
资源配额的类型：
- 计算资源，包括cpu和内存
cpu, limits.cpu, requests.cpu memory, limits.memory, requests.memory
- 存储资源，包括存储资源的总量以及指定storage class的总量
requests.storage：存储资源总量，如500Gi persistentvolumeclaims：pvc的个数
- 对象数，即可创建的对象的个数
pods, replicationcontrollers, configmaps, secrets resourcequotas, persistentvolumeclaims services, services.loadbalancers, services.nodeports
资源配额示例
apiVersion: v1
kind: ResourceQuota
metadata:
name: resource-quotas
spec:
hard:
pods: "4"
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
persistentvolumeclaims: "10"
该配置表示，该命名空间下
最多只能有4个pod CPU请求1核，限制2核 内存请求1GB，限制2GB 最多可以声明10个PVC
###使用示例 创建myspace命名空间：
[root@docker22 kubernetes]# kubectl create namespace myspace
namespace "myspace" created
创建myspace命名空间的资源配额对象：
[root@docker22 kubernetes]# kubectl create -f resoureQuota.yml -n myspace
resourcequota "resource-quotas" created
查看该命名空间下资源配额占用情况：
[root@docker22 kubernetes]# kubectl describe quota/resource-quotas -n myspace
Name: resource-quotas
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
persistentvolumeclaims 0 10
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
编写应用app-myspace.yaml配置，如下：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: app-myspace
spec:
replicas: 3
template:
metadata:
labels:
app: app-myspace
spec:
containers:
- name: app-myspace
image: app-myspace:k8s-test
resources:
requests:
memory: 100Mi
cpu: 100m
limits:
memory: 500Mi
cpu: 500m
创建Deployment：
[root@docker22 kubernetes]# kubectl create -f app-myspace.yml -n myspace
deployment "app-myspace" created
查看pod的状态，正常： [root@docker22 kubernetes]# kubectl get pod -n myspace -o wide NAME READY STATUS RESTARTS AGE IP NODE app-myspace-7d64df76c7-8cpjj 1/1 Running 0 4m 10.244.0.135 docker22 app-myspace-7d64df76c7-fb6xl 1/1 Running 0 4m 10.244.1.89 docker23 app-myspace-7d64df76c7-p5w24 1/1 Running 0 4m 10.244.2.121 docker24
查看资源占用情况：
[root@docker22 kubernetes]# kubectl describe quota/resource-quotas -n myspace
Name: resource-quotas
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 1500m 2
limits.memory 1500Mi 2Gi
persistentvolumeclaims 0 10
pods 3 4
requests.cpu 300m 1
requests.memory 300Mi 1Gi
注意：若把上述resource.limits.cpu改为1，则启动3个pod需要3颗CPU，而我们在Resource quota里声明了limits.cpu=2，无法满足创建3个pod的条件，所以这种情况下只能创建2个pod。
LimitRange
默认情况下，Kubernetes中所有容器都没有任何CPU和内存限制。LimitRange用来给Namespace增加一个默认资源限制，包括最小、最大值。
配置示例：
apiVersion: v1
kind: LimitRange
metadata:
name: mylimits
spec:
limits:
- max:
cpu: "2"
memory: 1Gi
min:
cpu: 200m
memory: 6Mi
type: Pod
- default:
cpu: 300m
memory: 200Mi
defaultRequest:
cpu: 200m
memory: 100Mi
max:
cpu: "2"
memory: 1Gi
min:
cpu: 100m
memory: 3Mi
type: Container
该配置表示，默认情况下：
一个Pod内所有容器内存使用最小6M，最大1G；CPU使用最小200m，最大2核。 一个容器内存使用最小3M，最大1G，requests 100M，limits 200M；CPU使用最小100m，最大2核，requests 200m，limits 300m。
若一个Pod的资源限制条件不满足该namespace下的limitRange，则该Pod不会被创建。即必须满足以下条件：min <= request <= limit <= max
QoS
QoS是Quality of Service的缩写，即服务质量。为了实现资源被有效调度和分配的同时提高资源利用率，Kubernetes针对不同服务质量的预期，通过QoS（Quality of Service）来对pod进行服务质量管理。对于一个pod来说，服务质量体现在两个具体的指标：CPU和内存。当节点上内存资源紧张时，kubernetes会根据预先设置的不同QoS类别进行相应处理。
QoS主要分为Guaranteed、Burstable和Best-Effort三类，优先级从高到低。
Guaranteed
属于该级别的pod有以下两种：
- Pod中的所有容器都且仅设置了CPU和内存的limits
- pod中的所有容器都设置了CPU和内存的requests和limits，且单个容器内的requests==limits（requests不等于0）
pod中的所有容器都且仅设置了limits：
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
memory: 100Mi
pod中的所有容器都设置了requests和limits，且单个容器内的requests==limits：
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
容器foo和bar内resources的requests和limits均相等，该pod的QoS级别属于Guaranteed。
Burstable
pod中只要有一个容器的requests和limits的设置不相同，该pod的QoS即为Burstable。
容器foo指定了resource，而容器bar未指定：
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
name: bar
容器foo设置了内存limits，而容器bar设置了CPU limits：
containers:
name: foo
resources:
limits:
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
注意：若容器指定了requests而未指定limits，则limits的值等于节点resource的最大值；若容器指定了limits而未指定requests，则requests的值等于limits。
Best-Effort
如果Pod中所有容器的resources均未设置requests与limits，该pod的QoS即为Best-Effort。
容器foo和容器bar均未设置requests和limits：
containers:
name: foo
resources:
name: bar
resources:
根据QoS进行资源回收策略
Kubernetes通过cgroup给pod设置QoS级别，当资源不足时先kill优先级低的pod，在实际使用过程中，通过OOM分数值来实现，OOM分数值范围为0-1000。 OOM分数值根据OOM_ADJ参数计算得出，对于Guaranteed级别的pod，OOM_ADJ参数设置成了-998，对于Best-Effort级别的pod，OOM_ADJ参数设置成了1000，对于Burstable级别的POD，OOM_ADJ参数取值从2到999。对于kuberntes保留资源，比如kubelet，docker，OOM_ADJ参数设置成了-999，表示不会被OOM kill掉。OOM_ADJ参数设置的越大，计算出来的OOM分数越高，表明该pod优先级就越低，当出现资源竞争时会越早被kill掉，对于OOM_ADJ参数是-999的表示kubernetes永远不会因为OOM将其kill掉。
QoS pods被kill掉场景与顺序
*Best-Effort pods：系统用完了全部内存时，该类型pods会最先被kill掉。 *Burstable pods：系统用完了全部内存，且没有Best-Effort类型的容器可以被kill时，该类型的pods会被kill掉。 *Guaranteed pods：系统用完了全部内存，且没有Burstable与Best-Effort类型的容器可以被kill时，该类型的pods会被kill掉。
QoS使用建议
如果资源充足，可将QoS pods类型均设置为Guaranteed。用计算资源换业务性能和稳定性，减少排查问题时间和成本。如果想更好的提高资源利用率，业务服务可以设置为Guaranteed，而其他服务根据重要程度可分别设置为Burstable或Best-Effort。
总结
kubernetes中的资源是很大一块内容，本文还有些东西没有讲到，因为我也没搞清楚，有兴趣的可以去官网查阅文档了解下。
参考：
https://feisky.gitbooks.io/kubernetes/concepts/quota.html
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md
http://dockone.io/article/2592
