在 Intenseye,為什麼我們選擇 Linkerd2 作為 Service Mesh 工具(Part.2)
- 2021 年 7 月 23 日
- 筆記
在我們 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
自動應用程式容器重啟已經解決了問題。
問題 4: Prometheus
Prometheus是一個用於監控和警報的開源雲原生應用程式。它在時間序列資料庫中記錄實時指標,具有靈活的查詢和實時警報。
Linkerd2
有精美的文檔教程,可讓您攜帶自己的 Prometheus
實例。 我們遵循它並且一切正常,直到我們將一個應用程式網格化,該應用程式使用 Prometheus
的 「PushGateway」
將我們自己的內部指標推送到 Linkerd2
生成的指標之外。
PushGateway
是一種中介服務,它允許您從無法抓取/拉取的作業中推送指標。
在網格之後,500
多個輕量級 Pod
開始通過 sidecar
代理推送指標。我們開始在 PushGateway
端遇到記憶體問題,我們從 500
多個 pod
中跳過了 9091
(PushGateway 埠)的網格。
結論
當艾莉亞殺死夜王時,並非一切都那麼容易。 在正在運行的系統中進行更改一直很困難。 我們知道在與 Linkerd2
集成時會遇到一些障礙,但我們一一解決了我們的問題。