在 Intenseye，为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.2)

为少

发布于 2021-07-30 15:41:49

5260

发布于 2021-07-30 15:41:49

文章被收录于专栏：黑客下午茶黑客下午茶黑客下午茶

在我们 service mesh 之旅的第一部分中，我们讨论了“什么是服务网格以及我们为什么选择 Linkerd2？”。在第二部分，我们将讨论我们面临的问题以及我们如何解决这些问题。

系列

在 Intenseye，为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.1)

问题 1：Apache ZooKeeper Leader 的选举

在 Intenseye，我们使用 Apache Pulsar 代替传统的 Apache Kafka 队列系统。

Apache Pulsar 是一个云原生(cloud-native)、多租户(multi-tenant)、高性能分布式消息传递和streaming 平台，最初由 Yahoo 创建！

Apache Pulsar 使用 Apache Zookeeper 进行元数据存储、集群配置和协调。在我们将 Zookeeper 与 Linkerd2 啮合后，K8S 一一重启了 pod，但它们卡在了 “CrashloopBackOff” 中。

我们检查了日志，发现 ZooKeeper 无法与其他集群成员进行通信。我们进一步挖掘，发现 Zookeeper 节点由于网格的原因无法选出一个 leader。ZooKeeper 服务器监听三个端口: 2181 用于客户端连接，2888 用于 follower 连接——如果它们是 leader, 3888 用于 leader 选举阶段的其他服务器连接。

然后，我们查看了文档，找到了 Linkerd2 sidecar 的 “skip-inbound-ports” 和 “skip-outbound-ports” 参数。一旦我们添加 2888 和 3888 端口以跳过入站/出站，那么建立仲裁就起作用了。由于这些端口用于内部 Zookeeper pod 通信，因此可以跳过网格。

如果您使用具有 leader 选举的应用程序，这是所有服务网格的常见问题，例如；Pulsar、Kafka 等，这是解决方法。

问题 2：Fail-Fast 日志

我们已经开始对我们的应用程序进行一一网格化。一切都很好，直到对其中一个 AI 服务进行网格划分，我们将其称为 application-a。我们有另一个应用程序作为 500 多个轻量级 Pod 运行，我们称之为 application-b，它使用 gRPC 向 application-a 发出请求。

在成功 mesh 1 或 2 分钟后，我们看到数百个 Failed to proxy request: HTTP Logical service in fail-fast errors 在 application-b 中。我们检查了 linkerd-proxy 仓库的源代码，我们找到了打印这个日志的地方，但无法理解错误信息。我的意思是，什么是 HTTP Logical service？

所以我们通过 GitHub 向 Linkerd2 提出了一个 issue。他们对这个问题非常感兴趣，并试图帮助我们解决它，甚至发布了专门的包来调试这个问题。

经过所有讨论，结果证明在 application-a 上设置的 “max_concurrent_streams” 值为 10，不足以处理请求。 Linkerd2 使它可见。我们已将该值从 10 增加到 100。不再出现快速失败的错误。

问题 3：Sidecar 初始化前的出站连接

我们在应用程序启动期间进行 HTTP 调用的应用程序很少。它需要在服务请求之前获取一些信息。所以应用程序试图在 Linkerd2 sidecar 初始化之前建立出站连接，因此它失败了。 K8S 正在重新启动应用程序容器（不是 sidecar 容器），在此期间 sidecar 已准备就绪。所以它在 1 个应用程序容器重启后运行良好。

同样，这是所有服务网格的另一个常见问题。对此没有优雅的解决方案。非常简单的解决方案是在启动期间 “sleep”。GitHub 上有一个未解决的 issue，Linkerd2 人员提供了一个解决方案，我认为这比 “sleep” 需要更多的工作。

我们保持原样。 1 自动应用程序容器重启已经解决了问题。