在 GKE 中設定 Pod 爆發

本頁面說明如何設定 Pod，在 Google Kubernetes Engine (GKE) 節點上，將可用資源用量提升至可用未用容量。

什麼是爆發？

「Bursting」是指 Pod 暫時使用比原本要求更多的節點運算能力。

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

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

如要進一步瞭解這項程序在 GKE 中的運作方式，請參閱本頁的「GKE 中的 burst 可用資源」一節。

Pod 爆發的優點

如果 Pod 只需要短時間內使用額外資源，來因應資源用量激增的情況，則可使用高載功能。這類情況包括：

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

透過爆發功能，您只需要求 Pod 在大部分執行階段所需的資源，並確保 Pod 能在需要時使用更多資源。高載的優點包括：

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

不適合使用爆發功能的情況

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

事前準備

開始之前，請確認您已執行下列工作：

  • 啟用 Google Kubernetes Engine API。
    • 啟用 Google Kubernetes Engine API
  • 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update 指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文件中的指令。
  • 確認您有執行 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 會逐步升級 worker 節點，使其與控制層版本一致。如要啟用爆量功能，必須重新啟動控制層，且所有節點都必須執行支援的版本和 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 就能使用節點上的所有 burst 可用資源。計算方式如下：
      • Autopilot 模式：節點上 Pod 資源要求總和中未使用的容量。
      • 標準模式：節點資源中未使用的容量。
    • spec.nodeSelector 和 spec.tolerations：選用。新增這些欄位並加上 pod-type: "non-critical" 等自訂標籤，指示 GKE 建立新節點來執行可高載的 Pod。GKE 會對這些新節點套用污點，防止其他 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 的 burst 可用資源

為促進 Pod 爆發，GKE 會計算叢集中每個節點的 burst 可用資源。特定節點的計算方式如下：

  • Autopilot 叢集：

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

    Autopilot 也會為 burst 可用資源新增預先定義的緩衝區，確保節點上任何系統 Pod 的 burst 超過要求時，不會影響您自己的 burst Pod。

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

高載的最佳做法

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

  • 針對環境中提供重要功能的任何 Pod，將資源要求設為與限制相同。這種做法有助於確保這些 Pod 取得 Guaranteed Kubernetes 服務品質 (QoS) 類別。
  • 請務必只在 Pod 上設定記憶體爆量，以便在 Kubernetes 需要回收節點上的記憶體時，處理遭淘汰的 Pod。
  • 請務必為 Pod 要求足夠的記憶體，以便啟動。請勿依賴記憶體爆量功能來滿足啟動需求。
  • 如果可高載 Pod 持續高載至 CPU 要求的數倍，可能會干擾重要工作負載。為避免這種情況，請使用工作負載區隔，避免將這些 Pod 與重要 Pod 放在一起。

最佳化 Autopilot 節點的 burst 可用資源

Autopilot 會將特定節點上所有 Pod (包括系統 Pod 和 DaemonSet) 的資源要求總和，視為 burst 可用資源。您可以透過下列方式，最佳化節點的 burst 可用資源。不過，爆發功能會視情況而定，不保證一定能使用。

  • 如要增加節點上特定工作負載的 burst 可用資源，請使用 Pod 親和性，將特定 Pod 放在同一個節點上。
  • 為確保每個節點一律有特定 burst 可用資源，請建立 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 都在同一個節點上執行。節點的總 burst 可用資源為 450m CPU (資源要求總和)。每個 Pod 只使用 100m CPU 執行，代表節點還有 250m 的可用 burst 資源。

請參考下列流量激增的情境：

  • Pod 1 需要額外 300m CPU：可以 burst 並使用 250m CPU，也就是可用的 burst 可用資源。節點已無任何可用的 burst 可用資源。
  • Pod 2 需要額外 150m CPU：可以高載並使用額外 150m CPU。節點的可用 burst 資源則剩下 100m CPU。
  • Pod 2 需要額外 200m CPU：可以高載並使用 150m CPU，使 Pod 2 的總用量達到 250m CPU。Pod 2 的 CPU 限制為 250m，無法超過這個限制。

GKE 如何處理超出 burst 可用資源的 Pod

如果 burstable Pod 嘗試使用的資源超過節點的 burst 可用資源，GKE 會採取下列行動：

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

建議您一律要求足夠的記憶體，確保 Pod 正常運作。如果容器必須依賴記憶體爆量才能正常運作，則在記憶體不足時，可能會重複發生異常終止。

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

GKE 可讓您部署閒置 Pod，預留額外的運算容量，以便在日後發生高流量事件 (例如網路商店快閃促銷) 時，更快擴充 Pod。同一節點上的其他 Pod 可以爆發至這個未使用的預留容量，這樣一來，在高流量事件發生之前，容量就不會閒置。您可以使用各種 Kubernetes 機制預留這項容量。例如，您可以部署 PriorityClass 較低的 Pod。詳情請參閱「佈建額外運算資源，快速調度 Pod 資源」。

GKE Standard 叢集中的 Pod 爆量

GKE Standard 叢集也支援 Pod 爆發，只要將限制設為高於要求，或省略限制即可。不過，在 Standard 叢集中，您必須建立及設定節點集區，並提供適當的資源容量來支援爆發。如要降低 Standard 叢集中可高載 Pod 的潛在費用，您必須更仔細地規劃節點和 Pod 裝箱，因為您必須支付基礎 Compute Engine VM 的費用。

請留意 Standard 叢集的下列事項：

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

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

後續步驟