Kubernetes-计算资源管理

心已赠人 2022-04-16 05:25 238阅读 0赞

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

作者： [Daniel\_Ji][Daniel_Ji]

原文：[https://www.kubernetes.org.cn/4723.html][https_www.kubernetes.org.cn_4723.html]

[Daniel_Ji]: https://www.kubernetes.org.cn/author/daniel_ji
[https_www.kubernetes.org.cn_4723.html]: https://www.kubernetes.org.cn/4723.html