云原生网络代理 MOSN 透明劫持技术解读

2020 年 5 月 21 日

云原生网络代理 MOSN 透明劫持技术解读

MOSN 是一款使用 Go 语言开发的网络代理软件,作为云原生的网络数据平面,旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称,可以与任何支持 xDS API 的 Service Mesh 集成,亦可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。
MOSN: https://github.com/mosn/mosn

在由 Istio 定义的 Service Mesh 体系中,服务治理相关逻辑由独立的 Sidecar 进程处理,如服务发现、故障注入、限流熔断等等。这些处理逻辑是 Service Mesh 着重要解决的问题。通常在谈论到 Service Mesh 时,会优先关注在这些点上,但是在落地过程中,有一个问题同等重要但往往容易被忽视。这个问题概括起来,就是流量是如何被导入到 Sidecar 的监听端口的。

在数据平面的 Sidecar 中拦截进出应用容器的流量,这一直以来就是 Istio Service Mesh 中一切功能的基础,如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点,本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。

流量接管

如果服务注册 / 发布过程能够允许适当的修改,这个问题会得到极大的简化,比如服务发布方 Sidecar 将地址修改为 127.0.0.1:15001,订阅方 Sidecar 监听本机 15001 端口,当订阅方访问 127.0.0.1:15001 时,流量就自然到达了本端 Sidecar。在这种情况下,无需在网络层面使用重定向技术就可以达到目的。

服务发布订阅修改逻辑框图

流量转发流程图

如上图中,在发布服务时,Sidecar 将服务端原本的地址转换为 Sidecar 自身的端口;服务订阅时,订阅方获取到的端口则是本地 Sidecar 监听的端口。这一方案的优势很明显,逻辑都收敛在了 Sidecar 中,除了需要对 Sidecar 服务注册 / 发布流程进行改造外,不需要其他组件的参与,但是缺点也很明显,如果业务模型不存在注册中心,或者是服务发布 / 订阅 SDK 不能进行改造,这个方案就行不通了,而在 Mesh 落地场景中,这个条件恰恰较难满足。

目前大多数业务的逻辑架构都不符合 Istio 定义的云原生体系,为了享受到 Service Mesh 在服务治理方面的优势,需要选择合适的流量劫持方案。一般而言,流量劫持工作在 L4 层,在进行劫持技术选型时需要考虑三个方面的问题:

  • 第一是环境适配,包括容器、虚拟机、物理机、内核、系统发行版等方面的考虑,确保劫持方案在运行环境中能够正常工作;
  • 第二是控制灵活简单,包括如何维护劫持规则,劫持规则如何下发等;
  • 第三是性能,确保在业务运行期间,劫持本身不会带来过大的开销;

下面将从这三个层面分析 MOSN 在落地过程中的一些思考。

环境适配

在环境适配性上,最容易想到的是 iptables,作为一项古典网络技术,iptables 使用简单,功能灵活,几乎所有现代生产级内核版本与 OS 发行版都默认具备使用条件,Istio 社区也使用 iptables 做流量透明劫持。

iptables 流量劫持原理图

尽管环境适应性强,但是基于 iptables 实现透明劫持存在以下问题:

  • DNAT 模式下,需要借助于 conntrack 模块实现连接跟踪,在连接数较多的情况下,会造成较大的消耗,同时可能会造成 track 表满的情况。为了避免这个问题,可以使用 TProxy 取代 DNAT,但受限于内核版本,TProxy 应用于 outbound 存在一定缺陷;
  • iptables 属于常用模块,全局生效,不能显式的禁止相关联的修改,可管控性比较差;
  • iptables 重定向流量本质上是通过 loopback 交换数据,outbond 流量将两次穿越协议栈,在大并发场景下会损失转发性能;

针对 oubound 流量,还可以使用 hook connect 来实现,如图所示:

hook connect 逻辑框图

无论采用哪种透明劫持方案,均需要解决获取真实目的 IP/ 端口的问题,使用 iptables 方案通过 getsockopt 方式获取,TProxy 可以直接读取目的地址,通过修改调用接口,hook connect 方案读取方式类似于 TProxy。

由于 MOSN 落地的场景十分复杂,有容器与 VM 甚至物理机环境,有基于 K8s 的云原生应用,有基于注册中心的微服务,也存在单体应用,有些场景对性能要求非常高,有些则是够用即可,针对不同的场景,我们选择不同的劫持方案进行适配。如果应用程序通过注册中心发布 / 订阅服务时,可以结合注册中心劫持流量;在需要用到透明劫持的场景,如果性能压力不大,使用 iptables DNAT 即可,大并发压力下使用 TProxy 与 sockmap 改善性能。

配置管理

通常基于申明式体系构建的服务在部署时能够得到全局信息,而非申明式体系往往需要在运行期间进行动态的配置修改,由于缺乏全局信息,在运行期间很难获取到准确的服务间调用信息。在生成透明劫持规则时,我们需要明确哪些流量要被重定向到 Sidecar,否则一旦出错,而 Sidecar 又无法处理这部分流量时,将会使得 Sidecar 变成流量黑洞,比如,某一个容器内的 TCP 流量全部被重定向至 Sidecar,而该容器中存在一个使用私有协议承载应用数据的监控 Agent,而 Sidecar 不能识别该协议导致无法争取转发,只能选择丢弃。

通常情况下,为了确保 Sidecar 能够正确的转发流量,需要满足两个条件,首先是要能够正确识别协议,其次是需要配置转发规则,明确下一跳。对于不满足这两个条件的流量,不应将其重定向至 Sidecar。对于现有的非云原生应用,同时满足这两个条件的代价非常高,比如,某个虚拟机上运行了一个业务,同时还运行了收集 Metrics 的 Agent、日志采集工具、健康检查工具等等。而基于 L4 规则很难精确的将业务流量重定向至 Sidecar,如果多个业务混部,可能导致无法在 L4 层进行业务流量的区分。总结起来,为了精确的把流量引至 Sidecar,需要获得全局的调用关系,这一目标原本应该由 Service Mesh 来完成,而在流量劫持的场景下,却成为了 Service Mesh 的前提。

为了使用 Service Mesh 而引入大量的部署运维开销是得不偿失的。在落地的过程中,MOSN 引入了多项手段来降低流量劫持的配置难度。我们将需要精确配置重定向规则的工作模式定义为精确匹配,与之相对应的是模糊匹配,即不要求精确区分出需要劫持的流量。降低配置难度的关键在于取消对于精确规则的依赖,在配置模糊规则的前提下,既做到对于关心的业务流量的治理,同时也不影响非业务流量的正常流程。

我们采用 L4 规则与 L7 规则融合的方式下发模糊的匹配规则,此规则下除了包含关心的业务流量外,还可能包含预期之外的非业务流量。对于业务流量,Sidecar 根据相应的服务治理规则处理,而对于非业务流量,则保持其默认行为不变。在模糊匹配模式下,仅需要为关心的流量配置服务治理与转发规则,而无需关心 miss match 导致流量黑洞。在模糊匹配之外,MOSN 仍然保留了精确匹配能力,可以通过配置项禁用模糊匹配,能够兼容之前的工作模式。

MOSN 流量劫持模糊匹配逻辑框图

为了支持更加灵活的配置手段,在配置模糊匹配规则时,支持默认白名单与默认黑名单两种模式。默认黑名单模式适合业务场景简单,业务流量特征明显的场景,由于劫持逻辑的输入流量少,性能损耗小。默认白名单模式适合业务特征明显不明显的场景,由于劫持逻辑的输入流量多,可能存在一定的性能损耗,在这种模式下,可以显示加入黑名单排除相应的流量,比如通常业务不会使用除了 80 之外的小于 1024 的端口。

MOSN 通过模糊规则匹配的手段极大降低了流量劫持的管理成本,在部署 Service Mesh 时,仅需要“大体上正确”即可,无需担心没有完全枚举流量规则而产生流量黑洞,而借助于 Service Mesh,可以得到全局的服务调用信息,进而能够对现有服务进行精细化的治理。

数据面性能

iptables 存在一个固有问题是在匹配规则数量增多时,匹配消耗会随之增加,在规则数量较多的情况下,会对新建连接性能造成较大的影响,为了避免这种情况,可使用 ipset 降低匹配消耗。此外,在内核版本满足要求(4.16 以上)的前提下,通过 sockmap 可以缩短报文穿越路径,进而改善 outbound 方向的转发性能。

在讨论流量劫持的性能损耗时,需要结合具体的场景来看,比如某些场景中只有 iptables dnat 能够满足环境适配的要求,在这种情况下,需要考虑的是 iptables dnat 的数据面性能是否能够满足业务的需求。实际落地过程中,需要结合实际情况与运维难度选择劫持手段。

总结

本文主要为大家介绍云原生网络代理 MOSN 是如何实现透明高效的拦截的。降低劫持规则的管理成本,使得 Service Mesh 的引入不会造成额外的负担,在落地过程中,可以更加专注在业务逻辑上,能够充分满足多语言,多环境下的服务治理需求。

流量劫持技术的发展与 Service Mesh 的落地密切相关,后续我们将围绕环境适配性、低时延、低管理成本等方面持续演进,构建由 DNAT、TProxy、tc redirect、sockmap 等技术组成的多模单体底座,在不同内核环境、不同性能要求、不同管理成本的场景中自适应选取最合适的劫持技术,不断降低 Service Mesh 的接入成本。

如果大家对 MOSN 有问题以及建议,欢迎与我们交流,也非常欢迎加入 MOSN 开源社区的共建。

MOSN: https://github.com/mosn/mosn

MOSN 官网: https://mosn.io/

本文归档在 sofastack.tech。

本文转载自公众号金融级分布式架构(ID:Antfin_SOFA)。

原文链接

https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247486145&idx=1&sn=e193044d2fc97d68621b588a8d08c4e0&chksm=faa0e51bcdd76c0d4e507dcabf81b5b67a2e03b4be4f9430a43af0c2a68e39d0d53212a5c093&scene=27#wechat_redirect

2020 年 5 月 21 日 14:05 934

评论

发布
暂无评论
发现更多内容

第一周 UML图

mm马

就餐卡系统设计

golangboy

极客大学架构师训练营

架构师训练营-第一周学习总结

Geek_5c3f14

架构师

架构师方法论

wing

极客大学架构师训练营

架构师训练营第1期-Week1 架构方法学习总结

鲁小鲁

软件工程 极客大学架构师训练营 UML 架构方法

架构训练营1期-第1周练习

balsamspear

第一周命题作业 架构师训练营第一期

关于软件建模语言UML总结

solike

极客大学架构师训练营

计算机网络学习笔记:计算机网络和因特网

Liuchengz.

计算机网络

食堂就餐卡系统设计

行者

架构师训练营第一周作业

Erwa

极客大学架构师训练营

作业-2020-9-20

芝麻酱

极客大学架构师训练营

架构师训练营 - week1 - 学习总结

month

极客大学架构师训练营

第一周学习总结

mm马

极客大学架构师训练营

第一周课程学习总结

Meow

极客大学架构师训练营 第一周总结

Week 1 作業一:食堂就餐卡系統設計 (Christy羅同學)

--------世界中心---------

架構師 極客大學 女程序員

第一周学习总结

jizhi7

极客大学架构师训练营

架构师训练营第一周心得

CmHuang

架构师训练营第一期第一周课后作业

cyningchen

架构师训练营第一期

食堂就餐卡系统设计

ABS

食堂就餐卡系统设计

饭桶

极客时间架构1期:第1周架构方法-学习总结

Null

架构师训练营 第一周作业

haha

极客大学架构师训练营

Week 1 學習總結 (Christy羅同學)

--------世界中心---------

「架构师训练营第 1 期」第一周作业(作业一)

Geek_83908e

极客大学架构师训练营

第一周学习总结

饭桶

架构师训练营第一期第一周总结

cyningchen

架构师训练营第一期

独孤求败的五把剑,三个人生阶段 -Week1- 学习总结

小粽

食堂就餐卡系统设计

积极&丧

作业-食堂就餐卡系统设计

solike

极客大学架构师训练营

UML for Cafeteria System

极客食堂就餐卡系统设计

IT老兵重开始

极客大学架构师训练营 第一周命题作业

云原生网络代理 MOSN 透明劫持技术解读-InfoQ