Categories
程式開發

螞蟻金服 Service Mesh 大規模落地系列(控制面篇)


引言

Service Mesh 是螞蟻金服下一代架構的核心,本次主題主要分享在螞蟻金服當前的體量下,控制面平穩支撐大規模 Sidecar 的落地實踐。聚焦控制面核心組件 Pilot 和 Citadel,分享螞蟻金服雙十一控制面如何管理並服務好全站 Sidecar。本次分享主要分為兩大部分,分別是:

  • Pilot 落地實踐;
  • Citadel 安全加固;

Pilot 落地實踐

在開始分享落地實踐之前,我們先來看看 Istio 的架構圖:

螞蟻金服 Service Mesh 大規模落地系列(控制面篇) 1

理想很豐滿,現實很骨感。由於性能等方面的綜合考慮,我們在落地過程中,將控制面的組件精簡為 Pilot 和 Citadel 兩個組件了,不使用因性能問題爭議不斷的 Mixer,不引入 Galley 來避免多一跳的開銷。在架構圖中,控制面組件 Pilot 是與 Sidecar 交互最重要的組件,負責配置轉化和下發,直面 Sidecar 規模化帶來的挑戰。這也是雙十一大促中,控制面最大的挑戰。規模化的問題在生產實踐中,是一個組件走向生產可用級的必經之路。接下來將會分別從穩定性、性能優化、監控這三個方面分別展開。

穩定性增強

我們先梳理下Pilot 提供的服務能力,從功能實現上來看,Pilot 是一個Controller + gRPC Server 的服務,通過List/Watch 各類K8s 資源,進行整合計算生成XDS 協議的下發內容,並提供gRPC 接口服務。本次分享我們先把關注點放在 gRPC 接口服務這個環節,如何保證接口服務支撐大規模 Sidecar 實例,是規模化的一道難題。

負載均衡

要具備規模化能力,橫向擴展能力是基礎。 Pilot 的訪問方式我們採用常用的 DNSRR 方案,Sidecar 隨機訪問 Pilot 實例。由於是長連接訪問,所以在擴容時,原有的連接沒有重連,會造成負載不均。為解決這個問題,我們給 Pilot 增加了連接限流、熔斷、定期重置連接功能,並配合 Sidecar 散列重連邏輯,避免產生連接風暴。

螞蟻金服 Service Mesh 大規模落地系列(控制面篇) 2

  • 連接限流

為了降低大量MOSN 同時連接同一個Pilot 實例的風險,在gRPC 首次連接時,Pilot 增加基於令牌桶方案的流控能力,控制新連接的處理響應,並將等待超時的連接主動斷連,等待Sidecar下一次重連。

  • 熔斷

基於使用場景的壓測數據,限制單實例 Pilot 同時可服務的 Sidecar 數量上限,超過熔斷值的新連接會被Pilot 主動拒絕。

  • 定期重置

為了實現負載均衡,對於已經存在的舊連接,應該怎麼處理呢?我們選擇了 Pilot 主動斷開連接,不過斷開連接的周期怎麼定是個技術活。要考慮錯開大促峰值,退避擴縮容窗口之類,這個具體值就不列出來了,大家按各自的業務場景來決定就好了。

  • Sidecar 散列重連

最後還有一點是 Client 端的配合,我們會控制 Sidecar 重連 Pilot 時,採用退避式重試邏輯,避免對 DNS 和 Pilot 造成負載壓力。

性能優化

規模化的另一道難題是怎麼保證服務的性能。在 Pilot 的場景,我們最關注的當然是配置下發的時效性了。性能優化離不開細節,其中部分優化是通用的,也有部分優化是面向業務場景定制的,接下來會分享下我們優化的一些細節點。

螞蟻金服 Service Mesh 大規模落地系列(控制面篇) 3

  • 首次請求優化

社區方案裡 Pilot 是通過 Pod.Status 來獲取 Pod 的 IP 信息,在小集群的測試中,這個時間基本秒級內可以完成。然而在大集群生產環境中,我們發現 Status 的更新事件時間較慢,甚至出現超過 10s 以上的情況,而且延遲時間不穩定,會增加 Pilot 首次下發的時延。我們通過與基礎設施K8s 打通,由PaaS 側將Pod 分配到的IP 直接標記到Pod.Annotation 上,從而實現在第一次獲取Pod 事件時,就可以獲取到IP,將該環節的時延減少到0。

  • 按需獲取 & Custom Resource 緩存

這是一個面向 DBMesh 業務場景的定制性優化,是基於按需獲取的邏輯來實現的。其目的在於解決 DBMesh CR 數量過多,過大導致的性能問題,同時避免 Pilot 由於 List/Watch CR 資源導致 OOM 問題,Pilot 採用按需緩存和過期失效的策略來優化內存佔用。

  • 局部推送

社區方案中當 Pilot List/Watch 的資源發生變更時,會觸發全部 Sidecar 的配置推送,這種方案在生產環境大規模集群下,性能開銷是巨大的。舉個具體例子,如果單個集群有 10W 以上的 Pod 數量,任何一個 Pod 的變更事件都會觸發全部 Sidecar 的下發,這樣的性能開銷是不可接受的。

優化的思路也比較簡單,如果能夠控制下發範圍,那就可以將配置下發限制在需要感知變更的 Sidecar 範圍裡。為此,我們定義了 ScopeConfig CRD 用於描述各類資源信息與哪些 Pod 相關,這樣 Pilot 就可以預先計算出配置變更的影響範圍,然後只針對受影響的 Sidecar 推送配置。

  • 其他優化

強管控能力是大促基本配備,我們給 Pilot Admin API 補充了一些額外能力,支持動態變更推送頻率、推送限流、日誌級別等功能。

監控能力

安全生產的基本要求是要具備快速定位和及時止血能力,那麼對於 Pilot 來說,我們需要關注的核心功能是配置下發能力,該能力有兩個核心監控指標:

  • 下發時效性

針對下發的時效性,我們在社區的基礎上補充完善了部分下發性能指標,如下發的配置大小分佈,下發時延等。

  • 配置準確性

而對於配置準確性驗證是相對比較複雜的,因為配置的準確性需要依賴Sidecar 和Pilot 的配置雙方進行檢驗,因此我們在控制面裡引入了Inspector 組件,定位於配置巡檢,版本掃描等運維相關功能模塊。

螞蟻金服 Service Mesh 大規模落地系列(控制面篇) 4

配置巡檢的流程如下:

  • Pilot 下發配置時,將配置的摘要信息與配置內容同步下發;
  • MOSN 接收配置時,緩存新配置的摘要信息,並通過 Admin API 暴露查詢接口;
  • Inspector 基於控制面的 CR 和 Pod 等信息,計算出對應 MOSN 的配置摘要信息,然後請求 MOSN 接口,對比配置摘要信息是否一致;

由於 Sidecar 的數量較大,Inspector 在巡檢時,支持基於不同的巡檢策略執行。大體可以分為以下兩類:

  • 週期性自動巡檢,一般使用抽樣巡檢;
  • SRE 主動觸發檢查機制;

Citadel 安全方案

證書方案

Sidecar 基於社區 SDS 方案 (Secret Discovery Service),支持證書動態發現和熱更新能力。同時螞蟻金服是一家金融科技公司,對安全有更高的要求,不使用 Citadel 的證書自簽發能力,而是通過對接內部 KMS 系統獲取證書。同時提供證書緩存和證書推送更新能力。

我們先來看看架構圖,請看圖:

螞蟻金服 Service Mesh 大規模落地系列(控制面篇) 5

對整體架構有個大致理解後,我們分解下 Sidecar 獲取證書的流程,一圖胜千言,再上圖:

螞蟻金服 Service Mesh 大規模落地系列(控制面篇) 6

補充說明下圖中的每一步環節:

  • Citadel 與 Citadel Agent (nodeagent) 組件通過 MCP 協議(Mesh Configuration Protocol) 同步 Pod 和 CR 信息,避免 Citadel Agent 直接請求 API Server 導致 API Server 負載過高;
  • MOSN 通過 Unix Domain Socket 方式向 Citadel Agent 發起 SDS 請求;
  • Citadel Agent 會進行防篡改校驗,並提取 appkey;
  • Citadel Agent 攜帶 appkey 請求 Citadel 簽發證書;
  • Citadel 檢查證書是否已緩存,如無證書,則向 KMS 申請簽發證書;
  • KMS 會將簽發的證書響應回 Citadel,另外 KMS 也支持證書過期輪換通知;
  • Citadel 收到證書後,會將證書層層傳遞,最終到達MOSN ;

國密通信

國密通信是基於 TLS 通信實現的,採用更複雜的加密套件來實現安全通信。該功能核心設計是由 Policy 和 Certificate 兩部分組成:

  • Pilot 負責 Policy 的下發;
  • Citadel 負責 Certificate 下發 (基於 SDS 證書方案);

在落地過程中,僅依靠社區的 PERMISSIVE TLS MODE 還不能滿足螞蟻金服可灰度、可監控、可應急的三板斧要求。所以在社區方案的基礎上,引入 Pod 粒度的 Sidecar 範圍選擇能力(也是基於 ScopeConfig ),方案基本如下圖所示:

螞蟻金服 Service Mesh 大規模落地系列(控制面篇) 7

流程如下:

  • Pilot List/Watch ScopeConfig CRD 和 Policy CRD ,基於 Pod Label 選擇 Pod 粒度範圍實例;
  • Provider 端 MOSN 收到 Pilot 下發的國密配置後,通過 SDS 方案獲取證書,成功獲取證書後,會將服務狀態推送至 SOFARegistry;
  • SOFARegistry 通知 Consumer 端 MOSN 特定 Provider 端已開啟國密通信狀態,重新發起建連請求;

MCP 優化

Citadel Agent 通過 Citadel 去同步 POD 及 CRD 等信息,雖然避免了 Node 粒度部署的 Citadel Agent 對 API Server 的壓力。但是使用 MCP 協議同步數據時,我們遇到了以下兩個挑戰:

  • 大集群部署時,POD 數量在 10W 以上時,全量通信的話,每次需同步的信息在 100M 以上,性能開銷巨大,網絡帶寬開銷也不可忽視;
  • Pod 和 CR 信息變更頻繁,高頻的全量推送直接製約了可拓展性,同時效率極低;

為了解決以上兩個問題,就需要對 MCP 實現進行改造。改造的目標很明確,那就是減少同步信息量,降低推送頻率。為此,我們強化了社區 MCP 的實現,補充了這些功能:

  • 為 MCP 協議支持增量信息同步模式,性能大幅優於社區原生方案全量 MCP 同步方式;
  • Citadel Agent 是Node 粒度組件,基於最小信息可見集的想法,Citadel 在同步信息給Citadel Agent 時,通過Host IP ,Pod 及CR 上的Label 篩選出最小集,僅推送每個Citadel Agent 自身服務範圍的信息;
  • 更進一步,基於 Pod 和 CR 的變更事件可以預先知道需要推送給哪些 Citadel Agent 實例,只對感知變更的Citadel Agent 觸發推送事件,即支持局部推送能力;

未來思考

本次大促的控制面的重心在於解決規模化問題,後續控制面將會在服務發現、精細化路由、Policy As Code 等領域深入探索。我們將與社區深度合作,控制面將支持通過 MCP 對接多種註冊中心(SOFARegistry(已開源), Nacos等)進行服務發現信息同步,解決大規模服務註冊發現問題,支持增量推送大量 endpoint。同時控制面還能通過增強配置下發能力,為應用啟動提速,將在 Serverless 極速啟動場景獲取技術紅利。控制面還將結合 Policy As Code,從而更具想像空間,具備極簡建站,默認安全等能力。

到此,本次分享的內容就結束了。 Istio 生產級實踐機會難得,並且任重道遠。最後,歡迎有誌之士加入我們,一起打造世界級規模的 Service Mesh。

作者介紹

彭澤文(花名:封塵),螞蟻金服 Mesh 控制面主站負責人,主要 Focus 領域:Service Mesh(MOSN、Istio)。

本文轉載自公眾號金融級分佈式架構(ID:Antfin_SOFA)。

原文鏈接

https://mp.weixin.qq.com/s/51vzXIqKit_jaP5Iz0Y9Rg