【编者的话】作为Linkerd面向Kubernetes的独立版本，Conduit拥有着其独特的理念，本文就为大家解析了Conduit的主体设计以及未来的发展路线，希望供感兴趣的朋友们参考。
在本周 KubeCon + CloudNativeCon 2017 大会上所有关于服务网络的讨论中， Linkerd 项目母公司推出的一款名为 Conduit 的面向Kubernetes的Linkerd版本引发了多方关注。
开源项目 Linkerd 旨在创建一个独立的通讯层，以透明方式处理诸如服务发现，负载均衡，故障处理，测量以及面向云本地应用的服务路由等任务。这是一个面向云原生计算基金会（ Cloud Native Computing Foundation ）的项目，而Kubernetes正是该基金会的首选编排工具选项。
Linkerd立足于诸如Finagle，Netty，Scala以及JVM之类的组件之上，主司向上扩展（Scale up）工作，但对于资源受限的环境进行规模收缩（Scale down）则非其所长——这类场景常见于基于sidecar的Kubernetes部署， William Morgan ——赞助商 Buoyant 公司CEO解释道。
Linkerd 在2015年发布时，编排市场正呈现碎片化的状态，客户们各自分散于Nomad、Mesos、Kubernetes及其它平台之上，切一时无法作出最终决策。
“通过Linkerd，我们明确表达了尽可能多地实现环境集成的愿望，”他解释道。近两年，Kubernetes统治了编排领域。虽然Linkerd有很多客户使用其替代品，但是面对Kubernetes的快速增长，公司想要对此作出响应。
他称公司倾听了顾客的意见，而Conduit正是由此而来。
“现在，大家已经了解了服务网络，并且认识到其提供的价值，他们想要通过单独一套精简的轻量化软件包获得Linkerd的全部优势，及其经过重新设计的安全原语，”他说道。
Conduit服务网络作为数据面 部署 于Kubernetes集群之上，其由轻量化代理组成，负责充当服务代码的侧挂容器，并由一组控制面进程协调和管理这些代理。
单一Conduit代理拥有次微秒级的p99延迟，且所运行的RSS小于10mb。
数据面传输服务实例间的应用请求流量。代理以透明方式截断来自或通往pod的通讯，并添加一些特性，如重试与超时，度量（instrumentation），加密（TLS），以及按照相应策略允许/禁止请求。
控制面也正是聚合指标源之一。
数据面利用 Rust 编写，控制面则使用 Go 编写。
Morgan说，“Rust赋予我们编写本地代码的能力，因此它能够让软件获得尽可能快的运行速度，且能够保证内存的安全性。这意味着我们跨过了一大堆关于缓冲区溢出，CVE和云泄露的问题——这些对于数据面而言甚至已经不算是个问题。这对于我们而言真的很重要，因为数据面深深植根于堆栈当中，且有可能暴露PII（个人身份信息）、HIPAA数据以及信用卡信息。”
正因为Go在Kubernetes社区中是如此的普遍，它也就成为了一个比较自然的选择。一款容易上手的语言能够降低社区贡献的壁垒。
控制面API的设计目标在于尽可能通用，从而允许其它工具基于其进行构建。目前的初始版本尚不支持定制化功能，但未来gRPC插件将可以作为控制面的一部分运行，且无需重新编译Conduit。
用户可以通过命令行（CLI）实现与服务网络的交互，或者通过Web应用控制集群。
Morgan称，Kubernetes提供了一种自然的方式来使用侧挂方法，这对于确保某些类型的高级安全策略是必不可少的。
“为了实现侧挂，你会希望它变得尽可能小。例如保证仅需要处理一个单独实例的流量，但同时确保这部分流量既可靠又体积小巧。”
本次通告仅涵盖0.1版本。Morgan解释称，“该项目尚处于alpha阶段，甚至连HTTP1都不支持，而仅支持 HTTP2 ”。
他概述了一系列特性，以作为支持生产环境的先决条件，具体包括：
这份发展路线图包括了代理的透明性，处理所有服务间通讯（不仅仅是HTTP）的能力；默认提供服务间验证以及加密，扩展Kubernetes API以提供真实世界的运维策略支持，并支持特定于环境的策略插件。
Conduit的出现对于Linkerd项目的原有部署、支持以及维护工作而言影响不大，因为前者的核心定位在于尽可能多地集成环境并提升环境跨越能力。
在本周 KubeCon + CloudNativeCon 2017 大会上所有关于服务网络的讨论中， Linkerd 项目母公司推出的一款名为 Conduit 的面向Kubernetes的Linkerd版本引发了多方关注。
开源项目 Linkerd 旨在创建一个独立的通讯层，以透明方式处理诸如服务发现，负载均衡，故障处理，测量以及面向云本地应用的服务路由等任务。这是一个面向云原生计算基金会（ Cloud Native Computing Foundation ）的项目，而Kubernetes正是该基金会的首选编排工具选项。
Linkerd立足于诸如Finagle，Netty，Scala以及JVM之类的组件之上，主司向上扩展（Scale up）工作，但对于资源受限的环境进行规模收缩（Scale down）则非其所长——这类场景常见于基于sidecar的Kubernetes部署， William Morgan ——赞助商 Buoyant 公司CEO解释道。
Linkerd 在2015年发布时，编排市场正呈现碎片化的状态，客户们各自分散于Nomad、Mesos、Kubernetes及其它平台之上，切一时无法作出最终决策。
“通过Linkerd，我们明确表达了尽可能多地实现环境集成的愿望，”他解释道。近两年，Kubernetes统治了编排领域。虽然Linkerd有很多客户使用其替代品，但是面对Kubernetes的快速增长，公司想要对此作出响应。
他称公司倾听了顾客的意见，而Conduit正是由此而来。
“现在，大家已经了解了服务网络，并且认识到其提供的价值，他们想要通过单独一套精简的轻量化软件包获得Linkerd的全部优势，及其经过重新设计的安全原语，”他说道。
Conduit服务网络作为数据面 部署 于Kubernetes集群之上，其由轻量化代理组成，负责充当服务代码的侧挂容器，并由一组控制面进程协调和管理这些代理。
单一Conduit代理拥有次微秒级的p99延迟，且所运行的RSS小于10mb。
数据面传输服务实例间的应用请求流量。代理以透明方式截断来自或通往pod的通讯，并添加一些特性，如重试与超时，度量（instrumentation），加密（TLS），以及按照相应策略允许/禁止请求。
控制面也正是聚合指标源之一。
数据面利用 Rust 编写，控制面则使用 Go 编写。
Morgan说，“Rust赋予我们编写本地代码的能力，因此它能够让软件获得尽可能快的运行速度，且能够保证内存的安全性。这意味着我们跨过了一大堆关于缓冲区溢出，CVE和云泄露的问题——这些对于数据面而言甚至已经不算是个问题。这对于我们而言真的很重要，因为数据面深深植根于堆栈当中，且有可能暴露PII（个人身份信息）、HIPAA数据以及信用卡信息。”
正因为Go在Kubernetes社区中是如此的普遍，它也就成为了一个比较自然的选择。一款容易上手的语言能够降低社区贡献的壁垒。
控制面API的设计目标在于尽可能通用，从而允许其它工具基于其进行构建。目前的初始版本尚不支持定制化功能，但未来gRPC插件将可以作为控制面的一部分运行，且无需重新编译Conduit。
用户可以通过命令行（CLI）实现与服务网络的交互，或者通过Web应用控制集群。
Morgan称，Kubernetes提供了一种自然的方式来使用侧挂方法，这对于确保某些类型的高级安全策略是必不可少的。
“为了实现侧挂，你会希望它变得尽可能小。例如保证仅需要处理一个单独实例的流量，但同时确保这部分流量既可靠又体积小巧。”
本次通告仅涵盖0.1版本。Morgan解释称，“该项目尚处于alpha阶段，甚至连HTTP1都不支持，而仅支持 HTTP2 ”。
他概述了一系列特性，以作为支持生产环境的先决条件，具体包括：
- 可靠语义，例如重试，超时以及断路。
- 请求路由，流量流经方式可编程控制。
- 安全策略——“我们已经有适当的原语，只不过现在尚未完成”，他说道。
这份发展路线图包括了代理的透明性，处理所有服务间通讯（不仅仅是HTTP）的能力；默认提供服务间验证以及加密，扩展Kubernetes API以提供真实世界的运维策略支持，并支持特定于环境的策略插件。
Conduit的出现对于Linkerd项目的原有部署、支持以及维护工作而言影响不大，因为前者的核心定位在于尽可能多地集成环境并提升环境跨越能力。
原文链接：Conduit: A Lightweight Service Mesh for Kubernetes（翻译：孙科）
转自：http://dockone.io/article/2956
中文文档：http://conduit.doczh.cn
官网： https://github.com/runconduit/conduit
