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

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测监控 Prometheus 版,每月50GB免费额度
简介: 在 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实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
监控 负载均衡 Kubernetes
在 Intenseye,为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.1)
在 Intenseye,为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.1)
387 0
在 Intenseye,为什么我们选择 Linkerd2 作为 Service Mesh 工具(Part.1)
|
Prometheus Kubernetes 负载均衡
2020年-Service Mesh工具对比
2020年-Service Mesh工具对比
360 0
|
运维 监控 安全
Service Mesh 在中国工商银行的探索与实践
服务网格与现有微服务架构融合发展,助力工行应用架构向分布式、服务化转型,承载未来开放平台核心银行系统。
|
网络协议 Java API
Service Mesh
Service Mesh
254 0
|
运维 监控 安全
什么是service mesh?
什么是service mesh?
|
负载均衡 Kubernetes Cloud Native
对 Service Mesh 望而却步?可能都没理解这一点
Service Mesh 发展已经有 6-7年的时间,很多人对 Service Mesh 只停留在知道的水平上,特别是很多技术人第一次接触到 Service Mesh,看到服务网格的解释,看到 Istio 的架构,对这门技术仍然云里雾里。实际上,劝退大多数人的不是技术,而是概念本身。
216 0
对 Service Mesh 望而却步?可能都没理解这一点
Service Mesh 的实现,Google 的 Istio
Service Mesh 的实现,Google 的 Istio
106 0
|
负载均衡 监控 网络协议
Service Mesh之Sidecar
时间总是给你意外,在使用微服务架构吗?还在考虑使用哪种微服务架构呢?要准备大干一场,学习spring cloud吗? 还在纠结这些问题时,这些技术都将要被淘汰了,下一代微服务Service Mesh出现了
302 0
Service Mesh之Sidecar
|
Rust Prometheus Kubernetes
了解 Linkerd Service Mesh 架构
了解 Linkerd Service Mesh 架构
197 0
|
容器 Kubernetes 微服务
Service Mesh 初体验
前言 计算机软件技术发展到现在,软件架构的演进无不朝着让开发者能够更加轻松快捷地构建大型复杂应用的方向发展。容器技术最初是为了解决运行环境的不一致问题而产生的,随着不断地发展,围绕容器技术衍生出来越来越多的新方向。
4446 13

热门文章

最新文章