Conduit AMA 活动回放

本月初我们面向 Kubernetes 发布了 Conduit —— 新一代超轻量级 Service Mesh。在享受对 Conduit 的热烈欢迎的同时,我们还在 KubeCon + CloudNativeCon 上同大家有了近距离接触。为了和未能参加奥斯汀会议的用户进行沟通,我们于 12.11 日在 Slack 上举办了一场由 Buoyant 共同创始人 William Morgan 和 Oliver Gould 主持的AMA 活动。

我们还给错过这一活动的用户准备了一份谈话记录。为了方便阅读,这里在保持内容完整性的前提下对谈话稿进行了一些编辑。

Conduit 和 Istio 有什么不同?

William:基本上说来,Conduit 和 Istio 具有相同的目标(Linkerd 也是):面向微服务应用,通过管理通讯层,为其加入超时、重试、断路器、TLS、策略等在 Linkerd 中备受欢迎的功能,提高应用的可靠性、弹性和安全性。但是其切入角度不同:Conduit 希望为这一目标提供一个尽可能小的方案。这个小字的范围,除了包含 CPU、内存、延迟影响之外,还包含了 API 和学习曲线等方面,这是很重要的区别。

Linkerd 进入生产运维的 18 个月以来,我们积累了很多经验,其中的相当一部分是我们没有预料到的。Conduit 将会吸取这些宝贵经验。如我所愿,Conduit 应该在不大幅提高用户和系统负担的情况下,为用户提供 Service Mesh 应用的所有功能。

今天发布的 Conduit 0.1 包含了什么?路线图的下一步是什么?

Oliver:0.1 版本的首要目标是为 gRPC 服务提供第一支持。这主要是一个工程目标——相对于老旧的 HTTP/1 来说,HTTP/2 的传输是一个比较复杂的问题。在后续版本中,我们会把代理范围扩展到 HTTP/1 以及其他 TCP 连接。另外,我希望我们可以集成 CA 系统来提供开箱即用的 TLS 支持。

Conduit 什么时候会达到生产可用水平?

Oliver:Conduit 有了生产环境部署的时候就说明是生产可用了;D

不过我们希望是在 2018 年初。我们会专注于提供缺省的的可视化、安全性功能,以及基本的运维能力,这些都是进入生产环境的基础要求。我希望在成功提供一批生产特性之后再考虑提供更多的配置界面。

看起来 Conduit 目前没有提供 Ingress 控制器。这是否说明 Conduit Proxy 会当做 K8S Ingress 控制器运行?在这个(没有 Ingress 控制器)的空档期,如何让 Conduit 和现有的 K8S Ingress 控制器协同运行?

Oliver:在我们达成透明代理的目标之后,Conduit 能够支配任意流量的时候,这就很简单了。在这之后我们会有 K8S Ingress 资源的集成手段;日后我们会需要更好的东西。不过目前 Conduit 的路由功能优先级是最高的。

William:个人看法,我觉得 Conduit 和 Contour 这样的产品系统工作会很有意思。

Oliver:Conduor ?

William:TourDuit ?

注入了 Conduit 的 Deployment ,如果运行过程中 Conduit Sidecar 奔溃了会怎样?会导致整个 Deployment 失效么?能恢复么?

William:Sidecar 崩溃和 Pod 崩溃是一样的。我们在 K8S 中用了很多措施来处理这些问题。。。他应该不会崩溃。

Oliver:如果崩溃,欢迎提 Bug。

现在 Buoyant 所有的工程师都在做 Conduit 么?或者 Conduit 和 Linekerd 各自为政?如何协调双方的支持呢?

William:我们会持续对 Linkerd 做出重大的投入。Linkerd 是世上应用最广泛的开源 Service Mesh,也是世界上唯一一个生产就绪的 Service Mesh。双方占用的都是团队成本,很难分拆。总的说来,Linkerd 和 Conduit 是同一群工程师开发的,对我来说 Buoyant 的每个人都共享各自的特长也是很重要的。

这样是不是可以说在 Buoyant 两者的优先级是同样的?

William:更合适的说法是,我们把创意方面的点数加给了 Conduit。

Oliver:我们想让 Linkerd 变得稳定,稳定到无聊。

William:Conduit 也会无聊的。。在未来。

Conduit 最鹅妹子嘤的特性是什么?

Oliver:Tap,必须是 Tap。可能还有基于路径的统计。又或者是深度集成到缓冲管理中的流量控制。

非 Buoyant 社区成员如何参与这一新项目?

Oliver:最好的方式就是提出 https://github.com/runconduit/conduit/issues 以及提供反馈!未来的几个星期,我们会贴出更多的路线图和入门指南。

William:是的,我们在 Slack 的 #conduit 频道收到了第一个 Issue,有用户指出无法运行 Conduit,我们推测是 RBAC 问题。这很好,我们会跟进的。

从贡献的角度呢?选择 Rust 是否会对潜在的 PR 造成限制?

William:我真的希望采用 Go 编写控制平面会降低为 Conduit 做出贡献的门槛。我认为在 Linkerd 中,Scala 不太容易,这 (不是常规的 Scala,是 Finagle 式的 Scala) 造成了一些困难。

Oliver:Rust 也不太容易——虽然 Rust 挺有意思。

William:Rust 的学习曲线比较陡峭,但是数据平面和多数用户需要的东西进行了隔离,所以总体上来说,我们认为给 Conduit 做提交会更容易。我们正期待第一个 PR。

12.22 我们接受了第一个社区 PR,感谢 Fakod

周末试用 Conduit 的过程中,感觉 Proxy 状态界面有点困惑,能说明一下这一界面中表达的意义和预备如何使用么?

William:界面中呈现了 Deployment 之中的 Pod,绿色那些是注入了 Conduit 的,灰色的是没有注入的。在截屏中你会看到一个conduit inject引发的滚动更新过程正在进行。目前的展示还是符合目标要求的,但是一定有些方法能够让这一界面更加清晰。

Kevin Lingerfelt:上星期我们给这些圆形图标加入 hover 状态,用于说明具体意义。这一特性将在 0.1.1 版本中提供。

William:这样很好。我们目前还没提供 Pod 终结过程的展示,有了这个的话,Deployment 的迁移过程会更加清晰。

对 Conduit 感兴趣的非 Rust 开发者如何做出贡献呢?有个入门指南会很有用吧?

William:是的。我们的短期 TODO 列表中就包含这一项目。事实上无需 Rust 也能做出贡献。事实上我希望除了一些非常特定的功能,无需学习 Rust 都能做出贡献。

Oliver:基本同意。控制器 API 还在落实,这些是帮助构建更好功能的去处。

Conduit 的发布方式是怎样的?Linkerd 每两星期一次发布,Conduit 会如何呢?

William:虽然喜欢,但是我不确定是否能保证两星期一次的更新。为了能够尽快以最小功能集进入生产,我们有一些较为激进的目标,正如 Oliver 上面提到的,我们的目标是在 2018 年初完成。另外一个让我们比 Linkerd 轻松一点的是我们的控制平面是可以使用 gRPC 插件配置的,这意味着我们可以:

  1. 因为所有都是可以定制的,所以可以发行一个最小功能集。
  2. 用户插件无需运行在数据平面上。