调整分配给容器的 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 资源的就地调整大小
- 容器的资源
requests
和limits
对于 CPU 和内存资源是可变的。这些字段表示容器的期望资源。 - Pod 状态的
containerStatuses
中的resources
字段反映了分配给 Pod 容器的已分配资源。对于正在运行的容器,这反映了由容器运行时报告的实际资源requests
和limits
。对于未运行的容器,这些是在容器启动时分配给容器的资源。 - 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 的restartPolicy
为 Never
,则 Pod 中所有容器的容器调整大小重启策略必须设置为 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"
注意
在上面的示例中,如果 CPU 和内存的期望请求或限制都已更改,则将重启容器以调整其内存大小。限制
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 的 requests 和 limits 来表达新的期望资源,但你无法更改创建 Pod 时所处的 QoS 类。现在,将 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