關於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的易用性，進一步降低使用門檻。