Pilot 落地實踐

在開始落地實踐部分之前，先引入 Istio 的架構圖：

• 出于性能等方面的綜合考慮，在落地過程中，螞蟻團隊將控制面的組件精簡為 Pilot 和 Citadel 兩個組件，不使用因性能問題爭議不斷的 Mixer，不引入 Galley 來避免多一跳的開銷。

• 在架構圖中，控制面組件 Pilot 是與 Sidecar 交互最重要的組件，負責配置轉化和下發，直面 Sidecar 規?；瘞淼奶魬稹＿@也是雙十一大促中，控制面最大的挑戰。

在生產實踐中，規?；瘑栴}是一個組件走向生產可用級的必經之路。

穩定性增強

從功能實現上來看，Pilot 提供的服務能力可以總結為：Pilot 是一個 Controller + gRPC Server 的服務，通過 List/Watch 各類 K8s 資源進行整合計算，生成 XDS 協議的下發內容，并提供 gRPC 接口服務。

本文將把關注點放在 gRPC 接口服務這個環節：如何保證接口服務支撐大規模 Sidecar 實例，是規模化的一道難題。

負載均衡

要具備規?；芰Γ瑱M向擴展能力是基礎。螞蟻團隊采用常用的 DNSRR 方案來訪問 Pilot，Sidecar 隨機訪問 Pilot 實例。由于是長連接訪問，所以在擴容時，原有的連接沒有重連，會造成負載不均。為解決這個問題，螞蟻團隊配合 Sidecar 散列重連邏輯，給 Pilot 增加了下述功能，以避免產生連接風暴。

• 連接限流

• 熔斷

• 定期重置

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

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

• 定期重置：為了實現負載均衡，對于已經存在的舊連接，螞蟻團隊選擇讓 Pilot 主動斷開連接，不過斷開連接的周期需要考慮錯開大促峰值、退避擴縮容窗口等問題，需要按具體的業務場景來確定。

• Sidecar 散列重連：該功能涉及 Client 端的配合，讓 Sidecar 重連 Pilot 時，采用退避式重試邏輯，避免對 DNS 和 Pilot 造成負載壓力。

性能優化

規?；牧硪坏离y題是如何保證服務的性能。在 Pilot 的場景，最受關注的是配置下發的時效性。性能優化離不開細節，其中部分優化是通用的，也有部分優化是面向業務場景定制的，接下來會介紹一下螞蟻團隊優化的一些細節點。

• 首次請求優化：社區方案里 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 的配置推送，這種方案在生產環境大規模集群下，性能開銷是巨大的。例如：如果單個集群有 10 W 以上的 Pod 數量，任何一個 Pod 的變更事件都會觸發全部 Sidecar 的下發，這樣的性能開銷是不可接受的。

• 其他優化：強管控能力是大促基本配備，螞蟻團隊給 Pilot Admin API 補充了一些額外能力：支持動態變更推送頻率、推送限流、日志級別等功能。

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

監控能力

安全生產的基本要求是具備快速定位和及時止血能力。對于 Pilot 來說，需要關注的核心功能是配置下發能力，該能力有下述幾個核心監控指標：

• 下發時效性：針對下發的時效性，螞蟻團隊在社區的基礎上補充完善了部分下發性能指標，如：下發的配置大小分布、下發時延等。

• 配置準確性：配置準確性的驗證是相對比較復雜的，因為配置的準確性需要依賴 Sidecar 和 Pilot 的配置雙方進行檢驗。因此，螞蟻團隊在控制面里引入了 Inspector 組件，用來定位配置巡檢，版本掃描等運維相關功能模塊。

配置巡檢的流程，示例如下：

流程說明：

1. Pilot 下發配置時，將配置的摘要信息與配置內容同步下發。

2. MOSN 接收配置時，緩存新配置的摘要信息，并通過 Admin API 暴露查詢接口。

3. Inspector 基于控制面的 CR 和 Pod 等信息，計算出對應 MOSN 的配置摘要信息，然后請求 MOSN 接口，對比配置摘要信息是否一致。

由于 Sidecar 的數量較大，Inspector 在巡檢時，支持基于不同的巡檢策略執行巡檢。大體可以分為以下幾類：

• 周期性自動巡檢，一般使用抽樣巡檢。

• SRE 主動觸發檢查機制。

Citadel 安全方案

證書方案

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

證書方案架構圖

Sidecar 獲取證書的流程，示例如下：

流程說明：

1. Citadel 與 Citadel Agent (nodeagent) 組件通過 MCP 協議（Mesh Configuration Protocol）同步 Pod 和 CR 信息，避免 Citadel Agent 直接請求 API Server 所導致的 API Server 負載過高問題。

2. Citadel Agent 會進行防篡改校驗，并提取 appkey。

3. Citadel Agent 攜帶 appkey 請求 Citadel 簽發證書。

4. Citadel 檢查證書是否已緩存，如無證書，則向 KMS 申請簽發證書。

5. KMS 會將簽發的證書響應返回 Citadel，另外 KMS 也支持證書過期輪換通知。

6. Citadel 收到證書后，會通過步驟 7、8、9 將證書層層傳遞，最終到達 MOSN。

國密通信

國密通信是基于 TLS 通信實現的，采用更復雜的加密套件來實現安全通信。該功能核心設計是由 Policy 和 Certificate 兩部分組成：

• Pilot 負責 Policy 的下發。

• Citadel 負責 Certificate 下發 （基于 SDS 證書方案）。

在落地過程中，僅依靠社區的 PERMISSIVE TLS MODE 還不能滿足螞蟻集團可灰度、可監控、可應急的三板斧要求。所以，在社區方案的基礎上，引入了 Pod 粒度的 Sidecar 范圍選擇能力（也是基于 ScopeConfig ），方案示例如下：

流程如下：

1. Pilot List/Watch ScopeConfig CRD 和 Policy CRD ，基于 Pod Label 選擇 Pod 粒度范圍實例。

2. Provider 端 MOSN 收到 Pilot 下發的國密配置后，通過 SDS 方案獲取證書，成功獲取證書后，會將服務狀態推送至 SOFARegistry。

3. SOFARegistry 通知 Consumer 端：MOSN 特定 Provider 端已開啟國密通信狀態，要重新發起建連請求。

MCP 優化

Citadel Agent 通過 Citadel 同步 POD 及 CRD 等信息時，雖然避免了 Node 粒度部署的 Citadel Agent 對 API Server 的壓力，但是，使用 MCP 協議同步數據時，螞蟻團隊遇到了下述挑戰：

• 大集群部署時，POD 數量在 10 W 以上時，全量通信時，每次需同步的信息在 100 M 以上，性能開銷巨大，網絡帶寬開銷也不可忽視。

• 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，具備極簡建站，默認安全等能力，未來極具想象空間。