使用 Istio API 安裝及升級閘道

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

  • 輸出閘道：輸出閘道可讓您為離開網格的流量設定專屬的退出節點，藉此限制哪些服務可以或應存取外部網路，或啟用輸出流量的安全控管機制，為網格增添安全性。

  • 輸入閘道：輸入閘道可讓您設定專用入口節點，用於接收傳入的 HTTP/TCP 連線。

  • 由東向西閘道：由東向西流量的 Proxy，可讓服務工作負載在不同網路的多主體網格中，跨叢集邊界進行通訊。根據預設，這個閘道會在網際網路上公開。

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

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

部署網關的最佳做法

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

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

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

這些最佳做法：

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

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

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

這些最佳做法：

  • 讓命名空間管理員管理閘道，而無須對整個叢集提升權限。
  • 讓管理員使用與管理 Kubernetes 應用程式相同的部署工具或機制，部署及管理閘道。
  • 讓管理員全面掌控閘道部署作業，並簡化操作流程。當新的升級可用或設定有所變更時，管理員可以重新啟動閘道 Pod 來更新。這樣一來，閘道部署的運作體驗就會與為服務運作附屬 Proxy 相同。

部署範例閘道

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

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

  1. 如果還沒有閘道專屬命名空間，請建立一個。將 GATEWAY_NAMESPACE 替換為命名空間的名稱。

    kubectl create namespace GATEWAY_NAMESPACE

  2. 啟用要用於插入的命名空間。步驟取決於控制層實作。

    代管 (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

    如果您是現有的 Managed 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

  3. 從 anthos-service-mesh 存放區複製範例閘道設定檔。

  4. 將目錄變更為 samples 目錄。為確保您位於正確的目錄中，請執行 ls 指令來列出目錄內容，然後確認是否有 gateways 目錄 (您將在下一個步驟中存取) 和 online-boutique 目錄。

  5. 部署輸入或輸出閘道。這些指令碼位於 samples/gateways/ 目錄，您可以沿用原始設定，或根據需求進行修改。

    Ingress

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

    輸出

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

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

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

如需閘道設定和虛擬服務的範例，請參閱線上精品店範例應用程式中的 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 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

初期測試升級 (進階)

如果您使用叢集內控制層，且想要以較緩慢的速度控管新控制層修訂版本的發布作業，可以遵循 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"

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

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