Linkerd是世界上最小、最简单的服务网格。自Linkerd 2.0以来，我们一直遵循极简主义、可组合性的哲学，并在现有的生态系统之上构建。这个想法可能看起来有点疯狂，我将描述即将发布的Linkerd 2.10的一个特性，它将使Linkerd变得更小和更简单：扩展。

在Linkerd 2.10中，我们将Linkerd的默认控制平面安装剥离为一个基本的部署，不包括先前默认发布的Prometheus、Grafana、仪表板和其他非关键组件。由于这些变化，一个基本的Linkerd控制平面现在在启动时的大小从Linkerd 2.9的~500mb减少到200mb以下。

现在，这些组件可以作为一个可选的扩展，以及其他几个对基本操作来说不是严格必需的组件。Linkerd扩展的初始集合包括：

• viz，它将包含所有的集群度量堆栈：Prometheus，Grafana，仪表板等；
• multicluster，包含所有用于跨集群通信的机器；和
• jaeger，它将包含分布式追踪收集器和UI。

使用扩展有两个目的。首先，它允许Linkerd的使用者精确地选择他们想要安装在他们的集群上的Linkerd的哪一部分。其次，它允许Linkerd社区构建特定于Linkerd的操作器和控制器，而不必修改核心的Linkerd CLI。下面有更多相关内容。

它是如何工作的？

安装一个扩展就像你期望的那样简单。例如，要安装viz扩展，你可以运行：

linkerd install -f - | kubectl apply - # install the core control plane
linkerd viz install -f - | kubectl apply - # install the viz extension

（对于Helm用户：每个扩展将有一个相应的Helm chart。）

我们还使第三方扩展尽可能容易地连接到同一个系统中。例如，如果在用户的搜索路径中找到了linkerd-foo的二进制文件，那么调用linkerd foo将自动调用并将参数传递给linkerd-foo的二进制文件。此外，在安装之后，linkerd check将自动运行所有已安装扩展的检查，并将输出连接到一个报告中。

不管来自哪里，扩展应该“感觉”就像Linkerd的其他部分一样。

为什么这样做呢？

随着Linkerd的采用持续急剧增长，它必须处理的用例集也在不断增长。对于一些用户来说，开箱即用的可观察性是他们采用Linkerd的关键原因。对于其他人来说，它是安全的跨集群通信。还有一些是Linkerd的透明的默认mTLS。这种用例的多样性是很好的，但也给项目带来了压力——尤其是我们关注的是简单性。

到目前为止，我们以一种相对临时的方式处理这个问题，包括多集群组件的自定义安装流程、专门的“带来你自己的Prometheus”特性等等。将所有这些机制转移到扩展框架中可以实现一致性：现在可以以完全相同的方式对待这些特性扩展。

最后，让我们兴奋的想法是，允许Linkerd的特性感觉上就像Linkerd的其他部分，但不需要修改核心项目。