随着服务网格架构理念的深入人心,它的适用场景也慢慢为众人所了解,社区中也不乏争论,甚至是质疑的声音。笔者以在云原生和服务网格社区中多年的观察,将从亲历者的角度总结服务网格在 2021 年的进展。因为当前在国内 Istio 几乎是服务网格的代名词,本文也将主要从 Istio 的技术和生态层面来解读服务网格在 2021 年的发展。
作为 CNCF 定义的云原生关键技术之一,服务网格发展至今已经有五个年头了,其发展经历了以下几个时期:
如果根据“跨越鸿沟”理论,服务网格已经跨越了“鸿沟”,处于“早期大众”和“晚期大众”阶段之间。根据《Istio 大咖说》观众中的反馈来看,用户已不再盲从于新技术,开始辩证的考虑是否真的需要引入服务网格。
云原生的发展方兴未艾,虽然不断有新的技术和产品出现,但作为整个云原生技术栈的一部分,服务网格在过去一年里不断夯实了它作为“云原生网络基础设施”的定位。下图展示了云原生技术栈模型,其中每一层有一些代表性的技术来定义标准。作为新时代的中间件,服务网格与其他云原生技术交相辉映,如 Dapr(分布式应用程序运行时)定义云原生中间件的能力模型,OAM 定义云原生应用程序模型等,而服务网格定义的是云原生七层网络模型。
过去一年中,社区的焦点主要集中在以下几个方面:
Istio 设计之初的目标就是通过“原协议转发”的方式服务于服务间流量,让服务网格尽可能对应用程序“透明”,从而使用了 IPtables 劫持流量,根据社区提供的测试结果,对于在 16 个连接上具有 1000 RPS 的网格,Istio 1.2 仅增加了 3 毫秒的基准延迟。但是,因为 IPtables conntrack 模块所固有的问题,随着网格规模的扩大,Istio 的性能问题开始显现。关于 Istio sidecar 的资源占用及网络延迟的性能优化,社区给出了以下解决方案:
如何扩展 Istio 一直以来就是一个老大难的问题。Istio 的可扩展包含两方面:
Istio 使用的是 Envoy 作为数据平面,扩展 Istio 本质上就是对 Envoy 功能的扩展。Istio 官方目前给出的方案是使用 WebAssembly,并在 Istio 1.12 引入 Wasm 插件配置 API 用于扩展 Istio 生态,Istio 的扩展机制使用 Proxy-Wasm 应用二进制接口(ABI)规范,提供了一套代理无关的流媒体 API 和实用功能,可以用任何有合适 SDK 的语言来实现。截至目前,Proxy-Wasm 的 SDK 有 AssemblyScript(类似 TypeScript)、C++、Rust、Zig 和 Go(使用 TinyGo WebAssembly 系统接口)。
目前 WebAssembly 扩展应用还比较少,很多企业选择自定义 CRD,基于 Istio 构建服务网格管理平面。另外,让 Istio 支持异构环境,适用于一切工作负载,如虚拟机、容器,这个对于终端用户来说也有很强的需求,因为这可以让用户很方便的从传统负载迁移应用到服务网格中。最后是多集群、多网格的混合云流量管理,这个属于比较高阶的需求了。
在服务网格概念兴起之初就有 Per-node 和 Sidecar 模式之争,他们的代表分别是 Linkerd 和 Istio。后来 eBPF 提出将服务网格下沉的内核,从而演化出了更多的服务网格部署模式,如下图所示。
下表中详细对比了这四种部署方式,它们各有优劣,具体选择哪种根据实际情况而定。
模式 | 内存开销 | 安全性 | 故障域 | 运维 |
---|---|---|---|---|
Sidecar 代理 | 因为为每个 pod 都注入一个代理,所以开销最大。 | 由于 sidecar 必须与工作负载一起部署,工作负载有可能绕过 sidecar。 | Pod 级别隔离,如果有代理出现故障,只影响到 Pod 中的工作负载。 | 可以单独升级某个工作负载的 sidecar 而不影响其他工作负载。 |
节点共享代理 | 每个节点上只有一个代理,为该节点上的所有工作负载所共享,开销小。 | 对加密内容和私钥的管理存在安全隐患。 | 节点级别隔离,如果共享代理升级时出现版本冲突、配置冲突或扩展不兼容等问题,则可能会影响该节点上的所有工作负载。 | 不需要考虑注入 Sidecar 的问题。 |
Service Account/节点共享代理 | 服务账户/身份下的所有工作负载都使用共享代理,开销小。 | 工作负载和代理之间的连接的认证及安全性无法保障。 | 节点和服务账号之间级别隔离,故障同“节点共享代理”。 | 同“节点共享代理”。 |
带有微代理的共享远程代理 | 因为为每个 pod 都注入一个微代理,开销比较大。 | 微代理专门处理 mTLS,不负责 L7 路由,可以保障安全性。 | 当需要应用 7 层策略时,工作负载实例的流量会被重定向到 L7 代理上,若不需要,则可以直接绕过。该 L7 代理可以采用共享节点代理、每个服务账户代理,或者远程代理的方式运行。 | 同“Sidecar 代理”。 |
2021 年,Istio 社区也是精彩纷呈,举办了系列的活动,还发布了系列教程:
此外还有众多与 Istio 服务网格相关的项目开源,如下表所示。
项目名称 | 开源时间 | 类别 | 描述 | 主导公司 | Star 数量 | 与 Istio 的关系 |
---|---|---|---|---|---|---|
Envoy | 2016 年 9 月 | 网络代理 | 云原生高性能边缘/中间服务代理 | Lyft | 18700 | 默认的数据平面 |
Istio | 2017 年 5 月 | 服务网格 | 连接、保护、控制和观察服务。 | 29100 | 控制平面 | |
Linkerd2 | 2017 年 12 月 | 服务网格 | 适用于 Kubernetes 的轻量级服务网格。 | Buoyant | 7900 | 服务网格的另一种实现 |
Emissary Gateway | 2018 年 2 月 | 网关 | 用于微服务的 Kubernetes 原生 API 网关,基于 Envoy 构建 | Ambassador | 3600 | 可连接 Istio |
APISIX | 2019 年 6 月 | 网关 | 云原生 API 网关 | API7 | 8100 | 可作为 Istio 的数据平面运行也可以单独作为网关 |
MOSN | 2019 年 12 月 | 代理 | 云原生边缘网关及代理 | 蚂蚁 | 3500 | 可作为 Istio 数据平面 |
Slime | 2021 年 1 月 | 扩展 | 基于 Istio 的智能服务网格管理器 | 网易 | 236 | 为 Istio 增加一个管理平面 |
Tetrate Istio Distro | 2021 年 2 月 | 工具 | Istio 集成和命令行管理工具 | Tetrate | 95 | 第一个 Istio 开源发行版和多版本管理工具 |
Aeraki | 2021 年 3 月 | 扩展 | 管理 Istio 的任何七层负载 | 腾讯 | 330 | 扩展多协议支持 |
Layotto | 2021 年 6 月 | 运行时 | 云原生应用运行时 | 蚂蚁 | 393 | 可以作为 Istio 的数据平面 |
Hango Gateway | 2021 年 8 月 | 网关 | 基于 Envoy 和 Istio 构建的 API 网关 | 网易 | 253 | 可与 Istio 集成 |
回望 2021 年,我们可以看出用户对服务网格的追求更趋实用,作为云原生网络的基础设施,其地位得到进一步夯实,更重要的是服务网格生态渐起。展望 2022 年,有两个值得关注的技术是 eBPF 和 WebAssembly。我们有理由相信,更多的服务网格实践优秀案例出现,在生态和标准化上更进一步。
最后更新于 2024/10/08