Istio的复杂性导致一些用户使用Linkerd –thenewstack

21-01-21 banq

服务网格已经引起了很多关注,这是有充分理由的。通过在平台层提供可靠性,安全性和可观察性,服务网格可以在Kubernetes应用程序中扮演关键任务。

但是应用情况好坏参半:一些从业者报告说,由于它们看起来很复杂,他们避开了采用服务网格,而另一些从业者则报告说,使它们变得易于运行并运行起来。那是什么呢?服务网格是否过于复杂以至于不值得付出努力,还是准备今天立即采用?

在本文中,我想重点介绍Linkerd,它是Cloud Native Computing Foundation服务网格(和类别的先驱),以强调简单性而闻名。在日益拥挤的服务网格环境中,Linkerd在这种“ less-is-more”的方法以及在数据平面层使用基于Rust的专用“微代理”的过程中都是独一无二的。

Linkerd网站列出了相当多的组织在生产环境中运行它,因此我着手与其中的一些人进行交谈,并听听他们的经验。为什么选择Linkerd,并将其与更复杂的服务网格(例如该领域当前的市场领导者Istio)进行比较?

对于这篇文章,我采访了来自两个不同组织的两名DevOps专业人员。我们讨论了他们在生产中运行Linkerd的过程,并在过程中收集了一些有趣的收获。 大卫Sudia是一个高级的DevOps工程师GoSpotCheck,移动任务管理应用的现场服务团队,在那里他领导的运营小组。David在KubeCon + CloudNativeCon NA 2020上发表了有见地的主旨演讲,“更大的力量,更少的痛苦:使用CNCF工具构建内部平台。”

Freddy AndersenYouMail(视觉语音邮件和垃圾邮件阻止服务)的CIO 。自大流行之前,YouMail团队一直在进行远程工作。

到目前为止,我们讨论了他们的服务网格之旅,他们很高兴分享他们的经验。虽然我们分开讲,但他们的故事有一些惊人的相似之处。他们两个:

  1. 对服务网格有类似的要求
  2. 首先尝试过Istio,但发现它过于复杂
  3. 偶然发现了KubeCon的Linkerd展台,此后一直在转变。

详细点击标题见原文。

 

最后,我向他们征求他们对当今服务网格生态系统状态的看法以及对Istio的看法。他们赞同Istio尝试做很多事情的观点,尽管这可能对其他组织也有用,但他们想要的是具有针对性,灵活的事情,并为他们选中了所有合适的框。这正是他们在Linkerd中找到的。

当谈到Istio时,他们并不是特别受“ FOMO”的困扰,他们与Linkerd分享经验的热情充分说明了他们对该项目的支持。

 

猜你喜欢