服务网格大战，再见 Istio! - Fossas

在生产环境中使用 Istio 近 2 年后，我们要告别它了，这里阐述原因以及服务网格大战的当前状态。
让我们先了解一些基础知识。
为什么要使用服务网格？

• 它提供微服务之间的流量监控，包括服务通信地图和它们之间发生的 http 状态代码。
• 添加服务网格使您能够添加 mTLS，或者换句话说，您的服务之间的加密 http 流量。

我有使用 Istio 和 Linkerd 的经验，它们都声称支持许多协议。我发现这是非常不可靠的。Istio 对某些数据库协议的支持在版本之间中断。Linkerd 正在破坏 ampq 流量和https，或者经常抛出奇怪的错误。我的印象是编写透明的网络代理非常困难。在这一点上，我只信任具有 http 流量的服务网格，无论如何这就是我想要的，因为这是我的 Kubernetes 服务之间的流量。

2. 您的应用程序容器的网络调用在sidecar 代理没有运行时会失败

这个特别糟糕，也是我认为服务网格还没有为每个人准备好的主要原因。您的应用程序容器可能在 sidecar 代理之前启动，在这种情况下，它将无法完成 sidecar 代理配置为处理的网络请求。

有一个 Kubernetes 补丁来制作本机 sidecar（您可以将 pod 中的容器标记为必须首先启动的 sidecar）。它本应在 1.20 中发布，但现在已被推迟，以支持尽可能多的用例。
无论如何，有一些技巧可以解决这个问题，但这意味着成功实现服务网格对开发人员不再透明，因为他们需要进行一些代码或部署修改。

3. init 容器和 cronjobs 不能使用服务网格
为什么？服务网格代理容器永远不会退出。如果它永远不会退出，那么 init 容器和 cronjobs 永远不会真正“完成”。在前者中，您的应用程序容器永远不会启动，而在后者中，您的 cronjob 将超时并被标记为失败。
据说有一些解决方法，但我从未发现任何非常实用的建议。
  
我是否真的使用了服务网格？
我已经成功地在两个条件下成功地在生产和暂存集群中使用它们。我只有 sidecar 代理监控 http 流量，并且我将 mTLS 设为可选（因为如果 pod 不在网格上，它仍然可以与网格上的另一个 pod 通信）。
我不在评论集群上使用服务网格。在服务网格中获取审查应用程序存在太多问题。
  
为什么我卸载了 Istio？
简而言之，操作复杂。学习 Istio 的时间和我第一次学习 Kubernetes 的时间一样长。
配置 helm chart 以部署 Istio 需要花费数周的时间才能做到恰到好处（相比之下，我几乎总是在一天内配置一个新的 helm chart）。
Istio 对 CRD 很重。我尽量避免 CRD，因为它们会造成供应商锁定。他们的 CRD，如基本的网关、VirtualService 和 DestinationRule 也需要一段时间来理解，而且我阅读他们的文档的次数比我想承认的要多。
Istio 使用起来很可怕。这是一个巨大的单点故障。
可能我遇到的最糟糕的情况是，开发人员将包含网关 TLS 秘密的 Kubernetes secret 命名为错误。每个网关都坏了，基本上整个集群都瘫痪了。这是一个错误，如果 Istio 找不到secret ，它将无法配置并停止为所有内容提供服务。而且调试起来非常困难。日志中没有任何内容表明出了什么问题。Istio 完全中断的其他领域很少，通常与它将配置传递给 Envoy 代理的方式有关。他们称之为“打破玻璃配置”。
最后，也是最重要的一点，Istio 弃用了 Helm 部署以支持其istioctl命令行实用程序……然后他们将 Helm 部署带回了更高版本。我不喜欢使用一堆不同的方法在我的集群上部署 40 多种支持工具，所以当他们弃用 Helm 时我非常失望，我使用的所有其他工具都支持它。当我发现这是暂时的时，我更加沮丧。这意味着我将不得不关闭它并重新使用它以升级到最新的 Istio。
 
我当初为什么选择 Istio？
Kubernetes 刚出现时，还有其他 3 个主要竞争对手：Mesos、Nomad 和 Swarm。Kubernetes 将赢得这场战争，这一点相对较快变得显而易见。
我从未见过任何使用 Mesos 的人，这可能是没有得到大公司支持的不幸结果，尽管我听说它们对容器编排产生了巨大影响。
我见过的唯一使用 Swarm 的人使用它，因为它比 Kubernetes 更“简单”。我知道这不会持续下去。它的“简单”实际上是缺乏功能。如果您只使用 Kubernetes 的一小部分功能，那么 Kubernetes 也同样简单。
Nomad 今天实际上还很活跃，如果您需要将流程直接编排到服务器上，那么这就是您的选择。如果您只需要容器编排，我强烈推荐 Kubernetes。
不管怎样，当 Istio 出来时，情况看起来很熟悉。唯一的竞争对手是 Linkerd（我想我认为它与我心目中的 Swarm 类型的竞争对手有关），而 Istio 就像 Kubernetes 一样是 Google 的宝贝。所以，我选择了 Istio。
然后服务网格大战开始了。首先是 AWS 的 AppMesh，然后是 Traefik 的 Maesh，然后是 Azure 的开放服务网格（可能被命名为 Istio 没有加入 CNCF 的争议）和 Nginx 的服务网格。还有其他几个，大多数使用 Envoy 代理来创建他们的服务网格，例如 Kuma 和 Consul Connect。
看起来根本没有明显的赢家。
 
我现在用什么？
在比较了所有的服务网格之后，我最终选择了最初的 Linkerd。其他人似乎要么试图避免供应商锁定，要么只是没有按照我想要的方式工作（比如 Maesh，它向节点而不是 pod 添加了代理）。
我喜欢 Linkerd 的地方：

• 它支持使用 Helm 进行部署（实际上，我在所有部署中都使用了 Helm 的修改版本，并且我使用了一些自定义代码来避免外部手动配置）。
• 这相当简单。只有一个您真正需要的 CRD，而且舵图很容易学习。
• 他们的仪表板很光滑。Istio 使用 Grafana/Promethus 和 Kiali。Linkerd 也有 Grafana/Prometheus，但它也有一个易于使用的专用自定义仪表板。
• 他们用 Rust（在 v2 中）编写了自己的代理。一开始我很纠结，因为 Envoy 很受欢迎，但后来我意识到 Linkerd 可以快速移动。Envoy 现在是一个巨大的野兽，必须对许多供应商保持中立，但 Linkerd 可以对自己的代理做任何他们想做的事情，从而使开发速度更快。另外，它是用 Rust 编写的！这很酷，对吧？
• 他们组成了CNCF联盟。Istio 没有加入……
• Linkerd 首先做对了。Istio 试图拥有一堆您必须管理的不同部署，现在已转移到单个部署。Linkerd 是首先这样做的。他们确实有其他部署，但不是“核心”。它们添加了功能，因此您只需担心服务网格正常工作的一项关键部署。