【云原生|Kubernetes】09-Pod的CPU和内存的请求与限制

简介

在 Kubernetes 中，请求（request）和限制（limit）是用于管理容器资源的两个重要概念。

• 请求是指容器所需的资源量，可以视为容器启动时保证其正常运行所需的最小资源量。例如，如果一个容器需要 1 个 CPU 和 256MB 内存才能运行，那么可以在 Pod 的容器定义中设置这些资源的请求。请求资源将确保在 Kubernetes 集群中为该容器分配足够的资源量，以便可以正常运行。

• 限制是指容器能够使用的最大资源量。 例如，可以设置 CPU 和内存限制，以确保容器不会使用过多的资源，从而影响其他容器或宿主机的性能。如果容器试图使用超过其限制的资源量，Kubernetes 将终止该容器并重新启动它。

• 需要注意的是，请求和限制并不是强制性的设置。如果没有设置请求和限制，Kubernetes 将为容器分配默认值。这可能会导致容器在某些情况下无法正常工作。因此，建议在定义容器时为其设置请求和限制，以确保其在 Kubernetes 集群中可以稳定地运行，并避免资源争用和性能问题。

• 在设置请求和限制时，可以使用 CPU、内存等不同类型的资源，并为每种资源指定请求和限制。例如，可以设置一个容器的 CPU 请求为 0.5 个 CPU，限制为 1 个 CPU，内存请求为 256MB，限制为 512MB。这些值将根据实际情况而定，可以根据容器的具体需求和集群的资源情况进行调整。

内存的请求（request）和限制（limit）

• 内存请求（request）： 当节点拥有足够的可用内存时，容器可以使用其请求的内存，请求的大小会直接分配给容器，容器也可以不用到请求的这么多；
• 内存限制（limit）: 器不允许使用超过其限制的内存。

指定内存请求和限制

​ 要为容器指定内存请求，请在容器资源清单中包含 resources: requests 字段。 同理，要指定内存限制，请包含 resources: limits。

1. 创建一个拥有一个容器的 Pod。 容器将会请求 100 MiB 内存，并且内存会被限制在 200 MiB 以内。

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
### 配置文件的 args 部分提供了容器启动时的参数。 "--vm-bytes", "150M" 参数告知容器尝试分配 150 MiB 内存。

• 创建Pod

[root@master pod]# kubectl apply  -f memory-request-limit.yaml
pod/memory-demo created
[root@master pod]#

• 查看 Pod 相关的详细信息：

[root@master pod]# kubectl describe pods -n mem-example memory-demo

## 输出结果显示：该 Pod 中容器的内存请求为 100 MiB，内存限制为 200 MiB。
...
resources:
  requests:
    memory: 100Mi
  limits:
    memory: 200Mi
...

• 运行 kubectl top 命令，获取该 Pod 的指标数据：

使用kubectl top命令需要安装metrics-server，cpu和内存的监控服务

kubectl top pod memory-demo --namespace=mem-example

## 输出结果显示：Pod 正在使用的内存大约为 162,900,000 字节，约为 150 MiB。 这大于 Pod 请求的 100 MiB，但在 Pod 限制的 200 MiB之内。
NAME                        CPU(cores)   MEMORY(bytes)
memory-demo                 <something>  162856960

超过容器限制的内存

当节点拥有足够的可用内存时，容器可以使用其请求的内存。 但是，容器不允许使用超过其限制的内存。 如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。 如果容器继续消耗超出其限制的内存，则终止容器。 如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。

2. 创建一个 Pod，尝试分配超出其限制的内存。 这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB

piVersion: v1
kind: Pod
metadata:
  name: memory-demo-2
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-2-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

• 创建Pod

kubectl apply -f memory-request-limit-2.yaml --namespace=mem-example

• 查看 Pod 相关的详细信息：

kubectl get pod memory-demo-2 --namespace=mem-example

此时，容器可能正在运行或被杀死。重复前面的命令，直到容器被杀掉：
[root@master pod]# kubectl get -n mem-example pods
NAME            READY   STATUS      RESTARTS   AGE
memory-demo     1/1     Running     0          49m
memory-demo-2   0/1     OOMKilled   0          24s
[root@master pod]#

超过整个节点容量的内存

​ 内存请求和限制是与容器关联的，但将 Pod 视为具有内存请求和限制，也是很有用的。 Pod 的内存请求是 Pod 中所有容器的内存请求之和。 同理，Pod 的内存限制是 Pod 中所有容器的内存限制之和。Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。

3. 创建一个 Pod，其内存请求超过了你集群中的任意一个节点所拥有的内存。 这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了你集群中任何节点的容量。

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-3-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "1000Gi"
      limits:
        memory: "1000Gi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

• 创建Pod

[root@master pod]# kubectl apply -f memory-request-limit-3.yaml

• 查看Pod状态

[root@master pod]# kubectl get  pods -n mem-example
NAME            READY   STATUS             RESTARTS   AGE
memory-demo-3   0/1     Pending            0          11s
[root@master pod]#

• 查看关于 Pod 的详细信息，包括事件：

kubectl describe pod memory-demo-3 --namespace=mem-example

输出结果显示：由于节点内存不足，该容器无法被调度：
Events:
  ...  Reason            Message
       ------            -------
  ...  Warning  FailedScheduling  49s (x3 over 118s)  default-scheduler  0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 Insufficient memory.

内存单位

内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为 纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面是一些近似相同的值：

128974848, 129e6, 129M, 123Mi

如果不指定内存限制

如果你没有为一个容器指定内存限制，则自动遵循以下情况之一：

• 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存， 进而可能导致该节点调用 OOM Killer。 此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
• 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。 集群管理员可用使用 LimitRange 来指定默认的内存限制。

如果不知道内存请求

如果容器设置了内存限制值但未设置 内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。

内存请求和限制的目的

通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。 通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。 通过让内存限制大于内存请求，你可以完成两件事：

• Pod 可以进行一些突发活动，从而更好的利用可用内存。
• Pod 在突发活动期间，可使用的内存被限制为合理的数量

CPU的请求（request）和限制（limit）

指定 CPU 请求和 CPU 限制

​ 要为容器指定 CPU 请求，请在容器资源清单中包含 resources: requests 字段。 要指定 CPU 限制，请包含 resources:limits。

1. 创建一个具有一个容器的 Pod。容器将会请求 0.5 个 CPU，而且最多限制使用 1 个 CPU。 这是 Pod 的配置文件：

配置文件的 args 部分提供了容器启动时的参数。 -cpus "2" 参数告诉容器尝试使用 2 个 CPU。

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
    args:
    - -cpus
    - "2"

• 创建Pod

	kubectl apply -f  cpu-request-limit.yaml

• 查看显示关于 Pod 的详细信息：

kubectl get pod cpu-demo --output=yaml --namespace=cpu-example

## 输出显示 Pod 中的一个容器的 CPU 请求为 500 milliCPU，并且 CPU 限制为 1 个 CPU。
resources:
  limits:
    cpu: "1"
  requests:
    cpu: 500m

• 使用 kubectl top 命令来获取该 Pod 的指标：

kubectl top pod cpu-demo --namespace=cpu-example

##此示例输出显示 Pod 使用的是 974 milliCPU，即略低于 Pod 配置中指定的 1 个 CPU 的限制。
NAME                        CPU(cores)   MEMORY(bytes)
cpu-demo                    974m         <something>

设置超过节点能力的 CPU 请求

• CPU 请求和限制与都与容器相关，但是我们可以考虑一下 Pod 具有对应的 CPU 请求和限制这样的场景。 Pod 对 CPU 用量的请求等于 Pod 中所有容器的请求数量之和。 同样，Pod 的 CPU 资源限制等于 Pod 中所有容器 CPU 资源限制数之和。

• Pod 调度是基于资源请求值来进行的。 仅在某节点具有足够的 CPU 资源来满足 Pod CPU 请求时，Pod 将会在对应节点上运行。

1. 创建一个 Pod，该 Pod 的 CPU 请求对于集群中任何节点的容量而言都会过大。 下面是 Pod 的配置文件，其中有一个容器。容器请求 100 个 CPU，这可能会超出集群中任何节点的容量。

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo-2
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr-2
    image: vish/stress
    resources:
      limits:
        cpu: "100"
      requests:
        cpu: "100"
    args:
    - -cpus
    - "2"

• 创建Pod

kubectl apply -f  cpu-request-limit-2.yaml

• 输出显示 Pod 状态为 Pending。也就是说，Pod 未被调度到任何节点上运行， 并且 Pod 将无限期地处于 Pending 状态：

NAME         READY     STATUS    RESTARTS   AGE
cpu-demo-2   0/1       Pending   0          7m

• 查看有关 Pod 的详细信息，包含事件

kubectl describe pod cpu-demo-2 --namespace=cpu-example

## 输出显示由于节点上的 CPU 资源不足，无法调度容器：
Events:
  Reason                        Message
  ------                        -------
  FailedScheduling      No nodes are available that match all of the following predicates:: Insufficient cpu (3).

CPU单位

CPU 资源以 CPU 单位度量。Kubernetes 中的一个 CPU 等同于：

• 1 个 AWS vCPU
• 1 个 GCP核心
• 1 个 Azure vCore
• 裸机上具有超线程能力的英特尔处理器上的 1 个超线程

小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 精度不能超过 1m。

CPU 请求只能使用绝对数量，而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。

如果不指定 CPU 限制

如果你没有为容器指定 CPU 限制，则会发生以下情况之一：

• 容器在可以使用的 CPU 资源上没有上限。因而可以使用所在节点上所有的可用 CPU 资源。
• 容器在具有默认 CPU 限制的名字空间中运行，系统会自动为容器设置默认限制。 集群管理员可以使用 LimitRange 指定 CPU 限制的默认值。

如果你设置了 CPU 限制但未设置 CPU 请求

​ 如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其 设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置 内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。

设置CPU 请求和限制的初衷

通过配置你的集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。 通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。 通过使 CPU 限制大于 CPU 请求，你可以完成两件事：

• Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。
• Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。

QOS服务质量

​ Kubernetes 中的 服务质量（Quality of Service，QoS） 类， 阐述 Kubernetes 如何根据为 Pod 中的容器指定的资源约束为每个 Pod 设置 QoS 类。 Kubernetes 依赖这种分类来决定当 Node 上没有足够可用资源时要驱逐哪些 Pod。

QoS 类

Kubernetes 对你运行的 Pod 进行分类，并将每个 Pod 分配到特定的 QoS 类中。 Kubernetes 使用这种分类来影响不同 Pod 被处理的方式。Kubernetes 基于 Pod 中容器的资源请求进行分类， 同时确定这些请求如何与资源限制相关。 这称为服务质量 (QoS) 类。 Kubernetes 基于每个 Pod 中容器的资源请求和限制为 Pod 设置 QoS 类。Kubernetes 使用 QoS 类来决定从遇到节点压力的 Node 中驱逐哪些 Pod。可选的 QoS 类有 Guaranteed、Burstable 和 BestEffort。 当一个 Node 耗尽资源时，Kubernetes 将首先驱逐在该 Node 上运行的 BestEffort Pod， 然后是 Burstable Pod，最后是 Guaranteed Pod。当这种驱逐是由于资源压力时， 只有超出资源请求的 Pod 才是被驱逐的候选对象。

Guaranteed

Guaranteed Pod 具有最严格的资源限制，并且最不可能面临驱逐。 在这些 Pod 超过其自身的限制或者没有可以从 Node 抢占的低优先级 Pod 之前， 这些 Pod 保证不会被杀死。这些 Pod 不可以获得超出其指定 limit 的资源。这些 Pod 也可以使用 static CPU 管理策略来使用独占的 CPU。

Pod 被赋予 Guaranteed QoS 类的几个判据：

• Pod 中的每个容器必须有内存 limit 和内存 request。
• 对于 Pod 中的每个容器，内存 limit 必须等于内存 request。
• Pod 中的每个容器必须有 CPU limit 和 CPU request。
• 对于 Pod 中的每个容器，CPU limit 必须等于 CPU request。

Burstable

Burstable Pod 有一些基于 request 的资源下限保证，但不需要特定的 limit。 如果未指定 limit，则默认为其 limit 等于 Node 容量，这允许 Pod 在资源可用时灵活地增加其资源。 在由于 Node 资源压力导致 Pod 被驱逐的情况下，只有在所有 BestEffort Pod 被驱逐后 这些 Pod 才会被驱逐。因为 Burstable Pod 可以包括没有资源 limit 或资源 request 的容器， 所以 Burstable Pod 可以尝试使用任意数量的节点资源。

Pod 被赋予 Burstable QoS 类的几个判据：

• Pod 不满足针对 QoS 类 Guaranteed 的判据。
• Pod 中至少一个容器有内存或 CPU 的 request 或 limit。

BestEffort

BestEffort QoS 类中的 Pod 可以使用未专门分配给其他 QoS 类中的 Pod 的节点资源。 例如若你有一个节点有 16 核 CPU 可供 kubelet 使用，并且你将 4 核 CPU 分配给一个 Guaranteed Pod， 那么 BestEffort QoS 类中的 Pod 可以尝试任意使用剩余的 12 核 CPU。

如果 Pod 不满足 Guaranteed 或 Burstable 的判据，则它的 QoS 类为 BestEffort。 换言之，只有当 Pod 中的所有容器没有内存 limit 或内存 request，也没有 CPU limit 或 CPU request 时，Pod 才是 BestEffort。Pod 中的容器可以请求（除 CPU 或内存之外的） 其他资源并且仍然被归类为 BestEffort

配置 Pod 的服务质量

配置 Pod 以让其归属于特定的 [服务质量类（Quality of Service class，QoS class） Kubernetes 在 Node 资源不足时使用 QoS 类来就驱逐 Pod 作出决定。

Kubernetes 创建 Pod 时，会将如下 QoS 类之一设置到 Pod 上：

• Guaranteed
• Burstable
• BestEffort

创建一个 QoS 类为 Guaranteed 的 Pod

对于 QoS 类为 Guaranteed 的 Pod：

• Pod 中的每个容器都必须指定内存限制和内存请求。
• 对于 Pod 中的每个容器，内存限制必须等于内存请求。
• Pod 中的每个容器都必须指定 CPU 限制和 CPU 请求。
• 对于 Pod 中的每个容器，CPU 限制必须等于 CPU 请求。

这些限制同样适用于初始化容器和应用程序容器。 临时容器（Ephemeral Container） 无法定义资源，因此不受这些约束限制

1. 下面是包含一个 Container 的 Pod 清单。该 Container 设置了内存请求和内存限制，值都是 200 MiB。 该 Container 设置了 CPU 请求和 CPU 限制，值都是 700 milliCPU

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

• 查看pod详情

kubectl get pod qos-demo --namespace=qos-example --output=yaml
## 结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Guaranteed。 结果也确认了 Pod 容器设置了与内存限制匹配的内存请求，设置了与 CPU 限制匹配的 CPU 请求
spec:
  containers:
    ...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    ...
status:
  qosClass: Guaranteed

说明：

如果某 Container 指定了自己的内存限制，但没有指定内存请求，Kubernetes 会自动为它指定与内存限制相等的内存请求。同样，如果容器指定了自己的 CPU 限制， 但没有指定 CPU 请求，Kubernetes 会自动为它指定与 CPU 限制相等的 CPU 请求。

创建一个 QoS 类为 Burstable 的 Pod

如果满足下面条件，Kubernetes 将会指定 Pod 的 QoS 类为 Burstable：

• Pod 不符合 Guaranteed QoS 类的标准。
• Pod 中至少一个 Container 具有内存或 CPU 的请求或限制。

2. 下面是包含一个 Container 的 Pod 清单。该 Container 设置的内存限制为 200 MiB， 内存请求为 100 MiB。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-2
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

• 查看 Pod 详情：

kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml

## 结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable。
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: qos-demo-2-ctr
    resources:
      limits:
        memory: 200Mi
      requests:
        memory: 100Mi
  ...
status:
  qosClass: Burstable

创建一个 QoS 类为 BestEffort 的 Pod

对于 QoS 类为 BestEffort 的 Pod，Pod 中的 Container 必须没有设置内存和 CPU 限制或请求。

1. 下面是包含一个 Container 的 Pod 清单。该 Container 没有设置内存和 CPU 限制或请求。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-3
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-3-ctr
    image: nginx

• 查看 Pod 详情：

kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml

### 结果表明 Kubernetes 为 Pod 配置的 QoS 类为 BestEffort。
spec:
  containers:
    ...
    resources: {}
  ...
status:
  qosClass: BestEffort

创建包含两个容器的 Pod

4. 下面是包含两个 Container 的 Pod 清单。一个 Container 指定内存请求为 200 MiB。 另外一个 Container 没有指定任何请求或限制。

• 注意此 Pod 满足 Burstable QoS 类的标准。也就是说它不满足 Guaranteed QoS 类标准， 因为它的 Container 之一设有内存请求。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-4
  namespace: qos-example
spec:
  containers:

  - name: qos-demo-4-ctr-1
    image: nginx
    resources:
      requests:
        memory: "200Mi"

  - name: qos-demo-4-ctr-2
    image: redis

• 查看 Pod 详情

kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml

### 结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable：
spec:
  containers:
    ...
    name: qos-demo-4-ctr-1
    resources:
      requests:
        memory: 200Mi
    ...
    name: qos-demo-4-ctr-2
    resources: {}
    ...
status:
  qosClass: Burstable

检视 Pod 的 QoS 类

也可以只查看你所需要的字段，而不是查看所有字段：

kubectl --namespace=qos-example get pod qos-demo-4 -o jsonpath='{ .status.qosClass}{"
"}'

调整分配给容器的 CPU 和内存资源

此功能要求Kubernetes 服务器版本必须不低于版本 1.27

​ 如何在不重启 Pod 或其容器的情况下调整分配给运行中 Pod 容器的 CPU 和内存资源。 Kubernetes 节点会基于 Pod 的 requests 为 Pod 分配资源， 并基于 Pod 的容器中指定的 limits 限制 Pod 的资源使用。

对于原地调整 Pod 资源而言：

• 针对 CPU 和内存资源的容器的 requests 和 limits 是可变更的。

• Pod 状态中 containerStatuses 的 allocatedResources 字段反映了分配给 Pod 容器的资源。

• Pod 状态中 containerStatuses 的 resources 字段反映了如同容器运行时所报告的、针对正运行的容器配置的实际资源 requests 和 limits。

• Pod 状态中resize字段显示上次请求待处理的调整状态。此字段可以具有以下值：

  • Proposed：此值表示请求调整已被确认，并且请求已被验证和记录。
  • InProgress：此值表示节点已接受调整请求，并正在将其应用于 Pod 的容器。
  • Deferred：此值意味着在此时无法批准请求的调整，节点将继续重试。 当其他 Pod 退出并释放节点资源时，调整可能会被真正实施。
  • Infeasible：此值是一种信号，表示节点无法承接所请求的调整值。 如果所请求的调整超过节点可分配给 Pod 的最大资源，则可能会发生这种情况

容器调整策略

调整策略允许更精细地控制 Pod 中的容器如何针对 CPU 和内存资源进行调整。 例如，容器的应用程序可以处理 CPU 资源的调整而不必重启， 但是调整内存可能需要应用程序重启，因此容器也必须重启。

为了实现这一点，容器规约允许用户指定 resizePolicy。 针对调整 CPU 和内存可以设置以下重启策略：

• NotRequired：在运行时调整容器的资源。
• RestartContainer：重启容器并在重启后应用新资源。
• 如果未指定 resizePolicy[*].restartPolicy，则默认为 NotRequired。

如果 Pod 的 restartPolicy 为 Never，则 Pod 中所有容器的调整重启策略必须被设置为 NotRequired。

• 创建指导只有的Pod

1. 配置一个 Pod，其中 CPU 可以在不重启容器的情况下进行调整，但是内存调整需要重启容器。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
    - name: qos-demo-ctr-5
      image: nginx
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: RestartContainer
      resources:
        limits:
          memory: "200Mi"
          cpu: "700m"
        requests:
          memory: "200Mi"
          cpu: "700m"

在上述示例中，如果所需的 CPU 和内存请求或限制已更改，则容器将被重启以调整其内存。

• 更新Pod资源

设要求的 CPU 需求已上升，现在需要 0.8 CPU。这通常由 VerticalPodAutoscaler (VPA) 这样的实体确定并可能以编程方式应用。

说明：

尽管你可以更改 Pod 的请求和限制以表示新的期望资源， 但无法更改 Pod 创建时所归属的 QoS 类。

在对 Pod 的 Container 执行 patch 命令，将容器的 CPU 请求和限制均设置为 800m：

kubectl -n qos-example patch pod qos-demo-5 --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

在 Pod 已打补丁后查询其详细信息。

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

##以下 Pod 规约反映了更新后的 CPU 请求和限制。
spec:
  containers:
    ...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
...
  containerStatuses:
...
    allocatedResources:
      cpu: 800m
      memory: 200Mi
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
    restartCount: 0
    started: true

观察到 allocatedResources 的值已更新，反映了新的预期 CPU 请求。 这表明节点能够容纳提高后的 CPU 资源需求。

在 Container 状态中，更新的 CPU 资源值显示已应用新的 CPU 资源。 Container 的 restartCount 保持不变，表示已在无需重启容器的情况下调整了容器的 CPU 资源。