在 GKE 中設定 Pod 爆量

本頁面說明如何設定 Pod，在 Google Kubernetes Engine (GKE) 節點上爆發可用的閒置容量。

什麼是爆量？

爆量是指 Pod 暫時使用的節點運算容量超出原先要求。

Kubernetes 可讓您為 Pod 要求特定容量的資源，例如 CPU 或記憶體。您可以在 Pod 資訊清單中設定這些要求。Kubernetes 排程器會將 Pod 放置在有足夠容量的節點上，以滿足這些資源要求。

部分工作負載在整個執行期間，不會使用 100% 的要求資源。舉例來說，工作負載在啟動期間會消耗額外的 CPU，但正常運作時可能不需要相同數量的資源。在這些情況下，您可以將工作負載的資源限制設為高於資源要求的數值，或不設定限制。如果容量充足，GKE 允許工作負載暫時使用超出要求中指定量的資源。

如要進一步瞭解這個程序在 GKE 中的運作方式，請參閱本頁的「GKE 中的可爆量容量」。

Pod 爆量的優點

如果 Pod 只需要在短時間內使用額外資源，以因應資源用量暴增的情況，爆量功能就非常實用。情境範例包括：

  • 您有一組工作負載經常處於閒置狀態，每秒傳送的要求數量很少，但偶爾會出現流量尖峰，因此需要額外資源來處理這些要求。
  • 工作負載在啟動期間需要的資源，比正常運作期間多。
  • 您希望盡量使用佈建的運算容量。

爆量功能可讓您只要求 Pod 在大部分執行階段所需的資源，同時確保 Pod 在需要時可使用更多資源。爆量的好處包括：

  • 降低執行成本：您不需要要求工作負載的預期尖峰資源消耗量。您可以要求較低的穩定狀態值。在 Autopilot 模式中，您只需支付 Pod 資源要求的總和，因此執行成本較低。
  • 更有效率地運用資源：由於 Pod 會爆發到未使用的容量，因此可避免閒置運算容量。工作負載更有可能使用所有付費資源。
  • 提升效能：Pod 可視需要使用額外資源，縮短處理傳入要求所需的時間，或在擴充事件期間加快啟動速度。

不應使用爆量的時機

Kubernetes 會為指定資源限制高於要求的 Pod 指派 Burstable 服務品質 (QoS) 類別。當 Kubernetes 需要回收節點上的資源時，Burstable QoS Pod 較有可能遭到驅逐。詳情請參閱 Kubernetes 說明文件中的可爆發 QoS 類別。

事前準備

開始之前，請確認你已完成下列工作：

  • 啟用 Google Kubernetes Engine API。
    • 啟用 Google Kubernetes Engine API
  • 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update，取得最新版本。
  • 請確認您有執行 1.30.2-gke.1394000 以上版本的 GKE Autopilot 叢集，或是任何版本的 GKE Standard 叢集。如要建立新叢集，請參閱「建立 Autopilot 叢集」。

GKE 中的爆量可用性

工作負載可能會在下列情況下爆量：

突發模式可用性
GKE Autopilot 模式

在支援 Pod 要求硬體的任何 GKE 版本中，下列類型的 Pod 皆可爆量：

對於所有其他類型的 Pod，請先確保叢集符合下列所有條件，然後重新啟動控制層，即可使用爆量功能：

  • 叢集正在執行 cgroupv2。 使用 GKE 1.26 以上版本建立的叢集，或已遷移至 cgroupv2 的叢集，都會符合這項條件。請參閱檢查 cgroup 模式，判斷目前的 cgroup 版本，並視需要遷移。
  • 叢集執行 GKE 1.30.2-gke.1394000 以上版本。

詳情請參閱「限制」一節。
GKE Standard 模式 Pod 可在任何 GKE 版本中爆量。

限制

  • Autopilot 工作負載只能將突發模式用於 CPU 和記憶體要求。

  • 將 Autopilot 叢集升級至支援版本時，GKE 會在一段時間後將工作站節點升級至與控制層版本相符。如要啟用爆量功能，必須重新啟動控制層，且必須在所有節點執行支援的版本和支援的 cgroup 模式後進行。在調度資源、升級或維護等作業期間，控制層大約每週會自動重新啟動一次。

    如要手動觸發控制平面重新啟動，請按照下列步驟操作：

    1. 檢查所有節點是否執行 1.30.2-gke.1394000 以上版本：

      kubectl get nodes

      輸出結果會與下列內容相似：

      NAME                                          STATUS   ROLES    AGE     VERSION
gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000

      輸出內容中的所有節點都必須顯示必要版本或更新版本。

    2. 確認叢集執行 cgroupv2。如需操作說明，請參閱「檢查 cgroup 模式」。

    3. 手動啟動控制層升級作業，升級至叢集目前使用的版本。

      gcloud container clusters upgrade CLUSTER_NAME --master \
    --cluster-version CURRENT_CLUSTER_VERSION

      更改下列內容：

      • CLUSTER_NAME：現有叢集的名稱。
      • CURRENT_CLUSTER_VERSION：叢集執行的版本。

連線至叢集

執行下列指令：

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

更改下列內容：

  • CLUSTER_NAME：現有叢集的名稱。
  • LOCATION：叢集位置。

確認叢集支援爆量

在 Standard 模式叢集中，以及要求加速器或特定機器系列的 Autopilot 模式工作負載中，一律會啟用爆量功能。直接前往「部署可爆量的工作負載」一節。

只有在叢集中執行名為 efficiency-daemon 的 GKE 管理 DaemonSet 時，下列類型的 Autopilot 工作負載才能爆量：

當 Autopilot 叢集符合爆量需求時，GKE 會部署 efficiency-daemon DaemonSet，詳情請參閱「GKE 中的爆量可用性」一節。

如要檢查叢集中是否有 efficiency-daemon DaemonSet，請執行下列指令：

kubectl get daemonset --namespace=kube-system efficiency-daemon

輸出結果會與下列內容相似：

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

如果輸出內容為空白，請確認叢集符合「事前準備」一節中的所有需求和限制。

部署可爆量的工作負載

  1. 將下列資訊清單儲存為 burstable-deployment.yaml：

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 350m

    這個資訊清單具有下列欄位，可啟用爆量功能：

    • resources.requests：容器運作所需的資源。請將這個值設為容器在穩定狀態下所需的容量。
    • resources.limits：容器可使用的資源容量上限。如果節點有足夠的容量，將限制設得比要求高，Pod 就能爆量至指定上限。如果省略這個欄位，Pod 最多可爆量至節點上可用的爆量容量。計算方式如下：
      • Autopilot 模式：節點上 Pod 資源要求總和中未使用的容量。
      • 標準模式：節點資源中未使用的容量。
    • spec.nodeSelector 和 spec.tolerations：選用。新增這些欄位，並加上 pod-type: "non-critical" 等自訂標籤，即可告知 GKE 建立新節點來執行可爆發的 Pod。GKE 會將汙點套用至這些新節點，防止其他 Pod (例如重要工作負載) 在相同節點上執行。如果 Pod 使用工作負載分離功能，Autopilot 會強制執行較高的 Pod 資源要求下限。詳情請參閱「在 GKE 中設定工作負載分離」和「Autopilot 中的資源要求」。

  2. 部署工作負載：

    kubectl apply -f burstable-deployment.yaml

    工作負載可能需要幾分鐘才會啟動。

  3. 檢查 Pod 的 QoS 類別：

    kubectl describe pod helloweb | grep -m 1 "QoS"

    輸出內容如下：

    QoS Class: Burstable

GKE 中的爆發容量

為方便 Pod 爆量，GKE 會計算叢集中每個節點的爆量容量。特定節點的計算方式如下：

  • Autopilot 叢集：

    • 要求加速器或特定機器系列的 Pod：節點可分配的資源容量，也就是可供工作負載使用的容量。詳情請參閱「節點可分配資源」。
    • 所有其他 Pod：該節點上所有 Pod 的資源要求總和，無論節點的實際資源容量為何。如果 Pod 終止，可爆發容量會減少該 Pod 的要求。如果其中一個 Pod 需要爆量，系統會分配未由執行中 Pod 使用的爆量容量部分。

    Autopilot 也會在可爆發容量中加入預先定義的緩衝區，因此節點上超出要求的任何系統 Pod，都不會影響您自己的可爆發 Pod。

  • 標準叢集：節點可分配的資源容量，也就是工作負載可用的容量。詳情請參閱「節點可分配資源」。

爆量最佳做法

使用 Pod 爆量時，請採用下列做法：

  • 針對環境中提供重要功能的任何 Pod，將資源要求設為與限制相同。確保這些 Pod 取得 Guaranteed Kubernetes 服務品質 (QoS) 類別。
  • 請務必只在 Pod 上設定記憶體爆量，因為 Kubernetes 需要回收節點上的記憶體時，可能會將這些 Pod 逐出。
  • 請務必為 Pod 要求足夠的記憶體，才能啟動 Pod。請勿依賴記憶體爆量來滿足啟動需求。
  • 如要避免可突發 Pod 持續突發至 CPU 要求的多倍，進而可能中斷重要工作負載，請使用工作負載分離，避免將這些 Pod 與重要 Pod 放在一起。

在 Autopilot 節點中最佳化可爆發容量

Autopilot 會計算特定節點上所有 Pod 的資源要求總和，包括系統 Pod 和 DaemonSet，做為可爆發容量。您可以透過下列方式，最佳化節點的可爆發容量。不過，爆量是機會性的，無法保證。

  • 如要提高特定工作負載節點的爆量容量，請使用 Pod 相依性，將特定 Pod 放在同一節點上。
  • 如要確保每個節點一律提供特定可爆發容量，請建立 DaemonSets，在叢集中的所有節點上執行。

爆量運作方式範例

本節將使用下列具有可爆發 Pod 的範例 Deployment，說明 GKE Autopilot 叢集中的 Pod 爆發機制：

  • Pod 1 要求 250m CPU，且沒有 CPU 限制。Pod 1 使用 100m CPU 執行。
  • Pod 2 要求 200m CPU，並設有 250m CPU 限制。Pod 2 使用 100m CPU 執行。

兩個 Pod 都在同一節點上執行。節點的總爆量容量為 450m CPU (資源要求總和)。每個 Pod 僅使用 100m CPU 執行，這表示節點的可用爆量容量還剩下 250m。

請參考下列流量暴增情境：

  • Pod 1 需要額外 300m 的 CPU：它可以爆發並使用 250m 的 CPU，這是可用的爆發容量。節點已沒有任何可用的爆量容量。
  • Pod 2 需要額外 150m 的 CPU：它可以爆量並使用額外 150m 的 CPU。 節點隨後會剩下 100 m CPU 的可用爆量容量。
  • Pod 2 需要額外 200m 的 CPU：它可以爆量並使用 150m 的 CPU，使 Pod 2 的 CPU 總用量達到 250m。Pod 2 的 CPU 上限為 250m，無法超過這個限制。

GKE 如何處理超出可爆量容量的 Pod

如果可爆發 Pod 嘗試使用的資源超過節點上的可爆發容量，GKE 會採取下列動作：

  • CPU：如果 CPU 使用量超過可突發容量，GKE 會限制部分容器的 CPU 使用量，確保節點上的所有容器都能取得要求的 CPU。
  • 記憶體：如果記憶體用量超過可爆量容量，GKE 會終止容器，以回收節點上的記憶體。GKE 會先終止 Pod 中資源用量高的容器，這些 Pod 的 QoS 較低。

建議您一律要求足夠的記憶體，確保 Pod 正常運作。如果容器需要記憶體爆量才能正常運作，但記憶體不足，容器可能會重複當機。

使用 Pod 爆量功能，並預先佈建備用容量

GKE 可讓您部署閒置 Pod，預留額外的運算容量，以便在日後流量較高的活動 (例如網路商店快閃特賣) 期間，更快擴充 Pod。同一節點上的其他 Pod 可以爆發到這個未使用的預留容量，因此在流量高峰期之前，容量不會閒置。您可以使用各種 Kubernetes 機制預留這項容量。舉例來說，您可以部署 PriorityClass 較低的 Pod。詳情請參閱「為快速 Pod 擴展作業佈建額外的運算容量」。

GKE Standard 叢集中的 Pod 爆量

GKE Standard 叢集也支援 Pod 爆量，方法是將限制設得高於要求，或省略限制。不過，在標準叢集中，您必須建立及設定具有適當資源容量的節點集區，才能支援爆量。如要瞭解標準叢集中可爆量 Pod 的潛在成本減幅，您需要更仔細地規劃節點和 Pod 裝箱，因為您需要支付基礎 Compute Engine VM 的費用。

在標準叢集中，請注意下列事項：

  • 觸發 Kubernetes 驅逐或 CPU 節流的資源用量上限，是節點上可分配的資源容量。如要判斷這個值，請參閱「規劃 GKE Standard 節點大小」。

  • 在 Standard 叢集中，節點資源用量較有可能達到 Kubernetes 驅逐門檻，因為如果您未指定限制，GKE 不會自動限制資源用量。因此，記憶體用量暴增的 Pod 更有可能遭到 Kubernetes 節點壓力驅逐終止。

後續步驟