This release introduces Linkerd extensions. The default control plane no longer includes Prometheus, Grafana, the dashboard, or several other components that previously shipped by default. This results in a much smaller and simpler set of core functionalities. Visibility and metrics functionality is now available in the Viz extension under the linkerd viz command. Cross-cluster communication functionality is now available in the Multicluster extension under the linkerd multicluster command. Distributed tracing functionality is now available in the Jaeger extension under the linkerd jaeger command.

这个版本引入了Linkerd扩展。默认的控制平面不再包括Prometheus、Grafana、仪表盘或其他一些以前默认提供的组件。这导致了一个更小、更简单的核心功能集。可见性和指标功能现在可以通过 linkerd viz 命令在 Viz 扩展中使用。跨集群通信功能现在可以在 Multicluster 扩展中通过 linkerd multicluster 命令使用。分布式跟踪功能现在可以在 Jaeger 扩展中通过 linkerd jaeger 命令使用。

This release also introduces the ability to mark certain ports as “opaque”, indicating that the proxy should treat the traffic as opaque TCP instead of attempting protocol detection. This allows the proxy to provide TCP metrics and mTLS for server-speaks-first protocols. It also enables support for TCP traffic in the Multicluster extension.

这个版本还引入了将某些端口标记为 “不透明” 的功能。表示代理应该将流量视为不透明的TCP，而不是试图进行协议检测。这允许代理提供TCP指标和服务器优先协议的mTLS。它还可以支持多集群扩展中的TCP流量。

个人总结：引入Linkerd扩展

2021-04-16 Linkerd2 2.10.0发布

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

这个稳定版增加了对Apple Silicon M1芯片的CLI支持，并支持 SMI的TrafficSplit v1alpha2。

2021-05-18 Linkerd2 2.10.2发布

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

This stable release fixes a proxy task leak that could be triggered when clients disconnect when a service is in failfast. It also includes fixes for the fuzz testing that was performed on the proxy and its dependencies;

这个稳定版修复了一个代理任务泄露问题，该问题可能会在客户端处于故障快速状态时触发断开时可能引发的代理任务泄漏。它还包括对代理及其依赖的模糊测试的修复。

2021-07-08 CNCF毕业

William Morgan的博客

Announcing Linkerd’s Graduation

For a project that started out as a small wrapper over some open source Twitter libraries and went on to face intense competition from some of the biggest companies in the world, graduation is a significant victory. But not just for Linkerd.

对于一个一开始只是在一些开源Twitter库上做了一个小包装，后来又面临世界上一些大公司的激烈竞争的项目来说，毕业是一个重大的胜利。但不仅仅是对Linkerd而言。

This is a victory for everyone who has championed the virtues of simplicity and minimalism and rejected the narrative that service meshes must be complex and slow.

这对每一个拥护简单和极简主义的优点、拒绝服务网必须复杂和缓慢的说法的人来说都是一个胜利。

This is a victory for everyone who has chosen a service mesh based on performance benchmarks, or coherent design principles, or solving concrete problems, rather than relying on vendor marketing or giving into hype cycles.

对于每一个根据性能基准、或连贯的设计原则、或解决具体问题，而不是依赖供应商的营销或屈从于炒作周期来选择服务网格的人来说，这是一个胜利。

Linkerd is the first service mesh to rise to the level of graduation. But Linkerd has a long history of firsts: Linkerd was the first service mesh project and the one to coin the term itself. It was the first project to enter the CNCF’s inception (now sandbox) phase. It was the first CNCF project to adopt Rust—a language we believe is the future of the cloud.

Linkerd是第一个上升到毕业水平的服务网格。但是Linkerd有很长的第一历史: Linkerd是第一个服务网状结构项目，也是创造这个术语本身的人。它是第一个进入CNCF初始阶段（现在是沙盒阶段）的项目。它是第一个采用Rust语言的CNCF项目–我们相信这个语言是云计算的未来。

Linkerd adoption has only grown, year after year—not by marketing campaigns but by word of mouth.

Linkerd的采用年复一年地增长–不是靠营销活动，而是靠口碑。

个人评论：

简单说，William 对 Istio（背后的google）以大欺小，长期营销和炒作非常的不满和鄙视，而 linkerd2 的毕业则可以说是出了一口恶气。

CNCF的官宣文章

Cloud Native Computing Foundation Announces Linkerd Graduation

中文翻译版本: CNCF宣布Linkerd正式毕业！

个人评论：

Inaugural service mesh project used in production by industry leaders like Expedia, JPMC, Microsoft, Nordstrom, and more

从官宣的Linkerd用户看，缺乏重量级用户和使用案例是linkerd2落地的大问题（虽然列出来了Microsoft但我很质疑微软实际使用的范围和数量），社区支持度相比istio实在是太可怜。

It was the first service mesh project and the first CNCF project to adopt the Rust programming language to improve security and performance.

Linkerd2率先使用rust，并将rust在网络编程方面的生态提升到新的层次，可谓功不可没，非常令人配置。Linkerd2的开发团队的工程能力非常令人敬佩。

We didn’t choose a service mesh based on hype. My teams weren’t worried about which mesh had the most marketing behind it.

这是在讽刺 Istio？ CNCF官方文章，这么明显的奚落Istio，非常有趣。

Linkerd is working on an extensive roadmap, including server and client-side policies, “mesh expansion” to allow the Linkerd data plane to operate outside of Kubernetes, and much more.

终于要开始支持 k8s 之外的部署了。

1.2 - 2021年Envoy动态

2021年Envoy动态

2021年，

年度动态

2021-01-12 Envoy1.17.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.17.0

版本更新列表:

关键更新：默认已经不再开启xDS v2 API的支持
重要更新：

2021-04-16 Envoy1.18.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.18.0

版本更新列表:

关键更新：xDS v2 API已经彻底不支持
重要更新：开始http3的支持工作

2021-07-14 Envoy1.19.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.19.0

版本更新列表:

关键更新：HTTP/3 的alpha支持
重要更新：

年度总结

1.3 - Linkerd2对Rust网络编程的贡献

Linkerd2对Rust网络编程的贡献

在2017年底， conduit 发布第一个版本时，William Morgan 发表博客文章

https://linkerd.io/2017/12/05/introducing-conduit/

对 conduit 进行介绍时，就提到：

We’ve been hard at work on Conduit for the past 6 months. We’ve hired incredible people like Phil, Carl, Sean, and Brian. We’ve invested in core technologies like Tokio and Tower that make Conduit extremely fast without sacrificing safety.

在过去的6个月里，我们一直在努力工作在Conduit上。我们已经聘请了像 Phil, Carl, Sean 和 Brian 这样令人难以置信的人。我们已经投资了核心技术，如 Tokio 和 Tower，使Conduit在不牺牲安全的情况下非常快速。

核心员工

贡献的项目

Tokio

https://github.com/tokio-rs/tokio

Tower

https://github.com/tower-rs/tower

2 - 2020年Servicemesh动态

Servicemesh业界动态跟踪之2020年

2.1 - 2020年Envoy动态

2020年Envoy动态

2020年，

年度动态

2020-01-21 Envoy1.13.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.13.0

版本更新列表:

关键更新：xDS v1 API的内容全部移除，开始支持xDS v3 API
重要更新：新增 aggregate cluster以支持cluster之间的负载均衡, 新增 UDP proxy

2020-04-09 Envoy1.14.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.14.0

版本更新列表:

关键更新：冻结xDS v2 API
重要更新：新增 direct response filter

2020-07-08 Envoy1.15.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.15.0

版本更新列表:

关键更新：
重要更新：

2020-10-09 Envoy1.16.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.16.0

版本更新列表:

关键更新：
重要更新：

年度总结

2.2 - 2020年Linkerd2动态

Linkerd2在2020年主要改进了加密，支持k8s多集群

2020-02-07 Linkerd2 2.7.0 发布

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

这个版本增加了对Linkerd的PKI与外部证书颁发者（如cert-manager）集成的支持，并在总体上简化了证书轮换过程。

这个版本还包括对仪表盘的性能改进，减少代理的内存使用，对Helm图表的各种改进，以及更多更多。

个人小结：改善加密功能

2020-06-10 Linkerd2 2.8.0 发布

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

这个版本为Linkerd引入了新的多集群扩展，允许它在 Kubernetes 集群间建立安全的连接。

这对应用程序来说是透明的，并能与任何网络拓扑结构一起工作。

个人小结：新增对k8s多集群扩展的支持

2020-11-07 Linkerd2 2.9.0 发布

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

这个版本将Linkerd的零配置双向TLS（mTLS）支持扩展到所有的TCP连接，允许Linkerd在安装时透明地加密和验证集群中的所有TCP 连接。它还增加了对ARM的支持。引入了一个新的多核代理运行时，以获得更高的吞吐量，增加了对Kubernetes服务拓扑结构的支持。

个人小结：改进mTLS，改善性能

3 - 2019年Servicemesh动态

Servicemesh业界动态跟踪之2019年

3.1 - 2019年Linkerd动态

Linkerd1.x基本止步于2019年

2019-08-30 Linkerd 1.7.0 发布

https://github.com/linkerd/linkerd/releases/tag/1.7.0

备注：2019年之后linkerd的研发基本都停下来了，后续版本发布基本也都是在持续优化和改善以下支持：HTTP / Kubernetes / Prometheus / Consul / Namerd / TLS

2020年和2021年 Linker 基本停止维护：2020年只发了1.7.3、1.7.4两个版本，2021年只发了1.7.5-rc1版本。

这个 servicemesh 的业界先驱，止步于此，以遗憾和失败告终。

3.2 - 2019年Envoy动态

2019年Envoy动态

2019年，

年度动态

2019-04-06 Envoy1.10.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.10.0

版本更新列表:

关键更新：
重要更新：

2019-07-12 Envoy1.11.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.11.0

版本更新列表:

关键更新：
重要更新：

2019-11-01 Envoy1.12.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.12.0

版本更新列表:

关键更新：新增对 delta xDS 的支持
重要更新：

年度总结

3.3 - 2019年Linkerd2动态

Linkerd2挑起对抗Istio的重任

2019-02-13 Linkerd2 2.2.0 发布

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

这个稳定版引入了自动请求重试和超时，并将自动注入功能作为一个完全支持的（非实验性）功能而毕业。它增加了几个新的CLI命令，包括 logs 和 endpoints ，为Linkerd的控制平面提供诊断可见性。最后，它引入了两个令人兴奋的实验性功能：一个是加密安全的客户身份头，一个是CNI插件，在部署时避免了对 NET_ADMIN 内核功能的需要。

2019-02-12 博客：Linkerd2 2.2.0 发布

https://linkerd.io/2019/02/12/announcing-linkerd-2-2/

Retries and timeouts

Linkerd 2.2 can now automatically retry failed requests, improving the overall success rate of your application in the presence of partial failures. Building on top of the service profiles model introduced in 2.1, Linkerd allows you to configure this behavior on a per-route basis. Here’s a quick screencast of using retries and timeouts to handle a failing endpoint:

Linkerd 2.2现在可以自动重试失败的请求，在部分失败的情况下提高您的应用程序的整体成功率。在2.1中引入的服务配置文件模型的基础上，Linkerd允许你在每个路由的基础上配置这种行为。

Of course, controlling when retries can be implemented is a critical component of making retries safe to use. Linkerd 2.2 allows you to mark which routes are idempotent (isRetryable), limit the maximum time spent retrying an individual request (timeout), and configure the percentage of overall requests that can be retries (retryBudget). This parameterization allows you to ensure that retries happen safely and don’t escalate issues in an already-failing system.

当然，控制何时可以实施重试是使重试安全使用的一个重要组成部分。Linkerd 2.2允许你标记哪些路由是幂等的（isRetryable），限制重试单个请求的最大时间（timeout），并配置可以重试的总体请求的百分比（retryBudget）。这种参数化允许你确保重试安全发生，并且不会在一个已经失败的系统中升级问题。

Auto-inject (and uninject, and improvements to inject)

Linkerd 2.2 graduates auto-inject to be a fully-supported (non-experimental) feature. Auto-inject is a feature that allows a Kubernetes cluster to automatically add (“inject”) Linkerd’s data plane proxies to application pods as they’re deployed.

Linkerd 2.2毕业后，自动注入成为一项完全支持的（非实验性）功能。自动注入是一项功能，允许Kubernetes集群在部署应用pod时自动添加（“注入”）Linkerd的数据平面代理。

Moving proxy injection out of the client and onto the cluster can help ensure that all pods are running the proxy uniformly, regardless of how they’re deployed. Linkerd 2.2 also switches auto-inject’s behavior to be opt-in rather than opt-out. This means that, once enabled, only namespaces or pods that have the linkerd.io/inject: enabled annotation will have auto-inject behavior.

将代理注入从客户端转移到集群上，可以帮助确保所有pod统一运行代理，无论它们是如何部署的。Linkerd 2.2还将自动注入的行为改为选择进入而不是选择退出。这意味着，一旦启用，只有拥有 linkerd.io/inject: enabled 注解的命名空间或pod才有自动注入行为。

Finally, for client side (non-auto) injection, Linkerd 2.2 improves the linkerd inject command to upgrade the proxy versions if they’re already specified in the manifest (previous behavior was to skip them entirely), and introduces a linkerd uninject command for removing Linked’s proxy from given Kubernetes manifest.

最后，对于客户端（非自动）注入，Linkerd 2.2改进了 linkerd inject 命令，如果清单中已经指定了代理版本，则升级代理版本（之前的行为是完全跳过它们），并引入了 linkerd uninject 命令，从给定的Kubernetes清单中删除Linked的代理。

Better NET_ADMIN handling with a CNI plugin

Linkerd 2.2 introduces a new, experimental CNI plugin that does network configuration outside of the security context of the user deploying their application. This makes Linkerd better suited for multi-tenant clusters, where administrators may not want to grant kernel capabilities (specifically, NET_ADMIN) to users.

Linkerd 2.2 引入了一个新的、试验性的 CNI 插件，在用户部署其应用程序的安全环境之外进行网络配置。这使得Linkerd更适合于多租户集群，管理员可能不想授予用户内核能力（特别是NET_ADMIN）。

Background: injecting Linkerd’s data plane proxy into a pod requires setting iptables rules so that all TCP traffic to and from a pod automatically goes through its proxy, without any application configuration needed. Typically, this is done via a Kubernetes Init Container that runs as the deployer’s service account. In single-tenant clusters this is usually fine, but in multi-tenant clusters this can pose a problem: modifying iptables rules requires the kernel’s NET_ADMIN capability, but granting this capability allows tenants to control the network configuration across the host as a whole.

背景：将Linkerd的数据平面代理注入到一个pod中，需要设置iptables规则，使所有进出pod的TCP流量自动通过其代理，而不需要任何应用程序配置。通常情况下，这是通过Kubernetes初始容器完成的，该容器作为部署者的服务账户运行。在单租户集群中，这通常是好的，但在多租户集群中，这可能构成一个问题：修改iptables规则需要内核的NET_ADMIN能力，但授予这种能力允许租户控制整个主机的网络配置。

With Linkerd’s new CNI plugin, this network configuration is done in at the CNI level, effectively removes the requirement that users have the NET_ADMIN kernel capability. This makes running Linkerd in multi-tenant, security-conscious environments far more practical.

有了Linkerd的新CNI插件，这种网络配置在CNI层面完成，有效地消除了对用户拥有NET_ADMIN内核能力的要求。这使得在多租户、有安全意识的环境中运行Linkerd更加实用。

This plugin was contributed by our friends at Nordstrom Engineering and was inspired by Istio’s CNI plugin. A special thank you to Cody Vandermyn for this feature.

这个插件是由我们在Nordstrom Engineering的朋友贡献的，灵感来自Istio的CNI插件。在此特别感谢Cody Vandermyn提供的这个功能。

Client Identity

Linkerd 2.2 introduces a new, secure mechanism for providing client identity on incoming requests. When –tls=optional is enabled, Linkerd now adds l5d-client-id header to each request. This header can be used by application code to implement authorization, e.g. requiring all requests to be authenticated or restricting access to specific services.

Linkerd 2.2 引入了一种新的、安全的机制，在传入的请求中提供客户身份。当 -tls=optional 被启用时，Linkerd现在为每个请求添加 l5d-client-id 头。这个头可以被应用程序代码用来实现授权，例如，要求所有的请求都要经过认证或限制对特定服务的访问。

This header is currently marked as experimental, but is a critical first step towards providing comprehensive authentication and authorization mechanisms for Linkerd. In coming weeks, we’ll be publishing Linked’s roadmap for securely providing both identity and confidentiality of communication within a Kubernetes cluster.

这个头目前被标记为实验性的，但这是为Linkerd提供全面的认证和授权机制的关键第一步。在未来几周，我们将公布Linked的路线图，以安全地提供Kubernetes集群内通信的身份和保密性。

2019-04-17 Linkerd2 2.3.0 发布

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

这个版本将mTLS从实验性的功能发展为完全支持的功能，并引入了几个重要的安全基元。最重要的是，Linkerd 2.3默认开启了网格服务间的认证、加密通信。

2019-04-17 博客：Linkerd2 2.3.0 发布

Announcing Linkerd 2.3: Towards Zero-Touch Zero-Trust Networking for Kubernetes

https://linkerd.io/2019/04/16/announcing-linkerd-2.3/

This release graduates mTLS out of experimental to a fully supported feature, and introduces several important security primitives. Most importantly, Linkerd 2.3 turns authenticated, confidential communication between meshed services on by default.

This is the first step towards answering a challenge we posed ourselves over a year ago: Can we make secure communication easier than insecure communication for Kubernetes?

我们一年多前提出了一个挑战，这是回答这个挑战的第一步：我们能否让Kubernetes的安全通信比不安全通信更容易？

This isn’t just a theoretical question. In a world where the majority of web browsers and web sites use strong encryption and authentication with zero effort on the part of the user, it’s increasingly strange for Kubernetes services to communicate without authentication and over plain text. Why should surfing for cat pictures on Reddit have more security guarantees than the internals of our own applications?

这不仅仅是一个理论上的问题。在这个世界上，大多数网络浏览器和网站都使用强大的加密和认证，而用户不需要做任何努力，Kubernetes服务在没有认证的情况下通过纯文本进行通信，这一点越来越奇怪。为什么在Reddit上冲浪的猫咪图片要比我们自己的应用程序的内部有更多的安全保障？

Securing the communication between Kubernetes services is an important step towards adopting zero-trust networking. In the zero-trust approach, we discard assumptions about a datacenter security perimeter, and instead push requirements around authentication, authorization, and confidentiality “down” to individual units. In Kubernetes terms, this means that services running on the cluster validate, authorize, and encrypt their own communication.

确保Kubernetes服务之间的通信安全是采用零信任网络的重要一步。在零信任方法中，我们放弃了关于数据中心安全边界的假设，而是将围绕认证、授权和保密性的要求 “下沉” 到各个单元。在Kubernetes术语中，这意味着在集群上运行的服务要验证、授权和加密自己的通信。

But security that imposes a burden on the user—especially complex setup and configuration—is security that doesn’t get used. If zero trust is the foundation of the future of Kubernetes network security, then the cost of adopting zero trust must be as close to zero as possible. In Linkerd 2.3, we tackle this challenge head-on:

但是，给用户带来负担的安全–特别是复杂的设置和配置–是不被使用的安全。如果零信任是未来Kubernetes网络安全的基础，那么采用零信任的成本必须尽可能接近于零。在Linkerd 2.3中，我们正面应对这一挑战。

The control plane ships with a certificate authority (called simply “identity”).

The data plane proxies receive TLS certificates from this identity service, tied to the Kubernetes Service Account that the proxy belongs to, rotated every 24 hours.

The data plane proxies automatically upgrade all communication between meshed services to authenticated, encrypted TLS connections using these certificates.

Since the control plane also runs on the data plane, communication between control plane components is secured in the same way.

控制平面有一个证书授权机构（简称 “身份”）。
数据平面代理从这个身份服务中收到TLS证书，与代理所属的Kubernetes服务账户绑定，每24小时轮换一次。
数据平面代理会自动将网格化服务之间的所有通信升级为使用这些证书的认证、加密的TLS连接。
由于控制平面也在数据平面上运行，所以控制平面组件之间的通信也是以同样的方式来保障的。

All of this is enabled by default and requires no configuration. This means that as of the 2.3 release, Linkerd now gives you encrypted, authenticated communication between all your meshed services with no effort on your part. That may not be all you need for zero trust networking in Kubernetes, but it’s a significant start.

所有这些都是默认启用的，不需要配置。这意味着，从2.3版本开始，Linkerd现在为你提供了所有网格服务之间的加密、认证的通信，而不需要做任何努力。这可能不是在Kubernetes中实现零信任网络的全部要求，但这是一个重要的开始。

This release represents a major step forward in Linkerd’s security roadmap. In an upcoming blog post, Linkerd creator Oliver Gould will be detailing the design tradeoffs in this approach, as well as covering Linkerd’s upcoming roadmap around certificate chaining, TLS enforcement, identity beyond service accounts, and authorization.

这个版本代表了Linkerd的安全路线图的一个重要步骤。在即将发表的一篇博文中，Linkerd的创建者Oliver Gould将详细介绍这种方法的设计权衡，以及涵盖Linkerd即将推出的围绕证书链、TLS执行、超越服务账户的身份和授权的路线图。

Finally, we’d be remiss if we didn’t point out that this approach has been deeply inspired by our friends at Smallstep, Cloudflare, Let’s Encrypt, Mozilla, and other amazing organizations that strive to make the Internet secure by default.

最后，如果我们不指出这种方法受到Smallstep、Cloudflare、Let’s Encrypt、Mozilla和其他努力使互联网默认安全的优秀组织的深刻启发，那就是我们的失职。

2019-07-11 Linkerd2 2.4.0 发布

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

This release adds traffic splitting functionality, support for the Kubernetes Service Mesh Interface (SMI), graduates high-availability support out of experimental status, and adds a tremendous list of other improvements, performance enhancements, and bug fixes.

这个版本增加了流量拆分功能，支持Kubernetes服务网格接口（Service Mesh Interface / SMI），将高可用性支持从实验状态中毕业。并增加了大量的其他改进、性能提升和错误修复。

Linkerd’s new traffic splitting feature allows users to dynamically control the percentage of traffic destined for a service. This powerful feature can be used to implement rollout strategies like canary releases and blue-green deploys.

Linkerd的新流量分割功能允许用户动态地控制用于服务的流量比例。这一强大的功能可用于实施推出策略，如金丝雀发布和蓝绿部署。

Support for the Service Mesh Interface (SMI) makes it easier for ecosystem tools to work across all service mesh implementations.

对服务网格接口 (Service Mesh Interface / SMI) 的支持使生态系统工具更容易在所有服务网格实现中工作。

Along with the introduction of optional install stages via the linkerd install config and linkerd install control-plane commands, the default behavior of the linkerd inject command only adds annotations and defers injection to the always-installed proxy injector component.

随着通过 linkerd install config 和 linkerd install control-plane 命令引入的可选安装阶段，linkerd inject 命令的默认行为只添加注解，并将注入推迟到始终安装的代理注入器组件。

Finally, there have been many performance and usability improvements to the proxy and UI, as well as production-ready features including:

A new linkerd edges command that provides fine-grained observability into the TLS-based identity system

A --enable-debug-sidecar flag for the linkerd inject command that improves debugging efforts

最后，代理和用户界面有了许多性能和可用性的改进，还有一些可用于生产的功能，包括:

一个新的 linkerd edges命令，提供了对基于TLS的身份系统的细粒度观察。
为 linkerd inject 命令设置的 enable-debug-sidecar 标志，改善了调试工作。

个人小结：支持SMI，新增流量拆分功能

2019-08-21 Linkerd2 2.5.0 发布

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

这个版本增加了对Helm的支持，通过RBAC进行tap认证和授权，流量分割统计，动态日志级别，新的集群监控仪表板，以及无数的性能提升和错误修复。

2019-08-21 博客：Linkerd2 2.5.0 发布

https://linkerd.io/2019/08/20/announcing-linkerd-2.5/

Announcing Linkerd 2.5: Helm support and RBAC-aware tap

This release adds support for installation via Helm, hardens Linkerd’s tap command to obey Kubernetes RBAC rules, improves Linkerd’s CLI to report metrics during traffic splits, allows logging levels to be set dynamically, and much, much more.

这个版本增加了对通过Helm安装的支持，强化了Linkerd的tap命令以遵从Kubernetes的RBAC规则，改进了Linkerd的CLI以在流量分流时报告指标，允许动态设置日志级别，还有更多。

Linkerd’s new Helm support offers an alternative to linkerd install for installation. If you’re a Helm 2 or Helm 3 user, you can use this install Linkerd with your existing deployment flow. Even if you’re not, this method may provide a better mechanism for environments that require lots of customization at install time, which would otherwise require a complicated set of arguments to linkerd install. (And getting a Linkerd 2.x Helm chart into the Helm stable repo itself is in progress.)

Linkerd的新Helm支持提供了一个替代linkerd install的安装方式。如果你是Helm 2或Helm 3的用户，你可以使用这个安装Linkerd与你现有的部署流程。即使你不是，这种方法也可能为需要在安装时进行大量定制的环境提供一个更好的机制，否则就需要向linkerd install提供一组复杂的参数。 (而将Linkerd 2.x Helm图表纳入Helm稳定版本本身正在进行中)。

Linkerd’s tap command provides “tcpdump for microservices” functionality that allows users to view a sample of live request/response calls for meshed deployments. (Particularly useful since as of 2.3, Linkerd encrypts all meshed HTTP traffic by default, rendering tcpdump itself less than useful!) In Linkerd 2.5, tap now uses Kubernetes RBAC to provide granular access to results. This means that applications which process sensitive data can now control who has access that data in transit by using the RBAC rules of the underlying Kubernetes cluster.

Linkerd的tap命令提供了 “用于微服务的tcpdump” 的功能，允许用户查看网格化部署的实时请求/响应调用样本(特别有用的是，从2.3版本开始，Linkerd默认对所有网状的HTTP流量进行加密，使得 tcpdump 本身变得不那么有用！）。在Linkerd 2.5中，tap现在使用Kubernetes RBAC来提供对结果的细化访问。这意味着，处理敏感数据的应用程序现在可以通过使用底层Kubernetes集群的RBAC规则来控制谁可以在传输过程中访问这些数据。

个人小结：增加对Helm的支持

2019-10-11 Linkerd2 2.6.0 发布

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

这个版本引入了分布式跟踪支持，为linkerd tap增加了请求和响应头信息，极大地提高了仪表盘在大型集群上的性能，在仪表盘上增加了流量分割的可视化功能，增加了一个公共Helm repo，还有更多改进!

2019-10-10 博客：Linkerd2 2.6.0 发布

https://linkerd.io/2019/08/20/announcing-linkerd-2.5/

Announcing Linkerd 2.6: Distributed tracing, live request headers, faster dashboard, and more!

This release adds support for distributed tracing, brings request and response headers to Linkerd’s live tap output, adds traffic split visualizations to the dashboard, dramatically improves the performance of the dashboard on large clusters, adds a public Helm repo, and much, much more.

这个版本增加了对分布式跟踪的支持，为Linkerd的实时tap输出带来了请求和响应头，为仪表盘增加了流量分割的可视化，极大地提高了仪表盘在大型集群上的性能，增加了一个公共的Helm repo，还有很多很多。

Linkerd’s new distributed tracing support means that Linkerd’s data plane proxy now emit trace spans, allowing proxy timing for individual requests to be captured with systems like Jaeger. Since distributed tracing is a complex topic that (unlike most of Linkerd’s features!) requires some investment to use, Linkerd maintainer Alex Leong has written a handy blog post describing how to assemble a functioning end-to-end distributed tracing system with Linkerd 2.6.

Linkerd新的分布式跟踪支持意味着Linkerd的数据平面代理现在可以发出跟踪span，允许用Jaeger等系统捕获单个请求的代理时间。由于分布式跟踪是一个复杂的话题，（与Linkerd的大多数功能不同！）需要一些投资才能使用，Linkerd维护者Alex Leong写了一篇方便的博文，描述了如何用Linkerd 2.6组装一个有效的端到端分布式跟踪系统。

This release also adds live request and response headers to Linkerd’s tap output. Linkerd’s tap feature provides a live sample of actual requests flowing between any two pods, deployments, or namespaces. (Particularly useful since Linkerd encrypts all meshed HTTP traffic by default!) In Linkerd 2.5, we ensured that tap obeyed Kubernetes RBAC restrictions; the addition of 2.6 headers brings us one step closer to our vision of a complete “tcpdump for microservices”–if tcpdump obeyed fine-grained access control, that is.

这个版本还为Linkerd的tap输出增加了实时请求和响应头信息。Linkerd的tap功能提供了在任何两个pod、部署或命名空间之间流动的实际请求的实时样本。(特别有用的是，Linkerd默认对所有网格的HTTP流量进行加密！）。) 在Linkerd 2.5中，我们确保tap服从Kubernetes的RBAC限制；2.6头文件的增加使我们离我们的愿景更近了一步，即一个完整的 “微服务的tcpdump” – 如果tcpdump服从细粒度的访问控制，那就是。

Linkerd 2.6 brings several improvements to Linkerd’s dashboard. First, we’ve dramatically reduced the Prometheus load generated by the dashboard—the dashboard should now be usable on large clusters, and cause significantly less load even on small ones. Second, the dashboard now includes a visualization of the traffic split feature for canary deployments, which is already causing some excitement in the community:

Linkerd 2.6给Linkerd的仪表盘带来了一些改进。首先，我们极大地减少了仪表盘产生的Prometheus负载–现在仪表盘应该可以在大型集群上使用，即使在小型集群上也能显著减少负载。第二，仪表盘现在包括了一个可视化的金丝雀部署的流量分割功能，这已经在社区中引起了一些兴奋。

个人小结：增加了对分布式跟踪的支持

4 - 2018年Servicemesh动态

Servicemesh业界动态跟踪之2018年

4.1 - 2018年Linkerd动态

在重点投入Conduit/Linkerd2之后，Linkerd1.x的开发放缓

2017-05-01 Linkerd 1.4.0 发布

https://github.com/linkerd/linkerd/releases/tag/1.4.0

升级到 Finagle 18.4.0

2018-10-03 Linkerd 1.5.0 发布

https://github.com/linkerd/linkerd/releases/tag/1.5.0

Istio features are now marked as deprecated.

放弃对Istio的集成，此路不通！

后续小版本发布，基本都是在持续优化和改善以下支持：HTTP / HTTP/2 / Kubernetes / Prometheus / Consul / DNS SRV

2018-12-22 Linkerd 1.6.0 发布

升级到 Finagle 18.12.0
支持java9

4.2 - 2018年Envoy动态

Matt Klein在Lyft进行Envoy的开发

2017年，Envoy在平稳中逐渐走向成熟，xDS API逐渐成型

年度动态

2018-03-21 Envoy1.6.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.6.0

版本更新列表:

关键更新：gRPC 支持的各种改进（和google合作有关？），路由功能的持续完善和改进
重要更新：健康检查的完善和改进，支持Unix Domain socket

2018-05-22 Envoy1.7.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.7.0

版本更新列表:

关键更新：新增 http RBAC 支持
重要更新：健康检查的完善和改进,新增 weighted round robin 和 locality weighted 负载均衡策略

2018-10-05 Envoy1.8.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.8.0

版本更新列表:

关键更新：默认不再支持xDS v1, 支持xDS中的RLS(Rating Limit Service)和SDS(Secret Discovery Service)
重要更新：直接支持yaml作为配置文件、新增 Original destination cluster and load balancer 、新增 websocket 支持

个人小结：

xDS v2 API成熟，v1 API弃用

2018-11-28 CNCF宣布Envoy毕业

2018-12-21 Envoy1.9.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.9.0

版本更新列表:

关键更新：
重要更新：

备注：release note长达三页，都是比较琐碎的内容

年度总结

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

4.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.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也会继续开箱即用。

5 - 2017年Servicemesh动态

Servicemesh业界动态跟踪之2017年

5.1 - 2017年Servicemesh布道

Servicemesh概念基本成型

在2017年初，service mesh的概念基本成型

5.2 - 2017年Linkerd动态

2017年Linkerd业界动态跟踪

2017-02-23 Linkerd 0.9.0 发布

https://github.com/linkerd/linkerd/releases/tag/0.9.0

2017-04-25 Linkerd 1.0.0 发布

https://github.com/linkerd/linkerd/releases/tag/1.0.0

以下组件不再是实验性：

Marathon namer
Consul dtab store
K8s dtab store
Zk dtab store

2017-06-13 Linkerd 1.1.0 发布

持续改进 TLS 、http2、k8s 、metrics、consul

2017-07-11 Linkerd 1.1.1 发布

新增和Istio的集成
升级到 Finagle 6.45

2017-09-08 Linkerd 1.2.0 发布

持续改进 TLS 、http2、k8s 、metrics、consul
新增DNS SRV Record namer

2017-10-06 Linkerd 1.3.0 发布

持续改进 k8s 、Prometheus、consul、Curator、DNS SRV Record namer
升级到Finagle 7.1

5.3 - 2017年Envoy动态

Matt Klein在Lyft进行Envoy的开发

2017年，Envoy在平稳中逐渐走向成熟，xDS API逐渐成型

年度动态

2017-03-08 Envoy1.2.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.2.0

版本更新列表:

Cluster discovery service (CDS) API.
Outlier detection (passive health checking).
Envoy configuration is now checked against a JSON schema.
Ring hash consistent load balancer, as well as HTTP consistent hash routing based on a policy.
Vastly enhanced global rate limit configuration via the HTTP rate limiting filter.
HTTP routing to a cluster retrieved from a header.
Weighted cluster HTTP routing.
Auto host rewrite during HTTP routing.
Regex header matching during HTTP routing.
HTTP access log runtime filter.
LightStep tracer parent/child span association.
Route discovery service (RDS) API.
HTTP router x-envoy-upstream-rq-timeout-alt-response header support.
use_original_dst and bind_to_port listener options (useful for iptables based transparent proxy support).
TCP proxy filter route table support.
Configurable stats flush interval.
Various third party library upgrades, including using BoringSSL as the default SSL provider.
No longer maintain closed HTTP/2 streams for priority calculations. Leads to substantial memory savings for large meshes.
Numerous small changes and fixes not listed here.

个人小结：

关键更新：CDS（Cluster discovery service）API 、RDS(Route discovery service) API、离群检测 (Outlier detection，被动健康检查).
重要更新：环形哈希一致性的负载均衡，以及基于策略的HTTP一致性哈希路由，HTTP 路由增强，TCP 路由增强，使用BoringSSL作为默认的SSL提供商

2017-05-18 Envoy1.3.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.3.0

版本更新列表:

各种细节更新，没有特别大的新feature

2017-08-25 Envoy1.4.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.4.0

版本更新列表:

关键更新：增加 LDS API
重要更新：直接支持yaml作为配置文件、新增 Original destination cluster and load balancer 、新增 websocket 支持

2017-12-05 Envoy1.5.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.5.0

版本更新列表:

关键更新：xds v2 API接近Production Ready，新增Lua filter
重要更新：直接支持yaml作为配置文件、新增 Original destination cluster and load balancer 、新增 websocket 支持，支持 subset load balancer，路由功能的各种优化和增强

年度总结

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

5.4 - 2017年Conduit动态

2017年Conduit业界动态跟踪

2017-12-05 Conduit 0.1.0 发布

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

仅支持HTTP2(后续版本增加了对HTTP1.1的支持)
仅仅支持k8s部署（到2021年都只支持k8s）

2017-12-05 博客：Introducing Conduit

https://linkerd.io/2017/12/05/introducing-conduit/

We’ve built Conduit from the ground up to be the fastest, lightest, simplest, and most secure service mesh in the world. It features an incredibly fast and safe data plane written in Rust, a simple yet powerful control plane written in Go, and a design that’s focused on performance, security, and usability. Most importantly, Conduit incorporates the many lessons we’ve learned from over 18 months of production service mesh experience with Linkerd.

我们从头开始打造Conduit，使其成为世界上最快、最轻、最简单、最安全的服务网格。它的特点是用Rust编写的令人难以置信的快速和安全的数据平面，用Go编写的简单而强大的控制平面，以及专注于性能、安全性和可用性的设计。最重要的是，Conduit融合了我们从Linkerd超过18个月的生产服务网格经验中获得的许多教训。

One thing we’ve learned is that there are deployment models where Linkerd’s resource footprint is simply too high. While Linkerd’s building blocks—widely-adopted, production-tested components like Finagle, Netty, Scala, and the JVM—allow Linkerd scale up to incredibly high workloads when given lots of CPU and RAM, they aren’t designed to scale down to environments that have limited resources—in particular, to sidecar-based Kubernetes deployments. So, earlier this year, we asked ourselves: if we could build the ideal service mesh, focused on ultra-low-resource environments, but with the benefit of everything we’ve learned from 18 months of production service mesh experience—what would we build?

我们学到的一点是，在某些部署模式下，Linkerd的资源占用率太高。虽然Linkerd的构建模块–广泛采用的、经过生产测试的组件，如Finagle、Netty、Scala和JVM–允许Linkerd在有大量CPU和内存的情况下扩展到令人难以置信的高工作负载，但它们并不是为了扩展到资源有限的环境–尤其是基于sidecar的Kubernetes部署。因此，今年早些时候，我们问自己：如果我们能建立一个理想的服务网格，专注于超低资源环境，但受益于我们从18个月的生产服务网经验中学到的一切，我们会建立什么？

The answer is Conduit. Conduit is a next generation service mesh that makes microservices safe and reliable. Just like Linkerd, it does this by transparently managing the runtime communication between services, automatically providing features for observability, reliability, security, and flexibility. And just like Linkerd, it’s deployed as a data plane of lightweight proxies that run alongside application code, and a control plane of highly available controller processes. Unlike Linkerd, however, Conduit is explicitly designed for low resource sidecar deployments in Kubernetes.

答案是Conduit。Conduit是下一代服务网格，使微服务安全可靠。就像Linkerd一样，它通过透明地管理服务之间的运行时通信，自动提供可观察性、可靠性、安全性和灵活性等功能来做到这一点。就像Linkerd一样，它被部署为一个轻量级代理的数据面，与应用程序代码一起运行，以及一个高可用的控制器进程的控制面。然而，与Linkerd不同的是，Conduit是明确为Kubernetes中的低资源sidecar部署而设计的。

Conduit的特点：

Blazingly fast and lightweight A single Conduit proxy has a sub-millisecond p99 latency and runs with less than 10mb RSS. 惊人的速度和重量 单一的Conduit代理的p99延迟为亚毫秒级，并以低于10MB的RSS运行。

Built for security From Rust’s memory safety guarantees to TLS by default, we’re focused on making sure Conduit has security in mind from the very beginning. 为安全而构建 从 Rust 的内存安全保证到默认的TLS，我们专注于确保 Conduit 从一开始就考虑到安全性。

Minimalist Conduit’s feature set is designed to be as minimal and as composable as possible, while allowing customization through gRPC plugins. 极简主义 Conduit 的功能集被设计为尽可能的简约和可组合，同时允许通过 gRPC 插件进行定制。

6 - 2016年Servicemesh动态

Servicemesh业界动态跟踪之2016年

6.1 - 2016年Servicemesh概念

Servicemesh术语出现，开始早期社区布道

在2016年初，service mesh还只是Buoyant公司的内部词汇，而之后，它开始逐步走向社区.

2016-09-29 Service Mesh第一次公开使用

2016年9月29日在SF Microservices上，“Service Mesh”这个词汇第一次在公开场合被使用。这标志着“Service Mesh”这个词，从Buoyant公司走向社区。

2016-10-01 博客系列文章: A Service Mesh for Kubernetes

2016年10月，Alex Leong开始在buoyant公司的官方Blog中开始"A Service Mesh for Kubernetes"系列博客的连载。随着"The services must mesh"口号的喊出，buoyant和Linkerd开始service mesh概念的布道。

2016年年底

借助Service Mesh在社区的认可度，Linkerd在年底开始申请加入CNCF。

6.2 - 2016年Linkerd动态

Linkerd成为第一个Servicemesh产品

2016年1月15日，离开twitter的基础设施工程师William Morgan和Oliver Gould，在github上发布了linkerd 0.0.7版本，他们同时组建了一个创业小公司Buoyant，业界第一个Service Mesh项目诞生。

年度动态

2016-01-15 Linkerd 0.0.7 发布

https://github.com/linkerd/linkerd/releases/tag/release-0.0.7

linkerd is a dynamic linker for distributed applications (aka “microservices”). In the same way that ld binds software components (libraries), linkerd binds services by mediating inter-service communication (RPC).

linkerd是一个用于分布式应用（又称"微服务"）的动态链接器。与ld绑定软件组件（库）的方式相同，linkerd通过调解服务间通信（RPC）来绑定服务。

协议支持：

http
thrift(实验性)
mux(实验性)

namer（服务发现）支持：

基于文件系统的服务发现（应该是用于开发阶段）
kubernetes(实验性)

2016-01-18 博客：Linkerd和Twitter的关系

Linkerd: Twitter-style Operability for Microservices

备注：这是linkerd的第一篇博客文章。

Happily, a tremendous amount of that knowledge was already encoded in an open-source project called Finagle, the high-throughput RPC library that powers Twitter’s microservice architecture.

令人高兴的是，大量的知识已经编码在一个名为 Finagle 的开源项目中，这是一个为Twitter的微服务架构提供动力的高吞吐量RPC图书馆。

Finagle is Twitter’s core library for managing the communication between services. Practically every online service at Twitter is built on Finagle, and it powers millions upon millions of RPC calls every second.

Finagle 是 Twitter 管理服务间通讯的核心类库。Twitter 上几乎每一项在线服务都建立在 Finagle 上，每秒钟为数百万个 RPC 调用提供支持。

Today, we’re happy to announce a small step towards our vision of making Finagle usable by the masses. Linkerd has hit 0.1.0

今天，我们高兴地宣布，我们朝着让 Finagle 为大众所利用的愿景迈出了一小步。Linkerd 已经达到 0.1.0。

Linkerd is our open-source service mesh for cloud-native applications. It’s built directly on Finagle…

Linkerd 是我们的开源 service mesh，用于云原生应用程序。它直接建立在Finagle上……

2016-01-31 Linkerd 0.0.8发布

https://github.com/linkerd/linkerd/releases/tag/release-0.0.8

支持 Zookeeper
支持服务器端TLS

2016-02-10 Linkerd 0.0.10发布

支持端到端的TLS

2016-02-18 Linkerd 0.1.0发布

引入基于Marathon的服务发现，用于Mesos平台
更新到 Finagle 6.33

2016-03-31 Linkerd 0.3.0发布

增加 namerd 服务

2016-04-14 Linkerd 0.3.1发布

支持zipkin
完善namerd

2016-04-29 Linkerd 0.4.0发布

继续完善namerd和dtab
新的dashboard

2016-05-11 Linkerd 0.5.0发布

继续完善trace和dtab
支持retry
支持prometheus

2016-05-25 Linkerd 0.6.0发布

完善ZooKeeper的支持

2016-06-29 Linkerd 0.7.0发布

完善HTTP的支持
完善timeout/zookeeper/dashboard的支持

2016-07-29 Linkerd 0.7.2发布

支持consul

2016-07-29 Linkerd 0.8.0发布

完善consul、trace的支持

2016-10-18 Linkerd 0.8.2发布

引入http2、grpc的支持（实验性）

年度总结

2016年1月15日，linkerd 在github发布第一个版本0.0.7。2016年下半年，Linkerd陆续发布了0.8和0.9版本，开始支持HTTP/2 和gRPC，1.0发布在即；并在2016年底开始申请加入CNCF。

6.3 - 2016年Envoy动态

Matt Klein在Lyft进行Envoy的开发

2016年，Matt Klein在Lyft默默的进行Envoy的开发。Envoy诞生的时间其实要比Linkerd更早一些，只是在Lyft内部不为人所知。

年度动态

2016-09-13 Envoy1.0.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.0.0

2016年9月13日，Matt Klein宣布Envoy在github开源，直接发布1.0.0版本。版本说明只有四个单词: Initial open source release.

2016-12-01 Envoy1.1.0版本发布

https://github.com/envoyproxy/envoy/releases/tag/v1.1.0

版本更新列表:

Switch from Jannson to RapidJSON for our JSON library (allowing for a configuration schema in 1.2.0).
Upgrade recommended version of various other libraries.
Configurable DNS refresh rate for DNS service discovery types.
Upstream circuit breaker configuration can be overridden via runtime.
Zone aware routing support.
Generic header matching routing rule.
HTTP/2 graceful connection draining (double GOAWAY).
DynamoDB filter per shard statistics (pre-release AWS feature).
Initial release of the fault injection HTTP filter.
HTTP rate limit filter enhancements (note that the configuration for HTTP rate limiting is going to be overhauled in 1.2.0).
Added refused-stream retry policy.
Multiple priority queues for upstream clusters (configurable on a per route basis, with separate connection pools, circuit breakers, etc.).
Added max connection circuit breaking to the TCP proxy filter.
Added CLI options for setting the logging file flush interval as well as the drain/shutdown time during hot restart.
A very large number of performance enhancements for core HTTP/TCP proxy flows as well as a few new configuration flags to allow disabling expensive features if they are not needed (specifically request ID generation and dynamic response code stats).
Support Mongo 3.2 in the Mongo sniffing filter.
Lots of other small fixes and enhancements not listed.

个人小结：

各种类库更新，bug fix，性能优化
新增区域感知路由支持，通用的头匹配路由规则，HTTP/2优雅连接耗尽（双GOAWAY），故障注入HTTP过滤器，增加了拒绝流重试策略，上游集群的多个优先级队列，为TCP代理过滤器增加了最大连接断路功能

Envoy的历史追溯

备注：内容节选自文章网络代理 Envoy 开源五周年, 英文原文为 5 years of Envoy OSS

加入 Lyft 和创建 “Lyft 代理”

我在 2015 年春天离开了 Twitter，部分原因是下线事件的影响，部分原因是对没有得到晋升的挫败感，部分原因是想尝试新的东西。我跟着我的老板从 Twitter 到了 Lyft，还有我在 Twitter 的其他同事。

当我加入 Lyft 时，公司规模相对较小（少于 100 名工程师），并且正在努力从单体架构迁移到微服务架构。我已经多次谈到了 Envoy 的这部分历程，所以我不会再重述，在此简短的总结下，Lyft 遇到了所有典型的微服务迁移问题，主要是源于网络和可观察性。此外，Lyft 已经是 “多面手”（使用多种语言和框架），所以使用基于库的解决方案来解决这些问题似乎不切实际。因此，根据我以前建立 TSA 的经验和观察服务间通信在 Twitter 的工作方式，由于得到在 Lyft 的前 Twitter 同事们的信任，我提议建立一个新的应用网络系统，称为 “Lyft 代理”。

经过一些激烈的讨论，包括新的代理是否应该用 Python 构建（是的，真的），我们就项目的大致轮廓达成一致，并决定使用 C++ 作为实现语言。在当时，C++ 似乎是唯一合理的选择。今天我还会选择 C++ 吗？然而，如今已经不是 2015 年初了。

如果不说 “Envoy” 这个名字的由来，这部分的历史就不完整了。我们正在为这个项目建立最初的开发脚手架的时候，一个有远见的同事（Ryan Lane）说，我们不能把这个新项目叫做 “Lyft 代理”，我们必须选择一个更好的名字。我总是很实际，就去找辞典，查了一下 “代理”，然后决定用 Envoy 作为新名字。

在 Lyft 上线

直到 2015 年夏天，我才开始认真地研究 Envoy 的源代码。那几个月是我职业生涯中最有趣的几个月。我们应该珍惜这段初创时期，因为它不会持续很久。我花了很长时间，争取在合理的时间内（根据我的定义，这种类型的项目需要 3-4 个月的时间）做出能给 Lyft 带来价值的东西。俗话说，Lyft 给了我大量的绳子来吊死自己，而我致力于确保这种吊死不会发生。

当然，我的效率主要归功于刚从压缩的开发时间表和许多错误（主要是我自己的）中走出来，在 Twitter 的 TSA。我知道哪些错误是不能犯的，哪些抽象是需要的，哪些测试有效，哪些无效，等等。

2015 年秋天准备投入生产的 Envoy 的最初版本只包含了该项目今天所包含的功能和复杂性的一小部分。它不支持 TLS，只支持 HTTP/1，并且有极其简单的路由和弹性功能。它所拥有的是你今天所看到的东西的骨架。在这个项目的历史上，很少有重大的重构，主要是因为，正如我之前所说的，我知道将要发生什么，以及为了支持这些功能，需要有哪些抽象。Envoy 从一开始就拥有一流的可观察性输出，以指标和日志的形式。在 2021 年，这种类型的网络可观察性是桌面上的赌注（这在很大程度上要归功于 Envoy 的成功），但在当时却不是这样。

Envoy 最初是作为边缘代理在 Lyft 上线的，位于提供 TLS 终止的 AWS ELB 后面。到 2015 年秋末，Envoy 为 Lyft 的 100% 流量提供服务，该系统产生的边缘仪表盘立即得到了回报（例如，提供 API 调用百分点延迟直方图，每个终端的成功率和请求率等）。

在最初推出后不久，另一位 Twitter 同事（Bill Gallagher）加入了我的项目，我们迅速增加了一些功能，如 TLS 终止、HTTP/2 支持、更多路由和负载平衡功能等。

与此同时，Lyft 基于 Envoy 的 “服务网格 " 也开始成形了。首先，Envoy 被部署在 PHP 单片机旁边，以取代 HAProxy 及其一些固有的运维问题（例如，当时 HAProxy 仍然是单线程的），以帮助 MongoDB 的代理。可以毫不夸张地说，Envoy 的早期开发有很大一部分是针对 MongoDB 的稳定性（负载均衡、速率限制、可观察性等）。

基于 Envoy 的边缘机群和单体之间的直接观察能力的好处是非常明显的。不久之后，我们在一些高 RPS 分解的微服务旁边部署了 Envoy，以帮助排除网络问题。这方面的价值也得到了证明。随着时间的推移，我们超越了对可观察性的关注，增加了帮助系统可靠性的功能，如直接连接和服务发现（跳过内部 ELB）、异常值检测、健康检查、重试、断路等。Lyft 的基于负载的重大事件的数量从每 1-2 周一次慢慢减少。当然，Envoy 不能将所有此类事件的减少归功于此，但它提供的网络抽象确实有很大的帮助。

2016 年初，我们决定推动一个 100% 覆盖的服务网格。最初，我们认为这将是一个艰难的过程，需要自上而下的授权。在实践中，团队报名参加了迁移，因为他们将得到的好处是显而易见的。“胡萝卜 “式的迁移几乎总是成功的。而 “大棒” 式的迁移则很少成功，或者即使成功了，也会在组织内留下眼泪和愤怒。

到 2016 年中期，Envoy 被用于 Lyft 的所有网络通信，包括边缘服务、服务间通信、数据库、外部合作伙伴等。无论从哪个角度来看，该项目都取得了巨大的成功，帮助 Lyft 完成了微服务的迁移，提高了整体的可靠性，并对网络进行了抽象，使大多数工程师不需要了解真实的系统拓扑结构。此后，Bill 离开了这个项目，在 Lyft 从事其他工作，接替他的是 Roman Dzhabarov 和 Constance Caramanolis 加入我的团队。我们的小团队为整个 Lyft 开发和运维 Envoy。

开放源码

到 2016 年夏天，我们开始认真讨论开源 Envoy 的问题。早期的 Lyft 员工对开源和它为公司所做的事情很欣赏。很明显，Envoy 并不是 Lyft 的主要业务，那么为什么不把它放在那里并给予回报呢？我可以坦率地说，我们都带着不同的目标和期望来对待开放源代码的过程，以及对项目获得巨大成功后会发生什么感到非常天真。

在加入 Envoy 之前，我已经使用了相当多的开源软件，但我几乎没有开源贡献的经验，也没有维护者的经验。（虽然我在 Linux 内核中有过一次提交！）开源 Envoy 似乎是一个很好的机会，可以扩展我的技能组合，学习新的东西，可能会促进我的职业生涯，坦率地说，我不希望有一个 TSA v3 在第三家公司出现。对于 Lyft 来说，Envoy 是一个重要的工程项目，领导层认为，开放源代码将使 Lyft 作为一个工程组织具有可信度，并有助于招聘工作。正如我之前所说，我们所有人都对创建成功的开源，更重要的是在它获得成功的情况下培育它所需要的东西感到天真。

但是，我们决定给它一个机会。我们在 2016 年夏天花了很大一部分时间来编写文档（Jose Nino 在这个时候加入了团队，他的第一个任务就是阅读并帮助改进所有的文档），清理存储库，使其 " 不那么尴尬”，制作网站，发布博文等等。我真的很感谢这段时间里我在 Lyft 的同事，他们不仅支持我们，还帮助我们完成了无数的任务，包括网站设计、logo 等等。即使在这个早期阶段，我们也觉得第一印象很重要，如果我们要在开源领域有所作为，就必须通过高质量的文档、网站等给人留下良好的第一印象。

在此期间，我们还利用我们的行业关系，与 Lyft 的一些 “同行公司”（湾区的 “独角兽 " 互联网创业公司）会面，向他们展示我们在 Envoy 方面所做的工作，并获得他们的反馈，我们认为如果我们在正式开源前成功获得一个启动合作伙伴，这将是对项目的一个重大帮助。所有这些会议都非常友好，总的来说，所有与我们会面的公司都对我们所取得的成就印象深刻。但是，事后看来，他们都表示，以他们的小型基础设施团队，不可能马上采用 Envoy。他们祝愿我们在开放源代码方面取得最好的成绩，并说他们以后会回来看看。我们不禁对这些会议的结果感到沮丧，但我们还是向前推进了。

2015 年 8 月，我与谷歌进行了第一次友好的会面。一个 Lyft 的同事（Chris Burnett）在一个 gRPC 聚会上发言，提到了 Envoy，因为它与 Envoy 的 gRPC 桥接支持有关。我不知道的是，谷歌在发现 Envoy 的时候，正准备在 NGINX 的基础上推出 Istio。一次会议引出了另一次会议，然后是更多的会议，在 Envoy 开源之前，大量的谷歌员工已经看到了源代码和文档。(稍后会有更多关于这方面的内容）。

到 9 月初，我们已经准备好了，并将开源日定为 9 月 14 日。总的来说，我是一个（过度？）自信的人，但在我的生活中，有几次我对自己成功的能力有很大的焦虑。我立即想到的是：开始上高中，开始上大学，以及大学毕业后在微软工作。而开源的 Envoy 就是其中之一。我记得我被公众的反应吓坏了。人们会怎么说？反馈会是积极的还是恶毒的？虽然我们在开源时是一个小团队，但我仍然写了 90% 或更多的代码，并且觉得把它放到公共领域是对我自己和我的能力的一种反映。

如期而至，Envoy 在 2016 年 9 月 14 日成为开源产品。我记得我和妻子一起庆祝，并说了一些话。“如果我们能让其他公司像 Lyft 一样使用 Envoy，我就会很高兴。”

对开放源码发布的反应几乎是普遍的积极。令我们惊讶的是，几乎是立刻，我们开始听到大公司的声音，而不是小公司。在几周内，我们与苹果、微软进行了交谈，与谷歌的对话也不断加快。大公司在现有的解决方案中存在问题，并且有大量的团队准备投入到解决这些问题的工作中。具有讽刺意味的是（至少在 Twitter 的观点中），C++ 在这里是一种帮助，而不是一种阻碍。这些大公司都已经拥有充足的 C/C++ 开发资源，以及他们想要整合的现有库，等等。对他们来说，C++ 是一个卖点。

在这段时间里，毫不奇怪，我们与谷歌的人有最多的互动。最初主要是构建 Istio 的团队，但渐渐地，我们与 Anna Berenberg 花了更多时间，她现在是谷歌的杰出工程师，领导各种网络和负载均衡工作。这种关系将产生 " 喷气燃料”，在 2017 年初真正启动该项目。

年度总结

6.4 - 2016年Istio动态

Google和IBM联合Lyft，准备启动Istio项目

Google和IBM两位巨人，握手开始合作，他们联合Lyft，启动了Istio项目。

而在这个世界的另外一个角落，Google和IBM两位巨人，握手开始合作，他们联合Lyft，启动了Istio项目。这样，在第一代Service Mesh还未走向市场主流时，以Istio为代表的第二代Service Mesh就迫不及待地上路。