arrow_back

探索如何讓 GKE 虛擬機器發揮最佳成本效益

登录 加入
欢迎加入我们的社区,一起测试和分享您的知识!
done
学习 700 多个动手实验和课程并获得相关技能徽章

探索如何讓 GKE 虛擬機器發揮最佳成本效益

实验 1 小时 30 分钟 universal_currency_alt 5 积分 show_chart 中级
info 此实验可能会提供 AI 工具来支持您学习。
欢迎加入我们的社区,一起测试和分享您的知识!
done
学习 700 多个动手实验和课程并获得相关技能徽章

GSP767

Google Cloud 自修研究室標誌

總覽

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、N2、N2D 和 N1 機型與其規格,例如記憶體和 vCPU。

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

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

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

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

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

檢視 Hello 示範叢集的需求

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

  1. 實驗室佈建完畢後,請在 Cloud 控制台中依序點選「導覽選單」和「Kubernetes Engine」
  1. 在「Kubernetes 叢集」視窗中選取 hello-demo-cluster

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

「節點」分頁標籤在 hello-demo-cluster 中醒目顯示。

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

列出節點與規格的清單,規格包括狀態、CPU 要求和命名空間。

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

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

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

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

「Pod」部分列出一些 Pod,狀態是「執行中」。

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

如您所見,執行一項 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」圖示 「啟動 Cloud Shell」圖示

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

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

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

  1. (選用) 您可以執行下列指令來列出使用中的帳戶:
gcloud auth list
  1. 點按「授權」

  2. 輸出畫面應如下所示:

輸出內容:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (選用) 您可以使用下列指令來列出專案 ID:
gcloud config list project

輸出內容:

[core] project = <project_ID>

輸出內容範例:

[core] project = qwiklabs-gcp-44776a13dea667a6 附註:如需有關 gcloud 的完整說明,請前往 Google Cloud 並參閱「gcloud CLI overview guide」(gcloud CLI 總覽指南)。

向上擴充 Hello 應用程式

  1. 存取您的叢集憑證:
gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}
  1. 向上擴充 Hello-Server
kubectl scale deployment hello-server --replicas=2

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

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

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

注意:在實驗室中,您可能不會看到此錯誤。根據叢集的 Kubernetes 版本不同,kube-system Pod 可能提出較少的資源要求,使得叢集能容納新的工作負載。如未看見此錯誤,別擔心,這不影響完成實驗室。
  1. 按一下錯誤訊息即可查看狀態詳細資料。您會看見錯誤原因是 Insufficient cpu

這在預期之內。如前所述,叢集中幾乎沒有多餘的 CPU 資源,所以您已要求增加另一項 hello-server 備用資源,並額外增加 400m。

  1. 增加節點集區來應對新的要求:
gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}
  1. 系統提示您繼續操作時,請輸入 y 並按下 Enter 鍵。

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

「工作負載」頁面顯示 hello-server 處於「正常」狀態

檢查您的叢集

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

  1. 按一下 hello-demo-cluster

「節點」分頁標出 hello-demo-cluser

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

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

較大的節點集區,列出多個節點與相關資訊,例如狀態和儲存空間要求。

雖然 GKE 會盡量充分利用叢集資源,但仍有改進空間。如您所見,其中一個節點使用了大部分的記憶體,但另外兩個節點還有大量未使用的記憶體。

這時若繼續向上擴充應用程式,就會開始看到類似情況。Kubernetes 會嘗試尋找節點來處理每項新的 hello-server Deployment 備用資源,如果找不到可用節點,則會建立 CPU 大約 600m 的新節點。

裝箱問題

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

最佳化執行應用程式的 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-local-data --grace-period=10 "$node"; done

這時,應該會看到 Pod 在名為 larger-pool 的新節點集區中運作:

kubectl get pods -o=wide
  1. 遷移 Pod 後,即可放心刪除舊的節點集區:
gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}
  1. 系統提示您繼續操作時,請輸入 yenter

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

費用分析

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

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

Standard: 標準 e2 機型清單,包括規格 (虛擬 CPU 數量、記憶體) 與價格。

Shared Core: 標準 e2 機型清單,包括規格 (vCPU 數量、記憶體) 與價格。

三部 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 的流量,以便監控。

  1. 執行以下指令,建立第一個 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
  1. 使用以下指令,在 Kubernetes 中建立第一個 Pod:
kubectl apply -f pod-1.yaml
  1. 接著執行以下指令,建立第二個 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
  1. 在 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-1security: demo 標籤為基礎的運算式。「Pod 相依性」規則可確保 Pod 「安排至同一節點」,「Pod 反相依性」規則可確保 Pod「不會安排至同一節點」

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

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

  1. 查看您建立的 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
  1. 在殼層中傳送要求至 pod-2,並將 [POD-2-IP] 替換成 pod-2 的內部 IP 位址:
ping [POD-2-IP]

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

檢查流量記錄

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

  1. Cloud 控制台中開啟「導覽選單」,選取「網路」部分中的「虛擬私有雲網路」
  1. 區域中找到並點選 default 子網路。

圖中標出 us-central1 的預設子網路

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

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

  3. 點選「儲存」

  4. 接著點選「在記錄檔探索工具查看流量記錄」

醒目顯示「流量記錄」選單中的「查看流量記錄」選項。

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

清單中列出記錄,以及相應的摘要、時間戳記和嚴重性。

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

這可能不太容易辨識。接著,請匯出成 BigQuery 資料表,以便查詢相關資訊。

  1. 依序點選「更多動作」>「建立接收器」

「更多動作」下拉式選單中的兩個選項:「建立接收器」和「管理快訊」。

  1. 將接收器命名為 FlowLogsSample

  2. 點選「下一步」

接收器目的地位置

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

其他設定可以保持不變。

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

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

  1. 點選「完成」

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

  3. us_flow_logs 資料集底下,點選 compute_googleapis_com_vpc_flows_xxx 資料表。

「Explorer」窗格,包含搜尋框、已固定的專案,以及位於 us_central_flow_logs 資料集下的資料表。

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

  2. 在「BigQuery 編輯器」中,將以下內容貼到 SELECTFROM 之間:

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
  1. 按一下「執行」

「BigQuery 編輯器」顯示查詢結果,介面上包含「儲存」、「更多」和「排程」選項。

先前的流量記錄將根據 source zonesource vmdestination zonedestination vm 篩選列出。

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

regional-demo 叢集中的兩個資料列:us-central1-a 和 us-central1-c。

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

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

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

移動高流量的 Pod,有效降低跨可用區傳輸流量的成本

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

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

exit
  1. 執行以下指令以編輯 pod-2 資訊清單:
sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

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

  1. 刪除目前執行的 pod-2
kubectl delete pod pod-2
  1. pod-2 刪除後,使用新編輯的資訊清單重新建立此 Pod:
kubectl create -f pod-2.yaml

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

  1. 查看已建立的 Pod,確認狀態皆為 Running
kubectl get pod pod-1 pod-2 --output wide

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

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

  1. 取得 pod-1 容器的殼層:
kubectl exec -it pod-1 -- sh
  1. 在殼層中傳送要求至 pod-2,並將 [POD-2-IP] 替換成先前指令中 pod-2 的內部 IP。
ping [POD-2-IP]

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

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

費用分析

請參考 Google Cloud 內部 VM 之間的資料移轉定價

列出三種 Google Cloud 流量與相應費用,費用介於每 GB $0 美元至 $0.01 美元。

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

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

恭喜!

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

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

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

後續行動/瞭解詳情

Google Cloud 教育訓練與認證

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

使用手冊上次更新日期:2024 年 4 月 30 日

實驗室上次測試日期:2024 年 4 月 30 日

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

此内容目前不可用

一旦可用,我们会通过电子邮件告知您

太好了!

一旦可用,我们会通过电子邮件告知您