共计 2299 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章给大家介绍为什么选择使用 Linkerd 而放弃 Isito，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
我想重点介绍 Linkerd，它是 CNCF 基金会托管的服务网格，以简单性而闻名。在服务网格环境中，Linkerd 使用的“less-is-more”的方法以及在数据平面层使用基于 Rust 的“微代理”都是独一无二的。Linkerd 网站列出了很多组织在生产环境中运行它的案例，因此我着手与其中一些使用者进行交谈，并听了他们的经验。
Linkerd 的简单性
Istio 作为最广为人知的服务网格，我们首先尝试了。但是，他们很快发现 Istio 在许多方面都过于复杂和具有挑战性。
Sudia 回忆到，Istio 需要安装多个 Helm chart 并需要各种手动步骤才能将其部署到集群中。这个过程耗时一天，这对 Sudia 和他的小型 Ops 团队是一个很大的缺点。因为，他们没有时间“管理”服务网格工具。他也注意到，Istio 最近采取了一些步骤来简化其体系结构并使其更具简单性。
Andersen 首次尝试在 Kubernetes 集群上安装 Istio，但是失败了。他不得不从头开始重建它。最终成功安装 Istio 之后，他对 Istio 提供的指标觉得并没有独特之处。用户界面似乎也已经过时了，他几乎放弃了完全使用服务网格的想法。
偶然的机会，两个人发现了 Linkerd。他们喜欢 Linkerd 的简单性，并决定尝试。
Andersen 他将 Linkerd 安装在开发集群上，令他惊讶的是，仅用一个命令就启动了第一个实例并运行。他在 Kubernetes 命名空间中添加了 Linkerd 代理，并在几分钟之内就能看到服务之间的流量和通信。
Sudia 的经历与此类似。Sudia 和他的团队发现 Linkerd 直观且易于上手，可以在几分钟内通过命令行安装。
在服务网格方面，你有很多选择。Istio 的复杂性可能是由于它提供的功能。虽然，Linkerd 采用了一种极简主义的方法，可以简化很多工作，但是在某些使用案例中，使用 Istio 更有意义，并且我们知道有很多快乐的 Istio 用户。但是我们也不能忽视所有关于它的复杂性的抱怨。
Linkerd 的可视化
Sudia 和 Andersen 采用服务网格的主要动机是在服务间通信中获得可观察性。Linkerd 不仅提供正确的指标，而且还将它们可视化。
根据 Sudia 的说法，仪表板是 Linkerd 最好的部分之一。无需其他设置，就可以查看关键指标，例如请求率，错误率，请求持续时间和总响应。而且由于用户界面非常直观，他甚至不需要专门学习和培训。从安装部署的第二天开始，团队就能够准确地排查问题。
Andersen 发现，Linkerd 的“Tap”功能可跟踪服务之间的请求。无需任何额外设置即可实时查看正在发生的事情，这对他来说特别方便。
Linkerd 的可观察性
对于 Sudia 和 Andersen 而言，服务网格的最高要求是能够观察分布式应用程序中服务之间的通信。这不仅使运维团队受益，而且使开发人员和 QA 人员的生活变得更加轻松。
Sudia 说，Linkerd 无需为最常见的指标设置工具，这是因为默认情况下会提供关键的 RED（速率，错误，持续时间）指标。
Andersen 在运行 QA 任务时看到了 Linkerd 的一个好处，软件部署后衡量负载的功能特别有用，可以极大地改善调试和故障排除能力。而且，Linkerd 的跟踪功能也非常有用。
Linkerd 的安全性
安全是软件的一项关键任务，必须支撑所有其他决策。因此，这对于 Sudia 和 Andersen 都是头等大事。两者都试图在服务网格中，通过 mTLS 来管理安全证书，以对集群内部的流量进行加密。
Sudia 的团队通常使用证书管理器来发布 Letsencrypt 证书，并且需要每 24 小时轮换一次这些证书。他希望避免像 Istio 样，在每个容器的基础上实施复杂的 RBAC 策略。
对于一个规模较小的团队，具备使用 mTLS 快速创建高度安全的集群的能力至关重要。Sudia 的团队花了大约 30 分钟的时间来设置 mTLS，其中大部分时间都花在阅读文档上。Dave 指出，这种简单易用的水平设置 mTLS 非常强大，特别是对于像他这样的小型团队而言。
Andersen 的团队需要 mTLS 才能在 Linkerd 网格集群之间安全地路由流量。Linkerd 提供了证书自动生成的能力，这很方便。
Linkerd 的社区与支持
每当 Andersen 或 Sudia 遇到问题时，他们发现 Linkerd 社区会非常有帮助，并且能够迅速解决问题。
有一次，Andersen 遇到了 HTTP 会话无法与 Linkerd 一起使用麻烦，在 Linkerd Slack 上，通过社区的帮助，他快速找到了解决方案并在一天之内解决它。令他高兴的是，Linkerd 的下一个发行版中就修复了这个问题。
Sudia 说，当他的团队需要帮助时，几乎在一天之内，他就能在 Linkerd Slack 的社区中找到解决方案。他特别喜欢 Linkerd 精简的文档，这是 Istio 一直在努力解决的问题。
除了 Linkerd，Sudia 和 Andersen 还从多个来源访问监视数据，包括 Prometheus，Grafana Cloud，Elasticsearch，Rancher，Datadog，Jaeger 和 SumoLogic。尽管它们的监视工具组合各不相同，但他们俩都在将所有监视度量标准整合到一个工具中，以获取所有度量标准，日志和跟踪的统一视图。
关于为什么选择使用 Linkerd 而放弃 Isito 就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
