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

特性状态: Kubernetes v1.27 [alpha] (默认禁用:false)

此页面假定您熟悉 Kubernetes Pod 的服务质量

此页面展示如何在不重启 Pod 或其容器的情况下,调整正在运行的 Pod 容器分配的 CPU 和内存资源。Kubernetes 节点基于 Pod 的 requests 分配资源,并基于 Pod 容器中指定的 limits 限制 Pod 的资源使用。

更改正在运行的 Pod 的资源分配需要启用 InPlacePodVerticalScaling 特性门控。另一种方法是删除 Pod,让工作负载控制器创建一个具有不同资源要求的替换 Pod。

调整大小的请求通过 Pod 的 /resize 子资源发出,该子资源接收用于更新请求的完整更新后的 Pod,或用于补丁请求的 Pod 对象的补丁。

用于 Pod 资源的就地调整大小

  • 容器的资源 requestslimits 对于 CPU 和内存资源是可变的。这些字段表示容器的期望资源。
  • Pod 状态的 containerStatuses 中的 resources 字段反映了分配给 Pod 容器的已分配资源。对于正在运行的容器,这反映了由容器运行时报告的实际资源 requestslimits。对于未运行的容器,这些是在容器启动时分配给容器的资源。
  • Pod 状态中的 resize 字段显示上次请求的挂起调整大小的状态。它可以具有以下值
    • Proposed:此值表示 Pod 已调整大小,但 Kubelet 尚未处理调整大小。
    • InProgress:此值表示节点已接受调整大小的请求,并且正在将其应用于 Pod 的容器。
    • Deferred:此值表示当前无法授予请求的调整大小,并且节点将继续重试。当删除其他 Pod 并释放节点资源时,可能会授予调整大小。
    • Infeasible:表示节点无法容纳请求的调整大小的信号。如果请求的调整大小超过节点可以为 Pod 分配的最大资源,则可能会发生这种情况。
    • "":空值或未设置值表示上次调整大小已完成。只有容器规范中的资源与容器状态中的资源匹配时,才会出现这种情况。

如果节点有 Pod 具有未完成的调整大小,则调度器将从容器的期望资源请求的最大值以及状态中报告的实际请求来计算 Pod 请求。

开始之前

您需要一个 Kubernetes 集群,并且必须配置 kubectl 命令行工具以与您的集群通信。建议在至少两个不充当控制平面主机的节点上的集群上运行此教程。如果您还没有集群,可以使用minikube创建一个,或者可以使用这些 Kubernetes 游乐场之一

您的 Kubernetes 服务器必须是 1.27 或更高版本。要检查版本,请输入 kubectl version

必须为您的控制平面和集群中的所有节点启用 InPlacePodVerticalScaling 特性门控

容器调整大小策略

调整大小策略允许更精细地控制如何调整 Pod 容器的 CPU 和内存资源大小。例如,容器的应用程序可能能够处理 CPU 资源大小的调整而无需重启,但调整内存大小可能需要重启应用程序,从而重启容器。

为了启用此功能,容器规范允许用户指定 resizePolicy。可以为调整 CPU 和内存大小指定以下重启策略

  • NotRequired:在容器运行时调整其资源大小。
  • RestartContainer:重启容器并在重启时应用新资源。

如果未指定 resizePolicy[*].restartPolicy,则默认为 NotRequired

以下示例显示了一个 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"

限制

Pod 资源的就地调整大小目前有以下限制

  • 只能更改 CPU 和内存资源。
  • Pod QoS 类无法更改。这意味着有保证的 Pod 的请求必须继续等于限制,可突发的 Pod 不能将 CPU 和内存的请求和限制设置为相等,并且您不能向尽力而为的 Pod 添加资源要求。
  • 不能调整初始化容器和临时容器的大小。
  • 一旦设置,就不能删除资源请求和限制。
  • 容器的内存限制可能不会降低到低于其使用量。如果请求将容器置于此状态,则调整大小的状态将保持在 InProgress 状态,直到所需的内存限制变得可行。
  • 无法调整 Windows Pod 的大小。

使用资源请求和限制创建 Pod

您可以通过指定 Pod 容器的请求和/或限制来创建有保证或可突发的服务质量类 Pod。

考虑以下具有一个容器的 Pod 的清单。

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

qos-example 命名空间中创建 Pod。

kubectl create namespace qos-example
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-5.yaml

此 Pod 被归类为 Guaranteed QoS 类,请求 700m CPU 和 200Mi 内存。

查看有关 Pod 的详细信息。

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

另请注意,resizePolicy[*].restartPolicy 的值默认为 NotRequired,表示可以在容器运行时调整 CPU 和内存的大小。

spec:
  containers:
    ...
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
...
  containerStatuses:
...
    name: qos-demo-ctr-5
    ready: true
...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    restartCount: 0
    started: true
...
  qosClass: Guaranteed

更新 Pod 的资源。

假设 CPU 需求增加,现在需要 0.8 个 CPU。 这可以手动指定,也可以由诸如 VerticalPodAutoscaler (VPA) 之类的实体确定并通过编程方式应用。

现在,将 Pod 的容器修补为 CPU requests 和 limits 都设置为 800m

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

在修补 Pod 后,查询 Pod 的详细信息。

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

下面的 Pod 规范反映了更新后的 CPU requests 和 limits。

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
...
  containerStatuses:
...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
    restartCount: 0
    started: true

请注意,containerStatuses 中的 resources 已更新,以反映新的期望 CPU requests。 这表明节点能够满足增加的 CPU 资源需求,并且已应用新的 CPU 资源。容器的 restartCount 保持不变,表明容器的 CPU 资源已调整大小,而无需重新启动容器。

清理。

删除你的命名空间。

kubectl delete namespace qos-example

下一步做什么?

对于应用程序开发人员。

对于集群管理员。

上次修改时间:2024 年 10 月 30 日下午 5:17 PST:KEP 2837: Pod Level Resources Alpha (0374213f57)