其他
蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇
引言
Pilot 落地实践; Citadel 安全加固;
Pilot 落地实践
连接限流
熔断
定期重置
Sidecar 散列重连
首次请求优化
按需获取 & Custom Resource 缓存
局部推送
其他优化
下发时效性
配置准确性
Pilot 下发配置时,将配置的摘要信息与配置内容同步下发; MOSN 接收配置时,缓存新配置的摘要信息,并通过 Admin API 暴露查询接口; Inspector 基于控制面的 CR 和 Pod 等信息,计算出对应 MOSN 的配置摘要信息,然后请求 MOSN 接口,对比配置摘要信息是否一致;
周期性自动巡检,一般使用抽样巡检; SRE 主动触发检查机制;
Citadel 安全方案
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 ;
Pilot 负责 Policy 的下发; Citadel 负责 Certificate 下发 (基于 SDS 证书方案);
Pilot List/Watch ScopeConfig CRD 和 Policy CRD ,基于 Pod Label 选择 Pod 粒度范围实例; Provider 端 MOSN 收到 Pilot 下发的国密配置后,通过 SDS 方案获取证书,成功获取证书后,会将服务状态推送至 SOFARegistry; SOFARegistry 通知 Consumer 端 MOSN 特定 Provider 端已开启国密通信状态,重新发起建连请求;
大集群部署时,POD 数量在 10W 以上时,全量通信的话,每次需同步的信息在 100M 以上,性能开销巨大,网络带宽开销也不可忽视; Pod 和 CR 信息变更频繁,高频的全量推送直接制约了可拓展性,同时效率极低;
为 MCP 协议支持增量信息同步模式,性能大幅优于社区原生方案全量 MCP 同步方式; Citadel Agent 是 Node 粒度组件,基于最小信息可见集的想法,Citadel 在同步信息给 Citadel Agent 时,通过 Host IP ,Pod 及 CR 上的 Label 筛选出最小集,仅推送每个 Citadel Agent 自身服务范围的信息; 更进一步,基于 Pod 和 CR 的变更事件可以预先知道需要推送给哪些 Citadel Agent 实例,只对感知变更的Citadel Agent 触发推送事件,即支持局部推送能力;
未来思考
MOSN: https://github.com/sofastack/sofa-mosn SOFARegistry: https://github.com/sofastack/sofa-registry
蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述:蚂蚁金服双十一四大考题