istio的原理和功能介紹

目錄

• 1 什麼是Istio
• 2 架構和原理
  • 2.1 Proxy代理
  • 2.2 Mixer混合器
  • 2.3 Pilot引導
  • 2.4 Citadel堡壘
  • 2.5 Galley
• 3 功能列表
• 4 性能評估

1 什麼是Istio

當前咱們已經完成從單體的應用程序向微服務架構的轉型，將來還可能會面臨更多的分佈式場景需求。以往只須要運行好一個單體的應用，如今卻面臨着對總體服務網絡管理，隨着規模和複雜度的不斷增加，服務網絡勢必會愈來愈難以理解和管理。那麼咱們如何去應對這些挑戰呢？這就是Istio所能爲咱們解決的問題。

忘了在哪看到過相似的話了，開發人員應該把更多的精力放在對業務和功能的實現上，而不是被繁瑣的日誌、監控、測試等輔助模塊所禁錮。事實上，咱們啓用Redis、Grpc、Iris等——正是在往這個簡化開發步驟的方向走，總不能每開發一個應用都得實現一套TCP/IP通信、實現一套紅黑樹或跳錶吧。而Istio則爲咱們把這件事執行的更完全。讓咱們看看Istio到底能幹啥？

Istio lets you connect, secure, control, and observe services.官方給出的Istio的總結，很簡單明瞭。鏈接、安全、控制和觀測服務。換個思路來說，Istio針對現有的服務網絡，提供一種簡單的方式將鏈接、安全、控制和觀測的模塊，與應用程序或服務隔離開來，從而開發人員能夠將更多的精力放在覈心的業務邏輯上，如下是Istio的核心功能概述：
• HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡。
• 經過豐富的路由規則、重試、故障轉移和故障注入，能夠對流量行爲進行細粒度控制。
• 可插入的策略層和配置 API，支持訪問控制、速率限制和配額。
• 對出入集羣入口和出口中全部流量的自動度量指標、日誌記錄和追蹤。
• 經過強大的基於身份的驗證和受權，在集羣中實現安全的服務間通訊。

2 架構和原理

上面是官方給的架構圖，核心組件有：Proxy代理、Mixer混合器、Pilot引導、Citadel堡壘，以及Galley。

2.1 Proxy代理

Istio的核心原理，是網絡代理，攔截下全部想攔截的流量，而後想幹啥就幹啥吧。
Istio使用的代理組件是Lyft團隊的Envoy，一個C++開發的高性能代理。這是Lyft在Istio項目裏的惟一貢獻，卻讓Lyft排在跟Google/IBM並列的位置，可想而知Envoy對Istio的重要性。

Envoy之因此有能力攔截下全部的流量，是由於它被設計爲部署在每個須要管理的Pod裏，做爲一個獨立容器存在，支持經過配置iptables或cni網橋兩種方式來攔截流量（這裏也不展開說了，還不明白的同窗能夠翻看我以前發的k8s底層網絡的說明，看看Flannel的實現原理），請看上圖，Business-manager容器的請求發出時，會通過本Pod的Enovy代理，Enovy完成規則校驗、數據採集、日誌等操做後，再轉發出去；值得注意的是，請求方Enovy轉發出去的流量會發送給接收方的Enovy，以後纔有可能到達真正的接收方data-product容器。固然這些操做是Istio的活，咱們要作的僅僅是經過配置的形式告訴Istio咱們要對哪些流量作什麼動做。
經過對攔截下來的流量的解析和修改（是的，理論上什麼都能幹，包括修改甚至丟棄流量），Envoy包括但不限於如下功能：
• 動態服務發現
• 負載均衡
• TLS 終止
• HTTP/2 & gRPC 代理
• 熔斷器
• 健康檢查、基於百分比流量拆分的灰度發佈
• 故障注入
• 豐富的度量指標

2.2 Mixer混合器

顧名思義，Mixer混合了各類策略以及後端數據採集或遙測系統的適配器，從而實現了前端Proxy與後端系統的隔離與匯合。Mixer是一個靈活的插件模型（有沒有發現不管是k8s仍是Istio，實現上都很青睞於插件模型，這是一個很靈活的實現方式），它一端連着Envoy，同時咱們能夠將日誌、監控、遙測等各類系統「插入」到Mixer的另外一端中，從而獲得咱們想要的數據或結果。

咱們來看下官方的Mixer拓撲圖，Mixer被設計爲一個獨立運行的模塊，它能夠「插入」logging日誌、quota指標、auth安全認證、Tele遙測等不少模塊。每插入一個模塊都會在前端生成一個規則過濾器。前端的Enovy在每次流量到來時，都會請求Mixer，匹配每個過濾器。

這就涉及到性能問題了，因此Istio在這個拓撲下設計了一個二級緩存系統。Envoy端在每一個Pod裏有一個一級緩存，固然這個緩存不能太大；Mixer端會有一個二級緩存，因爲Mixer是獨立運行的，因此這個緩存能夠設計的比較大。這樣Envoy能夠預先緩存一部分規則，只有當規則缺失時才須要向Mixer請求，這就減小了每次流量到來的網絡請求次數；另外一方面，日誌等數據上送，也是異步執行的，先通過一級緩存、二級緩存再到達後端存儲或處理系統。

2.3 Pilot引導

簡單來講，Pilot是爲咱們提供配置智能路由（如A/B測試、金絲雀發佈等）、彈性（超時、重發、熔斷等）等功能的管理系統，它提供了一系列rules api，容許運維人員指定一系列高級的流量管理規則。Pilot負責將咱們的配置轉換並寫入到每一個sidecar（Enovy）。

2.4 Citadel堡壘

這個名字也頗有意思，它管理着集羣的密鑰和證書，是集羣的安所有門。典型的若是咱們的服務是跨網絡通信（Istio容許咱們創建一個安全的集羣的集羣網絡），開發人員想省事懶得對通信數據進行加解密和身份認證，這事就能夠交給Citadel來處理了。更詳細的說，Istio各個模塊在安全性上分別扮演如下角色：
• Citadel，用於密鑰和證書管理
• Sidecar和周邊代理，實現客戶端和服務器之間的安全通訊
• Pilot，將受權策略和安全命名信息分發給代理
• Mixer，管理受權和審計
這一塊應該暫時用不上，也不展開說了。

2.5 Galley

這個不知道咋翻譯，目前這個組件的做用是驗證用戶編寫的Istio api配置。從官網的說法來看，後面這個組件會逐步接管獲取配置、處理和分配的工做，好比從k8s的數據中心（etcd）獲取集羣信息的活，理論上應該交給Galley幹。從這個信息來看，Galley的定位應該相似於k8s的api server組件，提供集羣內統一的配置信息接口，從而將用戶配置的細節隔離開來。

3 功能列表

如下是從官網各項示例中整理出來的Istio所支持的功能列表：

類別	功能	說明
流量管理	請求路由	A/B測試、金絲雀發佈等，包括對集羣出入口、及集羣內部的流量的控制。好比某應用新版本發佈，能夠配置爲5%的流量流向新版本，95%的給舊版本
	流量轉移	與上一條請求路由相似，能夠平滑的將流量從舊版本轉移到新版本上
	負載均衡	目前支持3種方式，輪詢、隨機和帶權重的最少請求
	服務發現	帶心跳的健康檢查，失敗率超標的Pod移出負載均衡池
	故障處理	超時、重發、熔斷、上游併發請求或下游鏈接數限制等
	微調	支持用特殊的請求頭參數，覆蓋默認的超時、重發值
	故障注入	由Enovy在正常的集羣中人爲注入故障，好比TCP包損壞或延遲、HTTP錯誤碼等，支持按百分比注入，好比給10%的流向服務A的請求包增長5秒延遲
	多重匹配	上述規則的配置，支持按多種條件匹配，且支持and或or的方式匹配多條規則
	Gateway	接管集羣入口的流量，替代了Ingress，從而對入口流量執行其餘規則
	Service Entry	接管集羣內部訪問外部服務的流量，從而對出口流量執行一些規則
	鏡像	支持將特定的流量鏡像到服務路徑以外，而不影響主服務路徑的正常執行
安全	命名空間訪問控制	支持配置某命名空間的全部或個別服務能夠被其餘命名空間訪問
	服務級別訪問控制	容許或禁止訪問某個服務
	雙向TLS	HTTPS加密傳輸
	其餘安全策略
策略	速率限制	好比限制每秒的請求次數
	黑白名單	支持基於IP或屬性的黑名單、白名單
遙測	日誌收集	支持將Prometheus、Jaeger等系統插入Mixer，從而完成數據的採集
	指標採集
	分佈式追蹤

4 性能評估

官方給出了對最新版本V1.1.4的性能測試結果。在由1000個服務和2000個sidecar組成，每秒產生70000個網格範圍內的請求的網格中，獲得如下結果： • Envoy在每秒處理 1000 請求的狀況下，使用 0.6 個 vCPU 以及 50 MB 的內存。 • istio-telemetry在每秒1000個網格範圍內的請求的狀況下，消耗了0.6個vCPU。 • Pilot使用了 1 個 vCPU 以及 1.5 GB 的內存。 • Envoy在第 90 個百分位上增長了 8 毫秒的延遲。