您目前查看的是已封存的 1.20 版服務網格說明文件。

可觀看版本

Cloud Service Mesh 最新版本
 Cloud Service Mesh 1.28 封存版本
 Cloud Service Mesh 1.27 封存版本
 Cloud Service Mesh 1.26 封存版本
 Cloud Service Mesh 1.25 封存版本
 Cloud Service Mesh 1.24 封存版本
 Cloud Service Mesh 1.23 封存版本
 Cloud Service Mesh 1.22 封存版本
 Cloud Service Mesh 1.21 封存版本
 Cloud Service Mesh 1.20 封存版本
 Anthos 服務網格 1.19 封存版本

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

安裝及升級閘道

您可以選擇透過 Cloud Service Mesh 部署及管理閘道，做為服務網格的一部分。閘道是指在網格邊緣運作的負載平衡器，可接收傳入或傳出的 HTTP/TCP 連線。閘道是 Envoy 代理程式，可讓您精細控管進出網格的流量。閘道主要用於管理輸入流量，但您也可以設定閘道來管理其他類型的流量。例如：

輸出閘道：輸出閘道可讓您為離開網格的流量設定專用輸出節點，限制哪些服務可以或應該存取外部網路，或啟用輸出流量的安全控管，為網格新增安全性。
東西向閘道：東西向流量的 Proxy，可讓不同網路上的多主網格中，服務工作負載跨叢集邊界通訊。根據預設，這個閘道會在網際網路上公開。

本頁說明部署及升級閘道 Proxy 的最佳做法，並提供設定 istio-ingressgateway 和 istio-egressgateway 閘道 Proxy 的範例。只要將 Gateway 設定套用至閘道 Proxy，即可進行流量分割、重新導向和重試邏輯等作業。然後，您會將虛擬服務繫結至 Gateway，而不是將應用程式層流量路徑 (L7) 新增至相同的 API 資源。這樣一來，您就能像管理服務網格中的其他資料層流量一樣，管理閘道流量。

您可以透過不同方式部署閘道，也可以選擇在同一個叢集中使用多個拓撲。如要進一步瞭解這些拓撲，請參閱 Istio 說明文件中的「閘道部署拓撲」。

部署閘道的最佳做法

部署閘道的最佳做法取決於您使用的是受管理資料平面或非受管理資料平面。

受管理資料層的最佳做法

啟用受管理資料層。
為命名空間新增受管理修訂版本標籤。
分別部署及管理控制層和閘道。
為確保安全，我們建議您在控制層以外的命名空間中部署閘道。
使用自動 Sidecar Proxy 植入功能 (自動植入)，為閘道植入 Proxy 設定，與為服務植入 Sidecar Proxy 的方式類似。

這些最佳做法：

確保受管理閘道自動更新至最新版本，取得最新強化功能和安全性更新。
將閘道執行個體的管理和維護作業，卸載至 Cloud Service Mesh 代管資料層。

非受管理資料層的最佳做法

分別部署及管理控制層和閘道。
為確保安全，我們建議您在控制層以外的命名空間中部署閘道。
使用自動 Sidecar Proxy 植入功能 (自動植入)，為閘道植入 Proxy 設定，與為服務植入 Sidecar Proxy 的方式類似。

這些最佳做法：

讓命名空間管理員管理閘道，不必提升整個叢集的進階權限。
讓管理員使用與管理 Kubernetes 應用程式相同的部署工具或機制，部署及管理閘道。
讓管理員全面掌控閘道部署作業，並簡化作業。如有新版本或設定變更，管理員只要重新啟動閘道 Pod，即可更新。這項功能可讓您以操作服務的 Sidecar Proxy 相同方式，操作閘道部署作業。

部署閘道

為支援使用現有部署工具的使用者，Cloud Service Mesh 支援與 Istio 相同的閘道部署方式：IstioOperator、Helm 和 Kubernetes YAML。每種方法都會產生相同的結果。您可以選擇最熟悉的方法，但我們建議使用 Kubernetes YAML 方法，因為這種方法較容易修改，且您可以在原始碼控管系統中儲存經過補充的資訊清單。

如果還沒有閘道命名空間，請建立一個。將 GATEWAY_NAMESPACE 替換為您的命名空間名稱。
```
kubectl create namespace GATEWAY_NAMESPACE
```
如要啟用自動插入功能，請使用預設插入標籤標記命名空間 (如果已設定預設標籤)，或使用修訂版本標籤標記命名空間。您新增的標籤也會視您部署代管 Cloud Service Mesh 或安裝叢集內控制層而定。側車注入器 Webhook 會使用這個標籤，將注入的側車與特定控制層修訂版本建立關聯。

根據安裝類型 (代管或叢集內)，選取下方的分頁標籤。
受管理
使用下列指令找出可用的發布管道：
kubectl -n istio-system get controlplanerevision
輸出結果會與下列內容相似：
NAME AGE asm-managed 6d7h asm-managed-rapid 6d7h
在輸出內容中，「NAME」資料欄下方的值是修訂版本標籤，對應於 Cloud Service Mesh 版本的可用發布管道。
叢集內
如果是叢內控制層，istiod 服務和部署作業通常會有類似 istio.io/rev=asm-1287-4 的修訂版本標籤，其中 asm-1287-4 會識別 Cloud Service Mesh 版本。修訂版本會成為 istiod 服務名稱的一部分，例如：istiod-asm-1287-4.istio-system

使用下列指令，在 istiod 上找出叢內控制層的修訂版本標籤：
kubectl get deploy -n istio-system -l app=istiod \ -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
啟用要用於注入的命名空間。將和 REVISION 替換為修訂標籤的值。

注意：如果已設定預設標記，您可以將 istio.io/rev 替換為 istio-injection=enabled 標籤。執行 istioctl tag list，並使用 OUTPUT_DIR 中的 istioctl，確認預設代碼是否存在。
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
如果您使用 asmcli 安裝 Cloud Service Mesh，請切換至 --output_dir 中指定的目錄，然後 cd 至 samples 目錄。

重要事項： 為確保您位於正確的 samples 目錄，請執行 ls 指令列出目錄內容，並確認有 gateways 目錄 (您會在下一個步驟中存取) 和 online-boutique 目錄。

如果未使用 asmcli 安裝，請從anthos-service-mesh存放區複製閘道的設定檔。

您可以直接部署 samples/gateways/ 目錄中的範例閘道設定，或視需要修改。

輸入

kubectl apply -n GATEWAY_NAMESPACE -f gateways/istio-ingressgateway

輸出

kubectl apply -n GATEWAY_NAMESPACE -f gateways/istio-egressgateway

建立部署作業後，請確認新服務運作正常：

kubectl get pod,service -n GATEWAY_NAMESPACE

確認輸出結果與下列內容相似：

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

閘道選取器

您可以將「閘道」設定套用至 istio-ingressgateway 和 istio-egressgateway 代理程式，管理網格的輸入和輸出流量，並指定要讓哪些流量進入或離開網格。閘道部署項目的 Pod 標籤會由閘道設定資源使用，因此請務必讓閘道選取器與這些標籤相符。

舉例來說，在上述部署作業中，istio=ingressgateway 標籤是在閘道 Pod 上設定。如要將閘道設定套用至這些部署作業，請選取相同的標籤：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

如需閘道設定和虛擬服務的範例，請參閱 Online Boutique 範例應用程式中的 frontend.yaml。

升級閘道

直接升級

在大多數情況下，您應按照就地升級模式升級閘道。由於閘道會使用 Pod 注入功能，因此建立的新閘道 Pod 會自動注入最新設定，包括版本。

如要變更閘道使用的控制層修訂版本，可以在閘道 Deployment 上設定 istio.io/rev 標籤，這也會觸發滾動重新啟動。

代管控制層

由於 Google 會管理代管控制層的控制層升級作業，您只要重新啟動閘道部署作業，系統就會自動將最新設定和版本注入新的 Pod。

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

叢集內控制層

如果您有叢集內控制層，如要將相同模式套用至閘道，必須變更閘道使用的控制層修訂版本。在閘道 Deployment 上設定 istio.io/rev 標籤，觸發滾動重新啟動。所需步驟取決於是否需要更新命名空間和/或閘道 Pod 的修訂版本標籤。

如果您已為注入作業標記命名空間，請將命名空間的 istio.io/rev 標籤設為新的修訂版本值：
```
  kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION \
    --overwrite
```

如果只為閘道 Pod 啟用插入功能，請將 Deployment 上的 istio.io/rev 標籤設為新的修訂版本值，如下列 Kubernetes YAML 檔案所示：

cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

初期測試升級 (進階)

如果您使用叢集內控制層，且希望更緩慢地控管新控制層修訂版本的推出作業，可以按照初期測試版本升級模式進行。您可以執行多個閘道部署版本，並確保一切運作正常，只處理部分流量。舉例來說，如要推出新修訂版本，請建立閘道 Deployment 的副本，並將 istio.io/rev=REVISION 標籤設為新修訂版本和新名稱，例如 istio-ingressgateway-canary：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

建立這個 Deployment 後，您會有兩個閘道版本，兩者都由同一個 Service 選取：

kubectl get endpoints \
-o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name" \
-n GATEWAY_NAMESPACE

輸出結果會與下列內容相似：

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

確認應用程式運作正常後，請執行下列指令，刪除具有舊 istio.io/rev 標籤集的 Deployment，藉此轉換至新版本：

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

如果在測試應用程式時遇到問題，請執行下列指令，刪除設有新 istio.io/rev 標籤的 Deployment，即可返回舊版：

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

進階設定

設定閘道的最低 TLS 版本

如果是 Cloud Service Mesh 1.14 以上版本，閘道伺服器的預設最低傳輸層安全標準 (TLS) 版本為 1.2。您可以使用 minProtocolVersion 欄位設定最低 TLS 版本。詳情請參閱「ServerTLSSettings」。

排解閘道問題

無法從 `auto` 更新閘道圖片

部署或升級閘道時，Cloud Service Mesh 會在 image 欄位中插入 auto 做為預留位置。呼叫變異 Webhook 後，Cloud Service Mesh 會自動將這個預留位置替換為實際的 Cloud Service Mesh Proxy 映像檔。如果對變異 Webhook 的呼叫失敗，系統會保留 auto 預留位置，且找不到容器。這通常是由於命名空間標籤不正確所致。請確認已設定正確的命名空間，然後再次部署或升級閘道。