GSP769

總覽

使用 Google Cloud 的其中一項好處，是只需按照實際使用的資源付費。因此，為應用程式和基礎架構配置合理的資源數量，並充分活用資源，對您來說十分重要。GKE 提供了許多工具和策略，可讓您減少不同資源和服務的用量，同時提高應用程式的可用性。

本實驗室將逐步介紹幾個概念，幫助您提升工作負載的資源效率與可用性。藉由瞭解及微調叢集的工作負載，您可以進一步確保只使用需要的資源，讓叢集成本獲得最佳效益。

目標

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

• 透過 Ingress 建立容器原生負載平衡器
• 對應用程式執行負載測試
• 設定 liveness 和 readiness 探測
• 建立 pod disruption budget

設定和需求

點選「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. 按一下「授權」。

3. 建立三個節點叢集：

gcloud container clusters create test-cluster --num-nodes=3 --enable-ip-alias

其中包含 --enable-ip-alias 旗標，因為如果要透過 Ingress 使用容器原生負載平衡，則需要讓 pod 能使用別名 IP。

在本實驗室中，您要先將一個 HTTP 網頁應用程式部署為單一 pod。

4. 為 gb-frontend pod 建立資訊清單：

cat << EOF > gb_frontend_pod.yaml apiVersion: v1 kind: Pod metadata: labels: app: gb-frontend name: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 256Mi ports: - containerPort: 80 EOF

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

kubectl apply -f gb_frontend_pod.yaml 注意：您可能需要等候 1 至 2 分鐘，才能取得這項工作的分數。

點選「Check my progress」，確認目標已達成。 佈建實驗室環境

工作 1：透過 Ingress 使用容器原生負載平衡功能

容器原生負載平衡功能可讓負載平衡器直接指定 Kubernetes Pod，並將流量平均傳送給 pod。

要是沒有容器原生負載平衡功能，負載平衡器流量會前往節點執行個體群組，並且透過 iptables 規則轉送到多個 pod，而這些 pod 不一定位於同一節點內：

容器原生負載平衡功能可讓 pod 成為負載平衡的核心物件，而可能降低網路躍點的數量：

容器原生負載平衡不但能更有效率地轉送流量，還可以大幅減少網路使用率、提升效能，甚至可以分配 Pod 間的流量，以及進行應用程式層級的健康檢查。

為了充分利用容器原生負載平衡功能，必須在叢集中啟用虛擬私有雲原生設定。當您建立叢集並加入 --enable-ip-alias 旗標，系統會要求您啟用設定。

1. 以下資訊清單會建立 ClusterIP 服務，用於將流量轉送至應用程式 pod，進而允許 GKE 建立網路端點群組：

cat << EOF > gb_frontend_cluster_ip.yaml apiVersion: v1 kind: Service metadata: name: gb-frontend-svc annotations: cloud.google.com/neg: '{"ingress": true}' spec: type: ClusterIP selector: app: gb-frontend ports: - port: 80 protocol: TCP targetPort: 80 EOF

資訊清單包含 annotations 欄位，含有 cloud.google.com/neg 的註解，可在建立 Ingress 時為應用程式啟用容器原生負載平衡功能。

2. 將變更套用至叢集：

kubectl apply -f gb_frontend_cluster_ip.yaml

3. 接下來，為應用程式建立 Ingress：

cat << EOF > gb_frontend_ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: gb-frontend-ingress spec: defaultBackend: service: name: gb-frontend-svc port: number: 80 EOF

4. 將變更套用至叢集：

kubectl apply -f gb_frontend_ingress.yaml

建立 Ingress 後，HTTP(S) 負載平衡器會建立，NEG (網路端點群組) 也會在叢集執行所在的每個可用區裡建立。幾分鐘後，Ingress 會獲派外部 IP。

建立的負載平衡器會在專案中執行後端服務，定義 Cloud Load Balancing 分配流量的方式。這個後端服務擁有與其相關聯的健康狀態。

5. 如要檢查後端服務的健康狀態，請先擷取名稱：

BACKEND_SERVICE=$(gcloud compute backend-services list | grep NAME | cut -d ' ' -f2)

6. 取得服務的健康狀態：

gcloud compute backend-services get-health $BACKEND_SERVICE --global

健康檢查可能需要幾分鐘，才會傳回「健康狀態良好」狀態。

輸出內容應如下所示：

--- backend: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/networkEndpointGroups/k8s1-95c051f0-default-gb-frontend-svc-80-9b127192 status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/instances/gke-test-cluster-default-pool-7e74f027-47qp ipAddress: 10.8.0.6 port: 80 kind: compute#backendServiceGroupHealth 注意：這類健康狀態檢查隸屬於 Google Cloud 負載平衡器，與 Kubernetes API 提供的 liveness 和 readiness 探測不同，後者可用於判斷個別 pod 的健康狀態。Google Cloud 負載平衡器在執行健康狀態檢查時，會使用專案虛擬私有雲以外的特殊路徑，判斷後端作業成功或失敗。

一旦各執行個體的健康狀態回報為「健康狀態良好」，您就可以透過其外部 IP 存取應用程式。

7. 使用下列指令擷取狀態：

kubectl get ingress gb-frontend-ingress

8. 在瀏覽器視窗中輸入外部 IP，即可載入應用程式。

點選「Check my progress」，確認目標已達成。 透過 Ingress 使用容器原生負載平衡功能

工作 2：對應用程式進行負載測試

在為應用程式的 pod 選擇資源要求和限制，以及決定最佳的自動調度資源策略時，瞭解應用程式容量是很重要的步驟。

您已在本實驗室一開始就將應用程式部署為單一 pod。如果對在單一 pod 上執行的應用程式進行負載測試，且不設定自動調度資源策略，您就能瞭解應用程式可處理多少並行要求、需要多少 CPU 和記憶體，以及應用程式可能如何回應大量負載。

如要對 pod 進行負載測試，請使用 Locust，此為開放原始碼負載測試架構。

1. 在 Cloud Shell 中，為 Locust 下載 Docker 映像檔：

gsutil -m cp -r gs://spls/gsp769/locust-image .

提供的 locust-image 目錄中包含 Locust 設定檔。

2. 為 Locust 建構 Docker 映像檔，然後將其儲存在專案的 Container Registry：

gcloud builds submit \ --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/locust-tasks:latest locust-image

3. 確認 Docker 映像檔已位於專案的 Container Registry：

gcloud container images list

預期輸出內容：

Locust 包含一個主要機器與幾個工作站機器，用於產生負載。

4. 複製並套用資訊清單，為工作站的主要 Deployment 和 5 個備用資源 Deployment 建立單一 pod 的 Deployment：

gsutil cp gs://spls/gsp769/locust_deploy_v2.yaml . sed 's/${GOOGLE_CLOUD_PROJECT}/'$GOOGLE_CLOUD_PROJECT'/g' locust_deploy_v2.yaml | kubectl apply -f -

5. 如要存取 Locust UI，請擷取與其相對應的 LoadBalancer 服務的外部 IP 位址：

kubectl get service locust-main

如果外部 IP 的值為 <pending>，請稍後並重新執行上述指令，直到畫面顯示有效的值。

6. 在新的瀏覽器視窗中前往 [EXTERNAL_IP_ADDRESS]:8089，開啟 Locust 網頁：

點選「Check my progress」，確認目標已達成。 對應用程式進行負載測試

Locust 可讓您與多位使用者同時「群集處理」應用程式。您可以輸入以特定頻率產生的使用者數量，藉此模擬流量。

7. 舉例來說，如要表示一般負載，請輸入 200 做為要模擬的使用者數量，產生率則輸入 20。

8. 按一下「Start Swarming」。

幾秒後，「status」應該會顯示「Running」，使用者人數為 200 位，每秒要求數 (RPS) 則約 150 次。

9. 切換至 Cloud 控制台，然後依序點選「導覽選單」圖示 >「Kubernetes Engine」。

10. 在左側面板中選取「工作負載」。

11. 接著按一下您部署的 gb-frontend pod。

您會前往「Pod 詳細資料」頁面，您可以在其中查看 pod 的 CPU 和記憶體使用率圖表。請觀察「已使用」和「已要求」的值。

注意：如要查看圖表下方所列的指標值，請按一下圖表右上方的三點圖示，然後從下拉式選單中選取「展開圖表圖例」。

目前的負載測試是每秒約 150 次要求，您可以看到 CPU 使用率最低為 .04，最高則為 .06.。這表示單一 pod 的 CPU 要求為 40 到 60%。另一方面，記憶體使用率保持在約 80Mi，遠低於要求的 256Mi。此為每個 pod 的容量。在設定叢集自動配置器、資源要求和限制，以及選擇導入水平/垂直 Pod 自動配置器的方式和時機時，這項資訊就能派上用場。

在得出基準後，您也應該思考，若流量突然激增或達到尖峰，應用程式會如何因應。

12. 返回 Locust 瀏覽器視窗，然後按一下頁面頂端狀態下方的「Edit」。

13. 這次將要模擬的使用者人數輸入 900，產生率則輸入 300。

14. 按一下「Start Swarming」。

您的 pod 會在 2 到 3 秒內突然收到 700 個其他要求。在 RPS 值達到約 150，而狀態指出有 900 位使用者後，請返回「Pod 詳細資料」頁面，然後觀察圖表的變化。

記憶體的使用率不變，而 CPU 的峰值約為 .07，也就是 pod 的 CPU 要求百分比為 70%。如果這個應用程式是 Deployment，您或許可以安全地減少記憶體總要求數，並且設定依據 CPU 使用率觸發的水平自動配置器。

工作 3：readiness 和 liveness 探測

設定 liveness 探測

如果在 Kubernetes pod 或 Deployment 規格中設定 liveness 探測，它會繼續執行，偵測容器是否需要重新啟動，並且觸發重新啟動作業。這麼做可將處於死結狀態，但仍在繼續執行的應用程式自動重新啟動。舉例來說，只有所有容器傳送的 readiness 探測結果為成功，Kubernetes 代管的負載平衡器 (例如服務) 才會將流量傳送到 pod 後端。

1. 為了說明 liveness 探測，以下指令將為含有 liveness 探測的 pod 產生資訊清單，liveness 探測是以建立檔案時所執行的 cat 指令為基礎：

cat << EOF > liveness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: liveness-probe name: liveness-demo-pod spec: containers: - name: liveness-demo-pod image: centos args: - /bin/sh - -c - touch /tmp/alive; sleep infinity livenessProbe: exec: command: - cat - /tmp/alive initialDelaySeconds: 5 periodSeconds: 10 EOF

2. 將資訊清單套用至叢集，以便建立 pod：

kubectl apply -f liveness-demo.yaml

initialDelaySeconds 值代表的是在容器啟動後，要過多久才執行第一次探測。periodSeconds 值表示系統執行探測的頻率。

注意：Pod 也可以設為包含 startupProbe，用於指出容器中的應用程式是否啟動。如果指令中有 startupProbe，則在傳回 Success 狀態前，系統不會執行其他探測。若應用程式的啟動時間可能會變動，建議採用這種做法，以免 liveness 探測中斷。

基本上，在本示例中，liveness 探測會檢查容器中的檔案系統是否存在「/tmp/alive」檔案。

3. 如想驗證 pod 容器的健康狀態，可以檢查 pod 的事件：

kubectl describe pod liveness-demo-pod

在輸出內容底部的「Events」部分，應該會有 pod 最新的 5 個事件。這時，pod 的事件應該只會含有與建立和啟動 pod 相關的事件：

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 19s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 18s kubelet Pulling image "centos" Normal Pulled 18s kubelet Successfully pulled image "centos" Normal Created 18s kubelet Created container liveness-demo-pod Normal Started 18s kubelet Started container liveness-demo-pod

此事件記錄包含 liveness 探測的所有失敗結果，以及因此而觸發的重新啟動作業。

4. 手動刪除 liveness 探測所用的檔案：

kubectl exec liveness-demo-pod -- rm /tmp/alive

5. 檔案移除後，liveness 探測所用的 cat 指令應該會傳回非零結束代碼。

6. 再次檢查 pod 的事件：

kubectl describe pod liveness-demo-pod

liveness 探測失敗後，記錄中會新增事件，顯示一系列啟動步驟。開頭是 liveness 探測失敗 (Liveness probe failed: cat: /tmp/alive: No such file or directory)，結尾則是容器再次啟動 (Started container)：

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m21s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Warning Unhealthy 36s (x3 over 56s) kubelet Liveness probe failed: cat: /tmp/alive: No such file or directory Normal Killing 36s kubelet Container liveness-demo-pod failed liveness probe, will be restarted Normal Pulling 6s (x2 over 2m20s) kubelet Pulling image "centos" Normal Pulled 6s (x2 over 2m20s) kubelet Successfully pulled image "centos" Normal Created 6s (x2 over 2m20s) kubelet Created container liveness-demo-pod Normal Started 6s (x2 over 2m20s) kubelet Started container liveness-demo-pod 注意：在本實驗室中，用來探測 livenessProbe 的指令，取決於指定指令的結束代碼。除了指令探測之外，livenessProbe 也可以設為 HTTP 探測，根據 HTTP 回應來取得結果，或設為 TCP 探測，根據是否可在特定通訊埠上進行 TCP 連線來取得結果。

設定 readiness 探測

雖然 pod 可以成功啟動，且 liveness 探測結果顯示為健康狀態良好，pod 有可能還無法立即接收流量。如果將 Deployment 做為負載平衡器等服務的後端，則這是很常見的情形。readiness 探測是用於決定 pod 和其容器何時可以開始接收流量。

1. 為了方便說明，請建立資訊清單，用於建立單一 pod，做為測試網路伺服器及負載平衡器：

cat << EOF > readiness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe EOF

2. 將資訊清單套用至叢集，然後用它建立負載平衡器：

kubectl apply -f readiness-demo.yaml

3. 擷取指派給負載平衡器的外部 IP 位址。這項作業要先由上一個指令指派位址，因此可能需要一分鐘才能完成：

kubectl get service readiness-demo-svc

4. 在瀏覽器視窗中輸入 IP 位址，您會發現收到錯誤訊息，指出無法存取網站。

5. 檢查 pod 的事件：

kubectl describe pod readiness-demo-pod

輸出內容顯示 readiness 探測失敗：

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

與 liveness 探測不同，健康狀態不良的 readiness 探測不會使 pod 重新啟動。

6. 使用下列指令，產生 readiness 探測要檢查的檔案：

kubectl exec readiness-demo-pod -- touch /tmp/healthz

現在 pod 說明的「Conditions」部分中，「Ready」的值應該會顯示為「True」。

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

輸出內容：

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

7. 現在重新整理包含 readiness-demo-svc 外部 IP 的瀏覽器分頁。您應該會看到畫面上正常顯示「Welcome to nginx!」訊息。

為應用程式容器設定有意義的 readiness 探測，確保 pod 只會在準備就緒時接收流量。檢查應用程式仰賴的快取是否在啟動時載入，就是一種具有意義的 readiness 探測。

點選「Check my progress」，確認目標已達成。 readiness 與 liveness 探測

工作 4：Pod disruption budget

如想確保 GKE 應用程式的可靠性和運作時間，也可以使用 Pod disruption budget (pdp)。PodDisruptionBudget 為 Kubernetes 資源，可針對因自願中斷而可以同時執行的備用應用程式，限制其 pod 數量。

自願中斷包括各種管理動作，例如刪除 Deployment、更新 Deployment 的 pod 範本和執行滾動式更新、排除應用程式 pod 所在的節點，或是將 pod 移至不同節點。

首先，您必須將應用程式部署為 Deployment。

1. 刪除單一 pod 應用程式：

kubectl delete pod gb-frontend

2. 接著產生資訊清單來建立應用程式，做為 5 個備用資源的 Deployment：

cat << EOF > gb_frontend_deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: gb-frontend labels: run: gb-frontend spec: replicas: 5 selector: matchLabels: run: gb-frontend template: metadata: labels: run: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 128Mi ports: - containerPort: 80 protocol: TCP EOF

3. 將這個 Deployment 套用至叢集：

kubectl apply -f gb_frontend_deployment.yaml

點選「Check my progress」，確認目標已達成。 建立 Pod disruption budget

建立 PDB 前，您要排除叢集的節點，然後觀察若沒有 PDB，應用程式會有何種行為。

4. 如要排除節點，請循環執行 default-pool 的節點輸出內容，然後在每個節點上執行 kubectl drain 指令：

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --force --ignore-daemonsets --grace-period=10 "$node"; done

上述指令會從指定節點剔除並限制 pod，因此無法在指定節點上建立新 pod。如果可用資源允許，系統會在不同節點上重新部署 pod。

5. 如果節點遭到排除，請檢查 gb-frontend Deployment 的備用資源數量：

kubectl describe deployment gb-frontend | grep ^Replicas

輸出內容可能如下所示：

Replicas: 5 desired | 5 updated | 5 total | 0 available | 5 unavailable

如上述的輸出內容所示，排除節點後，Deployment 可用的備用資源最少為 0。如果沒有可用的 pod，應用程式的效能會顯著下降。讓我們再次嘗試排除節點，但這次要為應用程式使用 Pod disruption budget。

6. 首先取消對節點的限制，恢復遭排除的節點。以下指令可重新在節點上安排 pod：

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl uncordon "$node"; done

7. 再次檢查 Deployment 狀態：

kubectl describe deployment gb-frontend | grep ^Replicas

輸出內容應類似以下結果，包含所有 5 個可用的備用資源：

Replicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailable

8. 建立 Pod disruption budget，宣告可用 pod 的數量下限為 4。

kubectl create poddisruptionbudget gb-pdb --selector run=gb-frontend --min-available 4

9. 再次排除叢集的其中一個節點，然後觀察輸出內容：

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --timeout=30s --ignore-daemonsets --grace-period=10 "$node"; done

成功剔除應用程式的其中一個 pod 後，系統會循環執行下列指令：

evicting pod default/gb-frontend-597d4d746c-fxsdg evicting pod default/gb-frontend-597d4d746c-tcrf2 evicting pod default/gb-frontend-597d4d746c-kwvmv evicting pod default/gb-frontend-597d4d746c-6jdx5 error when evicting pod "gb-frontend-597d4d746c-fxsdg" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-tcrf2" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-6jdx5" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-kwvmv" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

10. 按下 CTRL+C 以結束指令。

11. 再次確認 Deployment 狀態：

kubectl describe deployment gb-frontend | grep ^Replicas

現在輸出內容應如下所示：

Replicas: 5 desired | 5 updated | 5 total | 4 available | 1 unavailable

在 Kubernetes 能在不同節點上部署第 5 個 pod，藉此剔除下一個 pod 之前，其餘的 pod 依然可用，以便符合 PDB 要求。在本示例中，Pod disruption budget 設定指定的是可用數量下限，但您也可以透過 PDB 設定來定義無法使用數量的上限。每個值皆能以整數表示，代表 pod 數量或 pod 總數的百分比。

恭喜！

您已瞭解如何透過 Ingress 建立容器原生負載平衡器，更有效率地善用負載平衡和轉送功能。您對 GKE 應用程式執行了簡易負載測試，並且觀察應用程式的基準 CPU 和記憶體使用率，以及應用程式如何因應流量高峰。此外，您也設定了 liveness 探測、readiness 探測和 Pod disruption budget，確保應用程式的可用性。將這些工具與技術搭配使用，能夠盡量減少多餘的網路流量、定義有意義的應用程式良好行為指標，並且強化應用程式的可用性，進而提升應用程式在 GKE 上執行的整體效率。

後續行動/瞭解詳情

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

• 在 GKE 上執行最具成本效益的 Kubernetes 應用程式的最佳做法：準備雲端式 Kubernetes 應用程式

Google Cloud 教育訓練與認證

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

使用手冊上次更新日期：2024 年 3 月 12 日

實驗室上次測試日期：2024 年 3 月 12 日

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