GSP767

總覽

Google Kubernetes Engine 叢集的底層基礎架構是由多個節點 (即 Compute VM 執行個體) 組成。本實驗室將說明如何調整叢集基礎架構，以便獲得最佳成本效益，達到節省成本的效果，應用程式的架構也會更有效率。

您將瞭解如何為範例工作負載選擇適當的機型，充分利用寶貴的基礎架構資源，避免資源使用率過低。除了類型之外，基礎架構的實際地理位置也會影響成本。透過這項練習，您將探索如何制定符合成本效益的高可用性區域叢集管理策略。

目標

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

• 檢視 Deployment 的資源使用情形
• 擴充 Deployment
• 將工作負載遷移至使用最佳機型的節點集區
• 瞭解叢集位置選擇
• 監控不同可用區之間 Pod 的流量記錄
• 移動高流量 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 產品和服務，請點選「導覽選單」，或在「搜尋」欄位輸入服務或產品名稱。

本實驗室會為您產生一個小型叢集，佈建時間大約 2 至 5 分鐘。

如果按下「Start Lab」按鈕後看見藍色的 resources being provisioned 訊息和載入圈圈，代表您的叢集仍在建立中。

在等待期間，您可以閱讀後續的指示和說明，但是在資源佈建完成之前，您將無法執行任何殼層指令。

工作 1：瞭解節點機型

一般總覽

機型是虛擬機器 (VM) 執行個體可以使用的一組虛擬化硬體資源，包括特定大小的系統記憶體、既定數量的虛擬 CPU (vCPU)，以及設有上限的永久磁碟容量。機型可依工作負載分為不同系列。

選擇節點集區的機型時，一般用途機型系列通常可針對多種各種工作負載，提供最佳性價比。一般用途機型包含 N 系列和 E2 系列：

機型之間的差異不一定對應用程式有助益。一般而言，E2 和 N1 系列的效能類似，但前者可在成本上提供最佳效益。通常單獨使用 E2 機型比較能節省成本。

不過使用叢集時，最重要的是根據應用程式的需求充分利用資源。大型應用程式或部署項目因為需要大量調度資源，所以將工作負載堆疊在少數最佳化機器上，會比分散在很多一般用途的機器上更經濟實惠。

您在做出這項決定時，一定要對應用程式有充分瞭解，因為這樣才能確保機型符合應用程式需求。

在下一個部分中，您將查看示範應用程式，並將其遷移至配置合適機型的節點集區。

工作 2：選擇適合 Hello 應用程式的機型

瞭解 Hello 示範叢集的需求

啟動時，實驗室已產生 Hello 示範叢集，其中包含兩個 E2 中型節點 (2 個 vCPU，4 GB 記憶體)。這個叢集將部署簡易網頁應用程式 Hello App 的一個副本。此應用程式是用 Go 編寫的網路伺服器，會對所有要求回應「Hello, World!」訊息。

1. 實驗室佈建完畢後，請在 Cloud 控制台中依序點選「導覽選單」和「Kubernetes Engine」。

2. 在「Kubernetes 叢集」視窗中選取 hello-demo-cluster。

3. 在後續視窗中選取「節點」分頁標籤：

您應會看到自己的叢集節點清單。

請觀察 GKE 如何利用您的叢集資源。您可以查看每個節點要求了多少 CPU 和記憶體，以及可分配給節點的資源量。

4. 按一下叢集的第一個節點。

請查看「Pod」部分。您應該會在 default 命名空間中看到 hello-server Pod。如果找不到 hello-server Pod，請返回「節點」分頁，並選取叢集的第二個節點。

您會發現 hello-server Pod 要求了 400 mCPU，另外還有一些 kube-system Pod 正在運作。載入這些 Pod 是為了是協助執行 GKE 的叢集服務，例如監控。

5. 按下「返回」按鈕，回到原先的「節點」頁面。

如您所見，執行一項 Hello-App 副本和基本的 kube-system 服務時，需要兩個 E2-medium 節點。此外，儘管您已使用叢集中大部分的 CPU 資源，卻僅使用大約三分之一的記憶體配額。

如果這個應用程式的工作負載固定不變，您就能精確知道需要多少 CPU 和記憶體，建立完全符合這些需求的自訂機型，整個叢集基礎架構都能節省費用。

不過，GKE 叢集通常會執行多個工作負載，這些工作負載一般需要配合需求擴充或縮減。

如果擴充 Hello 應用程式，會發生什麼情況？

啟動 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 總覽指南。

擴充 Hello 應用程式

1. 存取叢集憑證：

gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

2. 擴充 Hello-Server：

kubectl scale deployment hello-server --replicas=2

點選「Check my progress」，確認上述工作已完成。 擴充 Hello 應用程式

3. 返回控制台，從左側的「Kubernetes Engine」選單中選取「工作負載」。

您應會看到 hello-server 顯示「Does not have minimum availability」錯誤狀態。

注意：在實驗室中，您可能不會看到此錯誤。視叢集的 Kubernetes 版本為何，kube-system Pod 可能提出較少的資源要求，且叢集或許能容納新的工作負載。如未看見此錯誤，別擔心，您仍可完成實驗室。

4. 按一下錯誤訊息即可查看狀態詳細資料。您會看見錯誤原因是 Insufficient cpu。

這在預期之內。如前所述，叢集中幾乎沒有多餘的 CPU 資源，您另外增加的 hello-server 副本需要額外的 400 mCPU。

5. 增加集區中的節點，以便因應新要求的副本：

gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}

6. 系統詢問是否要繼續時，請輸入 y 並按下 Enter 鍵。

7. 在控制台中重新整理「工作負載」頁面，直到 hello-server 工作負載的狀態變成「正常」：

檢查您的叢集

成功擴充工作負載後，請返回叢集的「節點」分頁。

1. 按一下「hello-demo-cluster」：

2. 接著點選「節點」分頁標籤。

節點集區越大，能處理的工作負載越重，但請注意基礎架構資源的使用情形。

GKE 會盡量充分利用叢集資源，不過在這個範例中，資源的使用情形仍有改進空間。您可看到其中一個節點使用了大部分的記憶體，但另外兩個節點還有大量未使用的記憶體。

這時若繼續擴充應用程式，就會開始看到類似的模式：每次部署新 hello-server 副本時，Kubernetes 會嘗試尋找節點來因應新副本的需求，但找不到可用節點，然後建立有大約 600 mCPU 的新節點。

裝箱問題

所謂裝箱問題，是指將一些體積或形狀不同的物品，裝入一定數量、有規則形狀的「箱子」或容器中。解題目標是以最有效率的方式，將這些物品「裝箱」至最少數量的箱子中。

如果要調整 Kubernetes 叢集，以最經濟實惠的方式執行應用程式，實際上就是在解決類似的問題。假設您有多個應用程式，各有不同的資源需求 (例如記憶體和 CPU)，您要盡可能讓這些應用程式有效利用 Kubernetes 管理的基礎架構資源 (可能占叢集成本的大部分)。

您的 Hello 示範叢集未採用高效率的裝箱方式。若能在 Kubernetes 中配置更適合這個工作負載的機型，會更經濟實惠。

注意：為簡單起見，本實驗室僅針對單一應用程式進行最佳化調整。但實際上，您的 Kubernetes 叢集可能會執行很多需求不同的應用程式。Kubernetes 有各種便利工具，幫助您篩選 Kubernetes 可存取的各種機器，找到最適合應用程式工作負載的選擇。您可以使用多個 GKE 節點集區，利用單一 Kubernetes 叢集管理多種機型。

遷移至最佳化節點集區

• 使用更大的機型建立新的節點集區：

gcloud container node-pools create larger-pool \ --cluster=hello-demo-cluster \ --machine-type=e2-standard-2 \ --num-nodes=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

點選「Check my progress」，確認上述工作已完成。 建立節點集區

現在，您可以依照下列步驟將 Pod 遷移至新的節點集區：

1. 隔離現有節點集區：將現有節點集區 (node) 中的節點標示為「無法排程」。這樣一來，Kubernetes 就會停止將新 Pod 安排至這些節點。
2. 清空現有節點集區：按程序清空在現有節點集區 (node) 的節點上執行的工作負載。

• 首先，隔離原始節點集區：

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

• 接著清空集區：

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

這時，應該會看到 Pod 在新節點集區 larger-pool 運作：

kubectl get pods -o=wide

3. 遷移 Pod 後，即可放心刪除舊的節點集區：

gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

4. 系統詢問是否要繼續時，請輸入 y 並按下 Enter 鍵。

刪除作業大約需要 2 分鐘。等待時，您可以先閱讀下一部分。

費用分析

您已將原本需要三部 e2-medium 機器處理的工作負載，改成用一部 e2-standard-2 機器處理。

我們來看看使用 e2 標準和共用核心機型的每小時費用：

標準：

共用核心：

三部 e2-medium 機器每小時的費用約 $0.1 美元，一部 e2-standard-2 機器每小時的費用約 $0.067 美元。

每小時省下 $.04 美元看似微不足道，但在應用程式的整個生命週期中，這筆成本可能持續增加，逐漸累積成可觀費用。如果使用更多資源，差異將更為明顯。由於 e2-standard-2 機器較符合工作負載的資源需求，而且空間利用率更高，因此擴充成本增長速度較慢。

有趣的是，E2-medium 這種共用核心機型，是為不需要大量資源的小型應用程式設計，在這類應用程式上具經濟效益。然而，對於 Hello-App 目前的工作負載來說，使用機型較大的節點集區卻是更符合成本效益的策略。

在 Cloud 控制台中，您應該仍在 hello-demo 叢集的「節點」分頁上。請重新整理此分頁，檢視 larger-pool 節點的「已要求的 CPU」和「可分配的 CPU」欄位。

您會發現還有改進空間。新節點可以容納工作負載的另一項副本，不必佈建其他節點。另外，您或許能根據應用程式需要的 CPU 和記憶體，選擇適合的自訂大小機型，進一步節省資源。

值得注意的是，這些價格將視您的叢集位置而異。在下一部分中，您將瞭解如何選擇最佳區域與管理區域叢集。

選擇合適的叢集位置

區域和可用區總覽

您的叢集節點使用的 Compute Engine 資源託管於全球多個據點，這些據點是由眾多區域和可用區構成。區域是您可以託管資源的特定地理位置，具有三個以上的可用區。

可用區中的資源，比如虛擬機器執行個體或可用區永久磁碟，都稱為可用區資源。靜態外部 IP 位址等其他資源，則為區域性資源。區域性資源可供所屬區域內的任何資源使用，不受可用區限制；可用區資源則只能由所屬可用區內的其他資源使用。

選擇區域或可用區時，請務必考慮下列事項：

1. 應對故障情形 - 如果應用程式資源僅分配至單一可用區，該可用區無法使用時，應用程式也無法使用。若應用程式規模較大並具高需求，通常最佳做法是將資源分配至多個可用區或區域，以便應對故障情形。
2. 降低網路延遲時間 - 為降低網路延遲時間，建議選擇離您提供服務之處較近的區域或可用區。比如，若是您的顧客大部分位於美國東岸，挑選主要區域和可用區時，可選擇距離較近的地方。

叢集最佳做法

區域成本差異取決於多種因素。比如，us-west2 區域的資源通常比 us-central1 的資源昂貴。

選擇叢集的區域或可用區時，請考慮應用程式的實際運作情形。對於易受到延遲影響的正式環境，通常性價比最高的做法是將應用程式置於網路延遲時間較短、效率較高的區域/可用區。

另一方面，對於不太受延遲影響的開發環境，則可選擇成本較低的區域。

注意：如需 VM 和區域定價的詳細資訊，請參閱 VM 執行個體定價文件。

考量叢集可用性

GKE 提供可用區叢集 (單一可用區或多可用區) 和區域叢集。從表面上看，單一可用區叢集是最便宜的選擇，但為了確保應用程式具備高可用性，最好將叢集的基礎架構資源分配至多個可用區。

很多情況下，採用多可用區叢集或區域叢集，優先確保可用性，這樣架構的性價比最佳。

注意：多可用區叢集至少會定義一個額外可用區，但在單一可用區中，只會執行一項控制層副本。當控制層可用區的服務中斷時，工作負載仍能執行，但除非控制層恢復可用，否則無法對叢集做出任何設定。

區域叢集具有多個控制層副本，分別在指定區域的多個可用區中執行。節點也會在控制層副本所在的每個可用區運作。區域叢集消耗的資源最多，但能提供最佳可用性。

詳情請參閱介紹叢集類型的文章。

工作 3：管理區域叢集

設定

跨可用區管理叢集資源會稍微複雜一些。一不小心，就可能因為 Pod 之間出現不必要的跨可用區通訊，累積額外成本。

在這個部分，您將觀察叢集的網路流量，並將兩個互相帶來大量流量的高流量 Pod 移至同一可用區。

1. 在「Cloud Shell」分頁建立新的區域叢集 (完成這項指令需要幾分鐘的時間)：

gcloud container clusters create regional-demo --region={{{project_0.default_region | "REGION"}}} --num-nodes=1

為了在 Pod 和節點之間產生流量，您將在區域叢集中的兩個節點上分別建立一個 Pod。我們將使用 ping 從其中一個 Pod 產生流量到另一個 Pod，並加以監控。

2. 執行以下指令，建立第一個 Pod 的資訊清單：

cat << EOF > pod-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: security: demo spec: containers: - name: container-1 image: wbitt/network-multitool EOF

3. 使用以下指令，在 Kubernetes 中建立第一個 Pod：

kubectl apply -f pod-1.yaml

4. 接著執行以下指令，建立第二個 Pod 的資訊清單：

cat << EOF > pod-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-2 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - demo topologyKey: "kubernetes.io/hostname" containers: - name: container-2 image: gcr.io/google-samples/node-hello:1.0 EOF

5. 在 Kubernetes 中建立第二個 Pod：

kubectl apply -f pod-2.yaml

點選「Check my progress」，確認上述工作已完成。 確認 Pod 建立完畢

您建立的 Pod 會使用 node-hello 容器，並在收到要求時輸出 Hello Kubernetes 訊息。

如果回顧您建立的 pod-2.yaml 檔案，就會看到「Pod 反相依性」定義規則。這可以確保此 Pod「不會」安排至與 pod-1 相同的節點上，因為規則會比對以 pod-1 的 security: demo 標籤為基礎的運算式。「Pod 相依性」規則可確保 Pod「安排至同一節點」，「Pod 反相依性」規則可確保 Pod「不會安排至同一節點」。

注意：Kubernetes 還具有節點相依性的概念，可協助讓應用程式在最合適的機型上運作。

這裡使用「Pod 反相依性」規則是為了呈現節點之間的流量，而您可以藉由靈活運用「Pod 反相依性」和「Pod 相依性」，更有效利用區域叢集資源。

6. 查看您建立的 Pod：

kubectl get pod pod-1 pod-2 --output wide

您會看到這些傳回的 Pod 都顯示 Running 狀態和各自的內部 IP。

輸出範例： NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-1 1/1 Running 0 4m40s 10.60.0.7 gke-regional-demo-default-pool-abb297f1-tz3b pod-2 1/1 Running 0 4m31s 10.60.2.3 gke-regional-demo-default-pool-28b6c708-qn7q

請記下 pod-2 的 IP 位址，以備在後續指令中使用。

模擬流量

1. 取得 pod-1 容器的殼層：

kubectl exec -it pod-1 -- sh

2. 在殼層傳送要求至 pod-2，並將以下指令中的 [POD-2-IP] 替換成 pod-2 的內部 IP 位址：

ping [POD-2-IP]

請注意 pod-1 對 pod-2 執行連線偵測 (ping) 的平均延遲時間。

檢查流量記錄

從 pod-1 對 pod-2 執行連線偵測 (ping) 時，您可以在建立叢集的虛擬私有雲子網路上啟用流量記錄功能，以便觀察流量。

1. 在 Cloud 控制台開啟「導覽選單」，選取「網路」部分中的「虛擬私有雲網路」。

2. 點選「預設」網路。在「子網路」分頁的「」區域，找到並點選 default 子網路。

3. 按一下畫面頂端的「編輯」。

4. 將「流量記錄」設為「開啟」。

5. 點選「儲存」。

6. 接著點選「在 Logs Explorer 查看流量記錄」。

您將看到一份記錄清單，列出您的任何執行個體每次收發內容時產生的大量資訊。

如未產生記錄，請將 vpc_flows 前面的 / 替換成 %2F，如上方螢幕截圖所示。

這些記錄可能不太好讀。接著，請匯出成 BigQuery 資料表，以便查詢相關資訊。

7. 依序點選「動作」>「建立接收器」。

8. 將接收器命名為 FlowLogsSample。

9. 點選「下一步」。

接收器目的地位置

• 將「接收器服務」設為「BigQuery 資料集」。
• 針對「BigQuery 資料集」，選取「建立新的 BigQuery 資料集」。
• 將資料集命名為「us_flow_logs」，按一下「建立資料集」。

其他設定可以保持不變。

1. 按一下「建立接收器」。

2. 接著檢查新建立的資料集。在 Cloud 控制台中點選「導覽選單」，然後在「數據分析」部分點選「BigQuery」。

3. 點選「完成」。

4. 選取您的專案名稱，接著選取「us_flow_logs」即可查看新建立的資料表。如果看不到任何資料表，可能需要重新整理幾次。

5. 在 us_flow_logs 資料集底下，點選 compute_googleapis_com_vpc_flows_xxx 資料表。

6. 依序點選「查詢」>「在新分頁中開啟」。

7. 在「BigQuery 編輯器」中，將以下內容貼到 SELECT 和 FROM 之間：

jsonPayload.src_instance.zone AS src_zone, jsonPayload.src_instance.vm_name AS src_vm, jsonPayload.dest_instance.zone AS dest_zone, jsonPayload.dest_instance.vm_name

8. 按一下「執行」。

先前的流量記錄將根據 source zone、source vm、destination zone 和 destination vm 篩選列出。

找出顯示 regional-demo 叢集中的兩個可用區之間呼叫的資料列。

注意：實際記錄中的數字可能與示意圖中不同。

觀察流量記錄時，可以看到不同可用區之間經常有流量轉移。

接下來，您要將 Pod 移至同一可用區，觀察這有什麼好處。

移動高流量 Pod，盡量降低跨可用區流量費用

1. 返回「Cloud Shell」，按下 Ctrl + C 鍵取消 ping 指令。

2. 輸入 exit 指令退出 pod-1 的殼層：

exit

3. 執行以下指令，編輯 pod-2 的資訊清單：

sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

這會將 Pod Anti Affinity 規則改成 Pod Affinity 規則，但保留相同邏輯。也就是說，pod-2 將被安排在 pod-1 所用的節點上。

4. 刪除目前執行的 pod-2：

kubectl delete pod pod-2

5. pod-2 刪除後，使用新編輯的資訊清單重新建立此 Pod：

kubectl create -f pod-2.yaml

點選「Check my progress」，確認上述工作已完成。 模擬流量

6. 查看已建立的 Pod，確認狀態皆為 Running：

kubectl get pod pod-1 pod-2 --output wide

在輸出內容中，可以看到 Pod-1 和 Pod-2 在同一節點上執行。

請記下 pod-2 的 IP 位址，以備在後續指令中使用。

7. 取得 pod-1 容器的殼層：

kubectl exec -it pod-1 -- sh

8. 在殼層傳送要求至 pod-2，並將以下指令的 [POD-2-IP] 替換成先前指令中 pod-2 的內部 IP。

ping [POD-2-IP]

您會注意到，這些 Pod 之間的平均連線偵測 (ping) 時間比之前更短。

這時，您可以返回流量記錄的 BigQuery 資料集，檢查最近的記錄是否已經沒有不必要的跨可用區通訊。

費用分析

我們來看看 Google Cloud 內部 VM 之間的 egress 流量定價：

當不同可用區的 Pod 互相連線偵測 (ping) 時，每 GB 費用為 $0.01 美元。這筆費用看似微小，但是在多個服務經常跨可用區通訊的大規模叢集中，這些成本會迅速累積。

當您將 Pod 移至相同可用區後，執行連線偵測 (ping) 就不會再產生費用。

恭喜！

您已瞭解如何讓屬於 GKE 叢集的虛擬機器發揮最佳成本效益：首先是將工作負載遷移至配置合適機型的節點集區，接著是瞭解不同區域的優缺點，最後則是將區域叢集中的高流量 Pod 與相互通訊的 Pod 放在同一可用區。

在本實驗室中，我們已經介紹運用哪些工具和策略來配置 GKE 虛擬機器會更符合成本效益。不過，您仍需瞭解自己的應用程式與相關需求，才能選擇最合適的虛擬機器。只要知道您將執行的工作負載類型，並估算應用程式的需求，即可在決定 GKE 叢集虛擬機器的位置與機型時，做出最經濟實惠的選擇。

有效利用叢集的基礎架構將大大有助於實現最佳成本效益。

後續行動/瞭解詳情

• 機型文件
• 最佳做法 - 在 GKE 執行最具成本效益的 Kubernetes 應用程式：選擇合適機型
• 最佳做法 - 在 GKE 執行最具成本效益的 Kubernetes 應用程式：選取合適區域

Google Cloud 教育訓練與認證

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

使用手冊上次更新日期：2025 年 5 月 14 日

實驗室上次測試日期：2025 年 5 月 14 日

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