早上好，我是 Istio 1.1

1性能加強

 

雖然Istio1.0的目標是生產可用，但從去年7月份發佈以來，在性能和穩定性上並不能讓用戶滿意。社區的Performance and Scalability工做組在Istio v1.1中作了大量的努力以提升控制面和數據面的性能，其中最明顯的性能加強包括：

• Sidecar API，減小發給proxy的配置數量以及pilot負載。

• 網絡配置規則（Destinationrule,Virtualservie, ServiceEntry）中增長的 exportTo字段限制配置的可見範圍。

• Envoy默認收集的統計數據大量減小。

• 給mixer增長load-shedding功能，防止overload。

• 提高envoy和mixer之間的交互協議。

• 可配置併發線程數，提升吞吐量。

• 可配置filter來約束mixer遙測數據。

從對Istio 1.1的測試數據來看，這部分工做取得了顯著的效果。

 

1.1控制面性能表現

Pilot的CPU和內存使用受網格內的配置和系統狀態的影響，例如負載變化速率，配置變化速率，鏈接到Pilot的proxy的數量等。能夠經過增長Pilot的實例數來減小配置分發處理的時間，提升性能。

在網格內有1000個服務，2000 個sidecars，每秒1000請求下的表現：

• 單Pilot 實例使用 1 vCPU 和1.5 GB 的內存。

• istio-telemetry服務使用0.6 vCPU。

 

1.2數據面性能表現

CPU：proxy在每秒1000個請求下大約消耗0.6 vCPU 。

內存：proxy的內存消耗主要取決於它須要處理的配置數量，大量的listeners, clusters, and routes配置會增長內存使用。proxy每秒1000個請求下大約消耗50MB的內存。

時延：數據在傳輸時會經過客戶端和服務端的sidecar，傳輸路徑上的這兩個proxy在1000 rps狀況下，99%的請求時延是10 ms（TP99），單獨server端的proxy增長6ms的時延。若是啓用策略會進一步增長時延。

 

2多集羣方案

 

在1.0中只提供了一種基於扁平網絡的多集羣方案：Istio控制面部署在一個Kubernetes集羣中。這種方案要求各集羣的 Pod 地址不能重疊，且全部的 Kubernetes 控制平面API Server 互通。看上去就是物理上把多個Kubernetes併到一個Istio控制面下，在Istio看來是同一個網格。這種方案的網絡要求苛刻，實際應用並很少。

在新發布的1.1版本上，多集羣上作了很是多的加強，除了保留1.0扁平網絡做爲一種單控制面的方案外，還提出了另外兩種方案供用戶根據實際環境和需求靈活選擇，這兩種方案都不要求是扁平網絡：

• 多控制面方案：在每一個集羣中安裝完整的Istio控制面，能夠當作是一種鬆散的聯邦，集羣間服務在Gateway處聯通便可。經過一個全局的DNS將跨集羣的請求路由到另一個集羣裏去。這種集羣的訪問是基於Istio的ServiceEntry和Gateway來實現的，配置較多且複雜，需用戶本身維護。

• 一種集羣感知（Split Horizon EDS）的單控制面方案：Istio控制面板只在一個Kubernetes集羣中安裝，Istio控制面仍然須要鏈接全部Kubernetes集羣的Kube API Server。每一個集羣都有集羣標識和網絡標識。在服務間訪問時，若是目標是本集羣的負載，則相似單集羣的方式直接轉發；若是是其餘集羣的實例，則將流量轉發到集羣的入口網關上，再通過網關轉發給實際對端。

 

3安全

 

3.1HTTP Readiness Liveness Probe自動重寫

mTLS模式下，進入Envoy的HTTP請求會在TLS握手階段被拒絕。1.1新增長了HTTP Probe的自動重寫，經過將HTTP Probe請求發送到pilot-agent由其轉發HTTP探測到應用，進而繞開Envoy的TLS認證。默認自動重寫是關閉狀態，用戶須要根據實際須要打開。

3.2集羣級別的RBAC設置ClusterRbacConfig

RbacConfig被標記爲廢棄，用戶升級1.1後，必須遷移到使用ClusterRbacConfig。由於RbacConfig有bug，在一些狀況下，其做用範圍會被縮小到命名空間。

3.3SDS

SDS（SecretDiscovery Service）經過節點密鑰生成提供更強的安全性以及動態的證書回滾。能夠取代目前使用secret卷掛載的方式提供證書。1.1中目前爲alpha，不建議生產環境使用，可是隨着Istio發展值得期待。

3.4受權

新增對TCP類型服務的RBAC受權以及基於用戶組的受權。

3.5Vault集成

容許用戶集成開源Vault，使用Vault CA簽發證書。

 

4網絡

 

4.1新的sidecar API資源

在1.1中引入Sidecar這資源對象能夠更精細的控制Envoy轉發和接收的端口、協議。在指定命名空間中使用sidecar資源時，支持定義可訪問的服務範圍。這樣能夠下降發給proxy的配置的數量。在大規模的集羣中，咱們推薦給每一個namespace增長sidecar的對象。 這個功能主要是爲了提高性能，減輕pilot計算的負擔。對proxy的影響是：1. 內存佔用少，2. 下降網絡帶寬佔用。  

4.2exportTo

在Istio1.1版本中添加了一個重要字段exportTo。用於控制VirtualService、DestinationRule和 ServiceEntry 跨Namespace的可見性。這樣就能夠控制一個Namespace下定義的資源對象是否能夠被其餘Namespace下的Envoy執行了。若是未賦值，則默認全局可見。當前版本中只支持「.」和「*」兩種配置。

•  「.」表示僅應用到當前Namespace。

• 「*」表示應用到全部Namespace。

4.3Locality based loadbalancer

Istio 1.1 引入了負載均衡新特性：基於位置的負載均衡。這也是華爲主導的新特性。目前是alpha特性，只支持服務網格全局的位置感知的負載均衡設置：

1. 基於位置權重的負載均衡設置（Locality-weighted load balancing）：

   Locality-weighted load balancing容許管理員基於流量來源及終止的位置信息控制流量的分發。例如能夠設置從源位置{region}/{zone}/{sub-zone}的工做負載發出的流量轉發到目的位置的endpoints負載均衡權重：用戶能夠爲相同區域的工做負載訪問設置較高的權重，爲不一樣區域的工做負載設置較小的權重，減小網絡延遲。

2. 基於位置的故障轉移設置：

   相似於Envoy的「Zone aware routing」負載均衡策略，基於位置的故障轉移特性，經過爲不一樣的位置的endpoints設置不一樣的優先級，控制流量的轉發策略。默認設置以下，同一位置{region}/{zone}/{sub-zone}的endpoints優先級最高，同一{region}/{zone}的endpoints優先級次之，同一region的endpoints第三，最後故障轉移設置區域以及其餘區域的endpoints依次。endpoints所有健康的狀況下，流量只會在同一{region}/{zone}/{sub-zone}轉發。當endpoint變得不健康時，會進行相應的降級處理，選擇低優先級的endpoints轉發。

4.4pilot配置資源發現

Istio1.1將galley做爲默認的 配置規則發現中心，pilot經過MCP協議與galley進行配置訂閱，取代1.0之前直接從Kubernetes以CR的方式watch配置資源。

 

5策略和遙測

 

1. 默認關閉策略檢查功能 爲了提升多數客戶場景下的性能，安裝時默認關閉策略檢查， 後期可按需開啓此功能。

2. 棄用ServiceGraph，推薦使用 Kiali：提供了更豐富的可視化體驗。

3. 多方面下降開銷 ，提高性能和可擴展性：

   o 減小Envoy生成的統計數據的默認收集

   o Mixer的工做負載增長load-shedding功能

   o 改進Envoy和Mixer的通訊協議

4. 控制請求頭和路由 增長選項使適配器能夠修改請求頭和路由

5. 進程外適配器 進程外適配器功能生產可用，下個release棄用進程內適配器。

6. 多方面加強Tracing的能力： 

   o Trace id支持128bit的範圍

   o 支持向LightStep發送追蹤數據

   o 增長選項徹底禁用Mixer支持的服務的追蹤功能

   o 增長策略的decision-aware 追蹤

7. 默認的TCP指標 爲追蹤TCP鏈接增長默認指標

8. 下降Addon對Load Balancer的依賴 再也不經過獨立的load balancers對外暴露addons，而是經過Istio gateway來暴露插件服務。

9. 安全的Addon證書 改變插件的證書存儲方式。Grafana, Kiali, and Jaeger的用戶名和密碼存放在kubernetes的secrets中以提升安全性和合規性。

10. 去除內置的statsd collector。Istio目前支持用戶本身的statsd，以提升現有Kubernetes部署的靈活性。

另外，Istio運維管理的複雜度也不能被部分用戶接受（好比：衆多的crd資源），所以社區專門成立了User Experience工做組致力於提升Istio的易用性，進一步下降其使用門檻。

通過你們的共同努力，Istio1.1版本幾經推遲終於發佈了！咱們有理由對其充滿期待和信心，共同催熟以Istio爲表明的雲原生服務網格技術，爲咱們的用戶提供高品質的雲服務體驗。

歡迎試用華爲雲應用服務網格Istio。

 

 

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