在我們 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 整合時會遇到一些障礙，但我們一一解決了我們的問題。