作者 | William Morgan
译者 | 平川
策划 | 褚杏娟
本文最初发布于 Linkerd 官方博客。
今年对于 Linkerd 是个好年景。尽管软件行业的大部分都在经济衰退中苦苦挣扎，但 Linkerd 的应用却一直在增长。事实上，日志指标显示，运行 Linkerd 的稳定 Kubernetes 集群数量在 2022 年翻了一番。Linkerd 可能是唯一一个从 CNCF 毕业的服务网格，但它肯定不会因为毕业而放缓发展的脚步！
这种增长从何而来？为什么是现在？基于 2022 年与新采用者的交流，我们认为情况是这样的：由于极端的炒作，再加上炒作最厉害的项目相对并不成熟且比较复杂，服务网格在早期的名声并不好。早期的采用者决定等到一切尘埃落定时再说。现在，他们回来了，他们看到了第一次的事儿，正渴望着有一种不会让他们背负众所周知的操作复杂性的选择。
自然地，他们转向了 Linkerd，因为简单，它成了服务网格领域一个独特的存在。Linkerd 的主要优势在于它的数据平面。Linkerd 是唯一一个避开了 Envoy 的服务网格，它把重点放在了专用的边车（sidecar）“微代理”上。在 2018 年，这是一个有争议的决定；在 2022 年，事实证明这种方法可以带来巨大的回报。当其他项目花费时间为其数据平面的复杂性和资源消耗构建变通方案时，Linkerd 却专注于提供强大的功能，如多集群故障转移和基于 Gateway API 的完整 L7 授权策略。
但 2022 年，也并非完全像我们想象的那样。这一年里，即使是我们这些“头发花白”的老兵也得到了一些教训，同时也得到了一些真正的惊喜。以下是 2022 年让我们感到惊喜的几件事。
1 惊喜 1：Kubernetes 的 Gateway API 非常适合服务网格
到目前为止，Gateway API 是我们 2022 年最大的惊喜，实际上，它还让我们中途更改了计划。年中，当时我们正在最终确定 Linkerd 的 L7 授权功，Gateway API 在 Kubernetes 进入了 Beta 测试。当我们更深入地研究这个项目时，我们意识到了几件事：
  1. 它已经解决了我们正在 Linkerd 2.12 中处理的一个主要问题：如何以一种全面、可组合、kubernetes 式的方式描述一类 HTTP 流量（例如，“所有以 /foo/ 开头的东西”或“所有有这个报文头的东西”）。
  2. 虽然已经计划在 Linkerd 中添加 CRD，但我们并不情愿，而 Gateway API 资源已经是 Kubernetes 的一部分。
  3. 它的设计很好。真的很好。虽然它最初是为处理 Ingress 配置而设计的，但核心原语足够灵活，而且可组合，因此，它实际上也适用于服务网格用例。
因此，我们放弃了最初的计划，转而采用 Gateway API 作为 Linkerd 授权策略的核心配置机制。尽管这会使 2.12 版本的发布推迟几个月，但我们知道，这是在为 Linkerd 的采用者做正确的事。
这个决定已经有了回报。在即将发布的 2.13 版本中，我们将利用 Gateway API 资源类型来实现诸如基于头的路由和可配置的断路等功能。Linkerd 还参与了 GAMMA 计划，这是 Gateway API 中的一个项目，目的是更好地追踪服务网格用例。
延伸阅读：Linkerd 和 Gateway API（https://buoyant.io/blog/linkerd-and-the-gateway-api）。
2 惊喜 2：eBPF 是一项优化，而不是游戏规则改变者
当围绕服务网格 eBPF 的讨论在 2022 年年初达到顶峰时，我们决定进行更深入的研究。我们发现，那并没有我们希望的那么引人注目。虽然 eBPF 可以简化一些基本的服务网格任务，如转发原始 TCP 连接，但如果没有用户空间组件，它根本就无法处理 HTTP/2、mTLS 或其他 L7 任务，这意味着它无法带来根本性的改变——即使使用 eBPF，服务网格在集群上某个地方仍然会需要 L7 代理。
尤其是被大肆吹捧的“无边车 eBPF 服务网格”模型，感觉在可操作性和安全性方面是重大的倒退。将那种逻辑移到针对每个主机的 Envoy 代理中，将网络问题和节点上所有东西的 TLS 密钥资料混合在一起，这彻底违背了我们将事物容器化的初衷。eBPF 不是每个主机都需要的方式，营销资料中却将两者混为一谈，我们对此感到失望。
未来，我们确实计划研究将 eBPF 作为一种简化 Linkerd L4 特性集的方法，不过，将关键代码转移到内核中的前景还是让我们感到担忧，因为在内核中调试、观察和推理都非常困难。(更不用说 eBPF 引入的新的令人兴奋的攻击向量了。)
总的来说，我们对 eBPF 的调查并没有让我们真正相信 eBPF。但是与以往任何时候相比，我们都更相信边车仍然是服务网格的最佳模型，无论是出于操作还是安全考虑。
延伸阅读：eBPF、边车和服务网格的未来（https://buoyant.io/blog/ebpf-sidecars-and-the-future-of-the-service-mesh）。
3 惊喜 3：Ambient Mesh
很快，Istio 的无边车“Ambient Mesh”模式加入了无边车 eBPF 服务网格，该模式组合使用每主机和每服务代理。深入研究这种方法是我们的又一个学习经历。我们很高兴地看到，它的安全性更好，至少在这里是这样：例如，不同身份的 TLS 密钥资料在单独的进程中维护。
然而，取消边车的代价非常大：需要大量的新机器，其结果有很大的局限性，而且对性能有重大的影响。
总的来说，我们得出的结论是，它在生命周期管理和资源消耗方面的改进对 Linkerd 的用例并没有助益。我们的感觉是，Ambient Mesh 比其他任何东西都更能解决大规模运行 Envoy 的问题。
4 意料之中的事 1：容器排序仍然是 Kubernetes 的弱点
除了惊喜，2022 年，我们还看到了一些意料之中的情况。与前几年一样，Linkerd 的采用者继续与长期困扰 Kubernetes 的问题——缺少对容器排序的控制——做斗争。这体现在多个方面：
  • 需要访问网络的 Sidecar 容器需要在 linkd-init 容器之后运行；
  • 终止的作业需要有一种方式可以向其代理组件发出终止信号；
  • 重新启动或添加到现有集群的节点需要一种方法来暂停 Linkerd 网络初始化，直到 CNI 层初始化完成；
  • 等等。
在特定的情况下，这些问题都是可以解决的。但对于服务网格采用者来说，这类问题仍然是一个麻烦，并且严重地违反了我们的原则，即服务网格应该对应用程序透明。然而，随着臭名昭著的边车 KEP 走上了这条愚蠢的道路，我们可能还要忍受更长的时间。
虽然，关于另一个 KEP 的谣言甚嚣尘上……
就是这样，但经过多次讨论，我认为我们现在对如何做一种每个人都可以接受的形式有了很好的了解:)
——蒂姆·霍金（thockin.yaml）（@thockin）2022 年 11 月 11 日
延伸阅读：在启动时到底发生了什么：Linkerd、初始化容器、CNI 等等（https://linkerd.io/2022/12/01/what-really-happens-at-startup-linkerd-init-containers-the-cni-and-more/）。
5 意料之中的事 2：安全性仍然是采用 Linkerd 的主要动力
与前几年一样，采用 Linkerd 的主要动力仍然是安全性。Linkerd 的零配置 Mutual TLS 一直是该项目的一个主要吸引力来源，2022 年引入的 L7 授权策略完善了 Linkerd 的零信任特性集。
我们也很高兴地看到，市场显现出了日益成熟的迹象。几年前，“我们需要在传输过程中加密”是采用 mTLS 的主要理由。2022 年，我们听到许多采用者说，“是的，我们需要在传输过程中加密，但也需要使用真实的工作负载标识进行身份验证，以及在每个 Pod 上实现零信任授权”。零信任正变得越来越受欢迎，这已经不是什么秘密了，基于边车的服务网格如果不直接实现零信任原则，就什么都不是。边车模型再得一分！
像往常一样，我们也尽量保持项目的整洁，Linkerd 出色地完成了年度安全审计。
6 2023 年服务网格会带来什么？
2023 年有望成为 Linkerd 公司又一个辉煌的年份。我们已经有了一些令人兴奋不已的计划，从即将发布的 2.13 版本（包括基于头的路由和断路），到其他一些目前还保密的杀手级想法。一如既往，我们将专注于保持 Linkerd 简单、轻便和安全。
想参与 CNCF 第一个也是唯一一个毕业的服务网络吗？现在就是加入的好时机。
原文链接：
https://linkerd.io/2022/12/28/service-mesh-2022-recap-ebpf-gateway-api/index.html
声明：本文为 InfoQ 翻译，未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐
从大前端“穿越”到终端，开发者应该必备什么技能？| 解读终端的 2022
VS Code 有多么不安全：一个扩展就可能导致公司 GitHub 中的所有代码被擦除？
清华应届硕士炮轰字节：恶意低薪，硕士白读还倒贴；马云不再实际控制蚂蚁；开源 ROM 魔趣创始人宣布删库跑路｜Q 资讯
百万用户逃离Twitter转向这个小众社交平台，互联网中心化终将走向大溃败？
继续阅读
阅读原文