容量緩衝區會使用 Kubernetes CapacityBuffer CustomResourceDefinition (CRD)，主動管理叢集備用容量，以及預先佈建和設定的容量暫停狀態，藉此提高重要工作負載的回應速度和可靠性。使用容量緩衝區，即可明確定義叢集內未使用的節點容量。這項預留容量有助於縮短 Pod 排程時間。
當高優先順序工作負載需要快速擴充時，新工作負載可以立即使用閒置容量，不必等待節點佈建。這種做法可盡量縮短延遲時間，並避免在需求突然激增時發生資源爭用問題。
本頁提供設定容量緩衝區的方法：固定副本緩衝區、資源限制緩衝區和百分比緩衝區。
事前準備
開始之前，請務必先完成下列工作：
- 啟用 Google Kubernetes Engine API。 啟用 Google Kubernetes Engine API
- 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行
gcloud components update指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文中的指令。
- 建立或有權存取符合下列版本規定的 GKE 叢集：
- 如要使用作用中緩衝區，請在 Standard 和 Autopilot 叢集上使用 1.35.2-gke.1842000 以上版本。
- 如要使用待命緩衝區，請在 Standard 叢集上使用 1.36.0-gke.2253000 以上版本，或在 Autopilot 叢集上使用 1.36.0-gke.2853000 以上版本，並搭配自訂 ComputeClass。
- 在 Standard 叢集上啟用自動佈建節點功能。Autopilot 叢集已啟用自動佈建節點功能。自動佈建節點為選用功能，但建議用於使用中緩衝區，且為待命緩衝區的必要功能。
建立必要 Kubernetes 物件
如要設定 CapacityBuffer，您需要一個命名空間，其中包含所有必要物件 (CapacityBuffer 本身，以及 PodTemplate 或工作負載等其他資源)。PodTemplate 和 CapacityBuffer 必須位於同一個命名空間。您可以建立命名空間，或使用現有命名空間，包括 default 命名空間。
視您設定的 CapacityBuffer 類型而定，您還需要下列其中一項：
- PodTemplate：定義單一緩衝容量單元的資源需求。CapacityBuffer 物件中指定的設定會參照 Pod 範本。
工作負載：您在 CapacityBuffer 物件中參照的現有工作負載。本指南使用 Deployment 物件做為範例工作負載，但容量緩衝區支援下列任一資源類型：
- 部署作業
- ReplicaSet
- StatefulSet
- ReplicationController
- 工作
實作
scale子資源的 CustomResourceDefinitions (CRD)。
本節提供這些物件的範例。如果您已有要設定容量緩衝區的工作負載，請前往「套用容量緩衝區」。
如要建立 Kubernetes 工作負載範例，請完成下列步驟：
將下列資訊清單儲存為
namespace.yaml：apiVersion: v1 kind: Namespace metadata: name: capacity-buffer-example labels: name: capacity-buffer-example這個資訊清單會建立名為
capacity-buffer-example的命名空間。選用：如要搭配自訂 ComputeClass 使用容量緩衝區，請將下列資訊清單儲存為
custom-compute-class.yaml：apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: ccc-example spec: # Buffers are also created according to these priorities priorities: - machineFamily: n4 - machineFamily: n4d - machineFamily: c4 - machineFamily: c4d nodePoolAutoCreation: enabled: true這個資訊清單會建立自訂
ComputeClass，定義及控管 GKE 佈建節點的運算優先順序。詳情請參閱「自訂 ComputeClass」。將下列資訊清單儲存為
buffer-pod-template.yaml：apiVersion: v1 kind: PodTemplate metadata: name: buffer-unit-template namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer template: spec: terminationGracePeriodSeconds: 0 containers: - name: buffer-container image: registry.k8s.io/pause:3.9 resources: requests: cpu: "1" memory: "1Gi" limits: cpu: "1" memory: "1Gi" # Optional: Using buffers with a custom ComputeClass / # controls the properties of the provisioned nodes. nodeSelector: cloud.google.com/compute-class: ccc-example這份資訊清單會建立
PodTemplate，定義單一緩衝區容量單位的資源需求 (1CPU 和1Gi記憶體)。這項設定會指定 GKE 為緩衝區佈建的容量單位大小。舉例來說，如果叢集擴充，GKE 就不會將可用資源少於 1 個 CPU 和 1Gi 的節點視為緩衝區的一部分。將下列資訊清單儲存為
sample-workload-deployment.yaml：apiVersion: apps/v1 kind: Deployment metadata: name: critical-workload-ref namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer spec: replicas: 10 selector: matchLabels: app: critical-workload template: metadata: labels: app: critical-workload spec: containers: - name: busybox image: busybox command: ["sleep", "3600"] resources: requests: cpu: 100m # Optional: Using buffers with a custom ComputeClass / # controls the properties of the provisioned nodes. nodeSelector: cloud.google.com/compute-class: ccc-example這個資訊清單會建立含有 10 個副本的範例 Deployment，做為下一節百分比緩衝區範例的參考物件。
將資訊清單套用至叢集：
kubectl apply -f namespace.yaml -f custom-compute-class.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml確認 GKE 已建立物件：
kubectl get podtemplate -n capacity-buffer-example kubectl get deployment critical-workload-ref -n capacity-buffer-example輸出結果會與下列內容相似：
NAME AGE buffer-unit-template 1m NAME READY UP-TO-DATE AVAILABLE AGE critical-workload-ref 10/10 10 10 1m
套用容量緩衝區
本節提供範例，說明可套用至工作負載的不同類型容量緩衝區。
設定固定副本緩衝區
使用固定副本設定 CapacityBuffer 時，會根據 PodTemplate 指定所需的緩衝區單元確切數量。
如要建立具有固定副本的緩衝區，請完成下列步驟：
將下列資訊清單儲存為
cb-fixed-replicas.yaml：apiVersion: autoscaling.x-k8s.io/v1beta1 kind: CapacityBuffer metadata: name: fixed-replica-buffer namespace: NAMESPACE spec: podTemplateRef: name: POD_TEMPLATE replicas: 3 provisioningStrategy: "STRATEGY"更改下列內容：
NAMESPACE：命名空間的名稱，例如capacity-buffer-example。POD_TEMPLATE：定義資源需求的 PodTemplate，例如buffer-unit-template。STRATEGY：佈建策略，可為"buffer.x-k8s.io/active-capacity"(預設) 或"buffer.gke.io/standby-capacity"。
這份資訊清單會建立 CapacityBuffer 資源，並參照 PodTemplate 來要求特定數量的緩衝區單位。
套用資訊清單：
kubectl apply -f cb-fixed-replicas.yaml確認 GKE 已套用容量緩衝區：
kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE狀態中的
replicas欄位應顯示3，反映您在資訊清單中定義的副本數量。「STATUS」欄位應顯示「ReadyForProvisioning」。
設定資源限制緩衝區
您可以使用 limits 欄位，定義緩衝區應消耗的資源量上限，這項上限是根據 PodTemplate 大小計算。
如要建立資源限制緩衝區，請完成下列步驟：
將下列資訊清單儲存為
cb-resource-limits.yaml：apiVersion: autoscaling.x-k8s.io/v1beta1 kind: CapacityBuffer metadata: name: resource-limit-buffer namespace: NAMESPACE spec: podTemplateRef: name: POD_TEMPLATE limits: cpu: "5" memory: "5Gi" provisioningStrategy: "STRATEGY"更改下列內容：
NAMESPACE：命名空間的名稱，例如capacity-buffer-example。POD_TEMPLATE：定義資源需求的 PodTemplate，例如buffer-unit-template。STRATEGY：佈建策略，可為"buffer.x-k8s.io/active-capacity"(預設) 或"buffer.gke.io/standby-capacity"。
這個資訊清單會建立 CapacityBuffer 資源，總限制為 5 個 CPU 和 5 GiB 記憶體。如果您使用上一步的 PodTemplate 範例，請將每個單位定義為
1CPU 和1Gi記憶體，這樣應該會產生 5 個緩衝單位。套用資訊清單：
kubectl apply -f cb-resource-limits.yaml確認 GKE 已套用容量緩衝區：
kubectl get capacitybuffer resource-limit-buffer -n NAMESPACE檢查 CapacityBuffer 狀態。
replicas欄位應顯示從您定義的限制衍生而來的值。如果您使用上一節的 PodTemplate 範例，應該會看到5個緩衝區單位，因為這是符合定義限制的最大單位數。
設定以百分比為準的緩衝空間
設定百分比緩衝區，可根據現有可擴充工作負載的百分比，動態調整緩衝區大小。百分比容量緩衝區僅適用於實作資源調度子資源的 Kubernetes 可調度物件，例如 Deployment、StatefulSet、ReplicaSet 或 Job。Pod 範本沒有 replicas 欄位，因此無法定義以百分比為單位的緩衝區。
在大多數情況下，請先採用固定副本或資源限制策略，而非以百分比為基礎的緩衝區。決定時請考量下列事項：
- 如果工作負載縮放至低於一定數量或零，安全邊際會與作用中 Pod 成比例減少，因此以百分比為準的緩衝區對突然擴充的反應較慢。
- 在暫停之前，待命節點的初始化期間會產生運算費用。如果隨著工作負載波動動態調度待命緩衝區，會浪費運算資源，因此請改用固定副本或待命緩衝區的資源限制。
- 百分比緩衝區主要適用於大型部署作業中的有效緩衝區，這類部署作業不會縮減至低副本數量。
在 GKE 1.36.3-gke.1244000 以上版本中，如要在參照的工作負載縮減時維持最小緩衝區空間，請一併設定 replicas 和 percentage 欄位。GKE 會使用能產生更多緩衝單位的欄位。如要設定緩衝區空間上限，請一併設定 limits 欄位。
舉例來說，假設緩衝區包含 percentage: 20 和 replicas: 3，且參照的 Deployment 有 10 個副本。10 個副本的 20% 為 2，小於 replicas 值 3，因此 GKE 會佈建 3 個緩衝區單位。如果 Deployment 擴充至 20 個副本，緩衝區會增加至 4 個單位。詳情請參閱 CapacityBuffer 參考文件。
如要建立以百分比為單位的緩衝區，請完成下列步驟：
將下列資訊清單儲存為
cb-percentage-based.yaml：apiVersion: autoscaling.x-k8s.io/v1beta1 kind: CapacityBuffer metadata: name: percentage-buffer namespace: NAMESPACE spec: scalableRef: apiGroup: apps kind: Deployment name: SCALABLE_RESOURCE_NAME percentage: 20 provisioningStrategy: "STRATEGY"更改下列內容：
NAMESPACE：命名空間名稱。SCALABLE_RESOURCE_NAME：可擴充資源的名稱，例如critical-workload-ref。STRATEGY：佈建策略，可為"buffer.x-k8s.io/active-capacity"(預設) 或"buffer.gke.io/standby-capacity"。
這份資訊清單會建立 CapacityBuffer 資源，要求緩衝區空間相當於所參照資源副本的 20%。如果您使用上一節的 Deployment 範例，副本值會設為
10。套用資訊清單：
kubectl apply -f cb-percentage-based.yaml確認 GKE 已套用容量緩衝區：
kubectl get capacitybuffer percentage-buffer -n NAMESPACE檢查 CapacityBuffer 狀態。「
replicas」欄位應顯示百分比計算得出的值。如果您使用上一節的 Deployment 範例，應該會看到2緩衝區單元，也就是 Deployment 中定義的 10 個副本的 20%。手動將 Deployment 資源調度至 20 個副本，測試動態資源調度功能：
kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20CapacityBuffer 控制器會做出反應，並自動將緩衝區擴展至 4 個副本。
自訂待機緩衝區行為
您可以使用註解，自訂待命緩衝區的啟動和重新整理方式。
將這些註解新增至 CapacityBuffer 資源的 metadata.annotations 欄位：
buffer.gke.io/standby-capacity-init-time：節點在建立後保持活動狀態的時間長度，之後 GKE 會暫停節點。請指定時間長度字串，例如5m或1h。預設值為5m。buffer.gke.io/standby-capacity-refresh-frequency：GKE 重新整理暫停節點的頻率。指定時間長度字串，例如12h或24h。預設值為24h。
以下範例顯示含有這些選用欄位的資訊清單，可自訂待機緩衝區的行為：
apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
name: customized-standby-buffer
namespace: my-namespace
annotations:
buffer.gke.io/standby-capacity-init-time: "15m"
buffer.gke.io/standby-capacity-refresh-frequency: "12h"
spec:
podTemplateRef:
name: buffer-unit-template
replicas: 3
provisioningStrategy: "buffer.gke.io/standby-capacity"
在待機緩衝區預先載入圖片
如要加快待命節點恢復運作時的工作負載啟動時間，可以使用 DaemonSet 預先載入容器映像檔。DaemonSet 會在節點暫停前的啟動期間執行。
如要使用 DaemonSet 預先載入映像檔，請完成下列步驟：
將下列資訊清單儲存為
image-puller-daemonset.yaml：apiVersion: apps/v1 kind: DaemonSet metadata: name: image-prefetch-daemonset namespace: NAMESPACE spec: selector: matchLabels: name: image-prefetch template: metadata: labels: name: image-prefetch spec: tolerations: - key: "buffer.gke.io/standby-capacity-node-suspended" operator: "Exists" initContainers: - name: image-puller image: IMAGE_NAME command: ["sh", "-c", "true"] containers: - name: pause image: registry.k8s.io/pause:3.9更改下列內容：
NAMESPACE：DaemonSet 的命名空間，例如capacity-buffer-example。IMAGE_NAME：要預先載入的圖片名稱，例如your-app-image:latest。
這個資訊清單包含
buffer.gke.io/standby-capacity-node-suspended容忍度，因此在 GKE 暫停待命節點後，DaemonSet 仍會排定在這些節點上。將 DaemonSet 資訊清單套用至叢集：
kubectl apply -f image-puller-daemonset.yaml確認 DaemonSet 是否已建立：
kubectl get daemonset image-prefetch-daemonset -n NAMESPACE確認容量緩衝區已建立，並可進行佈建：
kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE查看狀態。「
STATUS」欄位應顯示「ReadyForProvisioning」。
監控容量緩衝區狀態和效能
您可以使用 kubectl 指令和 Cloud Monitoring 指標，監控容量緩衝區的狀態和健康情況。
驗證 CapacityBuffer 資源狀態
如要檢查容量緩衝區的健康狀態，並確認緩衝區已準備好接收工作負載，請完成下列步驟：
取得叢集中所有容量緩衝區的狀態：
kubectl get capacitybuffer -A檢查特定緩衝區的詳細狀態、條件和事件記錄：
kubectl describe capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE
找出已暫停的待命緩衝區節點
待命緩衝 VM 會預先佈建，但會保持暫停狀態，以降低成本。這些暫停的節點具有自訂條件，因此可以辨識。如要稽核已暫停的節點執行個體，請執行下列指令：
kubectl get nodes -o custom-columns='NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status'
如果狀態為 True，表示待命 VM 已暫停。如果狀態為 False 或 <none>，表示節點正在運作。
使用 Cloud Monitoring 監控效能
如要監控容量緩衝區對擴充時間的端對端影響，請使用 Google Cloud 控制台中的「啟動延遲」資訊主頁。使用「Pod Startup Latency Distribution」(Pod 啟動延遲分布) 和「Pod First Ready Latency」(Pod 首次就緒延遲) 圖表，追蹤 Pod 從建立到就緒的 kubernetes.io/pod/latencies/pod_first_ready 指標。您也可以在 Cloud Logging 中查詢 Scheduled 事件，評估 Pod 排程延遲時間。如需操作說明，請參閱「監控啟動延遲指標」。
移除容量緩衝區
如果工作負載不再需要容量緩衝區，請刪除 CapacityBuffer 物件。這會移除預留位置 Pod，並允許叢集自動配置器縮減節點。
kubectl delete capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE
將 CAPACITY_BUFFER_NAME 替換為要刪除的 CapacityBuffer 名稱。
疑難排解
下節說明如何解決容量緩衝區的常見問題。
計費模式不支援容量緩衝區
如果您為採用 Pod 計費模式 (按 Pod 付費) 的工作負載建立 CapacityBuffer，容量緩衝區將無法佈建。
如要找出這個問題，請檢查 CapacityBuffer 狀態：
kubectl describe capacitybuffer BUFFER_NAME -n NAMESPACE
尋找類型為 ReadyForProvisioning 且狀態為 False 的條件。
如要解決這個問題，請確認 CapacityBuffer 參照的工作負載或 PodTemplate 與節點計費模式相容。
自訂可擴充資源的權限錯誤
如果您設定 CapacityBuffer 來搭配自訂可擴充物件 (使用 scalableRef 欄位)，叢集自動配置器可能會因缺少必要權限，而無法擴充緩衝區。這個問題只會發生在 GKE 1.36.0-gke.2459000 之前的版本。
如要解決這個問題，請建立 ClusterRole 和 ClusterRoleBinding，手動授予必要權限，例如：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: custom-scale-getter
rules:
- apiGroups: ["api.example.com"]
resources: ["customreplicatedresources/scale"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: ca-custom-scale-getter
subjects:
- kind: User
name: "system:cluster-autoscaler"
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: custom-scale-getter
如要進一步瞭解如何設定 RBAC，請參閱 Kubernetes RBAC 說明文件。
緩衝 Pod 不會排定在自訂 ComputeClass 佈建的節點上
如果 CapacityBuffer 設定依附元件 (例如 PodTemplate) 選取自訂 ComputeClass，緩衝區 Pod 可能不會排定在新佈建的節點上。這個問題會導致叢集自動配置器重複建立多餘的節點集區和節點，同時刪除閒置節點。
如果自訂 ComputeClass 佈建的節點有污點或特定執行階段需求，而緩衝 Pod (或其依賴的 PodTemplate) 沒有相符的容忍度或設定，就會發生這個問題。
如要解決這個問題，請更新 CapacityBuffer 設定，指定必要的容忍、節點選取器或執行階段類別。舉例來說，如果依附元件選取了設定 GKE Sandbox 的自訂 ComputeClass，請更新依附元件，執行下列任一操作：
- 指定
spec.runtimeClassName: gvisor欄位。 - 明確容許
sandbox.gke.io/runtime=gvisor:NoSchedule汙點。
詳情請參閱自訂 ComputeClass 說明文件。
備用緩衝區節點無法繼續執行
暫停的待命緩衝區節點可能無法繼續運作，原因如下：
- 如要恢復暫停的待命節點，可用區中必須有可用的 Compute Engine 容量，可供節點的機型和特定 CPU 平台代別使用，例如 E2 或 N2 機器系列。如果可用區的運算能力不足，無法支援該設定，節點就無法恢復。詳情請參閱「Compute Engine 暫停和繼續作業的限制」。
- 如果自訂 ComputeClass 啟用主動遷移至優先順序較高的節點 (
activeMigration.optimizeRulePriority: true)，並將 Spot VM 的優先順序設為高於隨選 VM，GKE 會逐漸將隨選待命節點遷移至 Spot VM。由於 Spot VM 較容易受到容量限制，且暫停的 Spot VM 無法在恢復時轉換為隨選 VM，因此這些限制可能會導致待命節點無法恢復。 - 繼續節點會超過專案的 Compute Engine 配額。詳情請參閱「容量緩衝區因配額限制而無法佈建」。
如要找出待命節點無法繼續執行的原因，請在 Logs Explorer 中查詢 Compute Engine 稽核記錄，找出 compute.instances.resume 作業的 ZONE_RESOURCE_POOL_EXHAUSTED 或 QUOTA_EXCEEDED 錯誤。
如要解決或減輕這個問題，請採取下列一或多個做法：
- 使用區域叢集，讓叢集自動配置器在多個可用區佈建或恢復節點。
- 在自訂 ComputeClass 的
spec.priorities清單中，設定多個機器家族。如果暫停的節點無法恢復，叢集自動配置器可以根據不同的優先順序規則，建立新的節點。這些新節點準備就緒所需的時間，比恢復待命狀態的節點還長。這項設定無法協助暫停的節點恢復運作，因為暫停的節點只能以原始機型恢復運作。 - 使用專屬的自訂 ComputeClass 搭配隨選 VM，或將待命緩衝區使用的 ComputeClass
activeMigration.optimizeRulePriority欄位設為false。 - 將待命緩衝區與小型有效緩衝區配對，以吸收即時流量高峰。
配額限制導致容量緩衝區無法佈建
如果容量緩衝區超過 Kubernetes ResourceQuotas 或 Compute Engine 配額，佈建的副本數量可能會少於要求數量，或無法向上擴充。
如要找出限制緩衝區的配額，請檢查下列一或多項配額：
檢查命名空間中的 Kubernetes ResourceQuota 是否限制緩衝區：
kubectl describe capacitybuffer \ CAPACITY_BUFFER_NAME \ -n NAMESPACE在
status.conditions輸出內容中，尋找狀態為True的LimitedByQuotas條件。無論是運作中或待命緩衝區單位 (包括由暫停待命節點支援的單位)，都會計入命名空間 ResourceQuota 限制，就像緩衝區 Pod 正在執行一樣。如果緩衝區超出命名空間配額，GKE 會將status.replicas欄位限制在可用配額內。檢查 Compute Engine 專案配額是否阻礙節點佈建。在 Logs Explorer 中，搜尋
container.googleapis.com/cluster-autoscaler-visibility記錄檔中的no.scale.up.nap.quota.exceeded事件，或搜尋 Compute Engine 稽核記錄中的QUOTA_EXCEEDED錯誤。檢查待命緩衝區的 Compute Engine 配額時，除了 vCPU 和記憶體配額外，請一併確認下列配額：
- 暫停的待命節點會保留內部和外部 IP 位址，因此會耗用使用中的 IP 位址配額。
- 暫停待命 VM 時，Compute Engine 會將節點的記憶體寫入磁碟，這會耗用與節點記憶體大小成正比的
Persistent disk standard (GB)磁碟配額。
如要解決配額限制問題，請採取下列任一做法：
- 在緩衝區的命名空間中增加 Kubernetes ResourceQuota。
- 申請調整 Compute Engine 配額。
- 減少 CapacityBuffer 資訊清單中的
replicas、limits或percentage值。
後續步驟
- 進一步瞭解容量緩衝區。
- 請參閱 CapacityBuffer CRD 說明文件。