k8s资源管理: Resources

大番茄 2021年01月11日 1,813次浏览

资源管理:
https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits
https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-memory-resource/
https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-cpu-resource/

QOS:
https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/

k8s resources配置

一、使用

要知道具体的资源限制是通过系统的Cgroup。 k8s只是做资源统计来管理调度,以及传递资源参数给容器runtime程序, 如docker。docker再为容器创建具体的Cgroup对象, 然后系统对容器进程实现资源限制。

1、资源单位

cpu

时间片。
cpu 有两种方式表示:

  1. 带小数的数字或整数,如:1 表示一个CPU的计算资源, 0.1表示0.1个CPU的的计算资源。
  2. 单位是小写m的表示,如:1000m表示一个CPU的计算资源, 100m表示0.1个CPU的计算资源。

0.1这种表达方式的请求最终会转换成100m这种方式,所以最好还是使用100m这种方式。

500m 有人叫做500毫, 不是500毫秒, 时间片具体是如何计算的不太清楚。

1000m或者1 不是一个CPU,而是1个CPU的计算资源,毕竟资源不是上来就分配的,而是最大可以使用的,并不是独占cpu。

配置的值是绝对的表示,跟cpu的多少没有关系。 100m不管在一个cpu还是多个cpu的节点上,都是表示0.1个cpu的计算量。

内存

内存有两种单位:

  1. K, M, T... 这种是以1000为倍数计算的,不是通常计算机上的单位。
  2. Ki, Mi, Ti... 以1024为倍数的,一般是使用这种单位。

存储

跟内存的单位一样
临时性存储的限制还是beta阶段。

2、关键字

    spec:
      containers:
      - image: harbor.atest.pub/system/centos:7
        name: centos
        command: ['/bin/bash', '-c', 'while true;do echo hello world;sleep 2;done']
        resources:
          requests:
            cpu: 100m
            memory: 256Mi
          limits:
            cpu: 300m
            memory: 512Mi

containers的配置项里. 一个pod所需要的资源是所有containers的相加。

resources 主关键字。
requests 表示最小资源限制。
limits 最大资源限制。


requests

最小资源限制,就是保障服务正常运行需要的资源。
这个没有具体的资源限制,只是一个占位预留, K8S调度会使用。

K8S的统计调度

配置最小资源限制,就是告诉k8s这些pod正常运行所需要的资源,k8s就能调度到有这些资源的节点。

判断节点有没有足够的资源也是通过该节点上已经在运行的所有pod的requests需要的资源与总的资源计算的。

注意:request只是一种配置,并不是一定会消耗这么多的资源。

比如:节点总的内存是32G, 一个pod的requests是10G, 那么这个节点只能跑3个这种pod, 就算是实际内存的使用才100Mi。

通过这种方式调度,而不是直接通过获取节点可用资源的方式,就是因为服务是有高峰和低峰的, 这个值的判断由我们自己来才是最精确的。

其它

requests.cpu : 在使用docker时,会传递到--cpu-shares参数。

不同的pod的cpu使用都很高,已经发生抢占的情况,这个参数就是一个权重,表示能抢多少,默认情况下是平分。

limits

最大资源限制,实际存在的限制,资源的使用不能超过这个限制。
cpu是可压缩资源, 直接限制不能超出就行。
但是内存的使用一旦超出限制,系统就会触发OOM, kill -9 进程。

limits.cpu: 这个还不清楚会传递docker的哪个参数,测试了--cpus,发现有点不对。可能传递了多个关于cpu的参数。

limits.memory: 传递docker的--memory参数。

二、一些情况

只有limits

如果只设置了limits, 没有设置request,Kubernetes会自动为其设置一样的值。
甚至文件里都能看出变化:

文件里的yaml:

      resources:
        limits:
          cpu: 100m
          memory: 256Mi

运行里的yaml:

    resources:
      limits:
        cpu: 100m
        memory: 256Mi
      requests:
        cpu: 100m
        memory: 256Mi

注意,在已经配置了limitrange资源的情况下,不会去查找limitrange里面的默认值配置。 request直接就是与limits一样。

只有requests

如果只设置了requests,一般情况下也就这样了, 没有limits

如果配置了limitrange,并且有limits的默认值,会填充默认值。
在运行的文件里也可以看到。

同样的,如果requestslimits都没有配置, 也就没有配置了。还是要看limitrange里有没有默认值。


三、服务质量QOS类

QoS类来决定 Pod 的调度和驱逐策略。

Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类:
Guaranteed
Burstable
BestEffort

Guaranteed

Pod 中的每个容器,包括初始化容器,必须指定内存与cpu的requestslimits, 并且两者要相等。
如:

[root@k8smaster1 ~]# kubectl get pods/centos7-56d784d4cd-lbzt5 -o yaml
......
    resources:
      limits:
        cpu: 100m
        memory: 256Mi
      requests:
        cpu: 100m
        memory: 256Mi
......
  qosClass: Guaranteed

注意:

只要requestslimits都配置了内存cpu, 并且都一样就是Guaranteed
无论是不是默认值。 如下面的情况也同样是Guaranteed

  1. 只配置了limits, request就会跟limits一样。
  2. 只配置了request, limits通过limitrange的配置默认值,跟request一样。
  3. 什么也没有配置, limitrange里面有requestslimits的默认值,并且都一样。

Burstable

Pod 不符合 Guaranteed QoS 类的标准, Pod 中至少一个容器具有内存或 CPU requests

总的来说就是随便有一个限制就行,无论是limits还是requests,因为limits有了,requests也就有了。 然后不要符合Guaranteed的标准。

BestEffort

Pod 中的容器必须没有设置内存和 CPU requestslimits

就是所有容器都没有配置资源限制,干干净净。


驱逐方面的:
https://kubernetes.io/zh/docs/tasks/administer-cluster/out-of-resource/