Linkerd 2.0迎来更新,向着Kubernetes再进一步

296 阅读4分钟
原文链接: mp.weixin.qq.com

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无疑是其中最值得一提的对手,其目前已经得到谷歌、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最后总结称,“对我们来说,需求始终来自项目背后的用户社区,而这才是我们需要关注的重点所在。” 原文链接:https://www.sdxcentral.com/articles/news/linkerd-2-0-update-moves-closer-to-kubernetes/2018/09/