多叢集網路是實用的工具，可支援區域高可用性、全球分散式鄰近使用者以降低延遲，以及團隊間的組織隔離等用途。Google Kubernetes Engine (GKE) 提供多叢集網路的內建功能，您可以在 GKE 叢集機群中啟用及大規模使用這些功能。這項功能還可讓您在 GKE Standard 和 Autopilot 之間合併或遷移已部署的基礎架構，滿足各個應用程式的架構需求。
如果是 GKE Autopilot 叢集，Google 會管理基礎架構，包括控制層和節點。如要自行設定及管理節點，GKE 提供標準模式。如要進一步瞭解模式之間的差異，請參閱「選擇叢集作業模式」。
本頁面會透過幾種部署拓撲，展示這些功能。 您將瞭解如何將部署在單一 GKE 叢集中的應用程式，遷移至 GKE Standard 和 Autopilot 叢集的多叢集部署作業。您可以使用 GKE 多叢集服務處理東西向流量，並使用多叢集閘道啟用多叢集南北向網路。
本頁面適用於使用或計畫使用 GKE，在多個 Kubernetes 叢集部署服務的雲端架構師和營運團隊。閱讀本頁內容前，請務必先熟悉 Kubernetes。
多叢集 Service 和多叢集閘道
Kubernetes 可在不同的雲端可用區中使用單一控制層，為服務提供彈性和更高的可用性。GKE 更進一步，提供 GKE 多叢集服務 (MCS)，可跨叢集探索及叫用服務。使用這項功能的服務可透過虛擬 IP 在叢集間探索及存取，與叢集中可存取的 ClusterIP 服務行為相符。這種做法有以下優點：
- 服務可以在同一區域或不同區域的多個叢集之間進行負載平衡 (東西向流量)。
- 可實現跨區域服務高可用性選項。
- 您可以在不同叢集部署及管理有狀態和無狀態工作負載。
- 共用服務可跨叢集使用。
如要進一步瞭解如何部署 MCS，請參閱「設定多叢集服務」。
GKE 提供 Kubernetes Gateway API 的實作項目，使用 GKE Gateway 控制器。GKE 可透過 Gateway 部署 Google Cloud 負載平衡器，為 GKE 上部署的服務 提供輸入 (南北向) 流量路徑。 GKE 也提供多叢集閘道 (MCG)，可擴充 GKE 閘道控制器，以佈建負載平衡器，將流量路由至部署在不同 GKE 叢集的服務。
下圖顯示結合 MCS 和 MCG 後，您如何從單一控制層管理服務部署和流量路徑的互補層面：
詳情請參閱「部署多叢集閘道」。
遷移作業總覽
GKE 多叢集網路功能可為各種設定檔的工作負載帶來好處。舉例來說，您可能有一些無狀態元件，流量會突然暴增，因此想改用 Autopilot，因為 Autopilot 的成本模式更有效率。
或者，您可能想將應用程式前端放在更靠近使用者的位置。這種做法可縮短延遲時間並提供快取，進而提升應用程式效能和使用者體驗。同時，應用程式可能依賴某些有狀態元件，而這些元件只能位於一個位置。這項設定需要南北向多叢集負載平衡，才能將用戶端流量傳送至該位置的正確叢集。您也需要東西向多叢集負載平衡，才能在叢集之間傳送流量，以連線至具狀態的元件。
本頁面使用 Online Boutique 雲端微服務示範應用程式，示範可用於強化單一可用區示範部署作業的多叢集模式。您會先從應用程式的單一區域版本著手。接著，您可以使用多叢集服務和多叢集閘道，新增高可用性和彈性元素，並利用 Autopilot 減少營運負擔。
初始單一叢集部署作業
在下圖中，Online Boutique 應用程式一開始是部署到名為 std-west 的單一 GKE Standard 模式叢集，並透過 LoadBalancer 服務公開：
遷移至多叢集服務
在下一個中繼步驟中，您會建立兩個額外叢集，並在其他區域部署無狀態服務。您會在兩個不同的區域中建立兩個 GKE Autopilot 叢集，分別命名為 auto-east 和 auto-central，與單一 std-west GKE Standard 叢集不同，並將叢集註冊至Google Cloud 機群。
「機群」是一個按照邏輯整理叢集和其他資源的 Google Cloud 概念，可讓您使用及管理多叢集功能，並在不同系統中套用一致的政策。
您可以使用 ServiceExport，將 onlineboutique 命名空間中 std-west 叢集上的 cartservice 匯出至新的機群叢集。您在三個叢集上部署 Online Boutique 的 frontend Service，並透過 ClusterIP Service 公開。接著，您可以使用 ServiceExports 將服務匯出至機群。Online Boutique 的中介軟體層服務 (例如 productcatalog、shipping 和 adservice) 也會部署到所有三個叢集。
在機群中任何叢集內執行的 Pod，只要向該服務的 ClusterSet URI 傳送要求，即可存取匯出的 Service。要求會轉送至支援服務的端點。
frontend 服務可以在同一個叢集內，在本機使用中介軟體服務 (例如 productcatalogservice 或 currencyservice)。這個架構有助於將傳入的要求保留在前端回應要求的區域，並避免產生不必要的區域間網路流量費用。
下圖說明這兩項多叢集服務。無狀態前端服務會部署至三個叢集，有狀態後端購物車服務則會部署至一個叢集。圖表也顯示，在這個中繼步驟中，前端服務的傳入流量仍會透過 frontend-external LoadBalancer Service 建立的區域性外部直通式網路負載平衡器，轉送至 us-west1 中的原始 GKE Standard 叢集：
遷移至多叢集閘道
最後一個步驟是使用多叢集閘道，將外部用戶端要求傳送的 前端服務輸入流量，轉送至機群中多個叢集的服務。
第四個叢集名為 config-central，會新增至機群，用於託管及管理 Gateway 和 HTTPRoute 資源的設定，這些資源是這項設定的一部分。HTTPRoute 資源會將 / 前置字元對應至前端 ServiceImport。Online Boutique 前端的流量會傳送至其中一個可用區域中的健康端點。這種做法會為 Online Boutique 應用程式架構新增高可用性元素。
在下圖中，多叢集閘道部署了全域 Cloud Load Balancer，將外部流量轉送至部署在機群中每個應用程式叢集上的無狀態前端服務。
在最終狀態中，這個獨斷的模式會展示應用程式 (frontend、emailservice、checkoutservice、recommendationservice、paymentservice、productcatalogservice、currencyservice、shippingservice 和 adservice) 有狀態 (cartservice 和 redis-cart) 和無狀態部分之間的鬆散耦合。雖然這不在本頁的討論範圍內，但這種方法可讓您日後有機會為有狀態服務層新增彈性和高可用性。
目標
- 建立及設定 GKE Standard 和 Autopilot 叢集。
- 將 Online Boutique 部署至可用區 GKE Standard 叢集。
- 匯出多叢集
Services。 - 將資訊清單部署至 Standard 和 Autopilot 叢集。
- 啟用及設定多叢集閘道。
- 測試多區域應用程式行為。
費用
在本文件中，您會使用下列 Google Cloud計費元件：
如要根據預測用量估算費用，請使用 Pricing Calculator。
事前準備
貴機構定義的安全性限制，可能會導致您無法完成下列步驟。如需疑難排解資訊，請參閱「在受限的 Google Cloud 環境中開發應用程式」。
開始之前，請確認符合下列條件：
- 建議您使用新專案進行本指南中的操作，因為最簡單的清理方式就是在完成後刪除專案。
- 本指南假設您具備專案的擁有者 IAM 角色。Google Cloud 如果是正式環境或實際設定，最佳做法是將權限範圍設為最小權限。詳情請參閱「安全地使用 IAM」和「明確驗證每次存取嘗試」。
- 熟悉線上商店微服務示範應用程式架構。
準備環境
在本指南中，您會使用 Cloud Shell 輸入指令。Cloud Shell 可讓您在Google Cloud 控制台中存取指令列，並內含 Google Cloud SDK 和其他工具，例如 Google Cloud CLI。Cloud Shell 會在Google Cloud 控制台底部顯示為視窗。初始化作業可能需要幾分鐘，但視窗會立即顯示。
在 Google Cloud 控制台中啟用 Cloud Shell。
在 Cloud Shell 中，定義本指南使用的環境變數。將 PROJECT_ID 替換為您自己的專案 ID：
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}啟用本頁步驟所需的服務：
gcloud services enable \ gkehub.googleapis.com \ multiclusteringress.googleapis.com \ dns.googleapis.com \ trafficdirector.googleapis.com \ cloudresourcemanager.googleapis.com \ multiclusterservicediscovery.googleapis.com \ container.googleapis.com gcloud container fleet multi-cluster-services enableMulti-cluster Services 會管理 Cloud DNS、防火牆規則和 Cloud Service Mesh 等 Google Cloud 元件，因此也必須啟用這些 API。詳情請參閱「Cloud Service Mesh 總覽」。
輸出內容大致如下：
Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad" finished successfully. Waiting for Feature Multi-cluster Services to be created...done.確認多叢集服務顯示「ACTIVE」狀態：
gcloud container fleet multi-cluster-services describe輸出內容大致如下：
createTime: '2021-11-30T21:59:25.245190894Z' name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery resourceState: state: ACTIVE spec: {} updateTime: '2021-11-30T21:59:27.459063070Z'如果 state 的值不是 ACTIVE，請參閱多叢集服務疑難排解詳細資料。
建立及設定 GKE 叢集
為示範本指南中的多叢集模式，您將使用三個位於不同雲端區域的應用程式叢集，以及一個用於託管閘道資源設定的叢集。您會向與專案相關聯的機群註冊所有叢集。 Google Cloud 專案只能與單一車隊建立關聯。這項專案稱為機群主專案。
本文中的所有 GKE 叢集都部署在同一個專案中。共用虛擬私有雲網路是在這個專案中建立，也就是車隊的專案。
建立 Standard 和 Autopilot GKE 叢集，並將叢集註冊至專案的機群：
gcloud container clusters create std-west \ --location us-west1-a \ --num-nodes=6 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --gateway-api=standard \ --enable-fleet \ --async \ gcloud container clusters create-auto auto-east \ --location us-east1 \ --release-channel regular \ --enable-fleet \ --async gcloud container clusters create-auto auto-central \ --location us-central1 \ --release-channel regular \ --enable-fleet \ --async gcloud container clusters create config-central \ --location us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --gateway-api=standard \ --enable-fleet \ --asyncGKE Autopilot 叢集預設會啟用 GKE 適用的 Workload Identity Federation，因此建立這類叢集時，不必像建立 GKE Standard 叢集一樣使用
--workload-pool旗標。等待叢集的「STATUS」從「PROVISIONING」變更為「RUNNING」。這項程序最多可能需要 10 分鐘的時間。您可以使用監控迴圈來監控進度：
watch -n 20 --difference=permanent "gcloud container clusters list"輸出內容大致如下：
NAME: auto-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 107.178.213.138 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: config-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 9 STATUS: PROVISIONING NAME: auto-east LOCATION: us-east1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.229.88.209 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: std-west LOCATION: us-west1-a MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.197.93.113 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 6 STATUS: PROVISIONING所有叢集都處於「RUNNING」狀態後，請按下
CTRL-C中斷指令。新增 Identity and Access Management (IAM) 政策繫結，將自有專案的網路使用者角色授予車隊主專案 MCS 服務帳戶：
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"您可以使用 Workload Identity Federation for GKE，將專案虛擬私有雲網路設定的讀取權限授予 MCS 服務。因此，機群主專案的 MCS Importer GKE 服務帳戶需要這個角色。
輸出內容大致如下：
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]在機群主專案中建立 IAM 繫結，將 GKE 服務代理角色指派給專案的 GKE 機群服務帳戶：
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:service-{${PROJECT}}@gcp-sa-gkehub.iam.gserviceaccount.com" \ --role roles/gkehub.serviceAgent在機群主專案中建立 IAM 繫結，將 MCS 服務代理程式角色指派給專案的 MCS 服務帳戶：
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:service-{${PROJECT}}@gcp-sa-mcsd.iam.gserviceaccount.com" \ --role roles/multiclusterservicediscovery.serviceAgent連線至叢集並產生 kubeconfig 項目：
gcloud container clusters get-credentials std-west \ --location us-west1-a --project $PROJECT gcloud container clusters get-credentials auto-east \ --location us-east1 --project $PROJECT gcloud container clusters get-credentials auto-central \ --location us-central1 --project $PROJECT gcloud container clusters get-credentials config-central \ --location us-central1 --project $PROJECT每個指令的輸出內容都類似以下範例：
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.重新命名叢集的環境，方便您在本頁面其餘部分使用：
kubectl config rename-context \ gke_${PROJECT}_us-west1-a_std-west \ std-west kubectl config rename-context \ gke_${PROJECT}_us-east1_auto-east \ auto-east kubectl config rename-context \ gke_${PROJECT}_us-central1_auto-central \ auto-central kubectl config rename-context \ gke_${PROJECT}_us-central1_config-central \ config-central在本指南中，情境會根據位置命名。雖然您可以提供替代名稱，但本指南的其餘步驟會使用這個步驟中使用的名稱。
在 GKE Standard 上部署 Online Boutique
在示範部署作業的第一個步驟中，您會將整套 Online Boutique 應用程式服務部署至 us-west1 中的單一 GKE Standard 叢集 std-west。
在 std-west 上建立 onlineboutique 命名空間：
kubectl create namespace onlineboutique --context std-west輸出內容大致如下：
namespace/onlineboutique created複製 Online Boutique GitHub 存放區，並設定 WORKDIR 變數：
cd ~ git clone --branch release/v0.4.1 \ https://github.com/GoogleCloudPlatform/microservices-demo.git cd microservices-demo/release && export WORKDIR=`pwd`在 std-west 部署 Online Boutique。這個程序會為 Online Boutique 的所有微服務建立
Deployments和Services，並納入 LoadBalancer 類型的 Service，對外公開 Online Boutique 的前端服務：cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-west等待
LoadBalancer服務取得外部 IP：watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"一開始，輸出內容會與以下範例類似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-external LoadBalancer 10.60.5.62 <pending> 80:30359/TCP 43sService準備就緒後，「EXTERNAL-IP」欄會顯示負載平衡器的公開 IP 位址。Service準備就緒後，請取得負載平衡器的外部 IP 位址，並使用 curl 驗證前端是否已準備就緒。如果這個 curl 指令傳回錯誤，請稍候片刻再重試：curl $(kubectl get svc frontend-external \ -n onlineboutique --context=std-west \ -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \ grep -e Cluster -e Zone -e Podcurl 指令的成功輸出內容類似以下範例：
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-b7bddcc97-wdjsk
您現在已在 us-west1-a 中執行 Online Boutique 的單一可用區版本。
您也可以使用網路瀏覽器前往指派給 frontend-external LoadBalancer 服務的外部 IP，存取應用程式並觀察其行為。這個初始單一部署作業如下圖所示：
將 cartservice 匯出為多叢集服務
在本節中，您會開始為應用程式新增高可用性元素。將後端 cartservice 匯出為多叢集 Service 至 GKE Autopilot 叢集。
在剩餘的叢集上建立 onlineboutique 命名空間：
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-central每個指令的輸出內容都類似以下範例：
namespace/onlineboutique created將
ClusterSet中 std-west 叢集的 cartservice 匯出至所有其他叢集。ServiceExport物件會向 GKE 多叢集 Service 註冊 cartservice Service，以便匯出至機群中所有具有 onlineboutique 命名空間的叢集。詳情請參閱「註冊服務以供匯出」。cat <<EOF>> $WORKDIR/cartservice-export.yaml kind: ServiceExport apiVersion: net.gke.io/v1 metadata: namespace: onlineboutique name: cartservice EOF kubectl apply -f $WORKDIR/cartservice-export.yaml \ -n onlineboutique --context=std-west
套用多叢集模式的應用程式資訊清單
在本節中，您將套用兩個精選資訊清單，部署多叢集模式。這些資訊清單包含您先前套用至 std-west 叢集的 kubernetes-manifests.yaml 部分內容：
- 第一個資訊清單用於前端
Deployment、Service和ServiceExport。 - 第二個資訊清單用於將中介軟體
Services(emailservice、checkoutservice、recommendationservice、paymentservice、productcatalogservice、currencyservice、shippingservice 和 adservice) 部署至所有執行 frontend 的區域。盡可能將要求保留在區域內，避免產生不必要的跨區域網路流量費用。
在機群中任何叢集執行的 Pod，都可以透過向該服務的 ClusterSet URI 傳送格式為 SERVICE_NAME.NAMESPACE.svc.clusterset.local 的要求，存取匯出的 Service。舉例來說，三個範例叢集中的 frontend
Deployments 都能向 cartservice.onlineboutique.svc.clusterset.local 提出要求，使用 onlineboutique 命名空間中的 cartservice。
因此，在每個資訊清單中，cartservice 的主機名稱都已更新為其 ClusterSet URI。這個步驟非常重要。如果未更新這項服務主機名稱，前端服務會向 kube-dns 要求 cartservice，而不是 cartservice.onlineboutique.svc.clusterset.local。如果叢集沒有本機版本的 cartservice，就會發生 HTTP Status 500 錯誤，並導致 frontend Pod 處於不正常的狀態。
為包含資訊清單的 GitHub 存放區設定環境變數：
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migration套用資訊清單，將前端層部署至所有三個工作負載叢集：
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-central套用資訊清單，將中介軟體層部署至所有三個工作負載叢集：
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-central
您現在已在 std-west、auto-east 和 auto-central 叢集中，啟用 frontend Deployment、Service 和 ServiceExport。每個叢集也都有在本機執行的 Online Boutique 中介軟體服務。不過，外部流量仍只會路由至 us-west1 初始叢集中執行的 Service，如下圖所示：
啟用及設定多叢集閘道
在本節中，您將在所有三個叢集的前端之間，將流量路由至外部流量並進行負載平衡。如要達成這項設定，請使用多叢集閘道 (MCG)。如要設定 MCG，請按照「啟用多叢集閘道」一文中的詳細說明操作。
在這些步驟中，您會使用 config-central 叢集，代管 Gateway 資源的設定。
確認所有叢集都已成功註冊至機群：
gcloud container fleet memberships list --project=$PROJECT下列輸出內容範例顯示所有叢集都已成功註冊：
NAME: auto-central EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f NAME: config-central EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98 NAME: std-west EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3 NAME: auto-east EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012在 config-central 叢集上安裝 Gateway API 自訂資源定義：
kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \ | kubectl apply -f -這個步驟會安裝 Gateway API 自訂資源定義，包括
GatewayClass、Gateway和HTTPRoute資源。自訂資源定義由 Kubernetes 網路特別興趣群組維護。安裝完成後，即可使用 GKE Gateway 控制器。如果尚未啟用，請為機群啟用多叢集 Ingress。 啟用這項功能也會啟用多叢集閘道控制器。
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECT輸出內容大致如下：
createTime: '2021-12-08T23:10:52.505888854Z' name: projects/PROJECT_ID/locations/global/features/multiclusteringress resourceState: state: ACTIVE spec: multiclusteringress: configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central state: state: code: OK description: Ready to use updateTime: '2021-12-08T23:11:37.994971649Z' updateTime: '2021-12-08T23:11:38.098244178Z'如果 state 的值不是 ACTIVE，請參閱「多叢集 Ingress 的疑難排解和作業」。
確認
GatewayClasses可在 config-central 叢集上使用：kubectl get gatewayclasses --context=config-central輸出內容大致如下：
NAME CONTROLLER AGE gke-l7-global-external-managed networking.gke.io/gateway 18s gke-l7-global-external-managed-mc networking.gke.io/gateway 19s gke-l7-regional-external-managed networking.gke.io/gateway 18s gke-l7-regional-external-managed-mc networking.gke.io/gateway 19s gke-l7-gxlb networking.gke.io/gateway 74s gke-l7-gxlb-mc networking.gke.io/gateway 16s gke-l7-rilb networking.gke.io/gateway 74s gke-l7-rilb-mc networking.gke.io/gateway 16s不同的
GatewayClass資源有不同的功能。如要進一步瞭解何時該使用哪種型別，請參閱「GatewayClass 功能」。將
external-http閘道資源部署至config-central：cat <<EOF>> $WORKDIR/external-http-gateway.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: external-http namespace: onlineboutique spec: gatewayClassName: gke-l7-global-external-managed-mc listeners: - protocol: HTTP port: 80 name: http EOF kubectl apply -f external-http-gateway.yaml \ -n onlineboutique --context=config-central如
gatewayClassName欄位所示，這個資源屬於GatewayClassgke-l7-global-external-managed-mc，可管理第 7 層外部 Cloud Load Balancing，並公開多叢集應用程式在 config-central 上部署名為 public-frontend-route 的
HTTPRoute：cat <<EOF>> $WORKDIR/public-frontend-route.yaml kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 metadata: name: public-frontend-route namespace: onlineboutique spec: parentRefs: - name: "external-http" hostnames: - "store.example.com" rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: frontend group: net.gke.io kind: ServiceImport port: 80 EOF kubectl apply -f public-frontend-route.yaml \ -n onlineboutique --context=config-central部署
HTTPRoute資源時，系統會建立外部第 7 層 Cloud Load Balancing 資源，並公開由 std-west、auto-east 和 auto-central 叢集中執行的前端服務支援的前端ServiceImport。下圖顯示部署多叢集閘道後，流量如何轉送至任一應用程式叢集上的前端多叢集服務：
請等待負載平衡器準備就緒，並佈建外部 IP 位址，再繼續下一步。IP 位址最多可能需要 10 分鐘才會指派。您可以使用監控迴圈監控進度。負載平衡器的名稱格式如下：gkemcg-onlineboutique-external-http-k09mfhk74gop：
watch -n 20 --difference=permanent \ "gcloud compute forwarding-rules list \ | grep -A 5 NAME..*external-http"輸出內容大致如下：
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop REGION: IP_ADDRESS: 34.149.29.176 IP_PROTOCOL: TCP TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gop負載平衡器準備就緒後，請在 Cloud Shell 中執行下列指令，匯出透過套用 external-http-gateway.yaml 和 public-frontend-route.yaml 資訊清單建立的負載平衡器外部 IP 位址：
export EXTERNAL_LB_IP=$(kubectl --context=config-central \ -n onlineboutique get gateway external-http \ -o=jsonpath='{.status.addresses[0].value}')使用適當的標頭將要求傳送至負載平衡器時，負載平衡器會傳回前端服務提供的 HTML 內容。舉例來說，由於您已設定
HTTPRoute資源，將store.example.com主機名稱對應至前端ServiceImport，因此發出 HTTP 要求時，必須提供HOST標頭。如果下列 curl 範例傳回錯誤，請稍候幾分鐘再試一次：curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podcurl 指令的成功輸出結果與下列範例類似：
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-f<br/> <b>Pod: </b>frontend-7c7d596ddc-jdh8f
測試應用程式多區域的路由行為
使用多叢集服務和多叢集閘道的一項強大功能，就是外部要求會轉送至地理位置最近的叢集。
如要測試應用程式的多區域行為，請從部署叢集的不同區域產生流量。建立三個小型 Pod，每個服務叢集 (std-west、auto-east 和 auto-central) 各一個，以便將 HTTP 要求傳送至負載平衡器端點。結果會顯示哪個前端 Pod 回應。
建立用戶端 Pod：
kubectl run --context=std-west \ --image=radial/busyboxplus:curl client-west \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-east \ --image=radial/busyboxplus:curl client-east \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-central \ --image=radial/busyboxplus:curl client-central \ -- sh -c 'while sleep 3600; do :; done'Pod 執行後，請使用 curl 指令，從 std-west 叢集中的用戶端
Pod將要求傳送至負載平衡器端點，並查看回應：kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podcurl 指令的成功輸出結果與下列範例類似：
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4從 auto-east 叢集中的用戶端
Pod執行相同的 curl 要求，並查看回應：kubectl exec -it --context=auto-east client-east \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podcurl 指令的成功輸出內容類似以下範例：
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdws由於這是 Autopilot 叢集，叢集可能需要佈建額外資源，才能排定
Pod。如果看到類似下列範例的輸出內容，請稍後再試：Error from server (BadRequest): pod client-east does not have a host assigned從用戶端
Pod在 auto-central 叢集中執行 curl，並檢查回應：kubectl exec -it --context=auto-central client-central \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podcurl 指令的成功輸出內容類似以下範例：
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4這些結果確認流量會路由至最接近要求來源位置的對應 Pod。
測試應用程式的多區域韌性
除了有效率地傳送流量，在多個區域執行服務也能提供韌性，以防基礎架構發生罕見但仍有可能發生的故障。
刪除特定叢集中的 frontend Deployments，然後在這些區域中從用戶端 Pod 重試 curl 指令，即可測試行為。請注意，應用程式仍可使用，並查看回應要求的 Pod 位置。
在 std-west 叢集中，從 client-west
Pod執行 curl 指令，並確認結果來自 us-west1 的前端：kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podcurl 指令的成功輸出內容類似以下範例：
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4刪除 std-west 叢集中的 frontend
Deployment：kubectl delete deploy frontend \ -n onlineboutique --context=std-west輸出內容大致如下：
deployment.apps "frontend" deleted從 std-west 叢集中的 client-west
Pod傳送另一項要求。您應該會看到來自其餘 frontend 的回應，Deployments位於 auto-east 或 auto-central 叢集：kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Pod類似下列範例的輸出內容會指出回應這項要求的正常
Pod所在位置：<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4或
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdws多次執行指令，查看交替出現的結果。
透過這個示範部署作業，您已使用多叢集服務和多叢集閘道，為 Online Boutique 應用程式新增彈性和地理位置分配元素。要求會轉送至最接近的地理區域，即使某個區域的前端或中介軟體服務發生問題，使用者仍可順利使用應用程式。
清除所用資源
為避免因為本教學課程所用資源，導致系統向 Google Cloud 帳戶收取費用，請刪除含有相關資源的專案，或者保留專案但刪除個別資源。
- 前往 Google Cloud 控制台的「Manage resources」(管理資源) 頁面。
- 在專案清單中選取要刪除的專案，然後點選「Delete」(刪除)。
- 在對話方塊中輸入專案 ID，然後按一下 [Shut down] (關閉) 以刪除專案。
後續步驟
- 進一步瞭解Google Cloud 機群和多叢集管理。
- 瞭解 如何將叢集， 包括 GKE 叢集，註冊至 Google Cloud 機群。
- 深入瞭解 Kubernetes Gateway API 和 GKE Gateway。
- 查看 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的 Cloud Architecture Center。