Linkerd社区对自身服务网格平台进行一轮最新更新，旨在进一步提高开发人员与服务拥有者的效率，同时与持续发展的Kubernetes生态系统实现紧密集成。另外，此次更新还为Linkerd在日益拥挤的服务网格领域中争取到一些喘息空间。
Bouyant公司CEO兼Linkerd社区初始开发者之一William Morgan表示，2.0版本最重要的特征就在于基础代码库进行了完全重写，且更加注重对服务网格部署的简化。
此次重写将控制层由JVM编程语言变更为Go编程语言。Morgan表示，与此前的迭代相比，这轮大规模调整使得Linkerd 2.0“体积更小，而速度更快。”
除了性能优势之外，转向Go语言还令Linkerd与Kubernetes生态系统更为接近。Morgan指出，“我们的大多数用户都身在Kubernetes阵营，因此我们希望尽早解决这个问题。”
Morgan解释称，除了与Kubernetes生态系统相结合之外，Go编程语言也“更容易上手”，并将推动这套平台迎来更为重大的创新。Linkerd与Kubernetes亦同属于云原生计算基金会（简称CNCF）生态系统中的组成部分。
Morgan解释道，这种方法与当前的服务网格平台相反——因为后者采取“全有或全无”的价值主张。他指出，路由是一项部署强度较高的任务，特别是考虑到最终用户对于云原生空间往往并不熟悉。
Morgan在描述当前进程时表示，“这是一项重要技术，需要投入大量时间才能学习完成。此外，用户还必须将相关知识与实际技术结合起来，这明显会提高使用门槛。”
而对于缺少云原生工程师或意见领袖的技术支持的服务拥有者而言，这道门槛无疑更高。Morgan指出，“人们并不关心Kubernetes、Docker或者服务网格，他们只是想让其直接发挥作用。”
在Linkerd 2.0的帮助下，Morgan认为这些服务拥有者能够使用边挂方式启动单一服务，从而简化过渡流程。“服务拥有者将获得可靠性、可见性与调试能力，从而在白天高效运作，并在夜晚安心入睡。”
Morgan指出，此次Linkerd更新能够在数秒之内完成服务安装，这一能力与其它服务网格平台“形成了鲜明的对比。”
考虑到其源自谷歌的身份，Istio当然受到Google Cloud Platform的官方支持，但目前仍未能与Amazon Web Services（简称AWS）以及微软Azure建立官方对接。此外，其亦严重依赖于同属于云原生基金会的Envoy服务代理平台。
红帽公司Istio产品经理Brian Harrington最近解释称，Istio与Linkerd之间存在明显不同，因为前者充当的实际是用于服务网格管理的控制层。其能够处理Enovy边挂部署——即将Envoy部署在运行中的容器Pod旁侧，并通过同Kubernetes或Apache Mesos等容器编排层平台的配合实现部署协调。
Harrington同时补充称，“通过这种流量拦截过程，Istio得以执行其「神奇的」服务组件自动连接能力。”
Linkerd社区此前已经添加过相关支持，允许用户同时运行Linkerd与Istio——其中的具体方法是将Istio作为Linkerd实例的控制层。
此外，Linkerd的关注重点与HasiCorp的Consul服务网格平台也比较相似。HashiGroup创始人兼联席CTO Mitchell Hasimoto最近在采访当中表示，与Istio相比，Consul无需强制要求用户接受所有组件即可建立服务网格，这将为组织提供更多选择。Hashimoto指出，“Istio在Kubernetes中的运行难度更低，但Consul则更具全局能力。”
Bouyant公司CEO兼Linkerd社区初始开发者之一William Morgan表示，2.0版本最重要的特征就在于基础代码库进行了完全重写，且更加注重对服务网格部署的简化。
此次重写将控制层由JVM编程语言变更为Go编程语言。Morgan表示，与此前的迭代相比，这轮大规模调整使得Linkerd 2.0“体积更小，而速度更快。”
除了性能优势之外，转向Go语言还令Linkerd与Kubernetes生态系统更为接近。Morgan指出，“我们的大多数用户都身在Kubernetes阵营，因此我们希望尽早解决这个问题。”
Morgan解释称，除了与Kubernetes生态系统相结合之外，Go编程语言也“更容易上手”，并将推动这套平台迎来更为重大的创新。Linkerd与Kubernetes亦同属于云原生计算基金会（简称CNCF）生态系统中的组成部分。
服务边挂
该平台还拥有新的服务边挂设计，即允许平台仅运行一项服务，同时在无需配置或代码变更的前提下实现自动化观察、可靠性与运行时诊断。Morgan解释道，这种方法与当前的服务网格平台相反——因为后者采取“全有或全无”的价值主张。他指出，路由是一项部署强度较高的任务，特别是考虑到最终用户对于云原生空间往往并不熟悉。
Morgan在描述当前进程时表示，“这是一项重要技术，需要投入大量时间才能学习完成。此外，用户还必须将相关知识与实际技术结合起来，这明显会提高使用门槛。”
而对于缺少云原生工程师或意见领袖的技术支持的服务拥有者而言，这道门槛无疑更高。Morgan指出，“人们并不关心Kubernetes、Docker或者服务网格，他们只是想让其直接发挥作用。”
在Linkerd 2.0的帮助下，Morgan认为这些服务拥有者能够使用边挂方式启动单一服务，从而简化过渡流程。“服务拥有者将获得可靠性、可见性与调试能力，从而在白天高效运作，并在夜晚安心入睡。”
Morgan指出，此次Linkerd更新能够在数秒之内完成服务安装，这一能力与其它服务网格平台“形成了鲜明的对比。”
服务网格空间
随着服务网格空间受到越来越多新产品的关注，这种对比也显得愈发必要。Istio无疑是其中最值得一提的对手，其目前已经得到谷歌、IBM以及Lyft等企业的采用。这套平台于今年7月迎来了自己的通用版本（1.0）。考虑到其源自谷歌的身份，Istio当然受到Google Cloud Platform的官方支持，但目前仍未能与Amazon Web Services（简称AWS）以及微软Azure建立官方对接。此外，其亦严重依赖于同属于云原生基金会的Envoy服务代理平台。
红帽公司Istio产品经理Brian Harrington最近解释称，Istio与Linkerd之间存在明显不同，因为前者充当的实际是用于服务网格管理的控制层。其能够处理Enovy边挂部署——即将Envoy部署在运行中的容器Pod旁侧，并通过同Kubernetes或Apache Mesos等容器编排层平台的配合实现部署协调。
Harrington同时补充称，“通过这种流量拦截过程，Istio得以执行其「神奇的」服务组件自动连接能力。”
Linkerd社区此前已经添加过相关支持，允许用户同时运行Linkerd与Istio——其中的具体方法是将Istio作为Linkerd实例的控制层。
此外，Linkerd的关注重点与HasiCorp的Consul服务网格平台也比较相似。HashiGroup创始人兼联席CTO Mitchell Hasimoto最近在采访当中表示，与Istio相比，Consul无需强制要求用户接受所有组件即可建立服务网格，这将为组织提供更多选择。Hashimoto指出，“Istio在Kubernetes中的运行难度更低，但Consul则更具全局能力。”
未来方向
Morgan认为，尽管目前的服务网格选项越来越多，但Linkerd社区仍将专注于提高平台的可用性。他指出，凭借着这一关注重点，Linkerd平台本身仍将为广大用户所喜欢，并预计Linkerd将“比计划时间更早”由云原生基金会的“孵化”项目转变为全面“结业”项目。Morgan最后总结称，“对我们来说，需求始终来自项目背后的用户社区，而这才是我们需要关注的重点所在。”
本文转自DockOne-Linkerd 2.0迎来更新，向着Kubernetes再进一步
