Istio的流量管理
Istio流量管理的核心組件是Pilot，它管理和配置部署在特定Istio服務網格中的所有Envoy代理實例。它允許您指定在Envoy代理之間使用什麼樣的路由流量規則，並配置故障恢復功能，如超時，重試和熔斷器。它還維護了網格中所有服務的規範模型，並使用這個模型，來通過發現服務讓Envoy瞭解網格中的其他實例。每個Envoy實例維護負載均衡信息，負載均衡信息是基於從Pilot獲得的信息，以及其負載均衡池中的其他實例的定期健康檢查。從而允許其在目標實例之間智能分配流量，同時遵循其指定的路由規則。
流量管理的好處：使用Istio的流量管理模型，本質上解耦流量和基礎設施擴展，讓運維人員通過Pilot指定他們希望流量遵循什麼規則，而不是哪些特定的pod/VM應該接收流量 - Pilot和智能Envoy代理搞定其餘的。因此，例如，您可以通過Pilot指定您希望特定服務的5％流量可以轉到金絲雀版本，而不考慮金絲雀部署的大小，或根據請求的內容將流量發送到特定版本。Pilot負責在Isti服務網格中部署的Envoy實例的生命週期。下圖是pilot架構：
Pilot維護了網格中的服務的規範表示，這個表示是獨立於底層平臺的。Pilot中的平臺特定適配器負責適當填充此規範模型。例如，Pilot中的Kubernetes適配器實現必要的控制器來查看Kubernetes API服務器，以得到pod註冊信息的更改，入口資源以及存儲流量管理規則的第三方資源。該數據被翻譯成規範表示。Envoy特定配置是基於規範表示生成的。Pilot公開了用於服務發現 、負載均衡池和路由表的動態更新的 API。這些API將Envoy從平臺特有的細微差別中解脫出來，簡化了設計並提升了跨平臺的可移植性。運維人員可以通過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根據這些規則動態地確定其服務版本的實際選擇。該模型使應用程序代碼能夠將它從其依賴服務的演進中解耦出來，路由規則允許Envoy根據諸如header，與源/目的地相關聯的標籤和/或分配給每個版本的權重的標準來選擇版本。Istio還爲同一服務版本的多個實例提供流量負載均衡。可以在服務發現和負載均衡中找到更多信息。Istio不提供DNS。應用程序可以嘗試使用底層平臺（kube-dns，mesos-dns等）中存在的DNS服務來解析FQDN。
虛擬服務和路由規則：Virtual Service讓您配置如何在服務網格內將請求路由到服務，這基於 Istio 和平臺提供的基本的連通性和服務發現能力。每個虛擬服務包含一組路由規則，Istio 按順序評估它們，Istio 將每個給定的請求匹配到虛擬服務指定的實際目標地址。通過對客戶端請求的目標地址與真實響應請求的目標工作負載進行解耦來實現。虛擬服務同時提供了豐富的方式，爲發送至這些工作負載的流量指定不同的路由規則。如果沒有虛擬服務，Envoy 會在所有的服務實例中使用輪詢的負載均衡策略分發請求。使用虛擬服務，您可以爲一個或多個主機名指定流量行爲。在虛擬服務中使用路由規則，告訴 Envoy 如何發送虛擬服務的流量到適當的目標。路由目標地址可以是同一服務的不同版本，也可以是完全不同的服務。整體來說就是作用，1）通過單個虛擬服務處理多個應用程序服務，可以配置一個虛擬服務處理特定命名空間中的所有服務。2）和網關整合並配置流量規則來控制出入流量。以示例解讀具體參數：
apiVersion: networking.istio.io/v1alpha3 hosts字段列舉虛擬服務的主機—即用戶指定的目標或
kind: VirtualService 是路由規則設定的目標。這是客戶端向服務發送請求時
metadata: 使用的一個或多個地址，值可以是IP地址、DNS名稱等
name: reviews 可以用通配符(“*”)前綴，創建一組匹配所有服務的路
spec: 由規則在http字段包含了虛擬服務的路由規則，用來描
hosts: 述匹配條 件和路由行爲，把不同協議流量發送到hosts字
- reviews 段指定的目 一個路由規則包含了指定的請求要流向哪個
http: 目標地址，具有0或多個匹配條件，取決於使用場景
- match: destination字段指定了符合此條件的流量的實際目標地
- headers: 址destination的host要是存在於Istio服務註冊中心的實
end-user: 址。destination的Envoy不知該將請求發送到哪裏。可
route: 以是一個有代理的服務網格，或者是一個通過服務入口
- destination: 被添加進來的非網格服務路由規則按從上到下的順序選
host: reviews 擇，虛擬服務中定義的第一條規則有最高優先級。本示
subset: v2 例中不滿足第一個路由規則的流量均流向一個默認的目
- route: 標該目標在第二條規則中指定。因此，第二條規則沒有
- destination: match 條件直接將流量導向v3子集。路由規則是將特定
host: reviews 流量子集路由到指定目標地址的強大工具。可以在流量
subset: v3 端口、header 字段、URI 等內容上設置匹配條件
目標規則：可以將虛擬服務視爲將流量如何路由到給定目標地址，然後使用目標規則來配置該目標的流量。在評估虛擬服務路由規則之後，目標規則將應用於流量的“真實”目標地址。可以將虛擬服務視爲將流量如何路由到給定目標地址，然後使用目標規則來配置該目標的流量。在評估虛擬服務路由規則之後，目標規則將應用於流量的“真實”目標地址。默認情況下，Istio 使用輪詢的負載均衡策略，實例池中的每個實例依次獲取請求。Istio 同時支持如下的負載均衡模型，可以在 DestinationRule 中爲流向某個特定服務或服務子集的流量指定這些模型。三種常用算法：1）隨機：請求以隨機的方式轉到池中的實例。2）權重：請求根據指定的百分比轉到實例。3）最少請求：請求被轉到最少被訪問的實例。
網關：Ingress和Egress。使用網關爲網格來管理入站和出站流量，可以指定要進入或離開網格的流量。網關配置被用於運行在網格邊界的獨立 Envoy 代理，而不是服務工作負載的 sidecar 代理。Istio假定進入和離開服務網絡的所有流量都會通過Envoy代理進行傳輸。通過將Envoy代理部署在服務之前，運維人員可以針對面向用戶的服務進行A/B測試，部署金絲雀服務等。類似地，通過使用Envoy將流量路由到外部Web服務（例如，訪問Maps API或視頻服務API），運維人員可以添加故障恢復功能，例如超時，重試，熔斷器等，並在訪問這些服務的連接上獲得詳細指標。
處理故障：Envoy提供了一套開箱即用, 選擇加入的故障恢復功能，可以在應用程序中受益。功能包括：
1. 超時：超時是 Envoy 代理等待來自給定服務的答覆的時間量，以確保服務不會因爲等待答覆而無限期的掛起，並在可預測的時間範圍內調用成功或失敗。HTTP 請求的默認超時時間是 15 秒，這意味着如果服務在 15 秒內沒有響應，調用將失敗。
2. 帶超時預算有限重試和重試之間的可變抖動：重試設置指定如果初始調用失敗，Envoy 代理嘗試連接服務的最大次數。通過確保調用不會因爲臨時過載的服務或網絡等問題而永久失敗，重試可以提高服務可用性和應用程序的性能。重試之間的間隔（25ms+）是可變的，並由 Istio 自動確定，從而防止被調用服務被請求淹沒。默認情況下，在第一次失敗後，Envoy 代理不會重新嘗試連接服務。
3. 熔斷器：熔斷器是 Istio 爲創建具有彈性的微服務應用提供的另一個有用的機制。在熔斷器中，設置一個對服務中的單個主機調用的限制，例如併發連接的數量或對該主機調用失敗的次數。一旦限制被觸發，熔斷器就會“跳閘”並停止連接到該主機。使用熔斷模式可以快速失敗而不必讓客戶端嘗試連接到過載或有故障的主機。
4. 故障注入：在配置了網絡，包括故障恢復策略之後，可以使用 Istio 的故障注入機制來爲整個應用程序測試故障恢復能力。故障注入是一種將錯誤引入系統以確保系統能夠承受並從錯誤條件中恢復的測試方法。使用故障注入特別有用，能確保故障恢復策略不至於不兼容或者太嚴格，這會導致關鍵服務不可用。
這些功能可以通過Istio的流量管理規則在運行時進行動態配置。重試之間的抖動使重試對重載的上游服務的影響最小化，而超時預算確保主叫服務在可預測的時間範圍內獲得響應（成功/失敗）。主動和被動健康檢查的組合最大限度地減少了在負載平衡池中訪問不健康實例的機會。當與平臺級健康檢查（例如由Kubernetes或Mesos支持的檢查）相結合時，應用程序可以確保將不健康的pod/container/VM快速地從服務網格中去除，從而最小化請求失敗和延遲產生影響。總之，這些功能使得服務網格能夠容忍故障節點，並防止本地化的故障級聯不穩定到其他節點。Istio 故障恢復功能對應用程序來說是完全透明的。在返回響應之前，應用程序不知道 Envoy sidecar 代理是否正在處理被調用服務的故障。這意味着，如果在應用程序代碼中設置了故障恢復策略，那麼您需要記住這兩個策略都是獨立工作的，否則會發生衝突。例如，假設您設置了兩個超時，一個在虛擬服務中配置，另一個在應用程序中配置。應用程序爲服務的 API 調用設置了 2 秒超時。而您在虛擬服務中配置了一個 3 秒超時和重試。在這種情況下，應用程序的超時會先生效，因此 Envoy 的超時和重試嘗試會失效。雖然 Istio 故障恢復特性提高了網格中服務的可靠性和可用性，但應用程序必須處理故障或錯誤並採取適當的回退操作。例如，當負載均衡中的所有實例都失敗時，Envoy 返回一個HTTP 503代碼。應用程序必須實現回退邏輯來處理HTTP 503錯誤代碼。
規則配置實例：Istio提供了簡單的領域特定語言（DSL），用來控制應用部署中跨多個服務的API調用和4層流量。DSL允許運維人員配置服務級別的屬性，如熔斷器，超時，重試，以及設置常見的連續部署任務，如金絲雀推出，A/B測試，基於百分比流量拆分的分階段推出等。例如，將“reviews”服務100％的傳入流量發送到“v1”版本的簡單規則，可以使用規則DSL進行如下描述：
apiVersion: config.istio.io/v1alpha2 destination是服務的名稱，流量將被導向到這裏route
kind: RouteRule lables標記將接受流量的特定服務實例,destination 的
metadata: 值隱式或者顯式地指定一個完全限定域名FQDN) Pilot
name: reviews-default 用它來給服務匹配規則。通常服務的FQDN由三個部分
spec: 組成：name, namespace，和domain:namespace的默
destination: 認值是規則自身的namespace.路由規則控制如何在Istio
name: reviews 服務網格中路由請求。例如路由規則可以將請求路由到
route: 服務的不同版本。可以基於源和目的地，HTTP header
- labels: 字段以及與個別服務版本相關聯的權重來路由請求。
version: v1 2）如過限制爲調用者的特定版本，規則書寫爲如下方
weight: 100 藍色部分，僅適用於"reviews"服務的"v2"版本的調用
spec: 3）選擇基於HTTP header的規則，以下規則僅適用於傳
destination: 入請求包含"cookie" header, 並且內容包含"user=jason"
name: ratings 規則定義如橙色部分，只需在match下添加相應規則如果
match: 提供了多個屬性值對，則所有相應的 header 必須與要應
source: 用的規則相匹配。可以同時設置多個標準。在這種情況下
name: reviews AND語義適用。如僅適用於請求的source爲"reviews:v2"，
request: 並且有包含"user=jason"的"cookie" header。與這個規則
headers: 的差別在source:裏定義name: reviews labels:version: v2。
cookie: 當規則被激活時，每個路由規則標識一個或多個要調用的
regex: "^(.*?;)?(user=jason)(;.*)?$" 加權後端。每個後端對應於目標服務的特定版本，其
route: 超時和重試缺省情況下，http請求的超時時間爲15秒，但
- labels: 可以在路由規則中覆蓋，如左邊規則設置爲10秒，對於給
version: v1 定的http請求，重試次數可以也可以在路由規則中指定，只
httpReqTimeout: 將httpReqTimeout改爲httpReqRetries: 將simpleTimeout
simpleTimeout: 改爲simpleRetry:最後timeout改爲attempts: 3
timeout: 10s
httpFault: 4）在請求路徑中注入故障，在將http請求轉發到規則的相
delay: 應請求目的地時，可以指定一個或多個要注入的故障如左
percent: 10 側的延時路由規則。中斷可以用來提前終止請，求將服務
fixedDelay: 5s 的10％請求返回HTTP 400錯誤代碼fixed改爲httpStatus:400
規則有優先權：多個路由規則可以應用於同一目的地。當有多個規則時，可以指定規則的評估順序。這些規則與給定目的地相對應的，通過規則的precedence字段來設置。規則配置precedence: 1。precedence字段是可選的整數值，默認爲0。首先評估具有較高優先級值的規則。如果有多個具有相同優先級值的規則，則評估順序是未定義的。優先級什麼時候有用？ 只要特定服務的路由故障純粹是基於權重的，可以在單個規則中指定，如前面的示例所示。另一方面，當正在使用的其他標準（例如，來自特定用戶的請求）來路由流量時，將需要多於一個的規則來指定路由。這是必須設置規則precedence字段的時候，以確保以正確的順序對規則進行評估。一般路由規範的通用模式是提供一個或多個較高優先級的規則，通過到特定destination的source/header來修飾規則，然後提供單個基於權重的規則，連最低優先級的匹配準則都不具備，以在所有其他情況下，提供流量的加權分發。
source ： 5）目的地策略：描述與特定服務版本相關聯的各種路由
name: reviews 相關策略，例如負載均衡算法，熔斷器配置，健康檢查等
labels: 與路由規則不同，目的地策略不能根據請求的屬性進行修
version: v2 飾，但是，可以限制策略適用於某些請求，這些請求是使
destination: 用特定標籤路由到destination後端的。例如左側負載均
name: ratings: 衡策略僅適用於針對"reviews"服務器的"v1"版本的請求
labels: 6）熔斷器：可以根據如連接和請求限制的多個標準來設
version: v1 置簡單的熔斷器。如目的地設置到服務版本爲"v1"後端
loadBalancing: 爲100個連接的限制。 將loadBalancing換成circuitBreaker，
name: ROUND_ROBIN 然後添加simpleCb:，在添加maxConnections: 100
apiVersion: config.istio.io/v1alpha2 7）出站規則：出站規則用於配置需要在服務網格中被調用
kind: EgressRule 的外部服務。左面規則可以被用來配置在 *.foo.com域名下
metadata: 下的外部服務。外部服務的地址通過svc字段指定,該字段可
name: foo-egress-rule 以是一個完全限定域名（Fully QualifiedDomain Name,FQDN）
spec: 也可以是一個帶通配符的域名。它代表了可在服務網格中
destination: 訪問的外部服務的一個白名單，該名單包括一個(字段值
service: *.foo.com 爲完全限定域名的情況)或多個外部服務(字段值爲帶通配符
ports: 域名的情況）。這裏可以找到svc字段支持的域名通配符
- port: 80 格式總的來說：目的地策略和路由規則的流量重定向和前
protocol: http 轉，重試超時，故障注入策略等特性都可以很好地支持外
- port: 443 部服務。但是由於外部服務沒有多版本的概念，和服務版
protocol: https 本關聯的按權重的路由規則是不支持的。