作者：Balint Molnar

編者按

本文是一篇Kafka的基準測試分析報告，作者詳細介紹了測試的環境和配置選擇，并在單集群、多集群、多云、混合云等各種場景下進行了A/B測試和性能分析，評估了Istio的引入對性能的影響情況。最后對作者所在公司Banzai Cloud的云產品進行了介紹。

---

我們的容器管理平臺Pipeline以及CNCF認證的Kubernetes發行版PKE的一個關鍵特性是，它們能夠在多云和混合云環境中無縫地構建并運行。雖然Pipeline用戶的需求因他們采用的是單云方法還是多云方法而有所不同，但通常基于這些關鍵特性中的一個或多個：

• 多云應用管理

• 一個基于Istio的自動化服務網格，用于多云和混合云部署

• 基于Kubernetes federation v2（集群聯邦）的聯合資源和應用部署

隨著采用基于Istio operator的多集群和多混合云的增加，對運行接入到服務網格中的分布式或去中心化的應用的能力的需求也增加了。我們的客戶在Kubernetes上大規模運行的托管應用之一是Apache Kafka。我們認為，在Kubernetes上運行Apache Kafka最簡單的方法是使用Banzai Cloud的Kafka spotguide來構建我們的Kafka operator。然而，到目前為止，我們的重點一直是自動化和操作單個集群Kafka部署。

TLDR

• 我們已經添加了在Istio上運行Kafka所需的支持 (使用Kafka 和 Istio operator，并通過 Pipeline編排）.

• 在Istio上運行Kafka不會增加性能開銷 (不同于典型的mTLS，在SSL/TLS上運行Kafka是一樣的)。

• 使用 Pipeline，你可以創建跨多云和混合云環境的Kafka集群。

帶有生產者ACK設置為all的3個broker、3個partition和3個replication因子場景的指標預覽：

單集群結果

多集群結果

在Istio服務網格上運行Kafka

Kafka社區對如何利用更多的Istio功能非常感興趣，例如開箱即用的Tracing，穿過協議過濾器的mTLS等。盡管這些功能有不同的需求，如Envoy、Istio和其他各種GitHub repos和討論板上所反映的那樣。大部分的這些特性已經在我們的Pipeline platform的Kafka spotguide中，包括監控、儀表板、安全通信、集中式的日志收集、自動伸縮，Prometheus警報，自動故障恢復等等。我們和客戶錯過了一個重要的功能：網絡故障和多網絡拓撲結構的支持。我們之前已經利用Backyards和Istio operator解決過此問題。現在，探索在Istio上運行Kafka的時機已經到來，并在單云多區、多云，特別是混合云環境中自動創建Kafka集群。

讓Kafka在Istio上運行并不容易，需要時間以及在Kafka和Istio方面的大量專業知識。經過一番努力和決心，我們完成了要做的事情。然后我們以迭代的方式自動化了整個過程，使其在Pipeline platform上運行的盡可能順利。對于那些想要通讀這篇文章并了解問題所在的人——具體的來龍去脈——我們很快將在另一篇文章中進行深入的技術探討。同時，請隨時查看相關的GitHub代碼庫。

認知偏差

認知偏差是一個概括性術語，指的是信息的上下文和結構影響個人判斷和決策的系統方式。影響個體的認知偏差有很多種，但它們的共同特征是，與人類的個性相一致，它們會導致判斷和決策偏離理性的客觀。

自從Istio operator發布以來，我們發現自己陷入了一場關于Istio的激烈辯論中。我們已經在Helm（和Helm 3）中目睹了類似的過程，并且很快意識到關于這個主題的許多最激進的觀點并不是基于第一手的經驗。當我們與對Istio的復雜性有一些疑問的人產生共鳴的時候——這正是我們開源了Istio operator和發布Backyards產品背后的根本原因——我們真的不同意大多數性能相關的爭論。是的，Istio有很多“方便”的特性你可能需要也可能不需要，其中一些特性可能會帶來額外的延遲，但是問題是和往常一樣，這樣做是否值得?

注意：是的，在運行一個包含大量微服務、策略實施和原始遙測數據過程的大型Istio集群時，我們已經看到了Mixer性能下降和其他的問題，對此表示關注；Istio社區正在開發一個mixerless版本——其大部分功能會疊加到Envoy上。

做到客觀，測量先行

在我們就是否向客戶發布這些特性達成一致之前，我們決定進行一個性能測試。我們使用了幾個在基于Istio服務網格上運行Kafka的測試場景來實現這點。你可能注意到，Kafka是一個數據密集型的應用，因此我們希望通過在依賴和不依賴Istio的兩種情況下進行測試，以測量其增加的開銷。此外，我們對Istio如何處理數據密集型應用很感興趣，在這些應用程序中保持I/O吞吐量恒定，讓所有組件負荷都達到了最大值。

我們使用了新版本的 Kafka operator，它提供了Istio服務網格的原生支持（版本 >=0.5.0）。

基準測試安裝設置

為了驗證我們的多云設置，我們決定先用各種Kubernetes集群場景測試Kafka：

• 單機群，3個broker，3個topic分3個partition，復制因子設置為3，關閉TLS

• 單機群，3個broker，3個topic分3個partition，復制因子設置為3，啟用TLS

這些設置對于檢查Kafka在選定環境中的實際性能是非常必要的，且沒有潛在的Istio開銷。

為了對Kafka進行基準測試，我們決定使用兩個最流行的云提供商下的Kubernetes解決方案，Amazon EKS和Google GKE。我們希望最小化配置和避免任何潛在的CNI配置不匹配問題，因此決定使用云提供商管理的K8s發行版。

在另一篇文章中，我們將發布混合云Kafka集群的基準測試，其中會使用自己的Kubernetes發行版PKE。

我們想要模擬經常在Pipeline平臺上的一個用例，因此部署了跨可用區的節點，Zookeeper和客戶端也位于不同的節點中。

下面是使用到的實例類型：

AMAZON EKS

對于存儲，我們請求了Amazon提供的IOPS SSD（io1），在上面列出的實例中，它可以持續的達到437MB/s吞吐量。僅供參考，Amazon在一天剩下的時間里會在30分鐘后對小型實例類型磁盤IO進行節流。你可以從 這里讀到更多信息。

GOOGLE GKE

KAFKA和加載工具存儲方面，我們設置了Google的pd-ssd，根據文檔，它可以達到400MB/s。

Kafka方面，我們使用了3個topic，partition 數量和 replication 因子都設置為 3。基于測試的目的我們使用了默認的配置值，除了 broker.rack,min.insync.replicas。

在基準測試中，我們使用自定義構建的Kafka Docker映像banzaicloud/ Kafka:2.12-2.1.1。它使用Java 11、Debian并包含2.1.1版本的Kafka。Kafka容器配置為使用4個CPU內核和12GB內存， Java的堆大小為10GB。

banzaicloud/kafka:2.12-2.1.1 鏡像是基于 wurstmeister/kafka:2.12-2.1.1 鏡像的， 但為了SSL庫的性能提升，我們想用 Java 11 代替 Java 8。

加載工具使用 sangrenel生成，它是一個基于Go語言實現的Kafka性能工具，配置如下：

• 512 字節的消息尺寸

• 不壓縮

• required-acks 設置為 all

• worker設置為20個

為了得到準確的結果，我們使用Grafana 儀表板1860的可視化NodeExporter指標監控整個架構。我們不斷增加生產者的數量，直到達到架構或Kafka的極限。

為基準測試創建的架構已經超出了這篇文章的范圍，但是如果你對重現它感興趣，我們建議使用Pipeline管道和訪問Kafka-operator 的GitHub獲取更多細節。

基準測試環境

在討論Kafka的基準測試結果之前，我們還對環境進行了測試。由于Kafka是一個極端數據密集型的應用，我們特別關注在測試磁盤速度和網絡性能；根據經驗，這是對Kafka影響最大的指標。網絡性能方面，我們使用了一個名為iperf的工具。創建了兩個相同的基于Ubuntu的Pod：一個是服務端，另一個是客戶端。

• 在 Amazon EKS 上我們測量到了 3.01 Gbits/sec 的吞吐量。

• 在 Google GKE 上我們測量到了 7.60 Gbits/sec 的吞吐量。

為了確定磁盤速度，我們在基于容器的Ubuntu系統下使用了一個叫 dd的工具。

• 在Amazon EKS上我們測量的結果是 437MB/s（這與Amazon為該實例和ssd類型提供的內容完全一致）。

• 在Google GKE上我們測量的結果是 400MB/s（這也與谷歌為其實例和ssd類型提供的內容一致）。

現在我們對環境有了更好的理解，讓我們繼續討論部署到Kubernetes的Kafka集群。

單集群

Google GKE

Kafka部署在Kubernetes - 沒有Istio

在我們得到關于EKS的結果之后，我們對Kafka在GKE上達到 417MB/s 的磁盤吞吐量并不感到驚訝。該性能受到實例的磁盤IO限制。

Kafka基于Kubernetes 開啟TLS - 沒有Istio

一旦我們為Kafka打開SSL/TLS，和預期的一樣并且已經多次基準測試過，就會出現性能損失。眾所周知，Java的SSL/TLS（插件化的）實現性能很差，而且它在Kafka中導致了性能問題。不過在最近的實現版本（9+）中有一些改進，因此我們升級到了Java 11。結果如下:

• 吞吐量274MB/s ，大約30% 吞吐量損失

• 和沒有TLS比較，包速率有大約兩倍的提升

Kafka基于Kubernetes - 且有Istio

我們急切地想知道在Istio中部署和使用Kafka時是否會增加開銷和有性能損失。結果很有希望:

• 沒有性能損失

• CPU方面略有增加

Kafka基于Kubernetes - 有Istio并開啟mTLS

接下來，我們在Istio上啟用了mTLS，并重用了相同的Kafka部署。結果比基于Kubernetes的Kafka并開啟了SSL/TLS的要好。

• 吞吐量323MB/s ，大約20% 吞吐量損失

• 和沒有TLS比較大約有2倍的包速率提升

Amazon EKS

Kafka基于Kubernetes - 沒有Istio

在這個配置下我們得到了一個相當可觀的寫入速度439MB/s，如果消息的尺寸是512字節，那么它就是892928消息/秒。事實上，我們壓榨出了AWS r5.4xlarge這種實例的磁盤吞吐量最大的負荷能力。

Kafka基于Kubernetes并開啟TLS - 沒有Istio

一旦我們再次為Kafka打開SSL/TLS，并進行了多次基準測試，就像預期的那樣會出現性能損失。Java的SSL/TLS實現性能問題在EKS上和GKE一樣存在。不過正如我們之前所說，最近的版本已經有了改進。因此我們將其升級到Java 11，結果如下：

• 吞吐量306MB/s ，大約30% 吞吐量損失

• 和沒有TLS比較，大約2倍包速率提升

Kafka基于Kubernetes - 有Istio

和以前一樣，結果也很好：

• 沒有性能損失

• CPU使用方面有輕微增加

Kafka基于Kubernetes - 有Istio且開啟mTLS

接下來，我們在Istio上啟用了mTLS，并重用了相同的Kafka部署。同樣的，結果比Kafka在Kubernetes上直接使用SSL/TLS要好。

• 吞吐量340MB/s ，大約20%吞吐量損耗

• 包速率增加了，但低于兩倍

額外的嘗試 - Kafka基于Linkerd（關閉mTLS）

我們測試了所有可用的情況，所以想用Linkerd再嘗試一下。為什么？因為我們可以做到。雖然我們知道Linkerd在可用的功能方面不能滿足客戶期望，但我們仍然想嘗試一下。我們的期望值很高，但得出的數字給了我們一個沉重的教訓，也提醒了我們什么是認知偏見。

• 吞吐量246MB/s

單集群結論

在繼續多集群基準測試之前，讓我們評估一下已有的數據。可以看出，在這些環境和場景中，使用沒有mTLS的服務網格不會影響Kafka的性能。在到達網絡、內存或CPU瓶頸前，底層磁盤的吞吐量限制了Kafka的性能。

無論是使用Istio還是Kafka自己的SSL/TLS庫，都會使Kafka的性能降低約20%。它也增加了一點CPU負載，并使通過網絡傳輸的數據包數量增加了一倍。

注意，在使用iperf進行架構測試期間，僅在網絡上啟用mTLS就會導致大約20%的性能損耗。

跨“racks”（云區域）topic復制的多集群場景

在這個設置中，我們模擬的內容更接近于生產環境，為了重用測試環境，我們堅持使用相同配置的AWS或Google實例，但是在不同的區域上設置了多個集群（跨云區域的topic復制）。請注意，無論我們跨單個云提供商使用這些集群，還是跨多個云或混合云來使用這些集群，流程都應該是相同的。從Backyards和Istio operator的角度來看沒有區別，我們支持3種不同的網絡拓撲。

其中一個集群比另一個集群更大，它包含兩個broker和兩個Zookeeper節點。而另一個集群則各有一個節點。注意，在支持mTLS的單網格多集群環境中是絕對必要的。此外我們還設置min.insync.replicas為3，讓生產者應答所有耐用性相關的請求。

網格是全自動的由 Istio operator提供。

Google GKE <-> GKE

在這個場景中，我們創建了一個單網格/單Kakfa集群，它跨越兩個Google云區域：eu-west1和eu-west4

• 吞吐量211MB/s

Amazon EKS <-> EKS

在這個場景中，我們創建了一個單網格/單Kakfa集群，它橫跨兩個AWS區域：eu-north1和eu-west1

• 吞吐量85MB/s

Google GKE <-> EKS

在這個場景中，我們創建了一個單一的Istio網格，它跨越多個集群和多個云，形成了一個單一的Kafka集群（Google云區域是europe-west-3， AWS的區域是eu-central-1）。正如預期的那樣，結果要差得多。

• 吞吐量115MB/s

多集群結論

從基準測試來看，我們可以放心地說，在多云單網格環境中使用Kafka是值得的。人們選擇在Istio上部署Kafka這種環境的原因各不相同，但像Pipeline這樣易于安裝，有額外的安全收益，具有可伸縮性和耐用性，基于本地負載均衡和更多特性的工具是一個完美的選擇。

正如前面提到的，本系列后續的文章之一是關于基準測試/運維一個自動伸縮的混云Kafka集群，警報和縮放事件基于Prometheus的指標（我們對基于Istio指標的多個應用進行類似的自動伸縮，并通過網格部署和觀察它們——閱讀這篇之前的文章了解詳情：基于自定義Istio指標的Pod水平自動伸縮。）

關于 Backyards

Banzai Cloud的Backyards是一個支持多云和混合云的服務網格平臺，用于構建現代應用程序。基于Kubernetes，我們的Istio operator和Pipeline平臺支持跨實體數據中心和5個云環境的靈活性、可移植性和一致性。使用簡單但功能極其強大的UI和CLI，自己體驗自動金絲雀發布、流量轉移、路由、安全服務通信、深度的可觀察性等特性。

關于 Pipeline

Banzai Cloud的 Pipeline提供了一個平臺，允許企業開發、部署和擴展基于容器的應用程序。它利用了最好的云組件比如Kubernetes，為開發人員和運營團隊創建了一個高效、靈活的環境。強大的安全評估——多認證后端，細粒度的授權、動態安全管理、使用TLS，漏洞掃描，靜態代碼分析，CI/CD等特性的組件之間的自動化安全通信，Pipeline是一個0層（tier zero）特性的平臺，努力使所有企業實現自動化。

關于 Banzai Cloud

Banzai Cloud 正在改變私有云的構建方式：簡化復雜應用程序的開發、部署和擴展，并將Kubernetes和云原生技術的強大功能交到各地的開發人員和企業手中。

?推薦閱讀?

在Play with Kubernetes平臺上以測試驅動的方式部署Istio

（譯）Istio 1.0 的實戰測試

Istio和Linkerd的CPU基準測試報告

第六屆?Service Mesh Meetup 廣州站

8 月 11 日（本周日），廣州見！報名地址：https://tech.antfin.com/community/activities/781

總結

以上是生活随笔為你收集整理的运行在Istio之上的Apache Kafka——基准测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。