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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 在 Intenseye,为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.2)

问题 1:Apache ZooKeeper Leader 的选举



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

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

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


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


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


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


微信图片_20220612144559.png


问题 2:Fail-Fast 日志



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


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


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


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


微信图片_20220612144638.png


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



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


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

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


微信图片_20220612144656.png


问题 4: Prometheus



Prometheus是一个用于监控和警报的开源云原生应用程序。它在时间序列数据库中记录实时指标,具有灵活的查询和实时警报。


Linkerd2 有精美的文档教程,可让您携带自己的 Prometheus 实例。我们遵循它并且一切正常,直到我们将一个应用程序网格化,该应用程序使用 Prometheus“PushGateway” 将我们自己的内部指标推送到 Linkerd2 生成的指标之外。


PushGateway 是一种中介服务,它允许您从无法抓取/拉取的作业中推送指标。

在网格之后,500 多个轻量级 Pod 开始通过 sidecar 代理推送指标。我们开始在 PushGateway 端遇到内存问题,我们从 500 多个 pod 中跳过了 9091(PushGateway 端口)的网格。


结论



微信图片_20220612144725.jpg


当艾莉亚杀死夜王时,并非一切都那么容易。在正在运行的系统中进行更改一直很困难。我们知道在与 Linkerd2 集成时会遇到一些障碍,但我们一一解决了我们的问题。

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
5月前
|
Kubernetes 网络协议 数据库
在Service Mesh内访问网格外的服务
阿里云服务网格ASM提供了访问外部服务的三种方式,包含设置外部服务访问策略、配置ServiceEntry和设置拦截对外访问的网段。本文介绍如何在服务网格ASM上访问外部服务。
58 0
|
8月前
|
运维 监控 安全
什么是service mesh?
什么是service mesh?
|
10月前
|
Prometheus 负载均衡 Kubernetes
Service Mesh: Istio vs Linkerd
根据CNCF的最新年度调查,很明显,很多人对在他们的项目中使用服务网格表现出了浓厚的兴趣,并且许多人已经在他们的生产中使用它们。近69%的人正在评估Istio,64%的人正在研究Linkerd。Linkerd是市场上第一个服务网格,但是Istio使服务网格更受欢迎。这两个项目都是最前沿的,而且竞争非常激烈,因此选择一个项目是一个艰难的选择。在此博客文章中,我们将了解有关Istio和Linkerd体系结构,其运动部件的更多信息,并比较其产品以帮助您做出明智的决定。
103 0
|
10月前
Service Mesh 的实现,Google 的 Istio
Service Mesh 的实现,Google 的 Istio
66 0
|
Kubernetes 监控 Devops
Service Mesh 介绍| 学习笔记
快速学习 Service Mesh 介绍
152 0
|
负载均衡 Kubernetes Cloud Native
对 Service Mesh 望而却步?可能都没理解这一点
Service Mesh 发展已经有 6-7年的时间,很多人对 Service Mesh 只停留在知道的水平上,特别是很多技术人第一次接触到 Service Mesh,看到服务网格的解释,看到 Istio 的架构,对这门技术仍然云里雾里。实际上,劝退大多数人的不是技术,而是概念本身。
175 0
对 Service Mesh 望而却步?可能都没理解这一点
|
网络协议 Java API
Service Mesh
Service Mesh
217 0
|
监控 负载均衡 Kubernetes
在 Intenseye,为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.1)
在 Intenseye,为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.1)
326 0
在 Intenseye,为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.1)
|
负载均衡 监控 网络协议
Service Mesh之Sidecar
时间总是给你意外,在使用微服务架构吗?还在考虑使用哪种微服务架构呢?要准备大干一场,学习spring cloud吗? 还在纠结这些问题时,这些技术都将要被淘汰了,下一代微服务Service Mesh出现了
252 0
Service Mesh之Sidecar
|
Rust Prometheus Kubernetes
了解 Linkerd Service Mesh 架构
了解 Linkerd Service Mesh 架构
138 0