關於Istio 1.1,你所不知道的細節
本文整理自Istio社群成員Star在
Cloud Native Days China 2019 北京站的現場分享
第1則
主角 Istio
Istio作為service mesh領域的明星專案,從2016年釋出到現在熱度不斷攀升。
Istio & Envoy Github Star Growth
官網中Istio1.1的架構圖除了資料面的Envoy和控制面的Pilot,Mixer,Citadel三大元件外,引入了Galley元件驗證Istio API 的配置。
Istio能帶來什麼收益呢?
開發和運維過程中我們經常會碰到下面的問題:如何做到新版本的上線不影響現網業務的執行?如果訪問系統的請求突然增多,我們的系統處理不了怎麼辦?如果系統出現問題,究竟是哪個服務的問題,服務之間的呼叫關係如何?業務程式設計師通常缺乏安全相關的知識,能不能做到直接對沒有加密的流量自動加密?針對這些問題,Istio都有相應的方案解決,對應於它的各個功能元件。
第2則
Istio 1.1大不同
Istio 1.0的主題是生產可用,而1.1版本則是企業可用,強調1.1在大規模叢集(很多服務和負載)下的效能和可靠效能夠得以保障。
下表是Istio1.1和1.0在流量管理的特性狀態的對比:
Istio 1.1版本的效能提升方面成果顯著。
在應用效能上:
應用的平均時延下降 30%
在大規模叢集中,服務啟動速度提高 40%
在管理面元件資源佔用率上:
大規模叢集中,Pilot CPU使用下降 90%
大規模叢集中,Pilot 記憶體使用下降 50%
Istio 1.1版本為提高效能貢獻的重點優化項如下:
Sidecar API,減少發給proxy的配置數量以及pilot負載
網路配置規則(Destinationrule,Virtualservie, ServiceEntry)中增加的 exportTo欄位限制配置的可見範圍
Envoy預設收集的統計資料大量減少
給mixer增加load-shedding功能,防止overload。
提升envoy和mixer之間的互動協議
可配置併發執行緒數,提高吞吐量
可配置filter來約束mixer遙測資料
升級到Istio 1.1也很方便
- 控制面板升級
Kubernetes rolling update
Helm 升級
- 資料面升級
通過對所有的pods觸發rolling update重新注入sidecar (例如:patching the grace termination period)
Istio1.1的多叢集網格管理
新引入了多控制面方案和叢集感知(Split Horizon EDS)的單控制面方案:
多控制平面方案
單控制平面(Split Horizon EDS)方案
關於服務可見性,剛才說到的大叢集規模效能的提升很大一部分歸功於服務可見性。主要由兩部分結合起來使用:
ExportTo欄位
服務端的Service/ServiceEntry/Virtualservice/Destinationrule 配置exportTo欄位,申明此網路資源的可見範圍。
新增sidecar資源物件
請求端所在的namespace配置sidecar物件,可以精確控制sidecar轉發到指定的namespace或service。
安全特性方面比較關心的一項是SDS(Secret Discovery Service):
提供更強的安全性:
通過節點金鑰生成,私鑰僅存在於 Citadel 和 Envoy Sidecar 的記憶體中。
不依賴 Kubernetes Secret
不需要掛載Secret 卷。
證書替換不需要重啟 Envoy
Sidecar 能夠利用 SDS API 動態重新整理金鑰和證書。
Istio 1.1的命令列工具Istioctl增加了離線校驗命令和驗證安裝命令,Istioctl棄用create、replace、get 和 delete使用 kubectl 代替,同時支援kubectl操作Istio網路資源時使用縮寫。
Istio社群成立了使用者體驗工作組,專門致力於提高Istio的易用性,進一步降低使用門檻。