關于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也很方便

1. 控制面板升級

Kubernetes rolling update

Helm 升級

2. 數據面升級

通過對所有的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的易用性，進一步降低使用門檻。

相關服務請訪問：https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019