2022年的服务网格：Linkerd的下一步是什么？

作者：William Morgan

（Photo by Xan White on Unsplash.）

大家都说，2021 年对 Linkerd 来说是标志性的一年。该项目获得了云原生计算基金会（Cloud Native Computing Foundation）的毕业资格，这是项目成熟度的最高级别。它引进了授权策略和扩展等主要特性。Linkerd 团队在欧洲 Kubecon 会议上重点介绍了 Linkerd 用于抗击 COVID-19 的多种方式；它发布了多个基准测试，显示其性能和资源使用领先于 Istio 一个数量级；它继续引领着将 Rust 带入云原生空间的潮流。Linkerd 在今年的使用率直线上升，微软、标准普尔全球公司、挪威劳工和福利管理局以及其他许多组织都公开采用了 Linkerd。

最重要的是，在 2021 年，Linkerd 通过提供零配置双向 TLS 和基于身份的授权等关键特性，帮助全球数千家组织采用现代的零信任方法来保护 Kubernetes 集群。对于一个几年前还在试图向世界解释什么是服务网的项目来说，这并不算太寒酸！

当然，我们不是那种吃老本的项目。我们一直在为明年计划一个非常激动人心的路线图——看看 Linkerd 明年的日程安排吧。

客户端策略

在 2022 年，我们将致力于添加一些非常重要的东西到 Linkerd：客户端策略，或控制流量的能力，允许出网格 pod。客户端策略涵盖了大量的特性，包括：

• 基于 header 的路由：基于请求报头路由流量的能力。这将开启一组高级功能，特别是在涉及到一组服务中的路由时。
• 断路：自动关闭对过载服务的请求的能力。虽然 Linkerd 复杂的负载平衡和 Kubernetes 现有的健康检查机制已经提供了一个基本的断路形式，但仍然有一些很好的理由想要提供更明确的配置。
• 出口（Egress）控制：防止流量类型离开集群的能力。虽然这在出口网关之类的东西上是可能的，但这是客户端策略需要包含的自然特性，因为数据平面代理可以直接执行这些策略。
• ……还有更多。

Linkerd 实际上已经有了一个基本形式的客户端策略，即 ServiceProfiles，它允许你控制调用者对服务的重试行为。在 2.12 及以后的版本中，我们将重新访问 ServiceProfiles，并以更系统的方式处理这一类重要的特性。

多集群故障转移

我们看到了 Linkerd 用户对在出现故障时跨集群自动路由流量的兴趣明显增加。对于跨区域或云分布多个集群的用户，这种能力对于可用性目标、灾难恢复等至关重要。

Linkerd 已经为此提供了基本的构建块，我们将在这些构建块的基础上构建机制，以安全合理的方式实现自动、跨集群、每个服务的故障转移。

细粒度的授权策略

在 Linkerd 2.11 中，我们引入了服务器端策略，它让你控制允许进入（而不是离开）网格 pod 的流量。服务器端策略向 Linkerd 添加了一些重要的特性，比如授权策略，它基于工作负载标识等特性限制 pod 到 pod 连接。

我们将扩展这个模型，不仅涵盖工作负载标识，还包括 gRPC 方法、HTTP 动词和路由等，这样的策略，如“只允许从 Foo 命名空间的客户端通过 mTLS 的连接向/度量端点发送 GET 请求”是可能的。

网状扩展和 SPIFFE 支持

2022 年，我们将致力于让 Linkerd 的数据平面在 Kubernetes 之外工作。这意味着 Linkerd 用户将能够将 Kubernetes 之外的服务结合起来，并获得与现在 Kubernetes 服务相同的可靠性、可观察性和安全性保证。

今天，你已经可以在 Kubernetes 之外运行 Linkerd 的超轻、超快 Rust 代理了。然而，为了将 Linkerd 的操作保证（特别是围绕安全性）扩展到非 kubernetes 环境，我们需要概括一些现有的 Linkerd 特性，特别是它提供工作负载标识的方式。我们将 SPIFFE 标准视为一种以非 kubernetes 特有的方式实现这一点的方法。

Linkerd 1.x 的寿命结束

到 2022 年，Linkerd 1.x 将正式报废。1.x 分支已经处于维护模式很长一段时间了，随着最近对 Linkerd 的采用爆炸式增长，我们现在需要把精力完全集中在 Linkerd 2.x 上。

WebAssembly 呢？

我们正在密切关注 WebAssembly（Wasm）。作为特性交付的通用机制，它对 Linkerd 来说并没有什么意义：Wasm 带来了巨大的运行时性能损失，对于特定的特性，最好在代理中直接实现它们。（开发我们自己的代理的众多优势之一是，我们可以简单地做到这一点，无需大张大擂，也无需在项目之间寻找相互竞争的目标。）然而，作为一种支持终端用户插件的机制，Wasm 对 Linkerd 来说可能很有意义，我们也正从这个角度来评估它。

eBPF 呢？

我们正在密切关注 eBPF。作为一种使网络代码更快的技术，我们完全支持它，从这个意义上说，你现在可以同时使用 Linkerd 和 eBPF。作为“用每个节点的 Envoy 实例替换 sidecars”或“通过将所有逻辑放入内核来替换 sidecars”的想法，我们并不信服。我们对 Linkerd 1 中的每个节点模型非常熟悉。在设计 Linkerd 2.x 时，我们明确地远离了它。在 2.x 中移动到边车（每个 pod）代理，动机是基于我们在 Linkerd 1.x 中看到的各种问题，包括混乱的故障域，安全问题的分离，以及混乱的副问题。

当然，性能和资源消耗是服务网格的关键——我们已经定期发布竞争性服务网格基准，并为 Linkerd 所处的位置感到自豪。但是，套用 Louis Ryan（！）的话来说，维持最后一点性能远没有拥有良好的维护和隔离单元重要。我们从 Linkerd 1.x 中学到了这个惨痛的教训。

无论是用户空间还是内核空间，我们还没有看到任何挑战我们的信念，即 sidecar 模型使与服务网格交互和操作的人，从根本上变得更容易。

2022 年将是 Linkerd 的又一个伟大的一年

不用说，还有很多令人兴奋和有趣的工作，正在计划之中，但没有列入这个列表。如果以上任何一种听起来令人兴奋或有趣，我们希望你的帮助。如果你有功能需求，或者认为我们上面的分析完全错了，请告诉我们。如果你只是想坐下来，让功能滚动，这也很好！毕竟，Linkerd 适合所有人。

Linkerd 适用于所有人

Linkerd 是云原生计算基金会的一个毕业项目。Linkerd 致力于开放治理。如果你有功能要求，问题，或评论，我们希望你加入我们快速增长的社区！Linkerd 托管在 GitHub 上，我们在 Slack、Twitter 和邮件列表上有一个蓬勃发展的社区。快来加入乐趣吧！