作者：Balint Molnar

編者按

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

---

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

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

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

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

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

TLDR

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

• 在Istio上運(yùn)行Kafka不會(huì)增加性能開(kāi)銷 (不同于典型的mTLS，在SSL/TLS上運(yùn)行Kafka是一樣的)。

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

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

單集群結(jié)果

多集群結(jié)果

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

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

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

認(rèn)知偏差

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

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

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

做到客觀，測(cè)量先行

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

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

基準(zhǔn)測(cè)試安裝設(shè)置

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

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

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

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

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

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

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

下面是使用到的實(shí)例類型：

AMAZON EKS

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

GOOGLE GKE

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

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

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

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

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

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

• 不壓縮

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

• worker設(shè)置為20個(gè)

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

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

基準(zhǔn)測(cè)試環(huán)境

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

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

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

為了確定磁盤速度，我們?cè)诨谌萜鞯腢buntu系統(tǒng)下使用了一個(gè)叫 dd的工具。

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

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

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

單集群

Google GKE

Kafka部署在Kubernetes - 沒(méi)有Istio

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

Kafka基于Kubernetes 開(kāi)啟TLS - 沒(méi)有Istio

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

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

• 和沒(méi)有TLS比較，包速率有大約兩倍的提升

Kafka基于Kubernetes - 且有Istio

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

• 沒(méi)有性能損失

• CPU方面略有增加

Kafka基于Kubernetes - 有Istio并開(kāi)啟mTLS

接下來(lái)，我們?cè)贗stio上啟用了mTLS，并重用了相同的Kafka部署。結(jié)果比基于Kubernetes的Kafka并開(kāi)啟了SSL/TLS的要好。

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

• 和沒(méi)有TLS比較大約有2倍的包速率提升

Amazon EKS

Kafka基于Kubernetes - 沒(méi)有Istio

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

Kafka基于Kubernetes并開(kāi)啟TLS - 沒(méi)有Istio

一旦我們?cè)俅螢镵afka打開(kāi)SSL/TLS，并進(jìn)行了多次基準(zhǔn)測(cè)試，就像預(yù)期的那樣會(huì)出現(xiàn)性能損失。Java的SSL/TLS實(shí)現(xiàn)性能問(wèn)題在EKS上和GKE一樣存在。不過(guò)正如我們之前所說(shuō)，最近的版本已經(jīng)有了改進(jìn)。因此我們將其升級(jí)到Java 11，結(jié)果如下：

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

• 和沒(méi)有TLS比較，大約2倍包速率提升

Kafka基于Kubernetes - 有Istio

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

• 沒(méi)有性能損失

• CPU使用方面有輕微增加

Kafka基于Kubernetes - 有Istio且開(kāi)啟mTLS

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

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

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

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

我們測(cè)試了所有可用的情況，所以想用Linkerd再嘗試一下。為什么？因?yàn)槲覀兛梢宰龅健ｋm然我們知道Linkerd在可用的功能方面不能滿足客戶期望，但我們?nèi)匀幌雵L試一下。我們的期望值很高，但得出的數(shù)字給了我們一個(gè)沉重的教訓(xùn)，也提醒了我們什么是認(rèn)知偏見(jiàn)。

• 吞吐量246MB/s

單集群結(jié)論

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

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

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

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

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

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

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

Google GKE <-> GKE

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

• 吞吐量211MB/s

Amazon EKS <-> EKS

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

• 吞吐量85MB/s

Google GKE <-> EKS

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

• 吞吐量115MB/s

多集群結(jié)論

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

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

關(guān)于 Backyards

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

關(guān)于 Pipeline

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

關(guān)于 Banzai Cloud

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

?推薦閱讀?

在Play with Kubernetes平臺(tái)上以測(cè)試驅(qū)動(dòng)的方式部署Istio

（譯）Istio 1.0 的實(shí)戰(zhàn)測(cè)試

Istio和Linkerd的CPU基準(zhǔn)測(cè)試報(bào)告

第六屆?Service Mesh Meetup 廣州站

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

總結(jié)

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

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