Istio概念原理&&為什麼要使用 Istio？&&架構圖

使用雲平台可以為組織提供豐富的好處。然而，不可否認的是，采用雲可能會給 DevOps 團隊帶來壓力。開發人員必須使用微服務以滿足應用的可移植性，同時營運商管理了極其龐大的混合和多雲部署。Istio 允許您連接配接、保護、控制和觀測服務。

在較高的層次上，Istio 有助于降低這些部署的複雜性，并減輕開發團隊的壓力。它是一個完全開源的服務網格，可以透明地分層到現有的分布式應用程式上。它也是一個平台，包括允許它內建到任何日志記錄平台、遙測或政策系統的 API。Istio 的多樣化功能集使您能夠成功高效地運作分布式微服務架構，并提供保護、連接配接和監控微服務的統一方法。

Istio 提供一種簡單的方式來為已部署的服務建立網絡，該網絡具有負載均衡、服務間認證、監控等功能，隻需要對服務的代碼進行一點或不需要做任何改動。想要讓服務支援 Istio，隻需要在您的環境中部署一個特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，攔截微服務之間的所有網絡通信：

HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡。

通過豐富的路由規則、重試、故障轉移和故障注入，可以對流量行為進行細粒度控制。

可插入的政策層和配置 API，支援通路控制、速率限制和配額。

對出入叢集入口和出口中所有流量的自動度量名額、日志記錄和追蹤。

通過強大的基于身份的驗證和授權，在叢集中實作安全的服務間通信。

Istio 旨在實作可擴充性，滿足各種部署需求。

核心功能：

Istio 在服務網絡中統一提供了許多關鍵功能：

流量管理

通過簡單的規則配置和流量路由，您可以控制服務之間的流量和 API 調用。Istio 簡化了斷路器、逾時和重試等服務級别屬性的配置，并且可以輕松設定 A/B測試、金絲雀部署和基于百分比的流量分割的分階段部署等重要任務。

通過更好地了解您的流量和開箱即用的故障恢複功能，您可以在問題出現之前先發現問題，使調用更可靠，并且使您的網絡更加強大——無論您面臨什麼條件。

安全

Istio 的安全功能使開發人員可以專注于應用程式級别的安全性。Istio 提供底層安全通信信道，并大規模管理服務通信的認證、授權和加密。使用Istio，服務通信在預設情況下是安全的，它允許您跨多種協定和運作時一緻地實施政策——所有這些都很少或根本不需要應用程式更改。

雖然 Istio 與平台無關，但将其與 Kubernetes（或基礎架構）網絡政策結合使用，其優勢會更大，包括在網絡和應用層保護 pod 間或服務間通信的能力。

可觀察性

Istio 強大的追蹤、監控和日志記錄可讓您深入了解服務網格部署。通過 Istio 的監控功能，可以真正了解服務性能如何影響上遊和下遊的功能，而其自定義儀表闆可以提供對所有服務性能的可視性，并讓您了解該性能如何影響您的其他程序。

Istio 的 Mixer 元件負責政策控制和遙測收集。它提供後端抽象和中介，将 Istio 的其餘部分與各個基礎架構後端的實作細節隔離開來，并為運維提供對網格和基礎架構後端之間所有互動的細粒度控制。

所有這些功能可以讓您可以更有效地設定、監控和實施服務上的 SLO。當然，最重要的是，您可以快速有效地檢測和修複問題。

平台支援

Istio 是獨立于平台的，旨在運作在各種環境中，包括跨雲、内部部署、Kubernetes、Mesos 等。您可以在 Kubernetes 上部署 Istio 或具有 Consul 的 Nomad 上部署。Istio 目前支援：

在 Kubernetes 上部署的服務

使用 Consul 注冊的服務

在虛拟機上部署的服務

內建和定制

政策執行元件可以擴充和定制，以便與現有的 ACL、日志、監控、配額、審計等方案內建。

架構圖：

本頁概述了 Istio 中流量管理的工作原理，包括流量管理原則的優點。本文假設你已經閱讀了 Istio 是什麼？并熟悉 Istio 的頂層設計架構。有關單個流量管理功能的更多資訊，您可以在本節其他指南中了解。

使用 Istio 的流量管理模型，本質上是将流量與基礎設施擴容解耦，讓運維人員可以通過 Pilot 指定流量遵循什麼規則，而不是指定哪些 pod/VM 應該接收流量——Pilot 和智能 Envoy 代理會幫我們搞定。是以，例如，您可以通過 Pilot 指定特定服務的 5％ 流量可以轉到金絲雀版本，而不必考慮金絲雀部署的大小，或根據請求的内容将流量發送到特定版本。

Istio 流量管理

将流量從基礎設施擴充中解耦，這樣就可以讓 Istio 提供各種獨立于應用程式代碼之外的流量管理功能。 除了 A/B 測試的動态請求路由，逐漸推出和金絲雀釋出之外， 它還使用逾時、重試和熔斷器來處理故障恢複， 最後還可以通過故障注入來測試服務之間故障恢複政策的相容性。 這些功能都是通過在服務網格中部署的 Envoy sidecar/代理來實作的。

Pilot 和 Envoy

Istio 流量管理的核心元件是 Pilot，它管理和配置部署在特定 Istio 服務網格中的所有 Envoy 代理執行個體。它允許您指定在 Envoy 代理之間使用什麼樣的路由流量規則，并配置故障恢複功能，如逾時、重試和熔斷器。它還維護了網格中所有服務的規範模型，并使用這個模型通過發現服務讓 Envoy 了解網格中的其他執行個體。

每個 Envoy 執行個體都會維護負載均衡資訊資訊，這些資訊來自 Pilot 以及對負載均衡池中其他執行個體的定期健康檢查。進而允許其在目标執行個體之間智能配置設定流量，同時遵循其指定的路由規則。

Pilot 負責管理通過 Istio 服務網格釋出的 Envoy 執行個體的生命周期。

Pilot 架構

如上圖所示，在網格中 Pilot 維護了一個服務的規則表示并獨立于底層平台。Pilot中的特定于平台的擴充卡負責适當地填充這個規範模型。例如，在 Pilot 中的 Kubernetes 擴充卡實作了必要的控制器，來觀察 Kubernetes API 伺服器，用于更改 pod 的注冊資訊、入口資源以及存儲流量管理規則的第三方資源。這些資料被轉換為規範表示。然後根據規範表示生成特定的 Envoy 的配置。

Pilot 公開了用于服務發現 、負載均衡池和路由表的動态更新的 API。

運維人員可以通過 Pilot 的 Rules API 指定進階流量管理規則。這些規則被翻譯成低級配置，并通過 discovery API 分發到 Envoy 執行個體。

請求路由

如 Pilot 所述，特定網格中服務的規範表示由 Pilot 維護。服務的 Istio 模型和在底層平台（Kubernetes、Mesos 以及 Cloud Foundry 等）中的表達無關。特定平台的擴充卡負責從各自平台中擷取中繼資料的各種字段，然後對服務模型進行填充。

Istio 引入了服務版本的概念，可以通過版本（v1、v2）或環境（staging、prod）對服務進行進一步的細分。這些版本不一定是不同的 API 版本：它們可能是部署在不同環境（prod、staging 或者 dev 等）中的同一服務的不同疊代。使用這種方式的常見場景包括 A/B 測試或金絲雀部署。Istio 的流量路由規則可以根據服務版本來對服務之間流量進行附加控制。

服務之間的通訊

服務版本的處理。

服務版本

如上圖所示，服務的用戶端不知道服務不同版本間的差異。它們可以使用服務的主機名或者 IP 位址繼續通路服務。Envoy sidecar/代理攔截并轉發用戶端和伺服器之間的所有請求和響應。

運維人員使用 Pilot 指定路由規則，Envoy 根據這些規則動态地确定其服務版本的實際選擇。該模型使應用程式代碼能夠将它從其依賴服務的演進中解耦出來，同時提供其他好處（參見 Mixer）。路由規則讓 Envoy 能夠根據諸如 header、與源/目的地相關聯的标簽和/或配置設定給每個版本的權重等标準來進行版本選擇。

Istio 還為同一服務版本的多個執行個體提供流量負載均衡。可以在服務發現和負載均衡中找到更多資訊。

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

Ingress 和 Egress

Istio 假定進入和離開服務網絡的所有流量都會通過 Envoy 代理進行傳輸。通過将 Envoy 代理部署在服務之前，運維人員可以針對面向使用者的服務進行 A/B 測試、部署金絲雀服務等。類似地，通過使用 Envoy 将流量路由到外部 Web 服務（例如，通路 Maps API 或視訊服務 API）的方式，運維人員可以為這些服務添加逾時控制、重試、斷路器等功能，同時還能從服務連接配接中擷取各種細節名額。

通過 Envoy 的 Ingress 和 Egress。

請求流

服務發現和負載均衡

Istio 負載均衡服務網格中執行個體之間的通信。

Istio 假定存在服務系統資料庫，以追蹤應用程式中服務的 pod/VM。它還假設服務的新執行個體自動注冊到服務系統資料庫，并且不健康的執行個體将被自動删除。諸如 Kubernetes、Mesos 等平台已經為基于容器的應用程式提供了這樣的功能。為基于虛拟機的應用程式提供的解決方案就更多了。

Pilot 使用來自服務注冊的資訊，并提供與平台無關的服務發現接口。網格中的 Envoy 執行個體執行服務發現，并相應地動态更新其負載均衡池。

發現與負載均衡

如上圖所示，網格中的服務使用其 DNS 名稱通路彼此。服務的所有 HTTP 流量都會通過 Envoy 自動重新路由。Envoy 在負載均衡池中的執行個體之間分發流量。雖然 Envoy 支援多種複雜的負載均衡算法，但 Istio 目前僅允許三種負載均衡模式：輪詢、随機和帶權重的最少請求。

除了負載均衡外，Envoy 還會定期檢查池中每個執行個體的運作狀況。Envoy 遵循熔斷器風格模式，根據健康檢查 API 調用的失敗率将執行個體分類為不健康和健康兩種。換句話說，當給定執行個體的健康檢查失敗次數超過預定門檻值時，将會被從負載均衡池中彈出。類似地，當通過的健康檢查數超過預定門檻值時，該執行個體将被添加回負載均衡池。您可以在處理故障中了解更多有關 Envoy 的故障處理功能。

服務可以通過使用 HTTP 503 響應健康檢查來主動減輕負擔。在這種情況下，服務執行個體将立即從調用者的負載均衡池中删除。

故障處理

Envoy 提供了一套開箱即用，可選的的故障恢複功能，對應用中的服務大有裨益。這些功能包括：

逾時

具備逾時預算，并能夠在重試之間進行可變抖動（間隔）的有限重試功能

并發連接配接數和上遊服務請求數限制

對負載均衡池中的每個成員主動（定期）運作健康檢查

細粒度熔斷器（被動健康檢查）——适用于負載均衡池中的每個執行個體

這些功能可以使用 Istio 的流量管理規則在運作時進行動态配置。

對超載的上遊服務來說，重試之間的抖動極大的降低了重試造成的影響，而逾時預算確定調用方服務在可預測的時間範圍内獲得響應（成功/失敗）。

主動和被動健康檢查（上述 4 和 5 ）的組合最大限度地減少了在負載均衡池中通路不健康執行個體的機會。當将其與平台級健康檢查（例如由 Kubernetes 或 Mesos 支援的檢查）相結合時， 可以確定應用程式将不健康的 Pod/容器/虛拟機快速地從服務網格中去除，進而最小化請求失敗和延遲産生影響。

總之，這些功能使得服務網格能夠耐受故障節點，并防止本地故障導緻的其他節點的穩定性下降。

微調

Istio 的流量管理規則允許運維人員為每個服務/版本設定故障恢複的全局預設值。然而，服務的消費者也可以通過特殊的 HTTP 頭提供的請求級别值覆寫逾時和重試的預設值。在 Envoy 代理的實作中，對應的 Header 分别是 x-envoy-upstream-rq-timeout-ms 和 x-envoy-max-retries。

FAQ

Q: 在 Istio 中運作的應用程式是否仍需要處理故障？

是的。Istio可以提高網格中服務的可靠性和可用性。但是，應用程式仍然需要處理故障（錯誤）并采取适當的回退操作。例如，當負載均衡池中的所有執行個體都失敗時，Envoy 将傳回 HTTP 503。應用程式有責任實作必要的邏輯，對這種來自上遊服務的 HTTP 503 錯誤做出合适的響應。

Q: 已經使用容錯庫（例如 Hystrix）的應用程式，是否會因為 Envoy 的故障恢複功能受到破壞？

不會。Envoy對應用程式是完全透明的。在進行服務調用時，由 Envoy 傳回的故障響應與上遊服務傳回的故障響應不會被區分開來。

Q: 同時使用應用級庫和 Envoy 時，怎樣處理故障？

假如對同一個目的服務給出兩個故障恢複政策（例如，兩次逾時設定——一個在 Envoy 中設定，另一個在應用程式庫中設定），當故障發生時，将觸發兩者中更嚴格的那個。例如，如果應用程式為服務的 API 調用設定了 5 秒的逾時時間，而運維人員給 Envoy 配置了 10 秒的逾時時間，那麼應用程式的逾時将會首先啟動。同樣，如果 Envoy 的熔斷器在應用熔斷器之前觸發，對該服務的 API 調用将從 Envoy 收到 503 錯誤。

故障注入

雖然 Envoy sidecar/proxy 為在 Istio 上運作的服務提供了大量的故障恢複機制，但測試整個應用程式端到端的故障恢複能力依然是必須的。錯誤配置的故障恢複政策（例如，跨服務調用的不相容/限制性逾時）可能導緻應用程式中的關鍵服務持續不可用，進而破壞使用者體驗。

Istio 能在不殺死 Pod 的情況下，将特定協定的故障注入到網絡中，在 TCP 層制造資料包的延遲或損壞。我們的理由是，無論網絡級别的故障如何，應用層觀察到的故障都是一樣的，并且可以在應用層注入更有意義的故障（例如，HTTP 錯誤代碼），以檢驗和改善應用的彈性。

運維人員可以為符合特定條件的請求配置故障，還可以進一步限制遭受故障的請求的百分比。可以注入兩種類型的故障：延遲和中斷。延遲是計時故障，模拟網絡延遲上升或上遊服務超載的情況。中斷是模拟上遊服務的崩潰故障。中斷通常以 HTTP 錯誤代碼或 TCP 連接配接失敗的形式表現。

規則配置

Istio 提供了一個簡單的配置模型，用來控制 API 調用以及應用部署内多個服務之間的四層通信。運維人員可以使用這個模型來配置服務級别的屬性，這些屬性可以是斷路器、逾時、重試，以及一些普通的持續釋出任務，例如金絲雀釋出、A/B 測試、使用百分比對流量進行控制，進而完成應用的逐漸釋出等。

Istio 中包含有四種流量管理配置資源，分别是 VirtualService、DestinationRule、ServiceEntry 以及 Gateway。下面會講一下這幾個資源的一些重點。在網絡參考中可以獲得更多這方面的資訊。

VirtualService 在 Istio 服務網格中定義路由規則，控制路由如何路由到服務上。

DestinationRule 是 VirtualService 路由生效後，配置應用與請求的政策集。

ServiceEntry 是通常用于在 Istio 服務網格之外啟用對服務的請求。

Gateway 為 HTTP/TCP 流量配置負載均衡器，最常見的是在網格的邊緣的操作，以啟用應用程式的入口流量。

例如，将 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 制定了一個預定義的子集名稱，子集的定義來自于目标規則配置：

子集指定了一個或多個特定版本的執行個體标簽。例如，在 Kubernetes 中部署 Istio 時，“version: v1” 表示隻有包含 “version: v1” 标簽版本的 pod 才會接收流量。

在 DestinationRule 中，你可以添加其他政策，例如：下面的定義指定使用随機負載均衡模式：

kind: DestinationRule

trafficPolicy:

loadBalancer:

simple: RANDOM

subsets:

• name: v1

  labels:

  version: v1

• name: v2

  version: v2

可以使用 kubectl 指令配置規則。在配置請求路由任務中包含有配置示例。

以下部分提供了流量管理配置資源的基本概述。詳細資訊請檢視網絡參考。

Virtual Service

VirtualService 定義了控制在 Istio 服務網格中如何路由服務請求的規則。例如一個 Virtual Service 可以把請求路由到不同版本，甚至是可以路由到一個完全不同于請求要求的服務上去。路由可以用很多條件進行判斷，例如請求的源和目的地、HTTP 路徑和 Header 以及各個服務版本的權重等。

規則的目标描述

路由規則對應着一或多個用 VirtualService 配置指定的請求目的主機。這些主機可以是也可以不是實際的目标負載，甚至可以不是同一網格内可路由的服務。例如要給到 reviews 服務的請求定義路由規則，可以使用内部的名稱 reviews，也可以用域名 bookinfo.com，VirtualService 可以定義這樣的 hosts 字段：

• bookinfo.com

hosts 字段用顯示或者隐式的方式定義了一或多個完全限定名（FQDN）。上面的 reviews，會隐式的擴充成為特定的 FQDN，例如在 Kubernetes 環境中，全名會從 VirtualService 所在的叢集和命名空間中繼承而來（比如說 reviews.default.svc.cluster.local）。

在服務之間分拆流量

每個路由規則都需要對一或多個有權重的後端進行甄别并調用合适的後端。每個後端都對應一個特定版本的目标服務，服務的版本是依靠标簽來區分的。如果一個服務版本包含多個注冊執行個體，那麼會根據為該服務定義的負載均衡政策進行路由，預設政策是 round-robin。

例如下面的規則會把 25% 的 reviews 服務流量配置設定給 v2 标簽；其餘的 75% 流量配置設定給 v1：

• weight: 75

• subset: v2

  weight: 25

逾時和重試

預設情況下，HTTP 請求的逾時設定為 15 秒，可以使用路由規則來覆寫這個限制：

name: ratings

• ratings

• host: ratings

  timeout: 10s

還可以用路由規則來指定某些 http 請求的重試次數。下面的代碼可以用來設定最大重試次數，或者在規定時間内一直重試，時間長度同樣可以進行覆寫：

• retries:

  attempts: 3

  perTryTimeout: 2s

注意請求的重試和逾時還可以針對每個請求分别設定。

請求逾時任務中展示了逾時控制的相關示例。

錯誤注入

在根據路由規則向選中目标轉發 http 請求的時候，可以向其中注入一或多個錯誤。錯誤可以是延遲，也可以是退出。

下面的例子在目标為 ratings:v1 服務的流量中，對其中的 10% 注入 5 秒鐘的延遲。

• fault:

  delay:

  percent: 10

  fixedDelay: 5s

可以使用其他類型的故障，終止、提前終止請求。例如，模拟失敗。

接下來，在目标為 ratings:v1 服務的流量中，對其中的 10% 注入 HTTP 400 錯誤。

• abort:

  httpStatus: 400

有時會把延遲和退出同時使用。例如下面的規則對從 reviews:v2 到 ratings:v1 的流量生效，會讓所有的請求延遲 5 秒鐘，接下來把其中的 10% 退出：

• match:

  • sourceLabels:

    app: reviews

可以參考錯誤注入任務，進行這方面的實際體驗。

條件規則

可以選擇讓規則隻對符合某些要求的請求生效：

1. 使用工作負載 label 限制特定用戶端工作負載。例如，規則可以訓示它僅适用于實作 reviews 服務的工作負載執行個體（pod）的調用：

• ...

sourceLabels 的值取決于服務的實作。例如，在 Kubernetes 中，它可能與相應 Kubernetes 服務的 pod 選擇器中使用的 label 相同。

以上示例還可以進一步細化為僅适用于 reviews 服務版本 v2 負載均衡執行個體的調用：

1. 根據 HTTP Header 選擇規則。下面的規則隻會對包含了 end-user 标頭的來源請求，且值為 jason 的請求生效：

• headers:

  end-user:

  exact: jason

如果規則中指定了多個标頭，則所有相應的标頭必須比對才能應用規則。

1. 根據請求URI選擇規則。例如，如果 URI 路徑以 /api/v1 開頭，則以下規則僅适用于請求：

name: productpage

• productpage

• uri:

  prefix: /api/v1

多重比對條件

可以同時設定多個比對條件。在這種情況下，根據嵌套，應用 AND 或 OR 語義。

如果多個條件嵌套在單個比對子句中，則條件為 AND。例如，以下規則僅适用于用戶端工作負載為 reviews:v2 且請求中包含 jason 的自定義 end-user 标頭：

相反，如果條件出現在單獨的比對子句中，則隻應用其中一個條件（OR 語義）：

如果用戶端工作負載是 reviews:v2，或者請求中包含 jason 的自定義 end-user 标頭，則适用此規則。

優先級

當對同一目标有多個規則時，會按照在 VirtualService 中的順序進行應用，換句話說，清單中的第一條規則具有最高優先級。

為什麼優先級很重要：當對某個服務的路由是完全基于權重的時候，就可以在單一規則中完成。另一方面，如果有多重條件（例如來自特定使用者的請求）用來進行路由，就會需要不止一條規則。這樣就出現了優先級問題，需要通過優先級來保證根據正确的順序來執行規則。

常見的路由模式是提供一或多個高優先級規則，這些優先規則使用源服務以及 Header 來進行路由判斷，然後才提供一條單獨的基于權重的規則，這些低優先級規則不設定比對規則，僅根據權重對所有剩餘流量進行分流。

例如下面的 VirtualService 包含了兩個規則，所有對 reviews 服務發起的請求，如果 Header 包含 Foo=bar，就會被路由到 v2 執行個體，而其他請求則會發送給 v1 ：

• • Foo:

    exact: bar

注意，基于 Header 的規則具有更高優先級。如果降低它的優先級，那麼這一規則就無法生效了，這是因為那些沒有限制的權重規則會首先被執行，也就是說所有請求即使包含了符合條件的 Foo 頭，也都會被路由到 v1。流量特征被判斷為符合一條規則的條件的時候，就會結束規則的選擇過程，這就是在存在多條規則時，需要慎重考慮優先級問題的原因。

目标規則

在請求被 VirtualService 路由之後，DestinationRule 配置的一系列政策就生效了。這些政策由服務屬主編寫，包含斷路器、負載均衡以及 TLS 等的配置内容。

DestinationRule 還定義了對應目标主機的可路由 subset（例如有命名的版本）。VirtualService 在向特定服務版本發送請求時會用到這些子集。

下面是 reviews 服務的 DestinationRule 配置政策以及子集：

• simple: ROUND_ROBIN

• name: v3

  version: v3

注意在單個 DestinationRule 配置中可以包含多條政策（比如 default 和 v2）。

斷路器

可以用一系列的标準，例如連接配接數和請求數限制來定義簡單的斷路器。

例如下面的 DestinationRule 給 reviews 服務的 v1 版本設定了 100 連接配接的限制：

• connectionPool:

  tcp:

  maxConnections: 100

檢視斷路器示範請檢視 斷路器任務

規則評估

和路由規則類似，DestinationRule 中定義的政策也是和特定的 host 相關聯的，如果指定了 subset，那麼具體生效的 subset 的決策是由路由規則來決定的。

規則評估的第一步，是确認 VirtualService 中所請求的主機相對應的路由規則（如果有的話），這一步驟決定了将請求發往目标服務的哪一個 subset（就是特定版本）。下一步，被選中的 subset 如果定義了政策，就會開始是否生效的評估。

注意：這一算法需要留心是，為特定 subset 定義的政策，隻有在該 subset 被顯式的路由時候才能生效。例如下面的配置，隻為 review 服務定義了規則（沒有對應的 VirtualService 路由規則）。

既然沒有為 reviews 服務定義路由規則，那麼就會使用預設的 round-robin 政策，偶爾會請求到 v1 執行個體，如果隻有一個 v1 執行個體，那麼所有請求都會發送給它。然而上面的政策是永遠不會生效的，這是因為，預設路由是在更底層完成的任務，政策引擎無法獲知最終目的，也無法為請求選擇比對的 subset 政策。

有兩種方法來解決這個問題。可以把路由政策提高一級，要求他對所有版本生效：

還有一個更好的方法，就是為服務定義路由規則，例如給 reviews:v1 加入一個簡單的路由規則：

雖然 Istio 在沒有定義任何規則的情況下，能将所有來源的流量發送給所有版本的目标服務。然而一旦需要對版本有所差別，就需要制定規則了。從一開始就給每個服務設定預設規則，是 Istio 世界裡推薦的最佳實踐。

Service Entry

Istio 内部會維護一個服務系統資料庫，可以用 ServiceEntry 向其中加入額外的條目。通常這個對象用來啟用對 Istio 服務網格之外的服務送出請求。例如下面的 ServiceEntry 可以用來允許外部對 *.foo.com 域名上的服務主機的調用。

kind: ServiceEntry

name: foo-ext-svc

• *.foo.com

  ports:

• number: 80

  name: http

  protocol: HTTP

• number: 443

  name: https

  protocol: HTTPS

ServiceEntry 中使用 hosts 字段來指定目标，字段值可以是一個完全限定名，也可以是個通配符域名。其中包含的白名單，包含一或多個允許網格中服務通路的服務。

ServiceEntry 的配置不僅限于外部服務，它有兩種類型：網格内部和網格外部。網格内的條目和其他的内部服務類似，用于顯式的将服務加入網格。可以用來把服務作為服務網格擴充的一部分加入不受管理的基礎設定（例如加入到基于 Kubernetes 的服務網格中的虛拟機）中。網格外的條目用于表達網格外的服務。對這種條目來說，雙向 TLS 認證被禁用，政策實作需要在用戶端執行，而不像内部服務請求那樣在服務端執行。

隻要 ServiceEntry 涉及到了比對 hosts 的服務，就可以和 VirtualService 以及 DestinationRule 配合工作。例如下面的規則可以和上面的 ServiceEntry 同時使用，在通路 bar.foo.com 的外部服務時，設定一個 10 秒鐘的逾時。

name: bar-foo-ext-svc

• bar.foo.com
• host: bar.foo.com

流量的重定向和轉發、定義重試和逾時以及錯誤注入政策都支援外部目标。然而由于外部服務沒有多版本的概念，是以權重（基于版本）路由就無法實作了。

參照 egress 任務可以了解更多的通路外部服務方面的知識。

Gateway

Gateway 為 HTTP/TCP 流量配置了一個負載均衡，多數情況下在網格邊緣進行操作，用于啟用一個服務的入口（ingress）流量。

和 Kubernetes Ingress 不同，Istio Gateway 隻配置四層到六層的功能（例如開放端口或者 TLS 配置）。綁定一個 VirtualService 到 Gateway 上，使用者就可以使用标準的 Istio 規則來控制進入的 HTTP 和 TCP 流量。

例如下面提供一個簡單的 Gateway 代碼，配合一個負載均衡，允許外部針對主機 bookinfo.com 的 https 流量：

• port:

  • tls:

    mode: SIMPLE

    serverCertificate: /tmp/tls.crt

    privateKey: /tmp/tls.key

• gateways:
  • bookinfo-gateway # <---- 綁定到 Gateway
• prefix: /reviews