作者：Balint Molnar

編者按

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

---

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

• 多云應(yīng)用管理

• 一個基于Istio的自動化服務(wù)網(wǎng)格，用于多云和混合云部署

• 基于Kubernetes federation v2（集群聯(lián)邦）的聯(lián)合資源和應(yīng)用部署

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

TLDR

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

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

• 使用 Pipeline，你可以創(chuàng)建跨多云和混合云環(huán)境的Kafka集群。

帶有生產(chǎn)者ACK設(shè)置為all的3個broker、3個partition和3個replication因子場景的指標預覽：

單集群結(jié)果

多集群結(jié)果

在Istio服務(wù)網(wǎng)格上運行Kafka

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

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

認知偏差

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

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

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

做到客觀，測量先行

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

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

基準測試安裝設(shè)置

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

• 單機群，3個broker，3個topic分3個partition，復制因子設(shè)置為3，關(guān)閉TLS

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

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

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

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

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

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

AMAZON EKS

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

GOOGLE GKE

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

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

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

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

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

• 512 字節(jié)的消息尺寸

• 不壓縮

• required-acks 設(shè)置為 all

• worker設(shè)置為20個

為了得到準確的結(jié)果，我們使用Grafana 儀表板1860的可視化NodeExporter指標監(jiān)控整個架構(gòu)。我們不斷增加生產(chǎn)者的數(shù)量，直到達到架構(gòu)或Kafka的極限。

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

基準測試環(huán)境

在討論Kafka的基準測試結(jié)果之前，我們還對環(huán)境進行了測試。由于Kafka是一個極端數(shù)據(jù)密集型的應(yīng)用，我們特別關(guān)注在測試磁盤速度和網(wǎng)絡(luò)性能；根據(jù)經(jīng)驗，這是對Kafka影響最大的指標。網(wǎng)絡(luò)性能方面，我們使用了一個名為iperf的工具。創(chuàng)建了兩個相同的基于Ubuntu的Pod：一個是服務(wù)端，另一個是客戶端。

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

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

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

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

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

現(xiàn)在我們對環(huán)境有了更好的理解，讓我們繼續(xù)討論部署到Kubernetes的Kafka集群。

單集群

Google GKE

Kafka部署在Kubernetes - 沒有Istio

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

Kafka基于Kubernetes 開啟TLS - 沒有Istio

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

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

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

Kafka基于Kubernetes - 且有Istio

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

• 沒有性能損失

• CPU方面略有增加

Kafka基于Kubernetes - 有Istio并開啟mTLS

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

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

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

Amazon EKS

Kafka基于Kubernetes - 沒有Istio

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

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

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

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

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

Kafka基于Kubernetes - 有Istio

和以前一樣，結(jié)果也很好：

• 沒有性能損失

• CPU使用方面有輕微增加

Kafka基于Kubernetes - 有Istio且開啟mTLS

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

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

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

額外的嘗試 - Kafka基于Linkerd（關(guān)閉mTLS）

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

• 吞吐量246MB/s

單集群結(jié)論

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

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

注意，在使用iperf進行架構(gòu)測試期間，僅在網(wǎng)絡(luò)上啟用mTLS就會導致大約20%的性能損耗。

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

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

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

網(wǎng)格是全自動的由 Istio operator提供。

Google GKE <-> GKE

在這個場景中，我們創(chuàng)建了一個單網(wǎng)格/單Kakfa集群，它跨越兩個Google云區(qū)域：eu-west1和eu-west4

• 吞吐量211MB/s

Amazon EKS <-> EKS

在這個場景中，我們創(chuàng)建了一個單網(wǎng)格/單Kakfa集群，它橫跨兩個AWS區(qū)域：eu-north1和eu-west1

• 吞吐量85MB/s

Google GKE <-> EKS

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

• 吞吐量115MB/s

多集群結(jié)論

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

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

關(guān)于 Backyards

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

關(guān)于 Pipeline

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

關(guān)于 Banzai Cloud

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

?推薦閱讀?

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

（譯）Istio 1.0 的實戰(zhàn)測試

Istio和Linkerd的CPU基準測試報告

第六屆?Service Mesh Meetup 廣州站

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。