从 Istio 服务网格的基础知识到它的好处，这篇文章涵盖了你需要知道的关于 Istio 服务网的一切，以及 eBPF 在其中的作用。
Sidecar 的概念在容器和微服务的领域中非常流行，因此，人们很容易把 Sidecar 看作是云原生技术栈的一个自然的、健康的部分。
但是，如果你仔细想，你就会发现 Sidecar 并没有想象中的那么伟大。毕竟，它们被称为“Sidecar”，意思是说，你可以在摩托车上安装边车（就是 Sidecar 的字面含义），如果你想携带的东西摩托车本身无法携带的话。虽然 Sidecar 可以解决摩托车承载能力不足的问题，但是它们也会大幅拖慢摩托车的速度，并且使摩托车更难驾驶。典型的摩托车手都没有安装 Sidecar 是有原因的。
幸运的是，微服务应用也不再需要被 Sidecar 拖累了。多亏了 eBPF 这样的技术，我们才有可能在分布式应用中完成 Sidecar 曾经做过的事情，而不会有它们带来的弊端。
为了说明这个原因，我们先来看一下 Sidecar 以及像 Istio 这样的服务网格的作用，它们是云原生应用的一部分。接下来，我们将看看 eBPF 是怎样让 Istio 和传统的服务网格更加简单和高效的。
什么是服务网格？
服务网格是技术栈中的一层，它帮助连接、保护和监控分布式应用的各种组件。
如果你的应用程序是一个单体，你通常不会使用服务网格，也就是说，它是作为一个单一的进程运行，没有复杂的依赖关系，也没有进程之间的通信网格。但是，如果你转向使用微服务架构时，你就会面临着管理离散的微服务之间通信的挑战。你还需要确保微服务事务的安全性，还需要有一种有效的方式来收集每个微服务的可观察性数据。
如果你愿意，你可以通过在微服务本身的代码中插入指令来处理这些需求。但是这样做并不能使开发者满意，因为这就意味着他们要花很多时间去编写和维护每一个微服务中的定制代码来处理连接性、安全性和遥测。
服务网格通过提供管理服务的集中化手段来解决这个问题。从本质上讲，服务网格让开发者可以将很多管理微服务的连接性、安全性和可观察性所需的大部分工作外包给一个专门的基础设施层，而不是在微服务本身中处理这些任务。通过这种方式，服务网格就可以使微服务的管理更加简单、标准化。
Sidecar 与服务网格
当然，服务网格不可能神奇地与微服务进行对话或整合。它们需要一种连接它们的方法。从传统意义上讲，这意味着涉及所谓的“Sidecar 模式”。
在 Sidecar 模式下，你在主应用容器旁边部署一个特殊的容器，称为 Sidecar，主应用容器承载着每个微服务的业务逻辑。Sidecar 承载着一个服务网格代理，负责管理微服务。如果你在同一个 Pod 内运行 Sidecar 和主容器，Sidecar 容器可以与主容器集成，以执行你在服务网格中定义的任何治理规则。
从历史上看，Sidecar 模式对于管理作为容器部署并使用 Kubernetes 协调的分布式应用中的微服务有很大的意义。在没有更好的技术将服务网格连接到单个应用容器的情况下，在实际的微服务旁边部署 Sidecar 容器是将服务网格编织到微服务架构中的一种简单而直接的方式。
为什么大家都喜欢 Istio
现在有很多服务网格，比如 Linkerd 和 Traefik。但最流行的解决方案可能是 Istio，这是一种开源的服务网格，专门为以 Kubernetes 为中心的堆栈设计。
Istio 通过提供两个主要组件来实现服务网格。
数据平面：依靠运行 Envoy 代理的 Sidecar 容器来与各个微服务对接。控制平面：它作为一个集中式进程运行，以提供服务发现、强制配置和安全流量。
Istio 的开源性质，以及它对 Kubernetes 的友好设计，使该工具成为迄今为止成千上万的云原生托管堆栈的核心部分。
Istio 的黑暗面
Istio 和其他依赖于 Sidecar 模式的服务网格解决了真正的问题，你当然不能责怪任何人使用它们——尤其是在没有真正的替代方案可用时。
但是，如果你要设计一个完美的解决方案来管理连接、保护和观察分布式应用的挑战，那么像 Istio 这样的服务网格就不可能了。Istio 和类似的网格存在两个关键问题：高资源消耗和缓慢的性能。
资源开销
在分布式托管环境中，每一个微服务旁边都要运行一个 Sidecar 容器，这使得你运行的容器总数翻倍。这意味着你的应用程序最终会消耗更多的资源。除了 Sidecar 容器本身消耗的资源外，编排器还必须花更多的精力来管理 Sidecar，而你在部署和更新 Sidecar 时也会消耗更多的网络带宽。
当你占用了运行 Sidecars 的资源时，你的实际应用可用的资源就会减少，这可能会在需求高峰期转化为较低的性能。它也可能造成更高的托管成本，因为你最终需要更多的节点（或更昂贵的节点，有更高的资源分配）来处理你的工作负载。
性能和延时
除了托管 Sidecar 的成本外，当网络流量流入和流出每个微服务时，Sidecar 容器还会将自己“插入”网络流量的中间，这一事实也会对性能产生拖累。在你的应用程序能够接收和响应请求之前，每个数据包都必须通过 Sidecar，这就增加了延迟，并可能对你的用户体验产生负面影响。
从数据上看，Istio 的表现不佳
如果你想知道 Sidecar 容器的性能开销是否真的可以忽略不计，让我们不妨看看 Istio 自己记录的关于性能的数据。
虽然性能开销会根据你对 Istio 的具体配置而有所不同（你使用的功能越多，开销就越大），但 Istio 说每个 Envoy 代理每 1000 个请求会消耗 0.35 vCPU 和 40MB 内存。
因此，如果你有 10 个微服务，并为每个微服务部署一个 Envoy Sidecar，你将需要额外的 3.5 个 vCPU 和 400 兆的内存来托管它们。这很容易转化为相当于一个额外的虚拟机实例，只是为了运行这些 Sidecar。（我们甚至不提控制平面，根据 Istio 的说法，它还需要 1 个 vCPU 和 1.5GB。）
还要注意的是，Istio 表示，每个代理容器平均会在第 90 个百分点的延迟上增加 2.65 毫秒。因此，只要你的响应需要通过一个 Sidecar，你就会减慢这个数字。诚然，2.65 毫秒不是很大，但在一个每一毫秒都很重要的世界里，它可能是破坏性的，特别是对于需要真正实时执行的应用程序。
再见，Sidecar；你好，eBPF！
以往，开发人员和 IT 团队都认为，Sidecar 容器的性能和延迟成本都是必要的。使用带有 Sidecar 模式的服务网格比不使用服务网格和不得不在每个微服务中进行管理要容易得多，因此，为了在服务网格中对微服务进行集中管理，它们愿意为托管支付更多的费用和 / 或接受性能上的影响。
然而，今天，一个更好的世界已经成为可能——因为 eBPF 可以在不需要处理内核模块或者修改内核源的情况下，就可以直接在 Linux 内核中运行超高效、超安全的动态代码。
对于需要服务网格的工程师来说，这意味着，使用 eBPF，传统上使用 Sidecar 容器实现的微服务治理可以通过 eBPF 程序在内核中处理。由于 eBPF 程序可以在 Kubernetes 集群中的每个（基于 Linux 的）节点上运行，它们可以从内核中直接管理微服务的连接性、安全性和可观察性，而不是作为单独的服务网格运行。
这种方法将解决与 Istio 等传统服务网格相关的几个挑战。
性能：由于 eBPF 程序消耗的资源极少，与使用 Sidecar 结构相比，它们将极大地减少运行服务网格的开销。
简单性：一个基于 eBPF 的服务网格将消除部署和管理一套 Sidecar 容器的需要。
可见性控制：通过直接在内核中运行，eBPF 程序在它们可以从容器中访问哪些数据以及它们可以对其进行哪些控制方面几乎拥有无限的范围。在这方面，基于 eBPF 的网格将比那些依赖 Sidecar 容器的网格更加强大。
eBPF 有许多用例，利用它来解决传统服务网格的缺点仍然是一个相对较新的想法。然而，开发人员正对这一战略投入越来越多的关注，Cilium 已经实施了这一战略。
eBPF 的光明前景
所以，如果你正在寻找另一个原因，为什么 eBPF 正在彻底改变开发者在分布式应用中跨越所有层的安全、可观察性和管理的方式，请将 eBPF 作为服务网格解决方案的潜力加入你的列表。除了更容易为观察目的收集丰富的数据，并在容器内和容器之间移动时保护数据，eBPF 可能会从 Istio 等服务网格中夺得桂冠，成为管理微服务之间互动的更简单、更有效、更少资源消耗的解决方案。
这并不是说 Istio 或其同类产品会完全消失。我们可以想象这样的一个世界：Istio 控制平面仍然存在，但数据平面由 eBPF 程序驱动，而不是在 Sidecar 容器中运行的 Envoy 代理。Istio 已经为服务发现和配置管理开发了很多强大的技术，这些功能在基于 eBPF 的服务网格中仍然适用。
但我们预计，在未来几年里，Sidecar 容器会显得越来越过时 -- 就像摩托车上的边车一样。那些优先考虑速度和效率的人将转向 eBPF，作为摆脱 Sidecar 限制的一种手段。
作者简介：
Shahar Azulay，Groundcover CEO。
原文链接：
https://www.groundcover.com/blog/istio-service-mesh
相关阅读：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 1 条评论