1. 程式人生 > >早上好,我是 Istio 1.1

早上好,我是 Istio 1.1

技術 des strong out 並發 節點 選擇 部署 遷移

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

早上好,我是 Istio 1.1