年度总结

xDS 的支持逐渐完善，xDS v2 API逐渐稳定
各种功能逐渐丰满

3 - 2018年Conduit动态

Condoit发布0.5.0版本之后，改名为Linkerd2

2018-02-01 Conduit 0.2.0 发布

https://github.com/linkerd/linkerd2/releases/tag/v0.2.0

新增对 HTTP/1.x 和 TCP 的支持

2018-02-22 Conduit 0.3.0 发布

https://github.com/linkerd/linkerd2/releases/tag/v0.3.0

主要是改进telemetry
conduit从experimental改为alpha

2018-04-17 Conduit 0.4.0 发布

https://github.com/linkerd/linkerd2/releases/tag/v0.4.0

继续改进telemetry（重点是Prometheus）和服务发现

2018-07-05 Conduit 0.5.0 发布

新增对 TLS 的支持

2018-07-06 博客：Conduit 0.5.0 and the future of Conduit

https://linkerd.io/2018/07/06/conduit-0-5-and-the-future/

We’re also happy to announce that 0.5.0 will be the last major release of Conduit. Conduit is graduating into the Linkerd project to become the basis of Linkerd 2.0.

我们也很高兴地宣布，0.5.0将是Conduit的最后一个主要版本。Conduit将毕业于 Linkerd 项目，成为 Linkerd 2.0的基础。

Why merge Conduit into Linkerd? When we launched Conduit in December 2017, our hypothesis was that we could build a dramatically simpler solution to the problems that we’ve spent the last several years helping Linkerd users tackle: monitoring, reliability, and security of their cloud native applications. Furthermore, we were pretty sure that we could do this using only a small fraction of the system resources that Linkerd requires. But this was a risky move, and it didn’t feel right to our many Linkerd production users to call it “Linkerd” until we were sure it would be successful.

为什么将Conduit并入Linkerd？当我们在2017年12月推出Conduit时，我们的假设是，我们可以建立一个非常简单的解决方案来解决我们在过去几年中帮助Linkerd用户解决的问题：他们的云原生应用程序的监控、可靠性和安全性。此外，我们非常确定，我们只需使用Linkerd所需系统资源的一小部分就可以做到这一点。但这是一个冒险的举动，对于我们的许多Linkerd生产用户来说，在我们确定它将获得成功之前，将其称为 “Linkerd” 是不合适的。

Happily, after seven months of iterating on Conduit, it’s clear to us that Conduit is worthy of bearing the Linkerd name. Conduit’s lightning-fast Rust proxies are ~10mb per instance, have sub-millisecond p99 latencies, and support HTTP/1.x, HTTP/2, and gRPC. Conduit can be installed in seconds on almost any Kubernetes cluster and applied incrementally to just the services you’re interested in. Conduit’s telemetry support is best in class and, like TLS, comes “for free” without requiring any application changes. Most importantly, the community around Conduit has dramatically ramped up over the past few months, with contributors, production users, and, of course, lots of GitHub stars!

令人高兴的是，在对Conduit进行了7个月的迭代之后，我们清楚地看到，Conduit值得以Linkerd的名义出现。Conduit的闪电式Rust代理每个实例约10MB，具有亚毫秒级的p99延迟，并支持HTTP/1.x、HTTP/2和gRPC。Conduit可以在几秒钟内安装到几乎所有的Kubernetes集群上，并逐步应用于你感兴趣的服务。Conduit的遥测支持是同类中最好的，而且像TLS一样，“免费"提供，不需要改变任何应用程序。最重要的是，在过去的几个月里，围绕Conduit的社区急剧增加，有贡献者，有生产用户，当然还有很多GitHub star!

具体的合并方式是：

github.com/runconduit/conduit 仓库被改为 github.com/linkerd/linkerd2
数据平面（rust proxy）被拆分到 github.com/linkerd/linkerd2-proxy 仓库
合并后，Linkerd 1.x 和 2.x 两条线将继续并行开发。（事实上 Linkerd 1.x 进入维护模式或者废弃）

个人评论

及时止损：linkerd 1.x 版本已经被证实完全不是istio、envoy的对手，继续在 linkerd 1.x 上投入没有意义，Buoyant是一家初创型的小公司，资源有限的情况下必须集中力量主打 Conduit / Linkerd 2.0
Conduit 可以理解为是一个原型验证，用了7个月的时间证明了自己，无论是技术选项（rust重写）还是产品形态（servicemesh only & k8s only & security first），可以委以重任，对抗istio和envoy
弃用 Conduit 的名称，继续延用 Linkerd ，可以直接集成 Linkerd 现有的品牌和社区影响力，还有在 CNCF 的位置。毕竟 Linkerd 早就是 CNCF 一员，以 Linkerd2 的名字直接继承会简单的多。这也使得后面 Linkerd2 在2021年7月快速成为 CNCF 的毕业项目，距离此时只有两年半的时间。

其他评论

Conduit 0.5发布—以及R.I.P. Conduit (来自崔秀龙):

回想一下，2017 年 12 月 5 日发布到现在的两百多天里，一共发布了 13 个版本、9 篇文档以及 12 篇博客。大致完成了 Conduit 问世之初的承诺：轻量、快速以及 Service Mesh 该有的种种功能；然而很可惜，第一篇 Conduit 博客中还提到了一点：“Conduit is not Linkerd 2.0. ”。这一次“战略性转移”，也印证了之前大家的担心——如果自身投入不足，又不能有效持续制造焦点、获取社区的持续关注和支持，先驱就变成先烈了。

Service Mesh 的鏖战尚未开始，已经有人出局了，R.I.P. Conduit。

4 - 2018年Linkerd2动态

Linkerd2挑起对抗Istio的重任

2018-07-18 Linkerd2 18.7.1 发布

https://github.com/linkerd/linkerd2/releases/tag/v18.7.1

Linkerd2的第一个版本。

2018-08-01 Linkerd2 18.7.3 发布

https://github.com/linkerd/linkerd2/releases/tag/v18.7.3

完成从Conduit到Linkerd2的品牌转变
性能改进，优化cpu使用率约20%

2018-09-18 Linkerd2 edge-18.9.2 发布

https://github.com/linkerd/linkerd2/releases/tag/edge-18.9.2

从这个版本开始，按照 edge 和 stable 划分发布通道

2018-09-19 Linkerd2 stable-2.0.0 发布

https://github.com/linkerd/linkerd2/releases/tag/stable-2.0.0

这是Linkerd 2.0的第一次GA发布!

2018-09-19 博客: Linkerd2.0发布

https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/

The 2.0 release of Linkerd brings some very significant changes. First, we’ve completely rewritten Linkerd to be orders of magnitude faster and smaller than Linkerd 1.x. Linkerd 2.0’s data plane is comprised of ultralight Rust proxies which consume around 10mb of RSS and have a p99 latency of <1ms. Linkerd’s minimalist control plane (written in Go) is similarly designed for speed and low resource footprint.

Linkerd的2.0版本带来了一些非常重要的变化。首先，我们完全重写了Linkerd，使其比Linkerd 1.x更快更小。Linkerd 2.0的数据平面由超轻量级的Rust代理组成，消耗约10MB的RSS，p99延迟<1ms。Linkerd的极简控制平面（用Go语言编写）也是为速度和低资源占用率而设计的。

Linkerd 2.0 has a ton of other great design goals: a focus on minimal configuration, a modular control plane design, and UNIX-style CLI tools, and we’ll be expanding on those in the future.

Linkerd 2.0还有很多其他伟大的设计目标：专注于最小化配置，模块化控制平面设计，以及UNIX风格的CLI工具，我们将在未来对这些进行扩展。

2018-12-07 Linkerd2 stable-2.1.0 发布

https://github.com/linkerd/linkerd2/releases/tag/stable-2.1.0

主要的改进包括: 每线路的指标、service profile和大为改进的仪表盘用户界面。它还增加了几个重要的实验性功能，包括代理自动注入、单一命名空间安装，以及控制平面的高可用性模式。

2018-12-06 博客: Linkerd2.1发布

https://linkerd.io/2018/12/06/announcing-linkerd-2-1/

Per-route metrics

In 2.1, Linkerd can now provide metrics not just at the service level but at the route level. This means that Linkerd can reveal failures, slowdowns, or changes in traffic levels to a particular API call in a service.

在2.1中，Linkerd现在不仅可以提供服务层面的指标，还可以提供路由层面的指标。这意味着Linkerd可以揭示服务中某一特定API调用的故障、减速或流量水平的变化。

Service Profiles

Linkerd 2.1 introduces the concept of the service profile, a lightweight way of providing information about a service to Linkerd. This information includes the service’s routes, i.e. the API calls that it is expected to respond to, and the way that Linkerd should treat these routes. (As a side note, service profiles are implemented as a Kubernetes CRD, bringing the grand total of Linkerd-created Kubernetes CRDs to 1.)

Linkerd 2.1引入了服务配置文件的概念，这是一种向Linkerd提供服务信息的轻量级方式。这些信息包括服务的路由，即它应该响应的API调用，以及Linkerd应该如何处理这些路由。(作为附带说明，服务配置文件作为Kubernetes CRD实现，使Linkerd创建的Kubernetes CRD总数达到1)。

Service profiles are a very exciting addition because they provide a fundamental building block for the project: the ability to configure Linkerd’s behavior on a per-service basis. In upcoming releases, we’ll be adding many features built on service profiles, including retries, circuit breaking, rate limiting, and timeouts.

服务配置文件是一个非常令人兴奋的补充，因为它们为项目提供了一个基本的构建块：在每个服务的基础上配置Linkerd行为的能力。在即将发布的版本中，我们将增加许多基于服务配置文件的功能，包括重试、断路、速率限制和超时。

Service profiles are also a great demonstration of the design philosophy behind Linkerd 2.x. By attaching configuration at the service level, rather than globally, we ensure that Linkerd continues to be incrementally adoptable—one service at a time. And, of course, Linkerd continues to just work out of the box even if no service profiles are specified.

服务配置文件也是Linkerd 2.x背后的设计理念的一个很好的证明。通过在服务层面附加配置，而不是全局配置，我们确保Linkerd继续是可逐步采用的，一次一个服务。当然，即使没有指定服务配置文件，Linkerd也会继续开箱即用。