早上好，我是 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特性，只支援服務網格全

局的位置感知的負載均衡設定：

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

Locality-weighted load balancing允許管理員基於流量來源及終止的位置資訊控制流量的分發。例如可以設定從源位置

{region}/{zone}/{sub-zone}的工作負載發出的流量轉發到目的位置的endpoints負載均衡權重：使用者可以為相同區域的工作

負載訪問設定較高的權重，為不同區域的工作負載設定較小的權重，減少網路延遲。

基於位置的故障轉移設定：

類似於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策略和遙測

預設關閉策略檢查功能 為了提高多數客戶場景下的效能，安裝時預設關閉策略檢查， 後期可按需開啟此功能。

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

多方面降低開銷 ，提升效能和可擴充套件性：

• 減少Envoy生成的統計資料的預設收集
  

• Mixer的工作負載增加load-shedding功能
  

• 改進Envoy和Mixer的通訊協議

控制請求頭和路由 增加選項使介面卡可以修改請求頭和路由

程式外介面卡 程式外介面卡功能生產可用，下個release棄用程式內介面卡。

多方面增強Tracing的能力： 

• Trace id支援128bit的範圍

• 支援向LightStep傳送追蹤資料

• 增加選項完全禁用Mixer支援的服務的追蹤功能

• 增加策略的decision-aware 追蹤

預設的TCP指標 為追蹤TCP連線增加預設指標

降低Addon對Load Balancer的依賴 不再透過獨立的load balancers對外暴露addons，而是透過Istio gateway來暴露外掛

服務。

安全的Addon證書 改變外掛的證書儲存方式。Grafana, Kiali, and Jaeger的使用者名稱和密碼存放在kubernetes的secrets中

以提高安全性和合規性。

去除內建的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