Kubernetes计算资源管理

在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。

参考资料

1.《Managing Compute Resources for Containers》地址：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/