conduit | 伪架构师

Conduit 0.5 发布 —— 以及 R.I.P. Conduit

Sat, 07 Jul 2018 09:20:04 +0800

7 月 6 日，Linkerd 博客再次更新，宣布 Conduit 0.5 发布：在翻炒了无数次 Prometheus 支持的冷饭之后，终于发布了新的功能 —— TLS 支持。

紧接着一个更加重磅的消息：0.5 将是 Conduit 最后一个版本，未来将作为 Linkerd 2.0 的基础继续存在 - Conduit 的 Github 项目将会转移为 Linkerd2。

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

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

Conduit 0.4.2 发布

Tue, 05 Jun 2018 10:04:16 +0800

Conduit 0.4.2 是生产就绪之路上的重要一步。这个版本为代理服务器的长期运行做出了很多修复和提高，并提供了更多的遥测功能。同时也为未来的双向 TLS 版本打好了基础。

生产就绪
- 代理服务器会丢弃 10 分钟未更新的指标，以防长期运行过程中造成的额外的内存增长。
- 新增了一个约束，限制一个节点能够路由的服务数量，缺省为 100。这样在代理服务器长期运行的时候，可以在容量到达上限的时候，丢弃闲置最久的客户端，从而达到节约资源的目的。
- 代理服务器现在能够正确的处理 HTTP/2 请求的取消。
- 修复连接错误时候的请求处理。
- 正确处理 DNS 的 TTL。
- conduit inject 现在可以处理 statefulset 对象了。
遥测
- 新版本的 conduit stat 现在支持所有的 Kubernetes 资源，能够展示一个命名空间内所有对象的流量统计。
- Conduit Web UI 提供了命名空间概述的展示。
- 修复了 Tap 功能的一个 Bug，这个 Bug 让代理服务器无法同时响应多个 Tap 请求。
- 修复了故障状态下，无法报告某些 TCP 流的问题。
- 加入了首字节响应时间的指标。
内部
- 环境配置加入了对友好的时间格式的支持（例如 10s）。
- 控制面使用 Kubernetes 1.10.2 客户端。
- 更丰富的 Debug 日志，包含了 Socket 和 Stream 的元数据。
- 为 TLS 支持对代理做出大量改进。

非常感谢 @carllhw、@kichristensen 和 @sfroment 做出的贡献。

从 0.4.1 升级

从 0.4.1 升级时，建议首先升级控制面，然后再升级注入。

Conduit 0.4.0：流量都去哪了？

Sat, 21 Apr 2018 18:49:25 +0800

原文：Conduit 0.4.0: Where’s my traffic?

本周早些时候我们发布了 Conduit v0.4.0，这一版本在基于 Prometheus 的遥测系统方面，有了很大进步；同时还给微服务的除错提供了新的工具。

安装后的一分钟里，Conduit 给每个 Kubernetes 部署都提供了一个预配置的 Grafana Dashboard。这些 Dashboard 不只是成功率、请求量以及每服务延迟等常见指标，他还将每个指标按照依赖关系进行了分解。这样你就可以在不修改应用的情况下，轻松地回答“这个服务的流量是从哪里来的？”或者 “Foo 调用 Bar 的成功率如何”之类的问题了。

我的流量呢？

在一个微服务形态的应用中，运行中的服务之间的依赖关系是很重要的问题。每服务成功率固然重要，流入服务的请求来自何处同样是不可忽视的问题，更不必说依赖服务的故障情况了。通常这些问题都是最难回答的，但是现在我们有了 Conduit 的帮助，就有机会对这些问题进行简化了。

为了达成这一目标，0.4.0 中我们把 Conduit 的遥测系统中指标的获取改为拉取方式来实现。这一过程中我们还把 Conduit 的 Rust 代理进行了改进，他的指标中描述了所有请求的源、目的以及健康状况。拉取方式获取指标，降低了代理的复杂度，更加贴近 Prometheus 的生态情况。

这样，Conduit 的遥测系统现在非常稳定。能深入到 Kubernetes 中任何两个 Deployment、Pod 或者命名空间之间的请求频率、成功率以及延迟等指标。还可以使用 Prometheus 进行各种查询。当然了，我们还把所有的这些集成到了 CLI 工具中，微服务中的 “TOP” 命令，想过么？

动手环节

我们现在来运行一个简单的例子（要看完整的安装介绍，请参考 Conduit 起步指南）。

首先安装 Conduit CLI：

curl https://run.conduit.io/install | sh

然后在 Kubernetes 中安装 Conduit：

conduit install | kubectl apply -f -

最后，安装 emojivoto 演示应用，并且将其加入 Conduit Mesh：

curl https://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml | conduit inject - | kubectl apply -f -

演示应用中包含了一个 vote-bot 服务，不断地在产生流量。这个基于 AI 的机器人在为他最喜欢的表情进行投票，他会变得越来越精明。所以为了安全起见，我们建议你不要让他长期运行。

让我们看看如何用 Conduit 在演示应用中获取流量走向：

先看看 Web 服务（确切的说是 Web Deployment）在做什么：

$ conduit stat -n emojivoto deployment web
NAME  MESHED  SUCCESS     RPS    LATENCY_P50  LATENCY_P95  LATENCY_P99
web      1/1   90.00%  2.0rps            2ms          4ms          9ms

voting 服务只有一个调用者，就是 web 服务。所以通过跟踪 Web 的依赖项，我们有了第一个需要监测的目标：voting 服务在被 web 服务调用的时候，有 83% 的成功率，这样我们就可以看看日志、跟踪或进行其他深入观察。

这只是 Conduit 众多功能中的一个例子。如果想要进一步探索，可以看看所有命名空间的成功率；各个命名空间以及每个 Deployment 调用某一命名空间的成功率；甚至是 Conduit 组件自身的成功率。

在 https://youtu.be/R5UDKgX72tg 还有我们录制的一个关于 Conduit 0.4 的视频。

下一步

我们的未来版本，会把指标和遥测能力扩展到其他的 Kubernetes 对象，例如 Pod 和 RS。另外我们还会把 conduit tap 命令也应用到这些对象上，让 stat 和 tap 完美配合。我们可能还会逐步为 Conduit 加入更多命令，来增强 Conduit 的遥测能力，敬请期待！

Conduit v0.2.0 发布

Thu, 01 Feb 2018 18:27:52 +0800

原文：Announcing Conduit support for HTTP/1.x and TCP

里程碑版本，这次发布中新增了对 HTTP/1.x 和 TCP 支持，这样就可以为绝大多数运行在 Kubernetes 上的应用提供支持了。

数据面
- Conduit 现在为包括 HTTP/1.x 和 HTTP/2 在内的所有 TCP 流量提供透明代理。
控制台界面
- 强化了 tap 命令的错误处理能力。
- tap 也提供了对 HTTP/1.x 的支持。
Dashboard
- 界面进行了小幅更新。
- 可以在 Dashboard 边栏搜索 Deployment。

预告

Conduit 将会为绝大多数协议提供自动支持，然而使用 WebSockets、HTTP 隧道/代理或者 MySQL、SMTP 等协议，需要一些额外配置，文档（注 1）中会有详细说明。
Conduit 还不支持外部 DNS。这一缺憾将在未来版本提供支持。
目前 Conduit 的遥测管线无法扩展到某些节点，后续版本会解决这个问题。
Conduit 还是 Alpha 阶段，请提交 Issue 或 PR 来支持我们（注 2）！

引用：

https://conduit.io/adding-your-service/#protocol-support
https://github.com/runconduit/conduit/issues/new

Conduit 登场

Wed, 06 Dec 2017 09:46:58 +0800

原文：Introducing Conduit

今天我们要介绍 Conduit，面向 Kubernetes 的新的开源 Service Mesh。

Conduit 横空出世，目标是成为最快、最轻、最简单并且最安全的 Service Mesh。他使用 Rust 构建了快速、安全的数据平面，用 Go 开发了简单强大的控制平面，总体设计围绕着性能、安全性和可用性进行。更重要的是，Conduit 将会完全吸收过去 18 个月中，我们在 Linkerd 的生产级 Service Mesh 中积累沉淀的真实经验。

为什么要做一个 Conduit？Linkerd 是世界上最多生产级部署的 Service Mesh。这一产品创造了 “Service Mesh” 这一词汇，在软件基础设施中成功的开辟了新的领域，为遍及全球的企业客户（例如 Salesforce、Paypal、Expedia、AOL 以及 Monzo）承载了数以万亿计的请求。这一段时间里，我们和客户以及用户们甘苦与共——我们一起开会，设计交叉路线图，凌晨三点起床救火。开源的基础设施和现实世界的对撞中，我们学到了弥足珍贵的经验和教训。

这中间有个突出的问题就是，Linkerd 的部署模型太重了。虽然 Linkerd 的各个组件，例如 Finagle、Netty、Scala 以及 JVM，都是被广泛采用千锤百炼的，有了这些组件的帮助，在有足够 CPU 和内存支持的情况下，Linkerd 能够达到非常高的负载能力；然而设计过程中鲜有考虑在有限的资源情况下，基于 sidecar 模式的 Kubernetes 部署方式。所以今年年初，我们自问：有了 18 个月的生产级 Service Mesh 的经验，如果要做出一个功能完备又可以在低资源环境下运行的 Service Mesh，我们会怎么做？

答案就是 Conduit。和 Linkerd 类似，Conduit 是让微服务安全可靠的下一代 Service Mesh。他能透明的管理服务之间的通信，自动提供可测性、可靠性、安全性和弹性的支持。还是跟 Linkerd 相仿，他的数据平面是在应用代码之外运行的轻量级代理，控制平面是一个高可用的控制器。然而和 Linkerd 不同的是，Conduit 的设计更加倾向于 Kubernetes 中的低资源部署。

Conduit 为什么伟大（hhhhh）：

轻量高速：Conduit 代理只需要不到 10 MB 实际内存（RSS），p99 延迟在分毫秒以内。
安全：Rust 的内存使用相当安全，同时还缺省使用了 TLS，Conduit 的安全性与生俱来。
最小化：Conduit 的特性集被设计为尽量的最小化和可编排，便于使用 gRPC 插件进行定制。
易用性：内置有聚合的服务指标，强大的客户端工具（想想看，微服务界的 tcpdump），Conduit 为运维人员提供了新的强大的工具来对付生产环境的微服务。

过去半年中我们一直在努力的构建 Conduit。我们聘请了 Phil、Carl、Sean 以及 Brain 这样的高手；向 Tokio 和 Tower 这样的核心技术投资，让 Conduit 又快又安全。最重要的是，我们决心用 Conduit 解决在 Linkerd 社区遇到的实际问题。

Linkerd 怎么办？

简单说说，Linkerd 是世界上最广泛在生产环境进行使用的 Service Mesh，他会长期存在，我们会持续的进行开发、管理并提供商业支持；我们会保证我们的 Linkerd 用户的幸福感。

Conduit 不是 Linkerd 2.0。Conduit 面向的是非常特定的环境 —— Kubernetes，而不准备像 Linkerd 一样做出众多的集成支持。我们的大量用户在使用 ECS、Consul、Mesos、ZooKeeper、Nomad、Rancher 或者混合的多环境系统，Linkerd 是目前的最好选择，我们会持续投入进行改善。

现在开始！

我们刚刚发布了 Conduit 0.1。来跳坑吧！目前这是个 Alpha 版本，所以理直气壮的仅提供 HTTP/2 的支持（是的，HTTP/1.1 都不支持）。我们希望我们的早期用户能够尽早接触 Conduit，并从中获得反馈。

接下来的几个月中，我们会积极工作，推进 Conduit 的生产化进程，预计来年初面世的 0.2 中，会加入 HTTP/1.1 和 TCP 的支持（路线图）。这一产品的进展和目标会非常公开。最后，我们还会提供 Conduit 的商业支持，如果有兴趣的话可以联系我们。

想要了解更多？可以订阅我们的发布通知邮件列表，加入 Linkerd 的 Slack 频道，或者 Follow @runconduit。

Conduit 是基于 Apache 2.0 协议的开源软件。