istio的原理和功能介紹

1 什麼是Istio

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

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

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 毫秒的延遲。

相關文章
相關標籤/搜索