調整指派給容器的 CPU 和記憶體資源大小
Kubernetes v1.27 [alpha]
(預設停用:false)此頁面假設您已熟悉 Kubernetes Pod 的服務品質。
此頁面說明如何在不重新啟動 Pod 或其容器的情況下,調整指派給執行中 Pod 容器的 CPU 和記憶體資源大小。Kubernetes 節點會根據 Pod 的 requests
為 Pod 分配資源,並根據 Pod 容器中指定的 limits
限制 Pod 的資源使用量。
變更執行中 Pod 的資源分配需要啟用 InPlacePodVerticalScaling
功能閘道。替代方案是刪除 Pod,並讓工作負載控制器建立具有不同資源需求的替換 Pod。
調整大小請求是透過 Pod /resize
子資源發出的,該子資源採用完整的更新 Pod 以進行更新請求,或採用 Pod 物件的 Patch 以進行 Patch 請求。
用於 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 Playground 之一
您的 Kubernetes 伺服器必須是 1.27 或更新版本。若要檢查版本,請輸入kubectl version
。您的控制平面和叢集中的所有節點都必須啟用 InPlacePodVerticalScaling
功能閘道。
容器調整大小策略
調整大小策略可讓您更精細地控制如何調整 Pod 容器的 CPU 和記憶體資源大小。例如,容器的應用程式可能可以處理未重新啟動而調整大小的 CPU 資源,但調整記憶體大小可能需要重新啟動應用程式,進而重新啟動容器。
為了啟用此功能,容器規格允許使用者指定 resizePolicy
。可以為調整 CPU 和記憶體大小指定以下重新啟動策略
NotRequired
:在容器執行時調整容器的資源大小。RestartContainer
:重新啟動容器,並在重新啟動時套用新資源。
如果未指定 resizePolicy[*].restartPolicy
,則預設為 NotRequired
。
注意
如果 Pod 的restartPolicy
為 Never
,則 Pod 中所有容器的容器調整大小重新啟動策略都必須設定為 NotRequired
。以下範例展示了 Pod,其 Container 的 CPU 可以在不重新啟動的情況下調整大小,但調整記憶體大小需要重新啟動 Container。
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和記憶體的期望請求或限制都已變更,Container 將會重新啟動以調整其記憶體大小。限制
Pod 資源的原地調整大小目前有以下限制:
- 僅能變更 CPU 和記憶體資源。
- Pod 的服務品質類別 (QoS Class) 無法變更。這表示對於 Guaranteed 等級的 Pod,請求必須繼續等於限制;Burstable 等級的 Pod 無法將 CPU 和記憶體的請求與限制設定為相等;且您無法為 Best Effort 等級的 Pod 新增資源需求。
- Init Containers 和 Ephemeral Containers 無法調整大小。
- 資源請求和限制一旦設定就無法移除。
- Container 的記憶體限制不得低於其使用量。如果請求使 Container 處於此狀態,則調整大小狀態將保持在
InProgress
,直到期望的記憶體限制變得可行。 - Windows Pod 無法調整大小。
建立具有資源請求和限制的 Pod
您可以透過為 Pod 的 Container 指定請求和/或限制,來建立 Guaranteed 或 Burstable 服務品質 類別的 Pod。
請參考以下 Pod 的 Manifest 範例,該 Pod 有一個 Container。
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 服務品質類別,請求 700m CPU 和 200Mi 記憶體。
檢視關於 Pod 的詳細資訊
kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example
另請注意,resizePolicy[*].restartPolicy
的值預設為 NotRequired
,表示 CPU 和記憶體可以在 Container 執行時調整大小。
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 的請求和限制以表達新的期望資源,但您無法變更 Pod 建立時所屬的服務品質類別。現在,將 CPU 請求和限制都設定為 800m
來修補 Pod 的 Container
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 的 Spec 反映了更新後的 CPU 請求和限制。
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 請求。這表示節點能夠容納增加的 CPU 資源需求,並且已套用新的 CPU 資源。Container 的 restartCount
保持不變,表示 Container 的 CPU 資源已在不重新啟動 Container 的情況下調整大小。
清除
刪除您的命名空間
kubectl delete namespace qos-example