k8s 资源约束

系统环境：Kubernetes 版本：1.14.0

# 1. 资源简介

Kubernetes 中有 Node 和 Pod 两种基础概念。

Node：一个 Node 就是 Kubernetes 集群中的一个节点，这个节点为 Kubernetes 提供计算资源（CPU、Memory、GPU等），并且由很多 Pod 组成，
Pod：一个 Pod 是 Kubernetes 中部署的最小的单位，由多个容器组成，这些容器会占用 Node 提供的资源来保持运行。

当 Kubernetes 集群中计算资源不足时（如 Pod 占用资源过多），为了避免 Kubernetes 某个 Node 瘫痪，Kubernetes 会清理已经存在的资源，比如杀死 Pod 来完成资源释放。为了避免或降低由于资源不足时导致 Pod 被杀死这种情况发生导致的风险，Kubernetes 提供了资源限制的机制，其核心如下：

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

在 Kubernetes 中资源又可分为 API 资源和计算资源。

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

# 2. Pod 资源配置参数

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

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

1
2
3
4

其中：

requests 是设置容器使用 CPU 与 Memory 资源占用预估值，它将作为容器调度分资源分配时的判断依据，只有当前节点上可分配的资源量大于 requests 中设置的值时才允许容器调度到该节点。

limits 是对容器使用 CPU 与 Memory 资源的上限，由于 CPU 是属于可压缩资源，Pod 是无法突破其设置值的上限的，而 Memory 是不可压缩资源，当 Pod 突破内存上限时 Kubernetes 会杀死该 Pod，所以设置内存限制时得慎重考虑。

# 2.1 CPU 与 Memory

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

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.2 限额参数原理简介

# 2.2.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.2.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

1
2

这说明在 100ms 配置 150ms 的 CPU 量来完成任务，150⁄100 = 1.5，所以即完成 1.5 个 CPU 的分配，关于 Docker 如何实现的这个限制功能，具体可以看内核的 CPU 分配策略。

Kubernetes 中的参数 spec.container[].resources.limits.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 的限制。

# 2.2.3 requests.memory

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

# 2.2.4 limits.memory

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

# 2.3 limits 与 requests 使用示例

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 2.4 Requests 和 Limits 对调度器调度的影响

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

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

# 3. QoS 资源服务质量控制

# 3.1 QoS 等级分类

Kubernetes 中如果一个 Node 节点上的 Pod 占用资源过多并且不断飙升导致 Node 节点资源不足，可能会导致为了保证节点可用，将容器被杀掉。

在遇见这种情况的时候，我们希望先杀掉那些不太重要的容器，确保核心容器不会首先被杀掉。为了衡量先杀掉哪个程序，所以推出了优先级机制 QoS （Quality of Service）来做判断。

Kubernetes 将容器划分为三种 QoS 等级：

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

# 3.2 Kubernetes Pod QoS 特点

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

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

# 3.3 Pod 是如何分 QoS 等级

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

Guaranteed （等级-最高）

如果 Pod 中所有容器都定义了 Limits 和 Requests，并且全部容器的 Limits 值 = Requests 值（值不能为0），那么该 Pod 的 QoS 级别就是 Guaranteed。注意：这种情况下容器可以只设置 Limits 值即可，引入在只设置 Limits 不设置 Requests 情况下，Requests 值默认等于 Limits 的值。

BestEffort（等级-最低）

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

Burstable（等级-中等）

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

# 3.4 三种 Qos 的示例

# 3.4.1 Guaranteed 完全可靠的

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

containers:
  - name: example-container1
    resources:
      limits:
        cpu: 10m
        memory: 512Mi
  - name: example-container2
    resources:
      limits:
        cpu: 100m
        memory: 100Mi

1
2
3
4
5
6
7
8
9
10
11

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

containers:
  - name: example-container1
    resources:
      limits:
        cpu: 100m
        memory: 512Mi
      requests:
        cpu: 100
        memory: 512Mi
  - name: example-container2
    resources:
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 200
        memory: 256Mi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 3.4.2 BestEffort 不太可靠的

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

containers:
  - name: example-container1
    resources:
  - name: example-container2
    resources:

1
2
3
4
5

# 3.4.3 Burstable 较可靠的

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

containers:
  - name: example-container1
    resources:
      limits:
        cpu: 100m
        memory: 512Mi
      requests:
        cpu: 100
        memory: 512Mi
  - name: example-container2
    resources:
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 100
        memory: 128Mi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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

containers:
  - name: example-container1
    resources:
      limits:
        memory: 512Mi
  - name: example-container2
    resources:
      limits:
        cpu: 200m

1
2
3
4
5
6
7
8
9

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

containers:
  - name: example-container1
    resources:
      limits:
        cpu: 100m
        memory: 512Mi
      requests:
        cpu: 100
        memory: 512Mi
  - name: example-container2
    resources:

1
2
3
4
5
6
7
8
9
10
11

# 4. LimitRange 资源范围管理对象

默认情况下如果创建一个 Pod 没有设置 Limits 和 Requests 对其加以限制，那么这个 Pod 可能能够使用 Kubernetes 集群中全部资源，但是每创建 Pod 资源时都加上这个动作是繁琐的，考虑到这点 Kubernetes 提供了 LimitRange 对象。

它能够对一个 Namespace 下的全部 Pod 使用资源设置默认值、并且设置上限大小和下限大小等操作。这里演示将使用 LimitRange 来限制某个 namespace 下的资源的测试用例。

# 4.1 创建测试用的 Namespace

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

$ kubectl create namespace limit-namespace

# 4.2 创建 LimitRange 对 Namespace 资源限制

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

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

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

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-test
spec:
  limits:
    - type: Pod        #对Pod中所有容器资源总和进行限制
      max:
        cpu: 4000m
        memory: 2048Mi
      min:
        cpu: 10m
        memory: 128Mi
      maxLimitRequestRatio:
        cpu: 5
        memory: 5
    - type: Container  #对Pod中所有容器资源进行限制
      max:
        cpu: 2000m
        memory: 1024Mi
      min:
        cpu: 10m
        memory: 128Mi
      maxLimitRequestRatio:
        cpu: 5
        memory: 5
      default:
        cpu: 1000m
        memory: 512Mi
      defaultRequest:
        cpu: 500m
        memory: 256Mi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

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

执行 Kubectl 创建 LimitRange：

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

# 4.3 查看创建后的 LimitRange

$ kubectl describe limitrange limit-test -n limit-namespace
Name:       limit-test
Namespace:  limit-namespace
Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio

----        --------  ---    ---  ---------------  -------------  -----------------------

Pod         cpu       10m    4    -                -              5
Pod         memory    128Mi  2Gi  -                -              5
Container   cpu       10m    2    500m             1              5
Container   memory    128Mi  1Gi  256Mi            512Mi          5

1
2
3
4
5
6
7
8
9
10
11

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

# 4.4 对 LimitRange 对象参数介绍

Container 参数：

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

Pod 参数：

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

# 4.5 创建 Pod 来进行测试

# 4.5.1 Container 默认值测试

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

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: nginx1
    image: nginx:latest
    // 查看 Pod 的描述信息，可以看到 Limits 和 Requests 的值和上面 LimitRange 中配置的默认值一致。
    Containers:
    nginx1:
    Limits:
      cpu:     1000m
      memory:  512Mi
    Requests:
      cpu:     500m
      memory:  256Mi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 4.5.2 Container Max 限制测试

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

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: nginx1
    image: nginx:latest
  - name: nginx2
    image: nginx:latest
    resources:
      limits:
        cpu: "3000m"
        memory: "512Mi"

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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

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

1
2
3

# 4.5.3 Container Min 限制测试

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

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: nginx1
    image: nginx:latest
  - name: nginx2
    image: nginx:latest
    resources:
      requests:
        cpu: "100m"
        memory: "64Mi"

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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

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

1
2
3
4
5

4.5.4 Container MaxLimitRequestRatio 限制测试

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

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: nginx1
    image: nginx:latest
  - name: nginx2
    image: nginx:latest
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "1024Mi"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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

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

1
2
3

# 5. ResourcesQuota 资源配额管理对象

Kubernetes 是一个多租户平台，更是一个镜像集群管理工具。一个 Kubernetes 集群中的资源一般是由多个团队共享的，这时候经常要考虑的是如何对这个整体资源进行分配。

在 kubernetes 中提供了 Namespace 来将应用隔离，那么是不是也能将资源的大小跟 Namespace 挂钩进行一起隔离呢？这当然是可以的，Kubernetes 提供了 Resources Quotas 工具，让集群管理员可以创建 ResourcesQuota 对象管理这个集群整体资源的配额，它可以限制某个 Namespace 下计算资源的使用量，也可以设置某个 Namespace 下某种类型对象的上限等。

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

# 5.1 开启资源配额 ResourceQuota

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

spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.2.11
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --admission-control=ResourceQuota    #开启ResourceQuota
    - ......

1
2
3
4
5
6
7
8
9

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

# 5.2 配额资源类型

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

# 5.2.1 支持限制的计算资源：

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

# 5.2.2 支持限制的存储资源：

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

# 5.2.3 支持限制的对象资源：

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 的数量。

# 5.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

# 5.4 ResourceQuota 使用示例

# 5.4.1 设置某 Namespace 计算资源的配额

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

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

1
2
3
4
5
6
7
8
9
10
11

创建该配额对象：

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

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

$ kubectl describe quota compute-resources -n limit-namespace
Name:            compute-resources
Namespace:       limit-namespace
Resource         Used   Hard
--------         ----   ----
limits.cpu       2      2
limits.memory    1Gi    2Gi
pods             2      4
requests.cpu     2      1
requests.memory  512Mi  1Gi

1
2
3
4
5
6
7
8
9
10

# 5.4.2 设置某 Namespace 对象数量的配额

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

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"

1
2
3
4
5
6
7
8
9
10
11
12

创建该配额对象：

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

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

$ kubectl describe quota object-counts -n limit-namespace

Name:                   object-counts
Namespace:              limit-namespace
Resource                Used  Hard
--------                ----  ----
configmaps              0     10
persistentvolumeclaims  0     4
replicationcontrollers  0     20
secrets                 1     10
services                0     10
services.loadbalancers  0     2

1
2
3
4
5
6
7
8
9
10
11
12

# 5.4.3 限制 Namespace 下 Pod 数量并只作用域 BestEffort

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

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "5"
  scopes:
  - BestEffort

1
2
3
4
5
6
7
8
9

创建该配额对象：

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

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

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

1
2
3
4
5
6
7
8

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

上次更新: 2022/10/05, 15:47:59

← k8s 调度约束 k8s 健康检测→