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」圖示 。

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

您在本工作階段中的 Cloud Platform 專案會設為「YOUR_PROJECT_ID」

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

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

gcloud auth list

3. 點按「授權」。

4. 輸出畫面應如下所示：

輸出內容：

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

輸出內容：

[core] project = <project_ID>

輸出內容範例：

[core] project = qwiklabs-gcp-44776a13dea667a6 附註：如需有關 gcloud 的完整說明，請前往 Google Cloud 並參閱「gcloud CLI overview guide」(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，然後再試一次上述指令。如果您看到 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 自動配置器 VPA，您需要部署 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。

您會發現垂直 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 叢集的「節點」分頁。

觀察新節點的建立方式，最有可能是在新節點集區中建立，以符合新建立的暫停集區。現在如果再次執行負載測試，當 php-apache Deployment 需要額外節點，系統會在含有暫停 pod 的節點上排程，而將暫停 pod 改放在新節點上。這種做法非常好，因為虛設的暫停 pod 可讓您的叢集事先佈建新節點，讓實際應用程式能以更快的速度向上擴充資源。如果您希望有較高的流量，可以新增更多暫停 pod，但建議做法是一個節點上不要新增超過一個暫停 pod。

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

恭喜！

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

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

後續行動/瞭解詳情

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

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

Google Cloud 教育訓練與認證

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

使用手冊上次更新日期：2024 年 2 月 1 日

實驗室上次測試日期：2023 年 9 月 20 日

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