在 Intenseye,為什么我們選擇 Linkerd2 作為 Service Mesh 工具(Part.2)


在我們 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 進行元數據存儲、集群配置和協調。在我們將 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 等,這是解決方法。

問題 2:Fail-Fast 日志

我們已經開始對我們的應用程序進行一一網格化。一切都很好,直到對其中一個 AI 服務進行網格划分,我們將其稱為 application-a。我們有另一個應用程序作為 500 多個輕量級 Pod 運行,我們稱之為 application-b,它使用 gRPCapplication-a 發出請求。

在成功 mesh 12 分鍾后,我們看到數百個 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。不再出現快速失敗的錯誤。

問題 3:Sidecar 初始化前的出站連接

我們在應用程序啟動期間進行 HTTP 調用的應用程序很少。
它需要在服務請求之前獲取一些信息。
所以應用程序試圖在 Linkerd2 sidecar 初始化之前建立出站連接,因此它失敗了。 K8S 正在重新啟動應用程序容器(不是 sidecar 容器),在此期間 sidecar 已准備就緒。所以它在 1 個應用程序容器重啟后運行良好。

同樣,這是所有服務網格的另一個常見問題。對此沒有優雅的解決方案。 非常簡單的解決方案是在啟動期間 “sleep”。 GitHub 上有一個未解決的 issueLinkerd2 人員提供了一個解決方案,我認為這比 “sleep” 需要更多的工作。

我們保持原樣。 1 自動應用程序容器重啟已經解決了問題。

問題 4: Prometheus

Prometheus是一個用於監控和警報的開源雲原生應用程序。它在時間序列數據庫中記錄實時指標,具有靈活的查詢和實時警報。

Linkerd2 有精美的文檔教程,可讓您攜帶自己的 Prometheus 實例。 我們遵循它並且一切正常,直到我們將一個應用程序網格化,該應用程序使用 Prometheus“PushGateway” 將我們自己的內部指標推送到 Linkerd2 生成的指標之外。

PushGateway 是一種中介服務,它允許您從無法抓取/拉取的作業中推送指標。

在網格之后,500 多個輕量級 Pod 開始通過 sidecar 代理推送指標。我們開始在 PushGateway 端遇到內存問題,我們從 500 多個 pod 中跳過了 9091(PushGateway 端口)的網格。

結論

當艾莉亞殺死夜王時,並非一切都那么容易。 在正在運行的系統中進行更改一直很困難。 我們知道在與 Linkerd2 集成時會遇到一些障礙,但我們一一解決了我們的問題。

References:


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM