設定容量緩衝區

容量緩衝區會使用 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 工作負載範例，請完成下列步驟：

1. 將下列資訊清單儲存為 namespace.yaml：

   apiVersion: v1
   kind: Namespace
   metadata:
     name: capacity-buffer-example
     labels:
       name: capacity-buffer-example
   

   這個資訊清單會建立名為 capacity-buffer-example 的命名空間。

2. 選用：如要搭配自訂 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」。

3. 將下列資訊清單儲存為 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，定義單一緩衝容量單位 (1 CPU 和 1Gi 記憶體) 的資源需求。這項設定會指定 GKE 為緩衝區佈建的容量單位大小。舉例來說，如果叢集擴充，GKE 不會將可用資源少於 1 個 CPU 和 1 Gi 的節點視為緩衝區的一部分。

4. 將下列資訊清單儲存為 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，做為下一節百分比緩衝區範例的參照物件。

5. 將資訊清單套用至叢集：

   kubectl apply -f namespace.yaml -f custom-compute-class.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml
   

6. 確認 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 指定所需的緩衝區單位確切數量。

如要建立具有固定副本的緩衝區，請完成下列步驟：

1. 將下列資訊清單儲存為 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 來要求特定數量的緩衝區單位。

2. 套用資訊清單：

   kubectl apply -f cb-fixed-replicas.yaml
   

3. 確認 GKE 已套用容量緩衝區：

   kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE
   

   狀態中的 replicas 欄位應顯示 3，反映您在資訊清單中定義的副本數量。「STATUS」欄位應顯示「ReadyForProvisioning」。

設定資源限制緩衝區

您可以使用 limits 欄位，定義緩衝區應消耗的資源量上限，系統會根據 PodTemplate 大小計算。

如要建立資源限制緩衝區，請完成下列步驟：

1. 將下列資訊清單儲存為 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 範例，請將每個單位定義為 1 CPU 和 1Gi 記憶體，這樣應該會產生 5 個緩衝單位。

2. 套用資訊清單：

   kubectl apply -f cb-resource-limits.yaml
   

3. 確認 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 參照了具有 10 個副本的 Deployment。10 個副本的 20% 為 2，小於 replicas 值 3，因此 GKE 會佈建 3 個緩衝區單位。如果 Deployment 擴充至 20 個副本，緩衝區會增加至 4 個單位。詳情請參閱 CapacityBuffer 參考文件。

如要建立以百分比為單位的緩衝區，請完成下列步驟：

1. 將下列資訊清單儲存為 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。

2. 套用資訊清單：

   kubectl apply -f cb-percentage-based.yaml
   

3. 確認 GKE 已套用容量緩衝區：

   kubectl get capacitybuffer percentage-buffer -n NAMESPACE
   

   檢查 CapacityBuffer 狀態。replicas 欄位應顯示百分比計算結果。如果您使用上一節的 Deployment 範例，應該會看到 2 個緩衝單位，也就是 Deployment 中定義的 10 個副本的 20%。

4. 手動將 Deployment 擴充至 20 個副本，測試動態調度資源：

   kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20
   

   CapacityBuffer 控制器會做出反應，並自動將緩衝區擴充至 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 預先載入映像檔，請完成下列步驟：

1. 將下列資訊清單儲存為 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 仍會排定在待命節點上。

2. 將 DaemonSet 資訊清單套用至叢集：

   kubectl apply -f image-puller-daemonset.yaml
   

3. 確認 DaemonSet 已建立：

   kubectl get daemonset image-prefetch-daemonset -n NAMESPACE
   

4. 確認容量緩衝區已建立，可供佈建：

   kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE
   

   查看狀態。「STATUS」欄位應顯示「ReadyForProvisioning」。

監控容量緩衝區狀態和效能

您可以使用 kubectl 指令和 Cloud Monitoring 指標，監控容量緩衝區的狀態和健康情況。

驗證 CapacityBuffer 資源狀態

如要檢查容量緩衝區的健康狀態，並確認緩衝區已準備好接收工作負載，請完成下列步驟：

1. 取得叢集中所有容量緩衝區的狀態：

   kubectl get capacitybuffer -A
   

2. 檢查特定緩衝區的詳細狀態、條件和事件記錄：

   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 控制台中的「Startup Latency」(啟動延遲時間) 資訊主頁。使用「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 欄位)，叢集自動配置器可能會因缺少必要權限，而無法擴充緩衝區。這個問題只會發生在 1.36.0-gke.2459000 之前的 GKE 版本。

如要解決這個問題，請建立 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 說明文件。

待命緩衝區節點無法繼續

暫停的待命緩衝區節點可能無法恢復，原因如下：

• 如要恢復暫停的待命節點，該節點的機型和特定 CPU 平台世代 (例如 E2 或 N2 機器系列) 必須在可用區內有可用的 Compute Engine 容量。如果可用區的運算能力不足，無法支援該設定，節點就無法恢復。詳情請參閱「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 值。

待命節點恢復後，DaemonSet Pod 停止接收資料

暫停的待命緩衝區節點恢復後，該節點上的 DaemonSet Pod 可能會停止透過節點暫停前開啟的長期連線接收資料。Pod 不會記錄任何錯誤，也不會重新連線。

如果 DaemonSet Pod 做為僅接收用戶端，例如串流 HTTP 回應、WebSocket 連線、伺服器傳送事件或 gRPC 伺服器串流呼叫，就會發生這個問題。待命節點暫停時，伺服器或中繼網路裝置會逾時並關閉連線。節點恢復運作時，Pod 的網路堆疊仍會將連線視為開啟狀態。由於 Pod 不會傳送任何資料，因此永遠不會偵測到連線已關閉，並會無限期等待資料。

如要解決這個問題，請在 DaemonSet Pod 中設定用戶端應用程式，偵測已關閉的連線，並透過下列任一方式重新連線：

• 在 Pod 的應用程式中設定用戶端 TCP 保持運作 (僅在伺服器上啟用保持運作不會通知 Pod)。如要進一步瞭解 TCP 保持運作參數，請參閱「閒置連線」。
  1. 在用戶端程式庫或語言執行階段中啟用 SO_KEEPALIVE 通訊端選項，例如 Node.js 中的 socket.setKeepAlive(true, initialDelay) 或 Go 中的 net.Dialer.KeepAlive。部分執行階段預設會停用 TCP 保持運作。
  2. 設定較短的 Keep-Alive 閒置時間 (TCP_KEEPIDLE)，例如幾秒鐘，而不是依賴作業系統預設值。
  3. 更新應用程式，以便在持續連線探測失敗時擷取連線錯誤 (例如連線重設或逾時)，並開啟新的連線。
• 在用戶端設定應用程式層級的心跳訊號或讀取逾時，例如 WebSocket ping 和 pong 框架或 gRPC keepalive ping，並更新應用程式，以便在逾時發生時重新連線。

後續步驟

• 進一步瞭解容量緩衝區。
• 請參閱 CapacityBuffer CRD 說明文件。