您正在查看舊版 v1.20 服務網格說明文件。

可用版本

Cloud Service Mesh
1.24 版封存資料
 1.23 版封存資料
 1.22 版封存資料
 1.21 版封存資料
 1.20 版封存資料
 1.19 版封存資料
 1.18 版封存資料

本頁面由 Cloud Translation API 翻譯而成。

安裝及升級閘道

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

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

本頁說明部署及升級閘道 Proxy 的最佳做法，以及設定您自己的 istio-ingressgateway 和 istio-egressgateway 閘道 Proxy 的範例。您可以將閘道設定套用至閘道 Proxy，藉此實現流量分割、重新導向和重試邏輯等功能。接著，您可以將虛擬服務繫結至 Gateway，而非將應用程式層流量路由 (L7) 新增至相同的 API 資源。這樣一來，您就能管理網關流量，就像管理服務網格中的任何其他資料層流量一樣。

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

部署網關的最佳做法

部署閘道的最佳做法取決於您是使用受管理的資料層還是未受管理的資料層。

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

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

這些最佳做法：

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

無管理資料處理層的最佳做法

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

這些最佳做法：

讓命名空間管理員管理閘道，而無須對整個叢集提升權限。
讓管理員使用與管理 Kubernetes 應用程式相同的部署工具或機制，部署及管理閘道。
讓管理員全面掌控閘道部署作業，並簡化操作流程。當新的升級可用或設定有所變更時，管理員只需重新啟動閘道 Pod 即可更新。這樣一來，閘道部署的操作體驗就會與為服務操作附掛 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-1253-8 的修訂版本標籤，其中 asm-1253-8 會標示 Cloud Service Mesh 版本。修訂版本會成為 istiod 服務名稱的一部分，例如：istiod-asm-1253-8.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 標籤。請使用 OUTPUT_DIR 中的 istioctl 執行 istioctl tag list，確認預設標記是否存在。
```
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/ 目錄中的閘道設定範例，或視需要進行修改。

Ingress

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
...

如需閘道設定和虛擬服務的範例，請參閱線上精品店範例應用程式中的 frontend.yaml。

升級閘道

直接升級

在大多數情況下，您應依照原地升級模式升級閘道。由於閘道會使用 Pod 插入功能，因此系統會自動為新建的閘道 Pod 插入最新設定 (包括版本)。

如果您想變更閘道器使用的控制平面修訂版本，可以在閘道器部署上設定 istio.io/rev 標籤，這也會觸發逐步重新啟動。

受管理的控制層

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

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

叢集內控制層

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

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

如果您只為閘道 Pod 啟用注入功能，請將部署作業的 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

初期測試升級 (進階)

如果您使用叢集內控制層，且想要以較緩慢的速度控管新控制層修訂版本的發布作業，可以遵循 Canary 升級模式。您可以執行多個版本的閘道部署，並確保一切都能在部分流量中正常運作。舉例來說，如果您想推出新修訂版本 (Canary)，請建立閘道部署作業的副本，並將 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

建立此部署後，您將擁有兩個版本的閘道，兩者皆由同一個服務選取：

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 標籤集的部署作業，以便轉換至新版本：

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

如果您在使用新版閘道測試應用程式時遇到問題，請執行下列指令，刪除具有新 istio.io/rev 標籤集的部署作業，以便改回舊版：

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 代理程式映像檔。如果呼叫變異 webhook 失敗，auto 預留位置會保留，且系統不會找到容器。這通常是因為命名空間標籤不正確。請確認已設定正確的命名空間，然後再次部署或升級閘道。