Kubernetes 资源管理QoS、LimitRange和ResourceQuota

2019-08-15 12:00:00 kubernetes limitRange resourceQuota qos

文章目录

系统环境：

Kubernetes 版本：1.14.0

Kubernetes 官方文档地址:

Kubernetes 资源管理

一、资源简介

Kubernetes 中有 Node 和 Pod 两种基础概念。一个 Node 就是 Kubernetes 集群中的一个节点，这个节点为 Kubernetes 提供计算资源（CPU、Memory、GPU等），并且由很多 Pod 组成，一个 Pod 是 Kubernetes 中部署的最小的单位，由多个容器组成，这些容器会占用 Node 提供的资源来保持运行。当 Kubernetes 集群中计算资源不足时（如 Pod 占用资源过多），为了避免 Kubernetes 某个 Node 瘫痪，Kubernetes 会清理已经存在的资源，比如杀死 Pod 来完成资源释放。为了避免或降低由于资源不足时导致 Pod 被杀死这种情况发生导致的风险，Kubernetes 提供了资源限制的机制，其核心如下：

限制 Pod 资源占用率；
为 Pod 划分等级(QoS)，当资源不足时先杀死等级低的 Pod 来释放资源；

在 Kubernetes 中资源又可分为 API资源 与 计算资源，API 资源主要包括 Pod、Service、Deployment 等，计算资源主要包括 CPU、GPU 及 Memory 等，在计算资源中资源可分成 可压缩资源 与 不可压缩资源，因为在资源不足的时候，它们的表现不一样，对于不可压缩资源，资源不足也就无法继续申请资源（例如内存不足是无法再分配的），并且会导致 Pod 的运行产生无法预测的错误。对于可压缩资源，如 CPU 时间片，即使 Pod 使用的 CPU 资源很多，CPU 使用也可以按照权重分配给所有 Pod 使用，虽然当某个 Pod 分配 CPU 过多时使其它 Pod 能够使用 CPU 的时间片减少，但不会导致程序直接不可用。

二、Pod 资源配置参数

Pod 中可以配置 CPU 与 Memory 参数，如下：

spec.container[].resources.requests.cpu
spec.container[].resources.requests.memory
spec.container[].resources.limits.cpu
spec.container[].resources.limits.memory

其中 requests 是设置容器使用 CPU 与 Memory 资源占用预估值，它将作为容器调度分资源分配时的判断依据，只有当前节点上可分配的资源量大于 requests 中设置的值时才允许容器调度到该节点。limits 是对容器使用 CPU 与 Memory 资源的上限，由于 CPU 是属于可压缩资源，Pod 是无法突破其设置值的上限的，而 Memory 是不可压缩资源，当 Pod 突破内存上限时 Kubernetes 会杀死该 Pod，所以设置内存限制时得慎重考虑。

1、CPU 与 Memory

CPU

CPU 的 Requests 和 Limites 能设置的值跟 CPU 的核心数息息相关，CPU 的资源值是个绝对值，0.1 CPU（100m）不论在单核心 CPU 的服务器上还是多核心 CPU 的服务器上，都是等于 0.1 CPU。

Memory

Memory 可以设置的 Requests 和 Limits 单位是字节数，需要整数加国际单位来表示内存值。

国际单位制：

十进制：E、P、T、G、M、K、m
二进制：Ei、Pi、Ti、Gi、Mi、Ki、MiB

比如：

1 KB = 1000 Bytes = 8000 Bits；
1 KiB = 1024 Bytes = 8192 Bits；

一般推荐 CPU 是用 m，例如 0.1 个 CPU 使用 100m 表示，1 个 CPU 用 1000m 表示；对于内存推荐使用 Mi，例如 256Mi、512Mi、1Gi。

2、限额参数原理简介

对于 Docker 对资源的限制及其参数的理解，可以查看 Docker 官方文档。

(1)、requests.cpu

在上面参数 spec.container[].resources.requests.cpu 设置的值会转换为 CPU 核心数，这个值乘以 1024 得到的结果，会作为 docker run 命令执行时 --cpu-shares 的参数。--cpu-shares 参数是一个相对权重值，这个相对权重值会决定 Docker 在资源竞争时调整分配给容器可用资源的比例，默认对所有的容器的 CPU 资源可利用的占比都一致，即 1024。这个值可以设置为 2 个 CPU（值为 2048）或者 3 个 CPU（值为 3072）依次类推。

例如，启动两个容器且设置 --cpu-shares 参数分别为 1024 和 2048，在主机 CPU 资源产生竞争时 Docker 会按照 1:2 的比例将 CPU 资源分配刚给这两个容器使用。

由上可知 requests.cpu 参数对 kubernetes 来说这个值是一个绝对值，用于 Kubernetes 调度与管理，对于 Docker 来说是相对值，用于 CPU 资源比例分配。

(2)、limits.cpu

在 Docker 中有两个参数 --cpu-quota 和 --cpu-period，这两个参数一般配合使用，其中 --cpu-period 是指使用 CPU 调度程序的周期，单位 μs （微秒），而 --cpu-quota 为在周期内使用 CPU 的配额，单位也是 μs（微秒）。例如，如何运行一个 Docker 容器并且设置它可用 CPU 为 1.5 个，那么就可用设置参数 --cpu-period=100000（100ms） 和 --cpu-quota=150000（150ms），这说明在 100ms 配置 150ms 的 CPU 量来完成任务，150/100 = 1.5，所以即完成 1.5 个 CPU 的分配，关于 Docker 如何实现的这个限制功能，具体可用看内核的 CPU 分配策略。

回头看看 Kubernetes 中的参数 spec.container[].resources.limits.cpu 如何限制 CPU 的，其实也是利用上面两个参数进行限制 CPU 使用的，利用公式 (limits.cpu * 100000)/1000 得出结果的值作为 --cpu-quota 参数值，且将 --cpu-period 参数值设置为 100000，然后这两个参数进行计算得出可用的 CPU 时间分片。例如，在 Kubernetes 中想限制只使用 0.1 个 CPU，就可以设置 limits.cpu = 100m，然后可以按照上面公式计算一下，(100 * 100000)/1000 = 10000，将这个值赋给 --cpu-quota 参数，然后 Kubernetes 设置 --cpu-period 参数默认为 100000，计算 Docker 分配容器最终 CPU 使用量为 --cpu-quota/--cpu-period 即 10000/100000 = 0.1，符合 Kubernetes 中对 CPU 的限制。

(3)、requests.memory

内存占用值，标识一般正常情况下镜像使用的内存量，这个参数值不会传递给 Docker，它一般供 Kubernetes 调度器调度和作为资源使用指标的依据。

(4)、limits.memory

容器内存限制，一般这个设置的值会传递给 Docker 启动时的 --memory 参数，用于限制启动的容器的内存使用大小，如果容器在运行过程中内存使用飙升超过这个限制的值，那么该容器可能会被杀掉，所以一般设置此值需要提前测试一下程序占用内存可能的值，进而考虑设置它的值的大小。

3、limits 与 requests 使用示例

下面写个简单的 Deployment 对象来加上 resources 配置，进行对启动的 Pod 资源限制：

 1apiVersion: apps/v1
 2kind: Deployment
 3metadata:
 4  name: nginx
 5spec:
 6  selector:
 7    matchLabels:
 8      app: nginx
 9  replicas: 1
10  template:
11    metadata:
12      labels:
13        app: nginx
14    spec:
15      containers:
16      - name: nginx
17        image: nginx:latest
18        ports:
19        - containerPort: 80
20        resources:
21          requests:
22            cpu: "100m"
23            memory: "256Mi"
24          limits:
25            cpu: "500m"
26            memory: "512Mi"

4、Requests 和 Limits 对调度器调度的影响

在 Kubernetes 中，每次创建 Pod 都是将其启动到 Kubernetes Node 节点上面，每个节点的计算资源（例如 CPU、Memory）是有限制的，该节点上所以的 Pod 占用资源大小综合不能超过节点所拥有的真实的资源大小。

这里举个例子，例如一个节点上拥有 10GB 内存，在这个节点上启动 limits.memory=2GB,requests.memory=1GB 的 Pod。考虑到系统占用资源情况，所以该节点最多启 9 个一样的 Pod。一般 Pod 中可设置的 requests 参数值会影响到调度器对 Pod 的调度，而 limits 参数主要是对容器可用资源的限制，对资源的调度影响比较小。

三、QoS 资源服务质量控制

1、QoS 等级分类

Kubernetes 中如果一个 Node 节点上的 Pod 占用资源过多并且不断飙升导致 Node 节点资源不足，可能会导致为了保证节点可用，将容器被杀掉。在遇见这种情况时候，我们希望先杀掉那些不太重要的容器，确保核心容器不会首先被杀掉。为了衡量先杀掉哪个程序，所以推出了优先级机制 QoS （Quality of Service）来做判断，Kubernetes 将容器划分为三种 QoS 等级：

Guaranteed： 完全可靠的。
Burstable： 较可靠的。
BestEffort： 不太可靠的。

2、Kubernetes Pod QoS 特点

在 Kubernetes 中资源不足时，根据 QoS 等级杀死 Pod 会有以下特点：

BestEffort Pod： 优先级最低，在 Kubernetes 资源不足时候会将此 Pod 先杀掉。
Burstable Pod： 优先级居中，如果整个系统内存资源不足，且已经杀完全部 BestEffort 等级的 Pod 时可能被杀掉。
Guaranteed Pod： 优先级最高，一般情况下不会被杀掉，除非资源不足且系统 BestEffort 和 Burstable 的 Pod 都不存在的情况下，才可能被杀掉。

3、Pod 是如何分 QoS 等级

Kubernetes 中 Qos 等级是根据 Limits 和 Requests 这两个参数设置的值息息相关，Kubernetes 会根据这两个值的不同而给 Pod 设置不同的 QoS 等级。

（1）、Guaranteed （等级-最高）

如果 Pod 中所有容器都定义了 Limits 和 Requests，并且全部容器的 Limits 值 = Requests 值（值不能为0），那么该 Pod 的 QoS 级别就是 Guaranteed。

注意：这种情况下容器可以只设置 Limits 值即可，引入在只设置 Limits 不设置 Requests 情况下，Requests 值默认等于 Limits 的值。

（2）、BestEffort（等级-最低）

如果 Pod 中所有容器都未定义 Requests 和 Limits 值，该 Pod 的 Qos 即为 BestEffort。

（3）、Burstable（等级-中等）

当一个 Pod 既不是 Guaranteed 级别，也不说 BestEffort 级别时候，该 Pod 的 QoS 级别就是 Burstable。例如，Pod 中全部或者部分容器 Requests 和 Limits 都定义，且 Requests 小于 Limits 值，或者 Pod 中一部分容器未定义 Requests 和 Limits 资源时。

4、三种 Qos 的示例

（1）、Guaranteed

每个容器都设置 Limits 而不设置 Requests：

 1containers:
 2  - name: example-container1
 3    resources:
 4      limits:
 5        cpu: 10m
 6        memory: 512Mi
 7  - name: example-container2
 8    resources:
 9      limits:
10        cpu: 100m
11        memory: 100Mi

每个容器都设置 Limits 值和 Requests 值都相等：

 1containers:
 2  - name: example-container1
 3    resources:
 4      limits:
 5        cpu: 100m
 6        memory: 512Mi
 7      requests:
 8        cpu: 100
 9        memory: 512Mi
10  - name: example-container2
11    resources:
12      limits:
13        cpu: 200m
14        memory: 256Mi
15      requests:
16        cpu: 200
17        memory: 256Mi

（2）、BestEffort

Pod 中的所有容器都未定义 Requests 和 Limits：

1containers:
2  - name: example-container1
3    resources:
4  - name: example-container2
5    resources:

（3）、Burstable

Pod 中只要有一个容器的 Requests 和 Limits 的设置的值不相同：

 1containers:
 2  - name: example-container1
 3    resources:
 4      limits:
 5        cpu: 100m
 6        memory: 512Mi
 7      requests:
 8        cpu: 100
 9        memory: 512Mi
10  - name: example-container2
11    resources:
12      limits:
13        cpu: 200m
14        memory: 256Mi
15      requests:
16        cpu: 100
17        memory: 128Mi

Pod 都存在 Limits，但是 Limits 中限制的类型不同：

1containers:
2  - name: example-container1
3    resources:
4      limits:
5        memory: 512Mi
6  - name: example-container2
7    resources:
8      limits:
9        cpu: 200m

Pod 中两个容器只有一个 Limits ，另一个都没有设置：

 1containers:
 2  - name: example-container1
 3    resources:
 4      limits:
 5        cpu: 100m
 6        memory: 512Mi
 7      requests:
 8        cpu: 100
 9        memory: 512Mi
10  - name: example-container2
11    resources:

四、资源范围管理对象 LimitRange

默认情况下如果创建一个 Pod 没有设置 Limits 和 Requests 对其加以限制，那么这个 Pod 可能能够使用 Kubernetes 集群中全部资源，但是每创建 Pod 资源时都加上这个动作是繁琐的，考虑到这点 Kubernetes 提供了 LimitRange 对象，它能够对一个 Namespace 下的全部 Pod 使用资源设置默认值、并且设置上限大小和下限大小等操作。这里演示将使用 LimitRange 来限制某个 namespace 下的资源的测试用例。

1、创建测试用的 Namespace

考虑到 LimitRange 是作用于 Namespace 的，所以这里提前创建一个用于测试的 Namespace。

1$ kubectl create namespace limit-namespace

2、创建 LimitRange 对 Namespace 资源限制

创建一个 LimitRange 对象限制 Namespace 下的资源使用，其中 limit 的类型有两种：

对 Container 使用资源进行限制，在 Pod 中的每一个容器都受此限制。
对 Pod 进行限制，即 Pod 中全部 Container 使用资源总和来进行限制。

资源对象 limit-range.yaml 内容如下：

 1apiVersion: v1
 2kind: LimitRange
 3metadata:
 4  name: limit-test
 5spec:
 6  limits:
 7    - type: Pod        #对Pod中所有容器资源总和进行限制
 8      max:
 9        cpu: 4000m
10        memory: 2048Mi 
11      min:
12        cpu: 10m
13        memory: 128Mi 
14      maxLimitRequestRatio:
15        cpu: 5
16        memory: 5
17    - type: Container  #对Pod中所有容器资源进行限制
18      max:
19        cpu: 2000m
20        memory: 1024Mi
21      min:
22        cpu: 10m
23        memory: 128Mi 
24      maxLimitRequestRatio:
25        cpu: 5
26        memory: 5
27      default:
28        cpu: 1000m
29        memory: 512Mi
30      defaultRequest:
31        cpu: 500m
32        memory: 256Mi

注意：LimitRange 类型为 Pod 中，不能设置 Default。

执行 Kubectl 创建 LimitRange：

1$ kubectl apply -f limit-range.yaml -n limit-namespace

3、查看创建后的 LimitRange

 1$ kubectl describe limitrange limit-test -n limit-namespace
 2
 3Name:       limit-test
 4Namespace:  limit-namespace
 5Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio
 6----        --------  ---    ---  ---------------  -------------  -----------------------
 7Pod         cpu       10m    4    -                -              5
 8Pod         memory    128Mi  2Gi  -                -              5
 9Container   cpu       10m    2    500m             1              5
10Container   memory    128Mi  1Gi  256Mi            512Mi          5

可以看到上面 LimitRange 对象中的配置可以了解到，如果容器使用默认值，则容器的 Request 和 Limits 一致。

4、对 LimitRange 对象参数介绍

Container 参数：

max： Pod 中所有容器的 Limits 值上限。
min： Pod 中所有容器的 Requests 值下限。
default： Pod 中容器未指定 Limits 时，将此值设置为默认值。
defaultRequest： Pod 中容器未指定 Requests 是，将此值设置为默认值。
maxLimitRequestRatio： Pod 中的容器设置 Limits 与 Requests 的比例的值不能超过 maxLimitRequestRatio 参数设置的值，即 Limits/Requests ≤ maxLimitRequestRatio。

Pod 参数：

max： Pod 中所有容器资源总和值上限。
min： Pod 中所有容器资源总和值下限。
maxLimitRequestRatio： Pod 中全部容器设置 Limits 总和与 Requests 总和的比例的值不能超过 maxLimitRequestRatio 参数设置的值，即 (All Container Limits)/(All Container Requests) ≤ maxLimitRequestRatio。

5、创建 Pod 来进行测试

（1）、Container 默认值测试

创建下面 Pod 对象，并观察创建后是否有默认的资源限制。

1apiVersion: v1
2kind: Pod
3metadata:
4  name: test
5spec:
6  containers:
7  - name: nginx1
8    image: nginx:latest

查看 Pod 的描述信息，可以看到 Limits 和 Requests 的值和上面 LimitRange 中配置的默认值一致。

1Containers:
2  nginx1:
3    Limits:
4      cpu:     1000m
5      memory:  512Mi
6    Requests:
7      cpu:     500m
8      memory:  256Mi

（2）、Container Max 限制测试

上面设置 Max 中 CPU 和 Memory 的值分别为 2000m 与 1024Mi，下面创建一个 Pod 并设置其中某一个容器 limits 值超过 LimitRange 中设置的值，查看是否能起到限制作用。Pod 内容如下：

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: test
 5spec:
 6  containers:
 7  - name: nginx1
 8    image: nginx:latest
 9  - name: nginx2
10    image: nginx:latest
11    resources:
12      limits:
13        cpu: "3000m"
14        memory: "512Mi"

执行 Kubectl 命令创建 Pod 时并没有通过验证，并且已经提示 CPU 不能超过 2 个：

1$ kubectl apply -f test.yaml -n limit-namespace
2
3Error from server (Forbidden): error when creating "test.yaml": 
4pods "test" is forbidden: maximum cpu usage per Container is 2, but limit is 3.

（3）、Container Min 限制测试

上面设置 Min 中 CPU 和 Memory 的值分别为 10m 与 128Mi，下面创建一个 Pod 并设置其中某一个容器 Requests 值小于 LimitRange 中设置的值，是否能起到限制作用。Pod 内容如下：

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: test
 5spec:
 6  containers:
 7  - name: nginx1
 8    image: nginx:latest
 9  - name: nginx2
10    image: nginx:latest
11    resources:
12      requests:
13        cpu: "100m"
14        memory: "64Mi"

执行 Kubectl 命令创建 Pod 时并没有通过验证，并且已经提示 Memory 不能低于 128Mi 大小：

1$ kubectl apply -f test.yaml -n limit-namespace
2
3Error from server (Forbidden): error when creating "test.yaml": pods "test" is forbidden: 
4[minimum memory usage per Container is 128Mi, but request is 64Mi.
5, cpu max limit to request ratio per Container is 5, but provided ratio is 10.000000.
6, memory max limit to request ratio per Container is 5, but provided ratio is 8.000000.]

（4）、Container MaxLimitRequestRatio 限制测试

上面 LimitRange 中设置 maxLimitRequestRatio 值为 5，就是限制 Pod 中容器 CPU 和 Memory 的 limit/request 的值小于 5,这里测试一下设置内存 limit/request 中值超过 5 创建 Pod 是否会报错。Pod 内容如下：

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: test
 5spec:
 6  containers:
 7  - name: nginx1
 8    image: nginx:latest
 9  - name: nginx2
10    image: nginx:latest
11    resources:
12      requests:
13        cpu: "100m"
14        memory: "128Mi"
15      limits:
16        cpu: "200m"
17        memory: "1024Mi"

执行 Kubectl 命令创建 Pod 时并没有通过验证，并且已经提示 limit/request ratio 为 8，超过了限制的值 5：

1$ kubectl apply -f test.yaml -n limit-namespace
2
3Error from server (Forbidden): error when creating "test.yaml": 
4pods "test" is forbidden: memory max limit to request ratio per Container is 5, but provided ratio is 8.000000.

五、资源配额管理对象 ResourcesQuota

Kubernetes 是一个多租户平台，更是一个镜像集群管理工具。一个 Kubernetes 集群中的资源一般是由多个团队共享的，这时候经常要考虑的是如何对这个整体资源进行分配。在 kubernetes 中提供了 Namespace 来讲应用隔离，那么是不是也能将资源的大小跟 Namespace 挂钩进行一起隔离呢？这当然是可以的，Kubernetes 提供了 Resources Quotas 工具，让集群管理员可以创建 ResourcesQuota 对象管理这个集群整体资源的配额，它可以限制某个 Namespace 下计算资源的使用量，也可以设置某个 Namespace 下某种类型对象的上限等。

上面说白了就是，通过设置不同的 Namespace 与对应的 RBAC 权限将各个团队隔离，然后通过 ResourcesQuota 对象来现在该 Namespace 能够拥有的资源的多少。

1、开启资源配额 ResourceQuota

ResourceQuota 对象一般在 Kubernetes 中是默认开启的，如果未开启且不能创建该对象，那么可以进入 Master 的 Kubernetes 配置目录修改 Apiserver 配置文件 kube-apiserver.yaml，在添加参数 --admission-control=ResourceQuota 来开启。

1spec:
2  containers:
3  - command:
4    - kube-apiserver
5    - --advertise-address=192.168.2.11
6    - --allow-privileged=true
7    - --authorization-mode=Node,RBAC
8    - --admission-control=ResourceQuota    #开启ResourceQuota
9    - ......

注意：一个 Namespace 中可以拥有多个 ResourceQuota 对象。

2、配额资源类型

计算资源配额： 限制一个 Namespace 中所有 Pod 的计算资源（CPU、Memory）的总和。
存储资源配额： 限制一个 Namespace 中所有存储资源的总量。
对象数量配额： 限制一个 Namespace 中指定类型对象的数量。

（1）、ResourcesQuota 支持的计算资源：

cpu：所有非终止状态的Pod中，其CPU需求总量不能超过该值。
limits.cpu：所有非终止状态的Pod中，其CPU限额总量不能超过该值。
limits.memory：所有非终止状态的Pod中，其内存限额总量不能超过该值。
memory：所有非终止状态的Pod中，其内存需求总量不能超过该值。
requests.cpu：所有非终止状态的Pod中，其CPU需求总量不能超过该值。
requests.memory：所有非终止状态的Pod中，其内存需求总量不能超过该值。

（2）、ResourcesQuota 支持限制的存储资源：

requests.storage：所有 PVC 请求的存储大小总量不能超过此值。
Persistentvolumeclaims： PVC 对象存在的最大数目。
.storageclass.storage.k8s.io/requests.storage：和 StorageClass 关联的 PVC 的请求存储的量大小不能超过此设置的值。
.storageclass.storage.k8s.io/persistentvolumeclaims：和 StorageClass 关联的 PVC 的总量。

（3）、ResourcesQuota 支持限制的对象资源：

Configmaps：允许存在的 ConfigMap 的数量。
Pods：允许存在的非终止状态的 Pod 数量，如果 Pod 的 status.phase 为 Failed 或 Succeeded ，那么其处于终止状态。
Replicationcontrollers：允许存在的 Replication Controllers 的数量。
Resourcequotas：允许存在的 Resource Quotas 的数量。
Services：允许存在的 Service 的数量。
services.loadbalancers：允许存在的 LoadBalancer 类型的 Service 的数量。
services.nodeports：允许存在的 NodePort 类型的 Service 的数量。
Secrets：允许存在的 Secret 的数量。

3、配额作用域

每个配额都有一组相关的作用域（scope），配额只会对作用域内的资源生效。当一个作用域被添加到配额中后，它会对作用域相关的资源数量作限制，如配额中指定了允许（作用域）集合之外的资源，会导致验证错误。

Terminating：匹配 spec.activeDeadlineSeconds ≥ 0 的 Pod。
NotTerminating：匹配 spec.activeDeadlineSeconds 是 nil（空）的 Pod。
BestEffort：匹配所有 QoS 等级是 BestEffort 级别的 Pod。
NotBestEffort：匹配所有 QoS 等级不是 BestEffort 级别的 Pod。

BestEffort 作用域限制配额跟踪以下资源：

pods

Terminating、 NotTerminating 和 NotBestEffort 限制配额跟踪以下资源：

cpu
limits.cpu
limits.memory
memory
pods
requests.cpu
requests.memory

4、ResourceQuota 使用示例

（1）、设置某 Namespace 计算资源的配额

创建 resources-test1.yaml 用于设置计算资源的配额：

 1apiVersion: v1
 2kind: ResourceQuota
 3metadata:
 4  name: compute-resources
 5spec:
 6  hard:
 7    pods: "4"
 8    requests.cpu: "1"
 9    requests.memory: 1Gi
10    limits.cpu: "2"
11    limits.memory: 2Gi

创建该配额对象：

-n：指定限制配额的 namespace

1$ kubectl apply -f resources-test1.yaml -n limit-namespace

查看创建后的 ResourcesQuota 配额的详细信息:

 1$ kubectl describe quota compute-resources -n limit-namespace
 2
 3Name:            compute-resources
 4Namespace:       limit-namespace
 5Resource         Used   Hard
 6--------         ----   ----
 7limits.cpu       2      2
 8limits.memory    1Gi    2Gi
 9pods             2      4
10requests.cpu     2      1
11requests.memory  512Mi  1Gi

（2）、设置某 Namespace 对象数量的配额

创建 resources-test2.yaml 用于设置对象数量的配额：

 1apiVersion: v1
 2kind: ResourceQuota
 3metadata:
 4  name: object-counts
 5spec:
 6  hard:
 7    configmaps: "10"
 8    persistentvolumeclaims: "4"
 9    replicationcontrollers: "20"
10    secrets: "10"
11    services: "10"
12    services.loadbalancers: "2"

创建该配额对象：

1$ kubectl apply -f resources-test2.yaml -n limit-namespace

查看创建后的 ResourcesQuota 配额的详细信息:

 1$ kubectl describe quota object-counts -n limit-namespace
 2
 3Name:                   object-counts
 4Namespace:              limit-namespace
 5Resource                Used  Hard
 6--------                ----  ----
 7configmaps              0     10
 8persistentvolumeclaims  0     4
 9replicationcontrollers  0     20
10secrets                 1     10
11services                0     10
12services.loadbalancers  0     2

（3）、限制 Namespace 下 Pod 数量并只作用域 BestEffort

创建 resources-test3.yaml 用于设置 Pod 对象数量的配额，并设置作用域 BestEffort：

1apiVersion: v1
2kind: ResourceQuota
3metadata:
4  name: besteffort
5spec:
6  hard:
7    pods: "5"
8  scopes:
9  - BestEffort

创建该配额对象：

1$ kubectl apply -f resources-test3.yaml -n limit-namespace

查看创建后的 ResourcesQuota 配额的详细信息:

1$ kubectl describe quota besteffort -n limit-namespace
2
3Name:       besteffort
4Namespace:  limit-namespace
5Scopes:     BestEffort
6 * Matches all pods that do not have resource requirements set. These pods have a best effort quality of service.
7Resource  Used  Hard
8--------  ----  ----
9pods      0     5

上面配额对象创建完成后，可以创建几个 Pod 对其配额规则进行验证。

到此资源管理介绍完毕，在实际使用过程中应当统计集群资源总量，然后按需分配给各个 Namespace 一定配额，如果想限制 Pod 使用资源的大小，就可以创建 LimitRange 来完成这个限制规则。最后说一句，创建 Pod 时候最好考虑好 Pod 的 QoS 优先级。

---END---