本文說明如何部署參考架構，請參閱「管理及調度在代管 Kubernetes 上執行的 Windows 應用程式網路」。
這些操作說明適用於雲端架構師、網路管理員和 IT 專業人員，他們負責設計及管理在 Google Kubernetes Engine (GKE) 叢集上執行的 Windows 應用程式。
架構
下圖顯示部署在受管理 GKE 叢集上執行的 Windows 應用程式時所用的參考架構。
如上圖所示，箭頭代表使用 Cloud Service Mesh 和 Envoy 閘道，管理在 GKE 上執行的 Windows 應用程式網路的流程。地區性 GKE 叢集包含 Windows 和 Linux 節點集區。Cloud Service Mesh 會建立及管理 Windows Pod 的流量路徑。
目標
- 建立及設定 GKE 叢集，用於執行 Windows 應用程式和 Envoy Proxy。
- 部署及驗證 Windows 應用程式。
- 將 Cloud Service Mesh 設為 Envoy 閘道的控制層。
- 使用 Kubernetes Gateway API 佈建內部應用程式負載平衡器，並公開 Envoy 閘道。
- 瞭解您建立的持續部署作業。
費用
部署此架構時，會使用下列Google Cloud的計費元件：
完成部署後，您可以刪除自己建立的資源，避免系統繼續計費。詳情請參閱清除所用資源一節。
事前準備
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verify that billing is enabled for your Google Cloud project.
-
Enable the Cloud Shell, and Cloud Service Mesh APIs.
-
In the Google Cloud console, activate Cloud Shell.
如果是在共用虛擬私有雲 (VPC) 環境中執行，您也需要按照手動建立僅限 Proxy 的子網路和防火牆規則的指示操作，以進行 Cloud Load Balancing 回應性檢查。
建立 GKE 叢集
請按照下列步驟建立 GKE 叢集。您可以使用 GKE 叢集，在這個部署作業中包含及執行 Windows 應用程式和 Envoy Proxy。
在 Cloud Shell 中執行下列 Google Cloud CLI 指令，建立地區性 GKE 叢集，每個區域包含一個節點：
gcloud container clusters create my-cluster --enable-ip-alias \ --num-nodes=1 \ --release-channel stable \ --enable-dataplane-v2 \ --region us-central1 \ --scopes=cloud-platform \ --gateway-api=standard將 Windows 節點集區新增至 GKE 叢集：
gcloud container node-pools create win-pool \ --cluster=my-cluster \ --image-type=windows_ltsc_containerd \ --no-enable-autoupgrade \ --region=us-central1 \ --num-nodes=1 \ --machine-type=n1-standard-2 \ --windows-os-version=ltsc2019這項作業可能需要 20 分鐘才能完成。
將 Google Cloud 專案 ID 儲存在環境變數中：
export PROJECT_ID=$(gcloud config get project)連線至 GKE 叢集：
gcloud container clusters get-credentials my-cluster --region us-central1列出 GKE 叢集中的所有節點：
kubectl get nodes輸出內容應會顯示三個 Linux 節點和三個 Windows 節點。
GKE 叢集準備就緒後，您就可以部署兩個以 Windows 為基礎的測試應用程式。
部署兩個測試應用程式
在本節中，您將部署兩個以 Windows 為基礎的測試應用程式。這兩個測試應用程式都會列印應用程式執行的主機名稱。您也會建立 Kubernetes Service，透過獨立網路端點群組 (NEG) 公開應用程式。
在區域叢集上部署 Windows 應用程式和 Kubernetes Service 時，系統會為應用程式執行的每個區域建立 NEG。本部署指南稍後會說明如何將這些 NEG 設定為 Cloud Service Mesh 服務的後端。
在 Cloud Shell 中，使用
kubectl套用下列 YAML 檔案，部署第一個測試應用程式。這個指令會部署三個測試應用程式執行個體，每個區域各一個。apiVersion: apps/v1 kind: Deployment metadata: labels: app: win-webserver-1 name: win-webserver-1 spec: replicas: 3 selector: matchLabels: app: win-webserver-1 template: metadata: labels: app: win-webserver-1 name: win-webserver-1 spec: containers: - name: windowswebserver image: k8s.gcr.io/e2e-test-images/agnhost:2.36 command: ["/agnhost"] args: ["netexec", "--http-port", "80"] topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: win-webserver-1 nodeSelector: kubernetes.io/os: windows套用相符的 Kubernetes 服務，並透過 NEG 公開：
apiVersion: v1 kind: Service metadata: name: win-webserver-1 annotations: cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-1"}}}' spec: type: ClusterIP selector: app: win-webserver-1 ports: - name: http protocol: TCP port: 80 targetPort: 80驗證部署作業：
kubectl get pods輸出內容顯示應用程式有三個執行中的 Windows Pod。
NAME READY STATUS RESTARTS AGE win-webserver-1-7bb4c57f6d-hnpgd 1/1 Running 0 5m58s win-webserver-1-7bb4c57f6d-rgqsb 1/1 Running 0 5m58s win-webserver-1-7bb4c57f6d-xp7ww 1/1 Running 0 5m58s
確認 Kubernetes 服務已建立：
$ kubectl get svc輸出結果會與下列內容相似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.64.0.1
443/TCP 58m win-webserver-1 ClusterIP 10.64.6.20 80/TCP 3m35s 針對
kubectl執行describe指令，確認應用程式執行的每個區域中，是否已為 Kubernetes 服務建立對應的 NEG：$ kubectl describe service win-webserver-1輸出結果會與下列內容相似：
Name: win-webserver-1 Namespace: default Labels:
Annotations: cloud.google.com/neg: {"exposed_ports": {"80":{"name": "win-webserver-1"}}} cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"win-webserver-1"},"zones":["us-central1-a","us-central1-b","us-central1-c"]} Selector: app=win-webserver-1 Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.64.6.20 IPs: 10.64.6.20 Port: http 80/TCP TargetPort: 80/TCP Endpoints: 10.60.3.5:80,10.60.4.5:80,10.60.5.5:80 Session Affinity: None Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Create 4m25s neg-controller Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-a". Normal Create 4m18s neg-controller Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-b". Normal Create 4m11s neg-controller Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-c". Normal Attach 4m9s neg-controller Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-a") Normal Attach 4m8s neg-controller Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-c") Normal Attach 4m8s neg-controller Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-b") 上述指令的輸出內容顯示，每個區域都已建立 NEG。
選用：使用 gcloud CLI 驗證是否已建立 NEG：
gcloud compute network-endpoint-groups list輸出看起來像這樣：
NAME LOCATION ENDPOINT_TYPE SIZE win-webserver-1 us-central1-a GCE_VM_IP_PORT 1 win-webserver-1 us-central1-b GCE_VM_IP_PORT 1 win-webserver-1 us-central1-c GCE_VM_IP_PORT 1
如要部署第二個測試應用程式，請套用下列 YAML 檔案：
apiVersion: apps/v1 kind: Deployment metadata: labels: app: win-webserver-2 name: win-webserver-2 spec: replicas: 3 selector: matchLabels: app: win-webserver-2 template: metadata: labels: app: win-webserver-2 name: win-webserver-2 spec: containers: - name: windowswebserver image: k8s.gcr.io/e2e-test-images/agnhost:2.36 command: ["/agnhost"] args: ["netexec", "--http-port", "80"] topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: win-webserver-2 nodeSelector: kubernetes.io/os: windows建立對應的 Kubernetes 服務：
apiVersion: v1 kind: Service metadata: name: win-webserver-2 annotations: cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-2"}}}' spec: type: ClusterIP selector: app: win-webserver-2 ports: - name: http protocol: TCP port: 80 targetPort: 80驗證應用程式部署作業：
kubectl get pods檢查輸出內容，確認有三個 Pod 正在執行。
確認 Kubernetes 服務和三個 NEG 是否已建立：
kubectl describe service win-webserver-2
設定 Cloud Service Mesh
在本節中，Cloud Service Mesh 會設定為 Envoy 閘道的控制層。
指定
scope_name參數，將 Envoy 閘道對應至相關的 Cloud Service Mesh 轉送設定。scope_name參數可讓您為不同 Envoy 閘道設定不同的轉送規則。在 Cloud Shell 中，建立防火牆規則，允許來自 Google 服務的輸入流量，這些服務會檢查應用程式的回應能力：
gcloud compute firewall-rules create allow-health-checks \ --network=default \ --direction=INGRESS \ --action=ALLOW \ --rules=tcp \ --source-ranges="35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22"檢查第一個應用程式的回應性：
gcloud compute health-checks create http win-app-1-health-check \ --enable-logging \ --request-path="/healthz" \ --use-serving-port檢查第二個應用程式的回應性：
gcloud compute health-checks create http win-app-2-health-check \ --enable-logging \ --request-path="/healthz" \ --use-serving-port為第一個應用程式建立 Cloud Service Mesh 後端服務：
gcloud compute backend-services create win-app-1-service \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --port-name=http \ --health-checks win-app-1-health-check為第二個應用程式建立 Cloud Service Mesh 後端服務：
gcloud compute backend-services create win-app-2-service \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --port-name=http \ --health-checks win-app-2-health-check新增先前建立的 NEG。這些 NEG 會與您建立的第一個應用程式相關聯，做為 Cloud Service Mesh 後端服務的後端。這個程式碼範例會為您建立的區域叢集，在每個區域中新增一個 NEG。
BACKEND_SERVICE=win-app-1-service APP1_NEG_NAME=win-webserver-1 MAX_RATE_PER_ENDPOINT=10 gcloud compute backend-services add-backend $BACKEND_SERVICE \ --global \ --network-endpoint-group $APP1_NEG_NAME \ --network-endpoint-group-zone us-central1-b \ --balancing-mode RATE \ --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT gcloud compute backend-services add-backend $BACKEND_SERVICE \ --global \ --network-endpoint-group $APP1_NEG_NAME \ --network-endpoint-group-zone us-central1-a \ --balancing-mode RATE \ --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT gcloud compute backend-services add-backend $BACKEND_SERVICE \ --global \ --network-endpoint-group $APP1_NEG_NAME \ --network-endpoint-group-zone us-central1-c \ --balancing-mode RATE \ --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT新增其他 NEG。這些 NEG 與您建立的第二個應用程式相關聯，做為 Cloud Service Mesh 後端服務的後端。這個程式碼範例會為您建立的區域叢集，在每個區域中新增一個 NEG。
BACKEND_SERVICE=win-app-2-service APP2_NEG_NAME=win-webserver-2 gcloud compute backend-services add-backend $BACKEND_SERVICE \ --global \ --network-endpoint-group $APP2_NEG_NAME \ --network-endpoint-group-zone us-central1-b \ --balancing-mode RATE \ --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT gcloud compute backend-services add-backend $BACKEND_SERVICE \ --global \ --network-endpoint-group $APP2_NEG_NAME \ --network-endpoint-group-zone us-central1-a \ --balancing-mode RATE \ --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT gcloud compute backend-services add-backend $BACKEND_SERVICE \ --global \ --network-endpoint-group $APP2_NEG_NAME \ --network-endpoint-group-zone us-central1-c \ --balancing-mode RATE \ --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
設定其他 Cloud Service Mesh 資源
您已設定 Cloud Service Mesh 服務，現在需要設定兩個額外資源，才能完成 Cloud Service Mesh 設定。
首先，下列步驟說明如何設定
Gateway資源。Gateway資源是虛擬資源，用於產生 Cloud Service Mesh 路由規則。Cloud Service Mesh 路由規則用於將 Envoy Proxy 設定為閘道。接下來的步驟說明如何為每個後端服務設定
HTTPRoute資源。HTTPRoute資源會將 HTTP 要求對應至相關後端服務。在 Cloud Shell 中，建立名為
gateway.yaml的 YAML 檔案，定義Gateway資源：cat <<EOF> gateway.yaml name: gateway80 scope: gateway-proxy ports: - 8080 type: OPEN_MESH EOF叫用
gateway.yaml檔案，建立Gateway資源：gcloud network-services gateways import gateway80 \ --source=gateway.yaml \ --location=globalGateway名稱會是projects/$PROJECT_ID/locations/global/gateways/gateway80。建立每個後端服務的
HTTPRoutes時，您會使用這個Gateway名稱。
為每個後端服務建立
HTTPRoutes：在 Cloud Shell 中，將專案 ID 儲存在環境變數中： Google Cloud
export PROJECT_ID=$(gcloud config get project)為第一個應用程式建立
HTTPRouteYAML 檔案：cat <<EOF> win-app-1-route.yaml name: win-app-1-http-route hostnames: - win-app-1 gateways: - projects/$PROJECT_ID/locations/global/gateways/gateway80 rules: - action: destinations: - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-1-service" EOF為第一個應用程式建立
HTTPRoute資源：gcloud network-services http-routes import win-app-1-http-route \ --source=win-app-1-route.yaml \ --location=global為第二個應用程式建立
HTTPRouteYAML 檔案：cat <<EOF> win-app-2-route.yaml name: win-app-2-http-route hostnames: - win-app-2 gateways: - projects/$PROJECT_ID/locations/global/gateways/gateway80 rules: - action: destinations: - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-2-service" EOF為第二個應用程式建立
HTTPRoute資源：gcloud network-services http-routes import win-app-2-http-route \ --source=win-app-2-route.yaml \ --location=global
部署及公開 Envoy 閘道
建立兩個以 Windows 為基礎的測試應用程式和 Cloud Service Mesh 後，請建立部署作業 YAML 檔案，部署 Envoy 閘道。部署 YAML 檔案可完成下列工作：
- 啟動 Envoy 閘道。
- 設定 Envoy 閘道，將 Cloud Service Mesh 設為控制層。
- 將 Envoy 閘道設定為對名為
Gateway80的閘道使用HTTPRoutes。
部署兩個 Envoy 閘道副本。這種做法有助於讓閘道容錯，並提供備援功能。如要根據負載自動調度 Envoy 閘道，您可以選擇設定水平 Pod 自動調度器。如果您決定設定水平 Pod 自動配置器，請按照「設定水平自動調度 Pod 資源」一文中的操作說明進行。
在 Cloud Shell 中建立 YAML 檔案：
apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: td-envoy-gateway name: td-envoy-gateway spec: replicas: 2 selector: matchLabels: app: td-envoy-gateway template: metadata: creationTimestamp: null labels: app: td-envoy-gateway spec: containers: - name: envoy image: envoyproxy/envoy:v1.21.6 imagePullPolicy: Always resources: limits: cpu: "2" memory: 1Gi requests: cpu: 100m memory: 128Mi env: - name: ENVOY_UID value: "1337" volumeMounts: - mountPath: /etc/envoy name: envoy-bootstrap initContainers: - name: td-bootstrap-writer image: gcr.io/trafficdirector-prod/xds-client-bootstrap-generator imagePullPolicy: Always args: - --project_number='my_project_number' - --scope_name='gateway-proxy' - --envoy_port=8080 - --bootstrap_file_output_path=/var/lib/data/envoy.yaml - --traffic_director_url=trafficdirector.googleapis.com:443 - --expose_stats_port=15005 volumeMounts: - mountPath: /var/lib/data name: envoy-bootstrap volumes: - name: envoy-bootstrap emptyDir: {}將 my_project_number 替換為專案編號。
- 執行下列指令，即可找出專案編號：
gcloud projects describe $(gcloud config get project) --format="value(projectNumber)"
通訊埠
15005用於公開名為/stats的 Envoy 管理端點。這項資訊也可用於下列用途：- 做為內部應用程式負載平衡器的回應端點。
- 從 Envoy 擷取 Google Cloud Managed Service for Prometheus 指標。
兩個 Envoy Gateway Pod 執行時，請建立
ClusterIP類型的服務，公開發布這些 Pod。您也必須建立名為BackendConfig的 YAML 檔案。BackendConfig：定義非標準的即時回應檢查。這項檢查用於驗證 Envoy 閘道的即時回應能力。如要使用非標準的回應性檢查建立後端設定，請建立名為
envoy-backendconfig的 YAML 檔案：apiVersion: cloud.google.com/v1 kind: BackendConfig metadata: name: envoy-backendconfig spec: healthCheck: checkIntervalSec: 5 timeoutSec: 5 healthyThreshold: 2 unhealthyThreshold: 3 type: HTTP requestPath: /stats port: 15005回應檢查會使用通訊埠
15005上的/stats端點，持續檢查 Envoy 閘道的回應情形。建立 Envoy 閘道服務：
apiVersion: v1 kind: Service metadata: name: td-envoy-gateway annotations: cloud.google.com/backend-config: '{"default": "envoy-backendconfig"}' spec: type: ClusterIP selector: app: td-envoy-gateway ports: - name: http protocol: TCP port: 8080 targetPort: 8080 - name: stats protocol: TCP port: 15005 targetPort: 15005查看您建立的 Envoy 閘道服務：
kubectl get svc td-envoy-gateway
建立 Kubernetes Gateway 資源
建立 Kubernetes Gateway 資源會佈建內部應用程式負載平衡器，以公開 Envoy 閘道。
建立該資源前，您必須先建立兩個自簽章範例憑證，然後將其匯入 GKE 叢集做為 Kubernetes Secret。憑證可啟用下列閘道架構：
- 每個應用程式都是透過 HTTPS 提供。
- 每個應用程式都會使用專屬憑證。
使用自行管理的憑證時，內部應用程式負載平衡器最多可使用憑證上限，公開具有不同完整網域名稱的應用程式。
如要建立憑證，請使用
openssl。在 Cloud Shell 中，為第一個憑證產生設定檔：
cat <<EOF >CONFIG_FILE [req] default_bits = 2048 req_extensions = extension_requirements distinguished_name = dn_requirements prompt = no [extension_requirements] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @sans_list [dn_requirements] 0.organizationName = example commonName = win-webserver-1.example.com [sans_list] DNS.1 = win-webserver-1.example.com EOF為第一個憑證產生私密金鑰：
openssl genrsa -out sample_private_key 2048產生憑證要求：
openssl req -new -key sample_private_key -out CSR_FILE -config CONFIG_FILE簽署並產生第一個憑證：
openssl x509 -req -signkey sample_private_key -in CSR_FILE -out sample.crt -extfile CONFIG_FILE -extensions extension_requirements -days 90產生第二個憑證的設定檔：
cat <<EOF >CONFIG_FILE2 [req] default_bits = 2048 req_extensions = extension_requirements distinguished_name = dn_requirements prompt = no [extension_requirements] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @sans_list [dn_requirements] 0.organizationName = example commonName = win-webserver-2.example.com [sans_list] DNS.1 = win-webserver-2.example.com EOF產生第二個憑證的私密金鑰：
openssl genrsa -out sample_private_key2 2048產生憑證要求：
openssl req -new -key sample_private_key2 -out CSR_FILE2 -config CONFIG_FILE2簽署並產生第二個憑證：
openssl x509 -req -signkey sample_private_key2 -in CSR_FILE2 -out sample2.crt -extfile CONFIG_FILE2 -extensions extension_requirements -days 90
將憑證匯入為 Kubernetes Secret
在本節中，您將完成下列工作：
- 將自行簽署的憑證匯入 GKE 叢集，做為 Kubernetes 密鑰。
- 為內部虛擬私有雲建立靜態 IP 位址。
- 建立 Kubernetes Gateway API 資源。
- 確認憑證是否正常運作。
在 Cloud Shell 中，將第一個憑證匯入為 Kubernetes Secret：
kubectl create secret tls sample-cert --cert sample.crt --key sample_private_key將第二個憑證匯入為 Kubernetes Secret：
kubectl create secret tls sample-cert-2 --cert sample2.crt --key sample_private_key2如要啟用內部應用程式負載平衡器，請在內部 VPC 建立靜態 IP 位址：
gcloud compute addresses create sample-ingress-ip --region us-central1 --subnet default建立 Kubernetes Gateway API 資源 YAML 檔案：
kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: internal-https spec: gatewayClassName: gke-l7-rilb addresses: - type: NamedAddress value: sample-ingress-ip listeners: - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: sample-cert - name: sample-cert-2根據預設，Kubernetes Gateway 沒有預設路徑。當要求傳送至閘道時，閘道會傳回找不到網頁 (404) 錯誤。
為 Kubernetes Gateway 設定預設
routeYAML 檔案，將所有連入要求傳遞至 Envoy 閘道：kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: envoy-default-backend spec: parentRefs: - kind: Gateway name: internal-https rules: - backendRefs: - name: td-envoy-gateway port: 8080將 HTTP 要求傳送至這兩個應用程式，驗證完整流程。如要確認 Envoy 閘道是否將流量轉送至正確的應用程式 Pod，請檢查 HTTP Host 標頭。
找出 Kubernetes Gateway IP 位址，並儲存在環境變數中：
export EXTERNAL_IP=$(kubectl get gateway internal-https -o json | jq .status.addresses[0].value -r)將要求傳送至第一個應用程式：
curl --insecure -H "Host: win-app-1" https://$EXTERNAL_IP/hostName將要求傳送至第二個應用程式：
curl --insecure -H "Host: win-app-2" https://$EXTERNAL_IP/hostName確認要求傳回的主機名稱與執行
win-app-1和win-app-2的 Pod 相符：kubectl get pods輸出內容應顯示
win-app-1和win-app-2。
監控 Envoy 閘道
使用 Google Cloud Managed Service for Prometheus 監控 Envoy 閘道。
您先前建立的叢集應預設啟用 Google Cloud Managed Service for Prometheus。
在 Cloud Shell 中，套用下列 YAML 檔案，建立
PodMonitoring資源：apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: prom-envoy spec: selector: matchLabels: app: td-envoy-gateway endpoints: - port: 15005 interval: 30s path: /stats/prometheus套用 YAML 檔案後，系統就會開始在資訊主頁中收集 Google Cloud Managed Service for Prometheus 指標。
如要建立 Google Cloud Managed Service for Prometheus 指標資訊主頁，請按照下列操作說明進行：
- 登入 Google Cloud 主控台。
- 開啟 選單。
- 依序點選「Operations」>「Monitoring」>「Dashboards」。
如要匯入資訊主頁，請按照下列操作說明操作：
- 在「資訊主頁」畫面中，按一下「範例庫」。
- 在篩選方塊中輸入「envoy」。
- 按一下「Istio Envoy Prometheus Overview」(Istio Envoy Prometheus 總覽)。
- 勾選核取方塊。
- 依序點選「匯入」和「確認」，匯入資訊主頁。
如要查看資訊主頁，請按照下列指示操作：
- 按一下「資訊主頁清單」。
- 選取「整合」。
- 按一下「Istio Envoy Prometheus Overview」(Istio Envoy Prometheus 總覽)，即可查看資訊主頁。
現在可以查看 Envoy 閘道最重要的指標。您也可以根據條件設定快訊。清理前，請再傳送幾項測試要求給應用程式，並查看資訊主頁如何更新最新指標。
清除所用資源
如要避免系統向您的 Google Cloud 帳戶收取本次部署所用資源的費用，請刪除含有相關資源的專案，或者保留專案但刪除個別資源。
刪除專案
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
後續步驟
- 進一步瞭解本部署指南中使用的 Google Cloud 產品：
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：Eitan Eibschutz | 員工技術解決方案顧問
其他貢獻者：
- John Laham | 解決方案架構師
- Kaslin Fields | 開發人員服務代表
- Maridi (Raju) Makaraju | 支援能力技術主管
- Valavan Rajakumar | 主要企業架構師
- Victor Moreno | 雲端網路產品經理