Istio 流量管理

阿新 • • 發佈：2019-01-24

綜述

本頁面概述了Istio中流量管理的工作原理，包括流量管理原則的優點。我們假定你已經閱讀了什麼是Istio？並熟悉Istio的高層架構。您可以在本節的其他指南中找到有關流量管理功能的更多資訊。

Pilot 和Envoy

Istio中流量管理的核心元件是Pilot，它管理和配置部署在Istio服務網格中的所有Envoy代理例項。它允許你指定要使用哪些規則在Envoy代理之間路由流量，並配置故障恢復功能，例如超時，重試和斷路器。它還維護網格中所有服務的規範模型，並使用它來讓Envoys 通過其服務發現瞭解網格中的其他例項。

每個Envoy例項根據從Pilot獲取的資訊和其負載平衡池中其他例項的定期執行狀況檢查獲取的資訊來維護負載平衡資訊，從而使其能夠在遵循其指定的路由規則的情況下智慧分配目標例項之間的流量。

流量管理的好處

使用Istio的流量管理模型基本上將交通流量和基礎設施擴充套件分離，讓運維通過Pilot為流量配置規則，而不是哪些特定的Pod/VM應該接收流量 - Pilot和智慧Envoy代理負責監督其餘流量。因此，例如，你可以通過Pilot指定您希望特定服務的5％流量轉換為金絲雀版本，而不用考慮金絲雀版本的大小，或根據請求內容將流量傳送到特定版本。

Traffic Management with Istio

將流量從基礎架構中分離出來，使Istio能夠提供各種流量管理功能，而且這些功能與應用程式碼分離。除了A/B測試，滾動部署和金絲雀釋出之外，它還使用超時、重試和斷路器處理故障恢復，以及故障注入，以測試跨服務的故障恢復策略的相容性。這些功能都是通過在服務網格中部署的Envoy sidecars/proxy 實現的。

Pilot

Pilot負責整個Istio服務網格中部署的Envoy例項的生命週期。

Pilot Architecture

如上圖所示，Pilot維護一個獨立於底層平臺的服務網格，所有的服務都通過Envoy 加入服務風格中。Pilot中的Platform Adapter 負責適當地填充此規範模型。例如，Pilot中的Kubernetes介面卡實現必要的controllers，以觀察Kubernetes API server以更改pod註冊資訊、ingress 資源和儲存流量管理規則的第三方資源。這些資料被翻譯成規範的表示。Envoy的配置是基於規範表（canonical representation）示生成的。

Pilot公開了用於

服務發現的API，可動態更新負載平衡池和路由表。這些API將Envoy與平臺特定的細微差別分離開來，簡化了設計並提高了跨平臺的可移植性。

運維可以通過Pilot的規則API指定高階流量管理規則。這些規則被轉換成低階（low-level）配置並通過discovery API分發給Envoy例項。

Request Routing（請求路由）

本節描述如何在Istio服務網格中的服務之間路由請求。

服務模型和服務版本

如Pilot所述，服務網格中服務的規範表示是由Pilot維護的。服務的Istio模型與其在底層平臺（Kubernetes，Mesos，Cloud Foundry等）中的表現方式無關。平臺相關的介面卡負責使用平臺中的元資料填充Istio內部模型。

Istio引入了服務版本的概念，該版本是按版本(v1, v2)或環境(staging, prod)細分服務例項的更細化的方式。這些變體不一定是不同的API版本：它們可能是對同一服務的迭代更改，部署在不同的環境中（prod，staging，dev等）。常用的場景包括A/B測試或金絲雀釋出。 Istio的流量路由規則可以指服務版本，以提供對服務之間流量的額外控制。

服務之間的通訊

Showing how service versions are handled.

如上圖所示，client不知道服務的不同版本。他們可以繼續使用服務的主機名/IP地址訪問服務。 Envoy sidecar/proxy 攔截並轉發client和服務之間的所有請求/響應。

Envoy 根據運運維人員使用Pilot指定的路由規則動態確定其實際服務版本。該模型使應用程式程式碼能夠將其自身從其相關服務的演變中分離出來，同時還提供其他好處（請參Mixer）。路由規則允許Envoy根據標準選擇版本，例如headers，與source/destination關聯的標籤，分配給每個版本的權重。

Istio還為流量提供相同服務版本的多個例項的負載平衡。您可以在Discovery和Load-Balancing中找到更多關於此的資訊。

Istio不提供DNS。應用程式可以嘗試使用底層平臺中存在的DNS服務（kube-dns，mesos-dns等）來解析FQDN。

Ingress 和 egress

Istio假設進入和離開服務網格的所有流量都通過Envoy代理。通過在服務前面部署Envoy代理，運維人員可以進行A/B測試，金絲雀部署服務等，以用於面向使用者的服務。同樣，運維人員可以通過sidecar Envoy將流量路由到外部Web服務（例如，訪問Maps API或視訊服務API），從而增加故障恢復功能，例如超時，重試，斷路器等，並獲取詳細資訊有關這些服務連線的度量標準。

Ingress and Egress through Envoy.

服務發現和負載均衡

本節介紹Istio如何負載均衡服務網格中服務例項間的流量。

服務註冊：Istio假設存在一個服務註冊中心，以跟蹤應用程式中服務的Pod/VM。它還假設新的服務例項會自動註冊到服務註冊中心，不健康的例項會被自動刪除。Kubernetes，Mesos等平臺已經為基於容器的應用程式提供了這樣的功能。基於VM的應用程式存在過多的解決方案。

服務發現：Pilot 使用來自服務註冊中心的資訊並提供與平臺無關的服務發現介面。Mesh中的Envoy例項執行服務發現並相應地動態更新其負載均衡池。

Discovery and Load Balancing

如上圖所示，網格中的服務使用其DNS名稱相互訪問。繫結到服務的所有HTTP流量都會通過Envoy自動重新路由。 Envoy 在負載均衡池中的例項之間分配流量。雖然Envoy支援多種複雜的負載均衡演算法，但Istio目前允許三種負載均衡模式：輪詢，隨機和權重最小請求。

除了負載平衡之外，Envoy還會定期檢查負載均衡池中每個例項的健康狀況。Envoy遵循斷路器配置模式，根據健康檢查API呼叫的故障率將例項歸類為健康或不健康。換句話說，當給定例項的狀況檢查失敗次數超過預先指定的閾值時，它將從負載均衡池中移除。類似地，當執行狀況檢查數超過預先指定的健康閾值時，例項將被添加回負載均衡池。你可以在處理故障中找到有關Envoy故障處理功能的更多資訊。

服務可以通過HTTP 503響應健康檢查來積極減輕負載。在這種情況下，服務例項將立即從呼叫者的負載平衡池中移除。

故障處理

Envoy提供了一套開箱即用的插拔式故障恢復功能，可以在應用程式中利用這些功能。功能包括：

超時
根據超時時間和重試次數、間隔等配置進行重試
併發連線數和對上游服務的請求限制
對負載均衡池的每個成員進行主動（定期）健康檢查
針對負載平衡池中針對每個例項應用的細粒度斷路器（被動健康檢查）

這些功能可以在執行時通過Istio的流量管理規則進行動態配置。

重試之間的抖動使重試對超負載的上游服務的影響最小，而超時設定可確保呼叫服務在可預測的時間範圍內獲得響應（成功/失敗）。

主動和被動健康檢查（上述4和5）的組合可最大限度地減少訪問負載均衡池中不健康例項的機會。與平臺級健康檢查（如Kubernetes或Mesos支援的那些）結合使用時，應用程式可以確保不健康的pods/容器/虛擬機器可以快速服務網格中清除，從而最大限度地減少請求失敗並減少對延遲的影響。

這些功能一起使服務網格能夠容忍失敗的nodes ，並防止由於級聯不穩定而導致本地故障影響到其他nodes。

微調

Istio的流量管理規則允許運維為每個服務/版本的故障恢復設定全域性預設值。但是，服務的使用者也可以通過特殊的HTTP頭提供請求級覆蓋來覆蓋超時和重試預設值。通過Envoy代理實現，標頭檔案分別是 x-envoy-upstream-rq-timeout-ms 和 x-envoy-max-retries。

FAQ

Q: 在Istio中執行時，應用程式是否還能處理失敗？

可以。 Istio提高了網格中服務的可靠性和可用性。但是，應用程式需要處理失敗（錯誤）並採取適當的後備（fallback）操作。例如，當負載平衡池中的所有例項都失敗時，Envoy將返回HTTP 503.應用程式負責處理來自上游服務的HTTP 503錯誤。

Q: Envoy的故障恢復功能是否會中斷已使用容錯庫（例如Hystrix）的應用程式？

不會。Envoy 對應用是完全透明的。由Envoy返回的失敗響應與由進行呼叫的上游服務返回的失敗響應無法區分。

Q: 在同時使用應用程式級類庫和Envoy時如何處理失敗？

給同一個服務的兩個故障恢復策略（例如，兩個超時 - 一個設定在Envoy中，另一個設定在應用程式的庫中），當故障發生時，兩個限制中較強的將會被觸發。例如，如果應用程式為服務的API呼叫設定5秒的超時，而操作員配置了10秒的超時，則應用程式的超時將首先啟動。同樣，如果Envoy的斷路器在應用程式的斷路器之前觸發，API呼叫服務將從Envoy獲得503。

故障注入

雖然Envoy sidecar/proxy為執行在Istio上的服務提供了大量故障恢復機制，但仍然有必要測試整個應用程式的端到端故障恢復能力。錯誤配置的故障恢復策略（例如，跨服務呼叫的不相容/限制性超時）可能導致應用程式中關鍵服務持續不可用，從而導致使用者體驗不佳。

Istio支援將指定協議的故障注入到網路中，而不是殺死Pod，延遲或破壞TCP層的資料包。我們的基本原理是，無論網路級別失敗，應用層觀察到的失敗都是相同的，並且可以在應用層注入更有意義的失敗（例如，HTTP錯誤程式碼）以增加應用程式的彈性。

運維人員可以配置故障注入到符合特定標準的請求中。運維可以進一步限制應該發生故障的請求的百分比。可以注入兩種型別的故障：延遲和中止。延遲是定時失敗，模仿網路延遲增加或上游服務超負荷。中止是模仿上游服務故障的崩潰故障。中止通常以HTTP錯誤程式碼或TCP連線失敗的形式出現。

規則配置

Istio提供了一個簡單的配置模型來控制API呼叫和第4層流量如何在應用程式中的各種服務之間流動。配置模型允許運維配置服務級屬性，如斷路器，超時，重試，以及設定常見的持續部署任務，如金絲雀部署，A/B測試，基於百分比流量的分階段釋出等。

例如，可以使用以下配置將reviews服務的傳入流量的100％傳送到版本“v1”：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

該配置表示傳送到reviews服務（在hosts 欄位中指定）的流量應該路由到reviews服務例項的v1子集中。路由subset 在相應的目標規則配置中指定定義的子集的名稱：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

subset 指定一個或多個標識版本例項的標籤。例如，在Istio的Kubernetes部署中，“version：v1”表示只有包含“version：v1”標籤的pod才會接收流量。

可以使用istioctl CLI配置規則，也可以使用kubectl命令在Kubernetes deployment 中配置規則，但只有istioctl 會驗證配置是否正確，我們建議使用istioctl 。有關示例，請參閱配置請求路由任務。

Istio中有四種流量管理配置資源：VirtualService，DestinationRule，ServiceEntry和Gateway。下面介紹使用這些資源的一些重要方面。詳細資訊請參閱參考。

Virtual Services

VirtualService定義了控制服務請求如何在Istio服務網格中路由的規則。例如，virtual service可以將請求路由到不同版本的服務，或者實際上可以將請求路由到完全不同的服務。請求可以根據請求源和目標、HTTP路徑和header 欄位以及與各個服務版本相關的權重進行路由。

Rule destinations

路由規則對應於VirtualService配置中指定的一個或多個請求目標hosts。這些hosts可能與實際的目標工作負載相同也可能不同，甚至可能沒有對應網格中的實際可路由服務。例如，要使用其內部網格名稱reviews 或通過hostbookinfo.com為請求評論服務定義路由規則，VirtualService可以有一個hosts欄位，如下所示：

hosts:
  - reviews
  - bookinfo.com

hosts欄位隱式或顯式指定一個或多個全限定域名（FQDN）。上面的短名稱reviews將隱式擴充套件為FQDN。例如，在Kubernetes環境中，reviews完整的域名為來自VirtualSevice的叢集和名稱空間（例如，reviews.default.svc.cluster.local）。

通過source/headers 來限定規則

Rules 可以選擇性地限定為僅適用於匹配某些特定條件的請求，例如以下條件：

限制為特定呼叫者。例如，Rules 可以指定ratings僅適用於來自reviews 服務（pods）的的呼叫。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
      sourceLabels:
        app: reviews
    ...

sourceLabels 的值取決於service的實現。例如，在Kubernetes中，它可能與相應Kubernetes 中pod選擇器中使用的標籤相同。

限制為特定版本的呼叫者。例如，以下規則將之前示例限定為僅允許reviews 服務“v2”版本的呼叫。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    ...

根據HTTP headers選擇規則。例如，以下規則僅適用於包含字串“user = jason”的“cookie”頭的請求。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
    ...

如果配置了多個header，則必須所有的header全部匹配才可以。

可以同時設定多個標準。在這種情況下，根據巢狀情況，使用AND或OR語義。如果多個條件巢狀在單個匹配子句中，則條件為ANDed。例如，以下規則僅適用於請求的來源為“reviews:v2”且包含“user = jason”的“cookie”的情況。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
      headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
    ...

相反，如果條件顯示在單獨的匹配條件中，則有一個匹配即可（OR語義）：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    - headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
    ...

在服務版本之間拆分流量

每條路由規則標識一個或多個加權後端，以便在規則啟用時進行呼叫。每個後端對應於目標服務的特定版本，其中版本可以使用標籤表示。如果多個已註冊例項有相同的標籤，則根據配置的負載平衡策略進行路由，預設為迴圈。

例如，以下規則將reviews 服務的25％流量路由到具有“v2”標籤的例項，剩餘流量（即75％）路由到“v1”。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

超時和重試

預設情況下，http請求的超時時間為15秒，但是這可以在路由規則中配置，如下所示：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s

也可以在路由規則中配置http請求的重試次數。在超時期限內，最大嘗試次數或儘可能多的嘗試次數可以設定如下：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

請注意，請求超時和重試也可以基於每個請求進行配置。

請參閱請求超時任務以瞭解超時控制的示例。

注入請求路徑中的錯誤

路由規則可以指定一個或多個故障注入（人為製造故障），同時將http請求轉發到規則的相應請求目標。故障可以是延遲或中止。

以下示例將向微服務ratings “v1”版本的10％請求中引入5秒延遲。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percent: 10
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

另一種型別的故障，中止，可用於模擬請求中斷故障。

以下示例會將ratings 服務“v1”版本10％請求的HTTP請求返回 400錯誤程式碼。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1

有時延遲和中止故障一起使用。例如，以下規則將從reviews 服務“v2”到評ratings 服務“v1”的所有請求延遲5秒，然後中止10％：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    fault:
      delay:
        fixedDelay: 5s
      abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1

要檢視故障注入的實際情況，請參閱故障注入任務。

HTTP路由規則優先順序

當給定destination有多個規則時，它們按照它們在VirtualService中出現的順序進行評估，即列表中的第一個規則具有最高優先順序。

為什麼優先順序重要？ 如果服務的路由規則純粹是基於權重的時候，就可以在單個規則中配置它。但是，當使用其他標準（例如，來自特定使用者的請求）來路由流量時，需要多個規則來配置路由。這裡必須仔細考慮規則優先順序，以確保以正確的順序執行規則。

通用路由規範的一種常見模式是提供一個或多個優先順序更高的規則，以便通過source/headers來限定規則，然後提供一個沒有匹配條件的單個基於權重的規則，最後為所有其他情況提供流量的加權分配。

例如，以下VirtualService包含2個規則，這些規則一起指定包含名為“Foo”且值為“bar”的header的reviews服務的所有請求都將傳送到“v2”例項。所有其餘的請求將被髮送到“v1”。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        Foo:
          exact: bar
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

請注意，這裡配置中基於header的規則具有更高的優先順序。如果它較低，這些規則將不會如預期的那樣工作，因為基於權重的規則（沒有特定的匹配標準）將首先被評估，然後將所有流量簡單地路由到“v1”，甚至包括匹配的“Foo “頭。一旦找到適用於傳入請求的規則，它將被執行並且規則評估過程將終止。這就是為什麼當存在多個規則時仔細考慮每個規則的優先順序是非常重要的。

Destination Rules

DestinationRule配置在虛擬服務路由發生後，應用於請求的一組策略。它們由服務所有者去配置定義，描述斷路器，負載平衡器設定，TLS設定等。

DestinationRule還定義相應目的地主機的可定址子集（即，版本名）。在將流量傳送到特定版本的服務時，這些子集用於VirtualService路由規範。

以下DestinationRule 配置reviews 服務的策略和subsets ：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

請注意，可以在單個DestinationRule配置中指定多個策略（例如，預設和v2）。

斷路器

可以根據許多標準（例如連線和請求限制）設定簡單的斷路器。

例如，以下DestinationRule設定了與reviews 服務版本“v1”後端限制100個連線。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

檢視斷路器控制的斷路任務演示。

DestinationRule evaluation

與路由規則類似，策略與特定host相關聯，但是如果它們配置了子集，則啟用哪個取決於路由規則評估結果。

規則評估過程中的第一步評估與所請求的主機相對應的VirtualService中的路由規則（如果定義了），以確定當前請求將被路由到的目的地服務的subset （即，特定版本）。接下來，評估與所選子集相對應的一組策略，以確定它們是否適用。

注意：要牢記演算法的一個細微之處在於，只有在相應的子集被明確路由到時才會應用為特定子集定義的策略。例如，考慮以下配置，作為為評論服務定義的唯一規則（即相應虛擬服務中沒有路由規則）。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

由於沒有為reviews 服務定義特定的路由規則，因此將應用預設的迴圈路由行為，有時可能會呼叫“v1”例項，如果“v1”是唯一正在執行的版本，甚至可能始終會呼叫“v1”例項。不過，由於預設路由是在較低級別完成的，因此不會呼叫上述策略。規則評估引擎將不知道最終目標，因此無法將子集策略與請求匹配。

你可以通過以下兩種方式之一修復上述示例。你可以將流量策略向上移動一個級別以適用於任何版本：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
  subsets:
  - name: v1
    labels:
      version: v1

或者更好的是，為服務定義合適的路由規則。例如，您可以為“reviews:v1”新增簡單的路由規則。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

雖然預設的Istio行為可以不設定任何規則就方便地將流量從任何源傳送到目標服務的所有版本，但只要需要版本區分，就需要規則。因此，最佳做法是從一開始就為每項服務設定預設規則。

Service Entries

ServiceEntry用於將其他條目新增到Istio內部維護的服務登錄檔中。它最常用於啟用Istio服務網格外服務的請求。例如，以下ServiceEntry可用於允許對* .foo.com域名下託管的服務進行外部呼叫。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: foo-ext-svc
spec:
  hosts:
  - *.foo.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: https
    protocol: HTTPS

ServiceEntry的目標是使用hosts欄位指定的，該欄位可以是完全限定的域名或萬用字元域名。它表示允許服務網格中的服務訪問的一個或多個服務的白名單中。

ServiceEntry不限於外部服務配置，它可以有兩種型別：網格內部或網格外部。網格內部條目與所有其他內部服務一樣，但用於向網格顯式新增服務。它們可用於新增服務，作為擴充套件服務網格以包含非託管基礎架構（例如，新增到基於Kubernetes的服務網格的VM）的一部分。網格外部條目代表網格外部的服務。對於他們來說，mTLS身份驗證被禁用，並且在客戶端執行策略實施，而不是在通常的伺服器端執行內部服務請求。

只要服務條目使用匹配的hosts引用服務，服務條目就可以與虛擬服務和目標規則配合使用。例如，可以將以下規則與上述ServiceEntry規則結合使用，以便在bar.foo.com上為外部服務的呼叫設定10秒超時。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bar-foo-ext-svc
spec:
  hosts:
    - bar.foo.com
  http:
  - route:
    - destination:
        host: bar.foo.com
    timeout: 10s

規則重定向和轉發流量，定義重試，超時和故障注入策略都支援外部地址。然而，加權（基於版本）路由是不可以的，因為沒有多個外部服務版本的概念。

檢視出口任務以獲取更多關於訪問外部服務的資訊。

Gateways

閘道器為HTTP/TCP流量配置負載均衡器，通常在服務網格的邊緣執行，以便為應用程式啟用入口流量。

與Kubernetes Ingress不同，Istio Gateway僅配置網路中L4-L6層的功能（例如，要暴露的埠，TLS配置）。然後，使用者可以使用標準的Istio規則來控制HTTP請求，以及通過繫結VirtualService來控制進入閘道器的TCP流量。

例如，以下閘道器配置負載均衡器，以允許主機bookinfo.com的外部https流量進入網格：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - bookinfo.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

要配置相應的路由，必須為同一個主機定義一個VirtualService，並使用配置中的gateways 欄位繫結到閘道器：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - bookinfo.com
  gateways:
  - bookinfo-gateway # <---- bind to gateway
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    ...

有關完整的入口閘道器示例，請參閱ingress任務。

雖然主要用於管理入口流量，但也可以使用閘道器對純粹的內部或出口代理進行建模。無論內部或外部網路，所有閘道器都可以用相同的方式進行配置和控制。有關詳細資訊，請參閱閘道器參考。