GSP768

總覽

Google Kubernetes Engine 提供各種水平與垂直解決方案，讓您自動調整 Pod 和基礎架構的資源配置。就成本效益而言，這些工具能派上極大用場，不僅確保工作負載高效執行，且只須支付實際使用的資源費用。

在本實驗室中，您將設定及觀察 Pod 層級的水平自動調度 Pod 資源和垂直自動調度 Pod 資源功能，並在節點層級設定叢集自動配置器 (水平基礎架構解決方案) 和自動佈建節點功能 (垂直基礎架構解決方案)。首先，我們會使用這些自動調度資源工具，盡可能節省資源，並在需求較低的期間縮減叢集大小。接著，請提升叢集需求，並觀察自動調度資源程序如何維持可用性。

目標

本實驗室的學習內容包括：

• 利用水平 Pod 自動配置器，減少 Deployment 的備用資源數量
• 利用垂直 Pod 自動配置器，減少 Deployment 的 CPU 要求量
• 利用叢集自動配置器，減少叢集所用節點數量
• 利用自動佈建節點功能，自動為工作負載建立最佳化的節點集區
• 測試需求高點時的自動調度資源行為
• 利用暫停 Pod 超額佈建叢集

設定和需求

瞭解以下事項後，再點選「Start Lab」按鈕

請詳閱以下操作說明。實驗室活動會計時，且中途無法暫停。點選「Start Lab」後就會開始計時，顯示可使用 Google Cloud 資源的時間。

您將在真正的雲端環境完成實作實驗室活動，而不是模擬或示範環境。為此，我們會提供新的暫時憑證，供您在實驗室活動期間登入及存取 Google Cloud。

為了順利完成這個實驗室，請先確認：

• 可以使用標準的網際網路瀏覽器 (Chrome 瀏覽器為佳)。

注意事項：請使用無痕模式 (建議選項) 或私密瀏覽視窗執行此實驗室，這可以防止個人帳戶和學員帳戶之間的衝突，避免個人帳戶產生額外費用。

• 是時候完成實驗室活動了！別忘了，活動一旦開始將無法暫停。

注意事項：務必使用實驗室專用的學員帳戶。如果使用其他 Google Cloud 帳戶，可能會產生額外費用。

如何開始研究室及登入 Google Cloud 控制台

1. 點選「Start Lab」按鈕。如果實驗室會產生費用，畫面上會出現選擇付款方式的對話方塊。左側的「Lab Details」窗格會顯示下列項目：

   • 「Open Google Cloud console」按鈕
   • 剩餘時間
   • 必須在這個研究室中使用的臨時憑證
   • 完成這個實驗室所需的其他資訊 (如有)

2. 點選「Open Google Cloud console」；如果使用 Chrome 瀏覽器，也能按一下滑鼠右鍵，選取「在無痕視窗中開啟連結」。

   接著，實驗室會啟動相關資源，並開啟另一個分頁，顯示「登入」頁面。

   提示：您可以在不同的視窗中並排開啟分頁。

   注意：如果頁面中顯示「選擇帳戶」對話方塊，請點選「使用其他帳戶」。

3. 如有必要，請將下方的 Username 貼到「登入」對話方塊。

   {{{user_0.username | "Username"}}}

   您也可以在「Lab Details」窗格找到 Username。

4. 點選「下一步」。

5. 複製下方的 Password，並貼到「歡迎使用」對話方塊。

   {{{user_0.password | "Password"}}}

   您也可以在「Lab Details」窗格找到 Password。

6. 點選「下一步」。

   重要事項：請務必使用實驗室提供的憑證，而非自己的 Google Cloud 帳戶憑證。 注意：如果使用自己的 Google Cloud 帳戶來進行這個實驗室，可能會產生額外費用。

7. 按過後續的所有頁面：

   • 接受條款及細則。
   • 由於這是臨時帳戶，請勿新增救援選項或雙重驗證機制。
   • 請勿申請免費試用。

Google Cloud 控制台稍後會在這個分頁開啟。

注意：如要使用 Google Cloud 產品和服務，請點選「導覽選單」，或在「搜尋」欄位輸入服務或產品名稱。

啟動 Cloud Shell

Cloud Shell 是搭載多項開發工具的虛擬機器，提供永久的 5 GB 主目錄，而且在 Google Cloud 中運作。Cloud Shell 提供指令列存取權，方便您使用 Google Cloud 資源。

1. 點按 Google Cloud 控制台頂端的「啟用 Cloud Shell」圖示 。

2. 系統顯示視窗時，請按照下列步驟操作：

   • 繼續操作 Cloud Shell 視窗。
   • 授權 Cloud Shell 使用您的憑證發出 Google Cloud API 呼叫。

連線建立完成即代表已通過驗證，而且專案已設為您的 Project_ID：。輸出內容中有一行文字，宣告本工作階段的 Project_ID：

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud 是 Google Cloud 的指令列工具，已預先安裝於 Cloud Shell，並支援 Tab 鍵自動完成功能。

3. (選用) 您可以執行下列指令來列出使用中的帳戶：

gcloud auth list

4. 點按「授權」。

輸出內容：

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (選用) 您可以使用下列指令來列出專案 ID：

gcloud config list project

輸出內容：

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注意：如需 gcloud 的完整說明，請前往 Google Cloud 參閱 gcloud CLI 總覽指南。

佈建測試環境

1. 將預設可用區設為 ：

gcloud config set compute/zone {{{project_0.default_zone | zone}}}

2. 執行以下指令，在 可用區中建立三個節點叢集：

gcloud container clusters create scaling-demo --num-nodes=3 --enable-vertical-pod-autoscaling

為示範如何水平自動調度 Pod 資源，本實驗室採用 php-apache 型的自訂 Docker 映像檔。該映像檔定義的 index.php 頁面會執行部分高 CPU 負載運算。您將監控此映像檔的 Deployment。

3. 為 php-apache Deployment 建立資訊清單：

cat << EOF > php-apache.yaml apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 3 template: metadata: labels: run: php-apache spec: containers: - name: php-apache image: k8s.gcr.io/hpa-example ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m --- apiVersion: v1 kind: Service metadata: name: php-apache labels: run: php-apache spec: ports: - port: 80 selector: run: php-apache EOF

4. 將新建立的資訊清單套用至叢集：

kubectl apply -f php-apache.yaml

點選「Check my progress」，確認上述工作已完成。佈建測試環境

工作 1：藉由水平自動調度 Pod 資源功能調整 Pod

水平自動調度 Pod 資源功能可根據工作負載的 CPU/記憶體消耗量，或根據 Kubernetes 內部報告的自訂指標/叢集外部來源的外部指標，自動增減 Pod 數量，從而變更 Kubernetes 工作負載的配置。

1. 在 Cloud Shell 中執行下列指令，檢查叢集的 Deployment：

kubectl get deployment

您應會看到 php-apache Deployment，內有 3/3 個 Pod 在執行：

NAME READY UP-TO-DATE AVAILABLE AGE php-apache 3/3 3 3 91s 注意：如果畫面沒顯示 3 個可用的 Pod，請稍候片刻，等待系統建立 Pod，然後再試一次上述指令。如果您看到可用 Pods 為 1/1，表示 Deployment 應該已完成縮減。

2. 對 php-apache Deployment 水平自動調度資源：

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

點選「Check my progress」，確認上述工作已完成。藉由水平自動調度 Pod 資源功能調整 Pod

這項 autoscale 指令會設定水平 Pod 自動配置器，將 php-apache Deployment 控管的 Pod 備用資源保持在 1 到 10 個之間。cpu-percent 標記會根據所有 Pod 要求的 CPU，將目標平均 CPU 用量指定為 50%。水平 Pod 自動配置器則會透過 Deployment 調整備用資源數量，讓所有 Pod 上的平均 CPU 用量保持在 50%。

3. 檢查水平 Pod 自動配置器的當前狀態：

kubectl get hpa

在「目標」欄下方，應會顯示 1%/50%。

這表示 Deployment 內的 Pod 的目標平均 CPU 用量目前為 1%。我們應可將此視為 php-apache 應用程式目前未收到任何流量。

注意：如果您看到 <未知>/50%，請稍候片刻，然後再次執行 kubectl get hpa 指令，因為水平 Pod 自動配置器尚未建立評估作業。

另請注意「備用資源」欄，起始的值會是 3。隨著所需 Pod 的數量更動，自動配置器會調整此數字。

在本例中，自動配置器會將 Deployment 的 Pod 縮減為您執行 autoscale 指令時指定的最低數量。水平自動調度 Pod 資源會耗費 5 到 10 分鐘，且需要視資源調度方式關閉或啟動新的 Pod。

繼續實驗室的下個步驟，稍候再檢查自動配置器的結果。

注意：您在本實驗室是將 cpu-percent 用做自動配置器的目標指標，但其實在水平 Pod 自動配置器中，您也可以定義自訂指標，根據記錄檔中擷取的其他實用指標調整 Pod 資源。

工作 2：藉由垂直自動調度 Pod 資源功能調整 Pod 大小

使用垂直自動調度 Pod 資源功能，您可以不必思考要為容器的 CPU 和記憶體要求指定什麼值。自動配置器可以建議 CPU/記憶體要求和相關限制的值，這些值也可自動更新。

注意：調度 CPU 或記憶體資源時，垂直自動調度 Pod 資源功能不應與水平自動調度 Pod 資源功能併用。這兩個自動配置器都會依據同一指標嘗試回應需求變更，因此會互相衝突。但是，以 CPU 或記憶體為依據的垂直 Pod 自動配置器，可與根據自訂指標的水平 Pod 自動配置器併用，如此便可避免重疊情況。

垂直自動調度 Pod 資源功能現已在 scaling-demo 叢集上啟用。

1. 如要驗證，請執行：

gcloud container clusters describe scaling-demo | grep ^verticalPodAutoscaling -A 1

輸出內容應會是 enabled: true

注意：透過 gcloud container clusters update scaling-demo --enable-vertical-pod-autoscaling 指令，可在現有叢集上啟用垂直自動調度 Pod 資源功能。

為示範垂直 Pod 自動配置器功能，需部署 hello-server 應用程式。

2. 將 hello-server Deployment 套用至叢集：

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

3. 確認 Deployment 已成功建立：

kubectl get deployment hello-server

4. 將 Deployment 的 CPU 資源要求量指派為 450m：

kubectl set resources deployment hello-server --requests=cpu=450m

5. 執行以下指令，檢查 hello-server Pod 的容器規格：

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

• 在輸出內容中找出 Requests。請注意，這個 Pod 目前的 CPU 要求量是您指派的 450m。

6. 接著為垂直 Pod 自動配置器建立資訊清單：

cat << EOF > hello-vpa.yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hello-server-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: hello-server updatePolicy: updateMode: "Off" EOF

上方指令會針對更新政策為 Off 的 hello-server Deployment，替垂直 Pod 自動配置器產生一份資訊清單。垂直 Pod 自動配置器有三種更新政策，可視應用程式擇一使用：

• 關閉：這項政策表示垂直 Pod 自動配置器會根據歷來資料產生建議，供您手動套用。
• 初始：垂直 Pod 自動配置器產生的建議只會用於建立新的 Pod，Pod 大小之後不會變動。
• 自動：按照建議大小定期刪除並重新建立 Pod。

7. 為 hello-vpa 套用資訊清單：

kubectl apply -f hello-vpa.yaml

8. 稍候幾分鐘，然後查看 VerticalPodAutoscaler：

kubectl describe vpa hello-server-vpa

在輸出內容結尾找出「Container Recommendations」。如果找不到，請多等待一點時間，然後再次執行上述指令。找到後，您會看到多種建議類型，以及 CPU 和記憶體的建議值：

• 下限：垂直 Pod 自動配置器會參考這個下限數字，觸發調整數量作業。如果 Pod 用量低於此數字，垂直 Pod 自動配置器會刪除該 Pod 並縮減規模。
• 目標：垂直 Pod 自動配置器會根據這個值，調整 Pod 大小。
• 目標 (無上限)：如未指派最小或最大容量，這會是垂直 Pod 自動配置器的目標用量。
• 上限：垂直 Pod 自動配置器會參考這個上限數字，觸發調整數量作業。如果 Pod 用量高於此數字，垂直 Pod 自動配置器會刪除該 Pod 並擴充規模。

您會發現垂直 Pod 自動配置器建議將這個容器的 CPU 要求量設為 25m，而非前述的 100m，並提供記憶體要求量建議。這時您可以將這些建議手動套用至 hello-server Deployment。

注意：垂直自動調度 Pod 資源功能是依據容器的歷來資料提供建議。實際上，在套用任何變更前，建議至少先等待 24 小時以便收集建議。

9. 為了在本實驗室中觀察垂直 Pod 自動配置器和其效果，請將 hello-vpa 更新政策設為 Auto，然後觀察資源調度情形。

10. 更新資訊清單，將政策設為 Auto，然後套用設定：

sed -i 's/Off/Auto/g' hello-vpa.yaml kubectl apply -f hello-vpa.yaml

為調整 Pod 數量，垂直 Pod 自動配置器需要刪除 Pod，並重新建立新數量的 Pod。根據預設，為了避免停機時間，垂直 Pod 自動配置器不會刪除及調整最後一個啟用中的 Pod。因此，您需要具備至少 2 個備用資源，以查看垂直 Pod 自動配置器做了那些變更。

11. 將 hello-server Deployment 調整為 2 個備用資源：

kubectl scale deployment hello-server --replicas=2

12. 現在請查看 Pod：

kubectl get pods -w

13. 稍候片刻，直到 hello-server-xxx Pod 顯示「終止中」或「待處理」狀態 (您也可以依序前往「Kubernetes Engine」>「工作負載」)：

這表示垂直 Pod 自動配置器正在刪除及調整 Pod 數量。如果看到這個內容，請按下 Ctrl + c 鍵結束指令。

點選「Check my progress」，確認上述工作已完成。藉由垂直自動調度 Pod 資源功能調整 Pod 大小

工作 3：水平 Pod 自動配置器結果

目前水平 Pod 自動配置器可能會縮減 php-apache Deployment 的資源。

1. 執行以下指令，檢查水平 Pod 自動配置器：

kubectl get hpa

• 查看「備用資源」欄，您會看到 php-apache Deployment 已縮減為 1 Pod。

注意：如果看到 php-apache Deployment 仍有 3 個備用資源，可能須等待幾分鐘，讓自動配置器完成作業。

• 水平 Pod 自動配置器會確認應用程式當下是否並未啟用，並移除所有未使用的資源。此外，如果 php-apache 應用程式的需求增加，自動配置器會再次擴充規模。

注意：如果應用程式可用性是最主要的考量，建議您為水平 Pod 自動配置器的最小 Pod 數預留較多緩衝，使其有時間調度資源。

在考量成本最佳化時，這種做法非常實用。如果自動配置器經過妥善調整，則不論需求如何，只需針對維持可用性所需的資源支付費用，就能維持應用程式的高可用性。

工作 4：垂直 Pod 自動配置器結果

現在垂直 Pod 自動配置器應該已重新調整 hello-server Deployment 中的 Pod 數量。

1. 檢查 Pod：

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

2. 查看「Requests:」欄位。

• 垂直 Pod 自動配置器會依據目標用量重新建立 Pod。現在系統對 CPU 的要求量應該會減少，也會要求特定的記憶體數量。

Requests: cpu: 25m memory: 262144k 注意：如果您看到每個 Pod 的 CPU 要求數依然是 450m，請使用這個指令手動設定 CPU 資源的目標：kubectl set resources deployment hello-server --requests=cpu=25m。有時候，處於自動模式的垂直 Pod 自動配置器需要很長的作業時間，或因沒有時間收集正確資料而設定過高/過低的界限值。為節省時間，本實驗室的建議假設垂直 Pod 自動配置器的模式已設為「Off」，這是比較簡單的做法。

這樣一來，垂直 Pod 自動配置器就會是最佳化資源使用率的絕佳工具，並能有效節省成本。原先要求的 CPU 數量為 400m，遠高於這個容器所需的數量。將要求數調整為建議的 25m，從節點集區使用的 CPU 就會減少，連帶減少叢集中需佈建的節點數。

透過自動更新政策，垂直 Pod 自動配置器會在生命週期中持續刪除及調整 hello-server Deployment 的 Pod 數量，在須處理龐大流量時擴充 Pod 規模，並在停機時間縮減 Pod 數量，因此可視為應用程式穩定成長需求的絕佳工具，但在流量尖峰時，可能會影響可用性。

視應用程式需求，最安全的做法通常是使用垂直 Pod 自動配置器，將更新政策設為 Off，並在需要時設定建議值，這樣就能有效善用資源，同時確保叢集高可用性。

在接下來幾節中，您將瞭解如何透過叢集自動配置器和自動佈建節點功能，進一步最佳化資源使用率。

工作 5：叢集自動配置器

叢集自動配置器可視需求新增或移除節點。如有高度需求，叢集自動配置器會在節點集區新增節點；當需求較低時，叢集自動配置器會移除節點，縮減叢集資源。這樣一來，既能維持叢集的高可用性，也能有效避免其他機器消耗多餘成本。

1. 為叢集啟用自動調度資源功能：

gcloud beta container clusters update scaling-demo --enable-autoscaling --min-nodes 1 --max-nodes 5

這項作業需要幾分鐘才能完成。

調度叢集資源時，如要判斷移除節點的時間點，應綜合評估使用率的最佳化成效與資源可用性。移除使用率偏低的節點可提高叢集使用率，但新的工作負載可能需要等到資源重新佈建後才能開始處理。

您可以指定要使用何種自動調度資源設定檔來做這類決策。目前可用的設定檔包括：

• 平衡：預設設定檔。
• 最佳化使用率：比起在叢集中保留備用資源，優先考量最佳化使用率。如選取這個選項，叢集自動配置器會更積極縮減叢集資源、移除更多節點，移除速度也會加快。這個設定檔經過最佳化調整，適合對啟動延遲不敏感的批次工作負載。

2. 改為 optimize-utilization 自動調度資源設定檔，以便觀察資源調度的完整效果：

gcloud beta container clusters update scaling-demo \ --autoscaling-profile optimize-utilization

3. 啟用自動調度資源功能後，在 Cloud 控制台中觀察叢集。按一下左上方的三橫線圖示，開啟「導覽選單」。

4. 在「導覽選單」，依序選取「Kubernetes Engine」>「叢集」。

5. 在「叢集」頁面，選取「scaling-demo」叢集。

6. 在「scaling-demo」叢集頁面中，選取「節點」分頁標籤。

7. 查看三個節點的資源使用率總覽。

注意：您的數字可能會與圖中數字不同。Kubernetes 每次佈建及指派資源的方式不盡相同。

如果合併 3 個節點的「已要求的 CPU」和「可分配的 CPU」值，則總數分別為 1555m 和 2820m。這表示整個叢集中的可用 CPU 總數為 1265m，大於一個節點可提供的數量。

如要最佳化使用率，可以根據現有需求，將目前的工作負載從三個節點整合為兩個節點。不過，您的叢集尚未自動縮減資源配置，這是因為「系統 Pod」分散在叢集中。

您的叢集會在 kube-system 命名空間執行多個 Deployment，讓 Logging、Monitoring 和自動調度資源等不同的 GKE 服務得以運作。

8. 您可以在 Cloud Shell 中執行下列指令，確認執行狀況：

kubectl get deployment -n kube-system

根據預設，這些 Deployment 大多數的系統 Pod，會導致叢集自動配置器無法藉由使 Pod 離線來重新排程 Pod。通常這樣較為理想，因為其他 Deployment 和服務會使用這些 Pod 收集資料。舉例來說，若「metrics-agent」暫時中斷服務，會導致垂直 Pod 自動配置器和水平 Pod 自動配置器收集的資料有落差，若「fluentd」Pod 中斷服務，會導致雲端記錄有落差。

為了本實驗室的目標，您要將 Pod disruption budget 套用至 kube-system Pod，讓叢集自動配置器安全地在其他節點上重新排程 Pod。這麼做可讓叢集有足夠的空間縮減資源。

Pod disruption budget (PDB) 會定義 Kubernetes 處理中斷 (例如升級、移除 Pod 或用盡資源等) 的方式。您可以在 PDB 中指定 Deployment 應包含的 max-unavailable 和/或 min-available Pod 數。

9. 執行下列指令，為每個 kube-system Pod 建立 Pod disruption budget：

kubectl create poddisruptionbudget kube-dns-pdb --namespace=kube-system --selector k8s-app=kube-dns --max-unavailable 1 kubectl create poddisruptionbudget prometheus-pdb --namespace=kube-system --selector k8s-app=prometheus-to-sd --max-unavailable 1 kubectl create poddisruptionbudget kube-proxy-pdb --namespace=kube-system --selector component=kube-proxy --max-unavailable 1 kubectl create poddisruptionbudget metrics-agent-pdb --namespace=kube-system --selector k8s-app=gke-metrics-agent --max-unavailable 1 kubectl create poddisruptionbudget metrics-server-pdb --namespace=kube-system --selector k8s-app=metrics-server --max-unavailable 1 kubectl create poddisruptionbudget fluentd-pdb --namespace=kube-system --selector k8s-app=fluentd-gke --max-unavailable 1 kubectl create poddisruptionbudget backend-pdb --namespace=kube-system --selector k8s-app=glbc --max-unavailable 1 kubectl create poddisruptionbudget kube-dns-autoscaler-pdb --namespace=kube-system --selector k8s-app=kube-dns-autoscaler --max-unavailable 1 kubectl create poddisruptionbudget stackdriver-pdb --namespace=kube-system --selector app=stackdriver-metadata-agent --max-unavailable 1 kubectl create poddisruptionbudget event-pdb --namespace=kube-system --selector k8s-app=event-exporter --max-unavailable 1

點選「Check my progress」，確認上述工作已完成。叢集自動配置器

在每個指令中，您要根據建立 Deployment 時定義的標籤，選擇不同的 kube-system Deployment Pod，並且指定每個 Deployment 中只能有 1 個不可用的 Pod。這麼做可讓自動配置器重新排程系統 Pod。

若使用 PDB，您的叢集就能在一至兩分鐘內，從三個節點縮減至兩個節點。

10. 在 Cloud Shell 中執行下列指令，直到您只看到兩個節點：

kubectl get nodes

在 Cloud 控制台中重新整理 scaling-demo的「節點」分頁，檢查資源的封裝方式：

您設定了自動化程序，將叢集資源從三個節點縮減為兩個節點！

在成本考量方面，若縮減節點集區，您就能在叢集需求較低時，減少須付費的機器。如果一天中的流量需求大幅波動，資源調整的幅度會更明顯。

值得注意的是，叢集自動配置器會移除不必要的節點，而垂直自動調度 Pod 資源和水平自動調度 Pod 資源則會因應 CPU 需求，減少不再需要的節點。結合使用這些工具，是優化整體成本和資源使用情形的絕佳做法。

叢集自動配置器能因應需要排程的 Pod，新增及移除節點。不過，GKE 還有專門垂直調整資源的功能，稱為自動佈建節點。

工作 6：自動佈建節點

自動佈建節點 (NAP) 會實際新增大小符合需求的節點集區。如未啟用自動佈建節點功能，叢集自動配置器只會在您指定的節點集區中建立新節點，也就是說，新節點的機器類型會與該集區中的其他節點相同。如要讓不必大幅調度資源的批次工作負載和其他應用程式能充分運用資源，這是最好的做法，因為只需在現有集區中新增更多節點，不必建立專為特定用途最佳化調整的節點集區，因此可以節省時間。

• 啟用自動佈建節點功能：

gcloud container clusters update scaling-demo \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 2 \ --max-cpu 45 \ --max-memory 160

在指令中，您要指定 CPU 和記憶體資源數量的下限與上限。這裡指的是供整個叢集使用的資源。

自動佈建節點功能需要一些作業時間，而根據 scaling-demo 叢集的當前狀態，很可能不需要建立新的節點集區。

在接下來幾節中，您將增加叢集的需求，然後觀察自動配置器和自動佈建節點功能的動作。

點選「Check my progress」，確認上述工作已完成。自動佈建節點

工作 7：在高需求環境下測試

目前您已分析過在應用程式需求偏低時，水平 Pod 自動配置器、垂直 Pod 自動配置器和叢集自動配置器如何協助節省資源和成本。接下來，您將瞭解在需求增加時，這些工具如何維持可用性。

1. 在 Cloud Shell 中點選「+」圖示，開啟新分頁：

2. 在新分頁中執行下列指令，向 php-apache 服務傳送無限迴圈的查詢：

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

3. 返回原本的「Cloud Shell」分頁。

4. 執行下列指令，過一分鐘左右，您應該會在水平 Pod 自動配置器上看到較高的 CPU 負載：

kubectl get hpa

稍後請重新執行指令，直到目標高於 100%。

5. 現在，請定期執行下列指令，觀察叢集如何因應增加的負載：

kubectl get deployment php-apache

您也可以在 Cloud 控制台中重新整理「節點」分頁來監控叢集。

幾分鐘後，您會看到系統執行一些操作。

• 首先，水平 Pod 自動配置器會自動擴充 php-apache Deployment 資源，以因應增加的負載。
• 接著，叢集自動配置器須佈建新節點，以調節增加的負載。
• 最後，自動佈建節點功能會建立一個節點集區，依據叢集工作負載的 CPU 和記憶體要求最佳化。在本例中，應該是高 CPU、低記憶體的節點集區，因為負載測試正接近 CPU 上限。

稍候片刻，直到 php-apache Deployment 擴充至 7 個備用資源，且節點分頁類似以下畫面：

6. 返回您執行負載測試的「Cloud Shell」分頁，按下 Ctrl + c 鍵取消作業。您的叢集將再次因需求減少而縮減資源。

您的叢集已有效擴充來因應更多需求！不過，請留意叢集應對需求激增所花的時間。對許多應用程式來說，佈建新資源時若無法維持可用性，可能會發生問題。

工作 8：最佳化大量負載

為處理大量負載而擴充時，根據您的設定，水平自動調度 Pod 資源功能會新增 Pod，而垂直自動調度 Pod 資源功能會調整 Pod 數量。如果現有節點還有空間，或許可以略過映像檔提取步驟，立即在新 Pod 上執行應用程式。如果您的節點並未先在應用程式上部署，若需要先下載容器映像檔再執行應用程式，則所需的作業時間會略為增加。

因此，如果現有節點上沒有足夠空間，且您正在使用叢集自動配置器，可能會需要更多時間。現在系統需要佈建新節點、設定節點，接著下載映像檔並啟動 Pod。如果自動佈建節點功能將建立新節點集區 (與在叢集中進行的作業相同)，由於須從佈建新節點集區開始，對新節點執行的步驟也完全相同，因此花費的時間更久。

注意：實務上，確保應用程式盡可能使用最小的容器映像檔，是很重要的一環。小型映像檔能減少 Pod 冷啟動時間，因為在叢集自動配置器為叢集佈建新節點時，節點可以用較快的速度下載映像檔。此外，大型映像檔可能會使 Pod 啟動時間較長，在流量激增時佈建新節點會導致效能不佳。

為因應自動調度過程中的不同延遲，建議您超額佈建一些資源，以降低應用程式的壓力。這對成本優化而言十分重要，因為您不會想支付不需要的資源費用，也不希望應用程式效能降低。

如想瞭解應額外配置多少資源，請使用以下公式：

以叢集的 CPU 使用率為例。您不希望使用率達到 100%，因此可選擇 15% 的緩衝，確保安全空間。接著，公式中的流量變數，是 2 到 3 分鐘內預期增加的流量百分比。在先前的負載測試中，流量增長 0% 到 150% 是較極端的例子，因此我們改用較平均的數值，也就是 30%。

依據這些數字，可以得出約 65% 的安全緩衝。這表示，您可以超額佈建約 65% 的資源，同時盡可能降低問題發生的可能性。

如想透過自動調度資源功能超額佈建叢集，「暫停 Pod」是很有效的策略。

暫停 Pod 是低優先順序的 Deployment，可由高優先順序的 Deployment 移除及取代。這代表您可以建立低優先順序的 Pod，但除了保留緩衝空間外，不實際執行任何操作。當高優先順序的 Pod 需要空間時，系統會移除暫停 Pod，並將其重新排程至其他節點或新節點，系統就有空間可以快速排程高優先順序的 Pod。

1. 為暫停 Pod 建立資訊清單：

cat << EOF > pause-pod.yaml --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning namespace: kube-system spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning containers: - name: reserve-resources image: k8s.gcr.io/pause resources: requests: cpu: 1 memory: 4Gi EOF

2. 將其套用至叢集：

kubectl apply -f pause-pod.yaml

3. 請稍候片刻，然後重新整理 scaling-demo 叢集的「節點」分頁。

觀察新節點的建立方式，很可能是在新節點集區中建立，以容納新建立的暫停 Pod。現在如果再次執行負載測試，當 php-apache Deployment 需要額外節點時，系統會在含有暫停 Pod 的節點上排程，並將該 Pod 改放到新節點。這是很好的做法，因為虛設的暫停 Pod 可讓叢集事先佈建新節點，實際的應用程式也就能更快擴充資源。如果預期會有較高流量，可以新增更多暫停 Pod，但原則上一個節點最多一個。

點選「Check my progress」，確認上述工作已完成。最佳化大量負載

恭喜！

恭喜！在本實驗室中，您設定了叢集，並能有效依需求自動擴充或縮減資源。此外，水平和垂直自動調度 Pod 資源功能，為叢集的 Deployment 提供了解決方案，而叢集自動配置器和自動佈建節點功能，則為叢集的基礎架構提供解決方案。

一如既往，您已瞭解如何根據工作負載使用適合的工具。謹慎使用這些自動配置器，可讓您在有需要時獲得最大可用性，在需求較低時則僅針對所需資源付費。就成本考量而言，這表示您可以充分運用資源，同時節省費用。

後續行動/瞭解詳情

查看下列資源，進一步瞭解本實驗室涵蓋的主題：

• 在 GKE 上執行最具成本效益的 Kubernetes 應用程式的最佳做法：微調 GKE 自動調度資源功能
• 叢集自動配置器說明文件
• 水平 Pod 自動配置器說明文件
• 垂直 Pod 自動配置器說明文件

Google Cloud 教育訓練與認證

協助您瞭解如何充分運用 Google Cloud 的技術。我們的課程會介紹專業技能和最佳做法，讓您可以快速掌握要領並持續進修。我們提供從基本到進階等級的訓練課程，並有隨選、線上和虛擬課程等選項，方便您抽空參加。認證可協助您驗證及證明自己在 Google Cloud 技術方面的技能和專業知識。

使用手冊上次更新日期：2025 年 8 月 28 日

實驗室上次測試日期：2025 年 8 月 28 日

Copyright 2026 Google LLC 保留所有權利。Google 和 Google 標誌是 Google LLC 的商標，其他公司和產品名稱則有可能是其關聯公司的商標。