蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇

本文涉及的产品
密钥管理服务KMS,1000个密钥,100个凭据,1个月
简介: 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇,聚焦控制面核心组件 Pilot 和 Citadel,分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。

Service Mesh-控制面篇

本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇,该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。

引言

Service Mesh 是蚂蚁金服下一代架构的核心,本次主题主要分享在蚂蚁金服当前的体量下,控制面平稳支撑大规模 Sidecar 的落地实践。聚焦控制面核心组件 Pilot 和 Citadel,分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。

本次分享主要分为两大部分,分别是:

  • Pilot 落地实践;
  • Citadel 安全加固;

Pilot 落地实践

在开始分享落地实践之前,我们先来看看 Istio 的架构图:

Istio 的架构图

理想很丰满,现实很骨感。由于性能等方面的综合考虑,我们在落地过程中,将控制面的组件精简为 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 散列重连逻辑,避免产生连接风暴。

负载均衡

  • 连接限流

为了降低大量 MOSN 同时连接同一个 Pilot 实例的风险,在 gRPC 首次连接时,Pilot 增加基于令牌桶方案的流控能力,控制新连接的处理响应,并将等待超时的连接主动断连,等待 Sidecar 下一次重连。

  • 熔断

基于使用场景的压测数据,限制单实例 Pilot 同时可服务的 Sidecar 数量上限,超过熔断值的新连接会被Pilot 主动拒绝。

  • 定期重置

为了实现负载均衡,对于已经存在的旧连接,应该怎么处理呢?我们选择了 Pilot 主动断开连接,不过断开连接的周期怎么定是个技术活。要考虑错开大促峰值,退避扩缩容窗口之类,这个具体值就不列出来了,大家按各自的业务场景来决定就好了。

  • Sidecar 散列重连

最后还有一点是 Client 端的配合,我们会控制 Sidecar 重连 Pilot 时,采用退避式重试逻辑,避免对 DNS 和 Pilot 造成负载压力。

性能优化

规模化的另一道难题是怎么保证服务的性能。在 Pilot 的场景,我们最关注的当然是配置下发的时效性了。性能优化离不开细节,其中部分优化是通用的,也有部分优化是面向业务场景定制的,接下来会分享下我们优化的一些细节点。

image.png

  • 首次请求优化

社区方案里 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 组件,定位于配置巡检,版本扫描等运维相关功能模块。

image.png

配置巡检的流程如下:

  1. Pilot 下发配置时,将配置的摘要信息与配置内容同步下发;
  2. MOSN 接收配置时,缓存新配置的摘要信息,并通过 Admin API 暴露查询接口;
  3. Inspector 基于控制面的 CR 和 Pod 等信息,计算出对应 MOSN 的配置摘要信息,然后请求 MOSN 接口,对比配置摘要信息是否一致;

由于 Sidecar 的数量较大,Inspector 在巡检时,支持基于不同的巡检策略执行。大体可以分为以下两类:

  1. 周期性自动巡检,一般使用抽样巡检;
  2. SRE 主动触发检查机制;

Citadel 安全方案

证书方案

Sidecar 基于社区 SDS 方案 (Secret Discovery Service),支持证书动态发现和热更新能力。同时蚂蚁金服是一家金融科技公司,对安全有更高的要求,不使用 Citadel 的证书自签发能力,而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。

我们先来看看架构图,请看图:

证书方案架构图

对整体架构有个大致理解后,我们分解下 Sidecar 获取证书的流程,一图胜千言,再上图:

Sidecar 获取证书的流程

补充说明下图中的每一步环节:

  • 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 ),方案基本如下图所示:

国密通信方案

流程如下:

  • 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 协议同步数据时,我们遇到了以下两个挑战:

  1. 大集群部署时,POD 数量在 10W 以上时,全量通信的话,每次需同步的信息在 100M 以上,性能开销巨大,网络带宽开销也不可忽视;
  2. Pod 和 CR 信息变更频繁,高频的全量推送直接制约了可拓展性,同时效率极低;

为了解决以上两个问题,就需要对 MCP 实现进行改造。改造的目标很明确,那就是减少同步信息量,降低推送频率。为此,我们强化了社区 MCP 的实现,补充了这些功能:

  1. 为 MCP 协议支持增量信息同步模式,性能大幅优于社区原生方案全量 MCP 同步方式;
  2. Citadel Agent 是 Node 粒度组件,基于最小信息可见集的想法,Citadel 在同步信息给 Citadel Agent 时,通过 Host IP ,Pod 及 CR 上的 Label 筛选出最小集,仅推送每个 Citadel Agent 自身服务范围的信息;
  3. 更进一步,基于 Pod 和 CR 的变更事件可以预先知道需要推送给哪些 Citadel Agent 实例,只对感知变更的Citadel Agent 触发推送事件,即支持局部推送能力;

未来思考

本次大促的控制面的重心在于解决规模化问题,后续控制面将会在服务发现、精细化路由、Policy As Code 等领域深入探索。我们将与社区深度合作,控制面将支持通过 MCP 对接多种注册中心(SOFARegistry(已开源), Nacos等)进行服务发现信息同步,解决大规模服务注册发现问题,支持增量推送大量 endpoint。同时控制面还能通过增强配置下发能力,为应用启动提速,将在 Serverless 极速启动场景获取技术红利。控制面还将结合 Policy As Code,从而更具想象空间,具备极简建站,默认安全等能力。

到此,本次分享的内容就结束了。Istio 生产级实践机会难得,并且任重道远。最后,欢迎有志之士加入我们,一起打造世界级规模的 Service Mesh。

作者简介

本文作者:彭泽文(花名:封尘),蚂蚁金服 Mesh 控制面主站负责人,主要 Focus 领域:Service Mesh(SOFAMosn、Istio)。

蚂蚁金服 Service Mesh 大规模落地系列文章

相关文章
蚂蚁集团 Service Mesh 进展回顾与展望
继 2019 年的 《蚂蚁集团 Service Mesh 落地实践与挑战》之后,蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年。这 3 年里有哪些新的变化,以及对未来的思考是什么,值此 SOFAStack 开源 4 周年之际,欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。
252 0
蚂蚁集团 Service Mesh 进展回顾与展望
蚂蚁Service Mesh大规模落地实践与展望
云原生的理念正如火如荼,然而真正大规模落地的公司依然屈指可数,蚂蚁作为国内比较早进行尝试的公司,经过了 2 年多的探索,沉淀出了一套切实可行的方案并最终通过了双十一的考验。
264 0
蚂蚁Service Mesh大规模落地实践与展望
蚂蚁 Service Mesh 大规模落地实践与展望
本文主要分享我们在 Service Mesh 大规模落地过程中的一些经验、社区好消息以及对未来的思考,希望能给大家带来一些启发。
蚂蚁 Service Mesh 大规模落地实践与展望
Service Mesh 在超大规模场景下的落地挑战
随着微服务软件架构在互联网企业的广泛实践,新一代微服务软件架构技术悄然兴起,Service Mesh 便是其中之一。阿里巴巴高级技术专家至简在 KubeCon 2020 阿里巴巴云原生专场分享了《Service Mesh 在超大规模场景下的落地挑战》,基于阿里巴巴的落地实践,分享一些经验和思路。本文是部分内容整理。
Service Mesh 在超大规模场景下的落地挑战
蚂蚁金服在 Service Mesh 监控落地经验总结
Service Mesh 是目前社区最为炙手可热的技术方向,去年双11在蚂蚁金服得到全面的应用,并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群,本文从监控的领域对 Service Mesh 落地进行经验总结。
1698 0
蚂蚁金服在 Service Mesh 监控落地经验总结
蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇
本文结合无线网关的发展历程,解读进行 Service Mesh 改造的缘由和价值,同时介绍蚂蚁金服在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。
1540 0
蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇
蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇
本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇,着重从 MOSN(Sidecar Proxy)的运维和风险管控方面,分享我们的实践经验。
1775 0
蚂蚁金服 双11 Service Mesh 超大规模落地揭秘
Service Mesh 是蚂蚁金服下一代架构的核心,本主题主要分享在蚂蚁金服当前的体量下,我们如何做到在奔跑的火车上换轮子,将现有的 SOA 体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案,分享蚂蚁金服 双11 核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。
蚂蚁金服 双11 Service Mesh 超大规模落地揭秘
阿里巴巴 Service Mesh 落地的架构与挑战
云原生已成为整个阿里巴巴经济体构建面向未来的技术基础设施,Service Mesh 作为云原生的关键技术之一,顺利完成在 双11 核心应用严苛而复杂场景下的落地验证。本文作者将与大家分享在完成这一目标过程中我们所面临和克服的挑战。
阿里巴巴 Service Mesh 落地的架构与挑战
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等