Anthos 服務網格和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

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

使用 Istio API 安裝及升級閘道

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

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

本頁說明部署及升級閘道 Proxy 的最佳做法，並提供設定 istio-ingressgateway 和 istio-egressgateway 閘道 Proxy 的範例。

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

部署閘道的最佳做法

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

受管理資料層的最佳做法

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

這些最佳做法：

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

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

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

這些最佳做法：

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

部署範例閘道

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

下列步驟說明如何部署範例閘道。

如果還沒有閘道命名空間，請建立一個。將 GATEWAY_NAMESPACE 替換為您的命名空間名稱。
```
kubectl create namespace GATEWAY_NAMESPACE
```
啟用要用於注入的命名空間。步驟取決於控制層實作方式。
代管 (TD)
1. 將預設插入標籤套用至命名空間：
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
受管理 (Istiod)
建議：執行下列指令，將預設插入標籤套用至命名空間：
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
如果您是使用受管理 Istiod 控制平面的現有使用者： 建議您使用預設插入功能，但系統也支援以修訂版本為準的插入功能。請按照下列指示操作：
1. 執行下列指令，找出可用的發布管道：
  
  kubectl -n istio-system get controlplanerevision
  
  輸出結果會與下列內容相似：
  
  NAME AGE asm-managed-rapid 6d7h
  
  注意：如果上述清單中出現兩個控制層修訂版本，請移除其中一個。叢集不支援多個控制層通道。
  
  在輸出內容中，「NAME」欄位下方的值是與 Cloud Service Mesh 版本適用的發布管道對應的修訂版本標籤。
2. 將修訂版本標籤套用至命名空間：
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
叢集內
建議：執行下列指令，將預設插入標籤套用至命名空間：
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
建議您使用預設插入方式，但系統也支援以修訂版本為準的插入方式： 請按照下列操作說明進行：
1. 使用下列指令找出 istiod 上的修訂版本標籤：
  
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. 將修訂版本標籤套用至命名空間。在下列指令中，REVISION_LABEL 是您在上一步記下的 istiod 修訂版本標籤值。
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
從 anthos-service-mesh 存放區複製範例閘道的設定檔。
將目錄變更為 samples 目錄。如要確保您位於正確的目錄，請執行 ls 指令列出目錄內容，然後確認有 gateways 目錄 (您會在下一個步驟中存取) 和 online-boutique 目錄。

部署輸入或輸出閘道。這些檔案位於 samples/gateways/ 目錄，您可以沿用或視需要修改。

輸入

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

輸出

kubectl apply -n GATEWAY_NAMESPACE -f samples/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

管理閘道資源的方式與其他 Kubernetes 應用程式相同。anthos-service-mesh-packages 存放區中的範例僅供參考，可做為快速入門指南。並視需要自訂。

閘道選取器

您可以將「閘道」設定套用至 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 Cloud 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"

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) 流量的閘道

詳情請參閱「在 Ingress 閘道中設定 TLS 終止」文件。

設定閘道的最低 TLS 版本

在 Cloud Service Mesh 中，閘道伺服器的預設最低 TLS 版本為 1.2。您可以使用 minProtocolVersion 欄位設定最低 TLS 版本。詳情請參閱「ServerTLSSettings」。

不支援的功能

如果您有TRAFFIC_DIRECTOR 控制層實作，則 Gateway 不支援下列欄位或值：

ServerTLSSettings.TLSmode，值為 AUTO_PASSTHROUGH
ServerTLSSettings.verifyCertificateSpki
ServerTLSSettings.verifyCertificateHash

排解閘道問題

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

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