使用两年之后，我为什么卸载了 Istio？

在生产中使用了 Istio 近两年之后，我们要和它说再见了。

服务网络大战正在肆虐。现在我把票投给了 Linkerd。

服务网格提供了微服务之间的流量监控，包括服务通信的映射和在它们之间生成的 HTTP 状态码。通过添加服务网格，你可以在服务间添加 mTLS，或者换句话说，可以在服务间添加加密的 HTTP 通信。

在我看来，这两个工具几乎对所有人都很有用。许多服务网格都提供了诸如流量分割、重试、超时等高级功能。我很少相信这些功能是有用的，或者我认为这不应该是由 Sidecar 代理来处理的功能。它们经常被错误地用来尝试解决一个本该以其他方式解决的问题。

但另一方面服务网格很难。如果你要使用任何一种服务网格，都需要一个艰苦的过程才能学到一些知识：

• 服务网格目前只能可靠地支持 HTTP 通信。

我有使用 Istio 和 Linkerd 的经验，它们都声称支持许多协议。我发现这很不可靠。Istio 对某些数据库协议的支持在不同版本之间存在中断。Linkerd 中断了 ampq 通信。在这两个平台上使用 HTTPS 经常会抛出一些奇怪的错误。我的印象是，编写一个透明的网络代理是极其困难的。在这一点上，我只相信一个带有 HTTP 通信的服务网格，无论如何，这是我想要的，因为那是 Kubernetes 服务之间通信的流量。

• 在 Sidecar 代理运行之前，应用程序容器的网络调用都将失败。

这一点尤为糟糕，这也是我认为服务网格尚不适用于所有人的主要原因。应用程序容器可能会在 Sidecar 代理之前启动，在这种情况下，它将无法完成需要由 Sidecar 代理来配置处理的网络请求。

可以借用 Kubernetes 的故事来制作 Sidecar（你可以标记 Pod 中某个容器中为自旋向上的 Sidecar）。它原本计划在 1.20 版本中发布，但现在为了支持尽可能多的用例而推迟了。

无论如何，总有一些技巧可以解决这个问题，但这意味着成功实现一个服务网格对开发人员来说不再是透明的，因为他们需要修改一些代码或部署。

• 初始化容器和 CronJob 不能使用服务网格。

为什么呢？服务网格代理容器永远不会退出。如果它永不退出，那么初始化容器和 CronJob 就永远不会真正“完成”。对容器来说，你的应用程序容器将永远不会启动，对 CronJob 来说，你的 CronJob 将超时并被标记为失败。

可能有一些解决方法，但我从未发现有任何建议是非常实用的。

我已经成功地在生产和预发集群中使用了服务网格，但有两个限制条件，只让 Sidecar 代理监控 HTTP 通信；将 mTLS 设置为可选（如果某个 Pod 不在网格上，它仍然可以与网格上的另一个 Pod 通信）。

我不在审查集群上使用服务网格。把审查应用程序放到服务网格中有太多的问题需要解决了。

为什么我卸载了 Istio？

简而言之，因为操作复杂。学习 Istio 的时间与我第一次学习 Kubernetes 的时候差不多长。

通过配 Helm 来部署 Istio 需要花费数周的时间（相比之下，我几乎总能在一天之内完成一个新 Helm 的配置）。

Istio 重度依赖 CRD。我尽量避免使用 CRD，因为它们会造成供应商锁定。他们的 CRD，比如，必不可少的 Gateway、VirtualService、DestinationRule 都要花费一些时间来理解，而且我阅读它们文档的次数比我能接受的要多得多。

Istio 用起来很吓人。我经历过一个巨大的单点故障，当开发人员误命名了包含 TLS 密钥的 Kubernetes 密钥时，每个网关都中断了，整个集群都垮了。这是一个 bug，如果 Istio 无法找到密钥，它将无法配置并停止所有服务。这调试起来非常困难。日志中没有任何内容可以指出到底出了什么问题。Istio 很少在其他方面完全失效，通常与它将配置传递给 Envoy 代理的方式有关。他们称之为“碎玻璃配置”（“Break Glass Configuration”）。

最后，也是最重要的一点是，Istio 不推荐使用 Helm 部署，而是推荐使用他们的 istioctl 命令行实用程序……然而，他们在更高的版本中重新引入了 Helm 的部署。我不喜欢用一堆不同的方法在集群上部署 40 多个支持工具，所以当他们弃用 Helm 时，我非常失望，我使用的其他工具都支持 Helm。当我发现这只是暂时的时候，我更加沮丧。这意味着我必须离开后再回来升级到最新的 Istio 版本。

当初我为什么会选择 Istio ?

当 Kubernetes 刚出现时，它还有其他 3 个主要竞争对手：Mesos、 Nomad 和 Swarm。很快，Kubernetes 就赢得这场战争。

我从未遇到过使用 Mesos 的人，这可能是因为它没有得到大公司的支持，尽管我听说过 Mesos 对容器编排有着巨大的影响。

我见过的唯一使用 Swarm 的人，是因为 Swarm 比 Kubernetes“更简单”才使用的。我知道这不会长久的。它的“简单”实际上是缺乏功能。如果你只使用 Kubernetes 特性中的一小部分，Kubernetes 也很简单。

Nomad 现在还很活跃，如果你需要将流程直接编排到服务器上，那么这就是你的选择。如果你只需要容器编排，我强烈推荐你使用 Kubernetes。

不管怎样，当 Istio 问世时，情况看起来非常熟悉。唯一的竞争对手是 Linkerd（我想在我的心目中这是一个 Swarm 类型的竞争对手)，而 Istio 就像 Kubernetes 一样，是谷歌的“孩子”。所以我选择了 Istio。

然后，服务网络大战开始了。首先出现的是 AWS 的 AppMesh，然后是 Traefik 的 Maesh，再然后是 Azure 的 Open Service Mesh（这可能是对 Istio 不加入 CNCF 争议的一种讽刺)，以及 Nginx 的服务网格。还有一些其他的，大多数都是使用 Envoy 代理来创建他们的服务网格，如 Kuma 和 Consul Connect。

这看来根本没有明显的赢家。

现在该用什么?

在比较了所有的服务网格之后，我最终选择了 Linkerd，也就是最初的那个。其他的要么想偷偷进入供应商锁定，要么只是没有按照我想要的方式工作（比如 Maesh，它向节点添加是代理而不是 Pod）。

我喜欢 Linkerd 的原因在于：

它支持使用 Helm 进行部署（实际上，我在所有部署中都使用了 Helm 的修改版本，并且我使用了一些自定义的代码来避免外部手动配置）。它相当简单。你只需要一个 CRD，Helm 图也很易学。它们的仪表盘很顺滑。Istio 使用 Grafana/Promethus 和 Kiali。Linkerd 也支持 Grafana/Prometheus，但它还有一个专用的定制仪表盘，很易于使用。它们用 Rust （v2）编写了自己的代理。起初我对此感到很困惑，因为 Envoy 如此受欢迎，但后来我意识到 Linkerd 可以快速发展。Envoy 现在是一个庞然大物，必须对许多供应商保持中立，但是 Linkerd 可以对自己的代理做任何想做的事情，从而使开发速度更快。而且，它是用 Rust 写的！很酷，对吧？它们加入了 CNCF。而 Isito 没有…Linkerd 第一步做对了。Istio 试图尝试一系列不同的部署，你必须管理它们，但现在它们已经转移到单一部署上了。Linkerd 是第一个这样做的。它确实有其他部署，但都不是“核心”的。它们增加特性后，你只需要关注核心部署就可以让你的服务网格工作了。

Linkerd 有什么不足之处吗? 其实只有一件小事。我想这更像是一种营销手段。他们声称这是一个服务网络，你可以在 5 分钟内安装并使用它，一切都能准备好。但是，正如上文所述，服务网格并不是简单地准备就绪就行了。Linkerd 也存在每个服务网格都有的问题：缺少原生 Sidecar 和不可靠的非 HTTP 协议处理。

小结

也许有一天，你使用哪个服务网格只是一个小问题，就像很多人甚至不知道他们在 Kubernetes 上使用的是什么覆盖网络一样。每个服务网格都在采用 SMI（服务网格接口），因此从长远来看，我认为服务网格将会成为 Kubernetes 中的原生资源，而采用开放标准就是朝这个方向迈出的第一步。

Istio 尚未加入 CNCF，尽管 Chris DiBona 在 Kubernetes Podcast 上做了解释，但我还是不太喜欢这个举动。Linkerd 加入了 CNCF。如果它能保持一贯的简洁，短时间内，我不打算在离开它。一旦 Kubernetes 获得了某种原生的 Sidecar 解决方案，我会非常高兴。

延伸阅读：

https://medium.com/polymatic-systems/service-mesh-wars-goodbye-istio-b047d9e533c7