在Kubernetes，当配置Pod时，可以为每一个容器设置CPU和内存这些计算资源。当容器被指定资源请求后，调度器将能够更好的决定将Pod部署在那一个Node上。

1、资源类型

在当前的Kubernetes版本中，计算资源有CPU和内存这两种类型。CPU的基本单位是核(Core)，内存的基本单位是字节(byte)。CPU和内存统称为“计算资源”。在Kubernetes中，计算资源是可以被请求、分配和消耗的可测量的数量。

Pod中的每一个容器都能够通过如下的方式设置CPU和内存的资源：

• spec.containers[].resources.limits.cpu
• spec.containers[].resources.limits.memory
• spec.containers[].resources.requests.cpu
• spec.containers[].resources.requests.memory

虽然从根源上来说，requests和limits是在容器上进行设置的，但是在Pod级别上的设置会带来更大的便利。Pod上的request/limit是Pod中各个容器request/limit的总和。

1.1 CPU资源

在Kubernetes中CPU资源通过cpu数量进行计算。如果容器的spec.containers[].resources.requests.cpu值为0.5，则表示它需要半个cpu。在Kubernetes中，如果spec.containers[].resources.requests.cpu值为0.1，则等价于spec.containers[].resources.requests.cpu值为100m。在kubernetes，设置CPU资源时，最小值为1m，也就是0.001。CPU资源是一个绝对值，而不是相对值，因此在单核，双核或者48核机器上，0.1都表达是同一意思，即0.1个CPU core。

1.2 内存资源

在Kubernetes中，内存资源的计算单位为字节数(byte)，可以直接使用整型数字表达，也可以使用整数加国际单位制来表示。国际单位制包括：十进制(E, P, T, G, M, K)和二进制(Ei, Pi, Ti, Gi, Mi, Ki)，其中：1KB(kilobyte)=1000bytes，1KiB(kibibyte)=2^10bytes=1024bytes。例如，以下代表大致相同的值：

128974848, 129e6, 129M, 123Mi

1.3 示例

下面的例子中拥有两个容器的Pod，每一个容器的request是0.25 cpu和 64MiB 内存，每个容器的limit是0.5 cpu和128MiB 内存。因此，Pod的requst是0.5核cpu和128MiB内存，Pod的limit是1核cpu和256MiB内存。

apiVersion: v1
kind: Pod
metadata:
 name: frontend
spec:
 containers: - name: db
 image: mysql
 env: - name: MYSQL_ROOT_PASSWORD
 value: "password"
 resources:
 requests:
 memory: "64Mi"
 cpu: "250m"
 limits:
 memory: "128Mi"
 cpu: "500m" - name: wp
 image: wordpress
 resources:
 requests:
 memory: "64Mi"
 cpu: "250m"
 limits:
 memory: "128Mi"
 cpu: "500m"

2、基于资源的Pod调度

在创建一个Pod时，Kubernetes调度器将会为Pod选择一个运行的Node。对于每一个Node来说，其都存在一个最大的资源能力(CPU和内存)。调度器在调度时，要确保Node上CPU和内存能够满足所有Pod对于计算资源的要求。

当kubelet启动Pod中的容器时，它会将容器的request和limit作为参数传递给容器运行时。如果容器运行时使用的是docker：

• spec.containers[].resources.requests.cpu的值会被转换为core，然后乘以1024，再将结果通过–cpu-shares参数的值传递给docker run命令。
• spec.containers[].resources.limits.cpu的值会被转化为millicore，然后乘以100。结果值是作为容器在100微秒内能够使用的CPU总量时间。默认的配额周期是100ms，最小的CPU配额是1ms。
• spec.containers[].resources.limits.memory被转化为整数，在docker run命令中作为–memory字段的值。

如果容器在运行过程中使用的内存超过了内存的limit，它将会被终止。同时如果此容器是可重启的，则kubelet会在后续会重新启动它。如果容器在运行过程中使用的内存超过了内存的request，则当Node内存不足时，它所在的Pod会被删除。

与内存不同的是，在容器运行过程中如果使用了超过要求CPU，容器并不会被杀死。

3、监控计算资源使用情况

在Kubernetes中，计算资源的使用情况作为Pod状态信息的一部分被报告。另外，如果已经在集群中配置了监控，也可以通过监控系统获取Pod的资源使用情况。

4、问题处理

4.2 Pod的状态为pending，事件信息为failedScheduling

如果调度器无法为Pod找到合适的Node，则Pod会一直处于未调度的状态。通过执行下面的命令能够查看信息：

$ kubectl describe pod frontend | grep -A 3 Events Events: FirstSeen LastSeen Count From Subobject PathReason Message 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others

在上面的例子中，Pod名称为fronted，由于Node的CPU资源不足，导致其无法被调度。同一如果内存不足的话也会导致Pod无法被调度。这里错误的解决方案如下：

• 往集群中添加新的Node；
• 终止不需要的Pod释放资源，以为处于pengding状态的Pod提供资源；
• 检查Pod的配置，以保证Pod的资源要求不超过Node提供资源最大值。例如，如果集群中所有的Node只提供了1核的CPU，如果Pod需要1.1核的CPU，则Pod将无法被调度。

通过执行如下的命令可以检查Node所提供的计算资源：

$ kubectl describe nodes e2e-test-minion-group-4lw4 Name: e2e-test-minion-group-4lw4 [ ... lines removed for clarity ...] Capacity:
 cpu: 2
 memory: 7679792Ki
 pods: 110 Allocatable:
 cpu: 1800m
 memory: 7474992Ki
 pods: 110 [ ... lines removed for clarity ...] Non-terminated Pods: (5 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits --------- ---- ------------ ---------- --------------- -------------
 kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
 kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
 kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
 kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
 kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.)
 CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)

4.2 容器被终止

如果应用资源的原因，容器被强行终止。可以通过执行下面的命令来检查导致容器终止的原因

[12:54:41] $ kubectl describe pod simmemleak-hra99
Name: simmemleak-hra99
Namespace: default Image(s): saadali/simmemleak
Node: kubernetes-node-tf0f/10.240.216.66 Labels: name=simmemleak
Status: Running Reason: Message:
IP: 10.244.2.75 Replication Controllers: simmemleak (1/1 replicas created) Containers:
 simmemleak: Image: saadali/simmemleak
 Limits:
 cpu: 100m
 memory: 50Mi State: Running Started: Tue, 07 Jul 2015 12:54:41 -0700 Last Termination State: Terminated Exit Code: 1 Started: Fri, 07 Jul 2015 12:54:30 -0700 Finished: Fri, 07 Jul 2015 12:54:33 -0700 Ready: False  Restart Count: 5 Conditions: Type Status Ready False Events: FirstSeen LastSeen Count From SubobjectPath Reason Message Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
 Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
 Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a

在上面的例子中，Restart Count: 5显示了Pod中的容器simmemleak被终止和重启了5次。

可以通过带-o go-template=…参数的kubectl get pod 命令获取已终止容器的状态信息：

[13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
Container Name: simmemleak
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]

通过输出的信息，可以看出是由于reason:OOM Killed的原因，导致了容器被终止，这里的OOM代表Out Of Memory。

本文转自中文社区-Kubernetes-计算资源管理