譯者 | 李睿

審校 | 重樓

Apache Kafka通常簡稱為Kafka，是由Apache軟件基金會(huì)維護(hù)的一個(gè)開源事件流平臺。Apache Kafka最初是在LinkedIn構(gòu)思的，由Jay Kreps、Neha Narkhede和Jun Rao合作創(chuàng)建，并于2011年作為開源項(xiàng)目發(fā)布。

如今，Kafka已成為最流行的事件流平臺之一，用于處理實(shí)時(shí)數(shù)據(jù)源。它被廣泛用于構(gòu)建可擴(kuò)展、容錯(cuò)和高性能的流式數(shù)據(jù)管道。

Kafka的用途在不斷擴(kuò)大，主要的五個(gè)案例由Brij Pandey在隨附的圖片中很好地說明了這一點(diǎn)。

作為一個(gè)簡單的入門，了解Kafka平臺的組件及其工作方式非常重要。

Kafka是一個(gè)分布式事件流平臺，旨在有效地處理實(shí)時(shí)數(shù)據(jù)饋送。它基于發(fā)布-訂閱消息模型進(jìn)行操作，并遵循分布式和容錯(cuò)架構(gòu)。它維護(hù)一個(gè)持久、有序和分區(qū)的記錄序列，稱為“主題”。生產(chǎn)者編寫有關(guān)這些主題的數(shù)據(jù)，消費(fèi)者從中讀取數(shù)據(jù)。這樣可以實(shí)現(xiàn)數(shù)據(jù)生產(chǎn)者和消費(fèi)者之間的解耦，并允許多個(gè)應(yīng)用程序獨(dú)立地使用相同的數(shù)據(jù)流。

Kafka的關(guān)鍵組件包括：

• 主題和分區(qū)：Kafka將數(shù)據(jù)組織到主題中。每個(gè)主題都是一個(gè)記錄流，一個(gè)主題中的數(shù)據(jù)被分成多個(gè)分區(qū)。每個(gè)分區(qū)都是一個(gè)有序的、不可變的記錄序列。通過允許數(shù)據(jù)分布在多個(gè)Kafka代理上，分區(qū)實(shí)現(xiàn)了水平可擴(kuò)展性和并行性。
• 生產(chǎn)者：生產(chǎn)者是向Kafka主題寫入數(shù)據(jù)的應(yīng)用程序。它們將記錄發(fā)布到特定的主題，然后將記錄存儲(chǔ)在主題的分區(qū)中。生產(chǎn)者可以顯式地將記錄發(fā)送到特定的分區(qū)，或者允許Kafka使用分區(qū)策略來確定分區(qū)。
• 消費(fèi)者：消費(fèi)者是從Kafka主題中讀取數(shù)據(jù)的應(yīng)用程序。它們訂閱一個(gè)或多個(gè)主題，并使用分配給它們的分區(qū)中的記錄。消費(fèi)者組用于擴(kuò)展消費(fèi)，主題中的每個(gè)分區(qū)只能由組中的一個(gè)消費(fèi)者使用。這允許多個(gè)消費(fèi)者并行地處理來自同一主題的不同分區(qū)的數(shù)據(jù)。
• 代理：Kafka作為一個(gè)服務(wù)器集群運(yùn)行，每個(gè)服務(wù)器稱為一個(gè)代理。代理負(fù)責(zé)處理來自生產(chǎn)者和消費(fèi)者的讀寫請求，以及管理主題分區(qū)。Kafka集群可以有多個(gè)代理來分配負(fù)載并確保容錯(cuò)性。
• 分區(qū)/復(fù)制：為了實(shí)現(xiàn)容錯(cuò)性和數(shù)據(jù)持久性，Kafka允許為主題分區(qū)配置復(fù)制。每個(gè)分區(qū)可以有多個(gè)副本，其中一個(gè)副本指定為領(lǐng)導(dǎo)者，其他副本指定為跟隨者。領(lǐng)導(dǎo)者副本處理該分區(qū)的所有讀寫請求，而跟隨者副本從領(lǐng)導(dǎo)者副本復(fù)制數(shù)據(jù)以保持同步。如果領(lǐng)導(dǎo)者副本的代理發(fā)生故障，其中一個(gè)跟隨者副本將自動(dòng)成為新的領(lǐng)導(dǎo)者副本，以確保持續(xù)運(yùn)行。
• 偏移量管理：Kafka維護(hù)每個(gè)分區(qū)的偏移量概念。偏移量表示分區(qū)內(nèi)記錄的唯一標(biāo)識符。消費(fèi)者跟蹤他們當(dāng)前的偏移量，允許他們在失敗或重新處理的情況下從他們離開的地方恢復(fù)消費(fèi)。
• ZooKeeper：雖然不是Kafka本身的一部分，但ZooKeeper經(jīng)常用于管理元數(shù)據(jù)和協(xié)調(diào)Kafka集群中的代理。它有助于領(lǐng)導(dǎo)者的選舉、主題和分區(qū)信息，以及管理消費(fèi)者群體的協(xié)調(diào)。[注：Zookeeper元數(shù)據(jù)管理工具將很快被Kafka Raft(Kraft是一種內(nèi)部管理元數(shù)據(jù)的協(xié)議)所取代]

總的來說，Kafka的設(shè)計(jì)和架構(gòu)使它成為一個(gè)高度可擴(kuò)展、容錯(cuò)和高效的平臺，可以處理大量的實(shí)時(shí)數(shù)據(jù)流。它已經(jīng)成為許多數(shù)據(jù)驅(qū)動(dòng)的應(yīng)用程序和數(shù)據(jù)基礎(chǔ)設(shè)施中的核心組件，促進(jìn)了數(shù)據(jù)集成、事件處理和流分析。

一個(gè)典型的Kafka架構(gòu)如下圖所示：

Kafka集群是指將多個(gè)Kafka代理作為一個(gè)組一起運(yùn)行以形成Kafka集群的實(shí)踐。集群是Kafka架構(gòu)的一個(gè)基本方面，它提供了一些好處，包括可擴(kuò)展性、容錯(cuò)和高可用性。Kafka集群用于處理大規(guī)模數(shù)據(jù)流，并確保系統(tǒng)即使面對故障也能保持運(yùn)行。

在集群中，Kafka主題被劃分為多個(gè)分區(qū)，以實(shí)現(xiàn)可擴(kuò)展性和并行性。每個(gè)分區(qū)都是一個(gè)線性有序的、不可變的記錄序列。因此，分區(qū)允許數(shù)據(jù)跨集群中的多個(gè)代理分發(fā)。

需要注意的是，一個(gè)最小的Kafka集群由三個(gè)Kafka代理組成，每個(gè)代理都可以運(yùn)行在單獨(dú)的服務(wù)器上(虛擬或物理)。三節(jié)點(diǎn)指導(dǎo)是為了避免在代理失敗的情況下出現(xiàn)腦裂(Split-Brain)的情況。

Kafka和Kubernetes

隨著越來越多的企業(yè)采用Kafka，在Kubernetes上部署Kafka的興趣也越來越大。

事實(shí)上，Dynatrace最近發(fā)布的《2023年Kubernetes In the Wild報(bào)告》表明，40%以上的大型組織在Kubernetes中運(yùn)行他們的開源消息傳遞平臺，其中大部分是Kafka。

該報(bào)告還大膽宣稱，“Kubernetes正在成為云計(jì)算的‘操作系統(tǒng)’”。

因此，Kafka管理員必須了解Kafka和Kubernetes之間的相互作用，以及如何適當(dāng)?shù)貙?shí)現(xiàn)這些相互作用。

多集群Kafka的案例

在單個(gè)Kubernetes集群設(shè)置中運(yùn)行Kafka集群相當(dāng)簡單，并且在理論上可以根據(jù)需要實(shí)現(xiàn)可擴(kuò)展性。然而在生產(chǎn)中，其畫面可能會(huì)變得有點(diǎn)模糊。

應(yīng)該在Kafka和Kubernetes之間區(qū)分集群這個(gè)術(shù)語的使用。Kubernetes部署還使用術(shù)語集群來指定一組連接的節(jié)點(diǎn)，稱為Kubernetes集群。當(dāng)Kafka工作負(fù)載部署在Kubernetes上時(shí)，最終會(huì)得到一個(gè)在Kubernetes集群中運(yùn)行的Kafka集群，但與這一討論更相關(guān)的是，也可能有一個(gè)跨越多個(gè)Kubernetes集群的Kafka集群，以實(shí)現(xiàn)彈性、性能、數(shù)據(jù)主權(quán)等。

首先，Kafka并不是為多租戶設(shè)置而設(shè)計(jì)的。在技術(shù)方面，Kafka不理解Kubernetes名稱空間或資源隔離等概念。在特定主題中，沒有簡單的機(jī)制來強(qiáng)制多個(gè)用戶組之間的安全訪問限制。

此外，不同的工作負(fù)載可能具有不同的更新頻率和規(guī)模需求，例如，批處理應(yīng)用程序與實(shí)時(shí)應(yīng)用程序。將兩個(gè)工作負(fù)載組合到一個(gè)集群中可能會(huì)產(chǎn)生不利影響，或者消耗的資源遠(yuǎn)遠(yuǎn)超過所需的資源。

數(shù)據(jù)主權(quán)和合規(guī)性也會(huì)對在特定區(qū)域或應(yīng)用程序中共同定位數(shù)據(jù)和主題施加限制。

當(dāng)然，彈性是多個(gè)Kafka集群背后的另一個(gè)強(qiáng)大驅(qū)動(dòng)力。雖然Kafka集群是為主題容錯(cuò)而設(shè)計(jì)的，但仍然需要為整個(gè)集群的災(zāi)難性故障做好準(zhǔn)備。在這種情況下，對完全復(fù)制集群的需求支持適當(dāng)?shù)臉I(yè)務(wù)連續(xù)性規(guī)劃。

對于正在將工作負(fù)載遷移到云端或有混合云策略的企業(yè)，可能希望設(shè)置多個(gè)Kafka集群，并隨著時(shí)間的推移執(zhí)行有計(jì)劃的工作負(fù)載遷移，而不是冒險(xiǎn)的全面Kafka遷移。

在實(shí)踐中，很多企業(yè)發(fā)現(xiàn)自己不得不創(chuàng)建多個(gè)Kafka集群，但這些集群需要彼此交互，這只是其中的幾個(gè)原因。

多集群Kafka

為了使多個(gè)Kafka集群相互連接，必須將一個(gè)集群中的關(guān)鍵項(xiàng)復(fù)制到另一個(gè)集群。其中包括主題、偏移量和元數(shù)據(jù)。在Kafka術(shù)語中，這種復(fù)制被認(rèn)為是鏡像。

有兩種方法可以實(shí)現(xiàn)多集群設(shè)置：拉伸集群或連接集群。

擴(kuò)展集群：同步復(fù)制

拉伸集群是跨多個(gè)物理集群“拉伸”的邏輯集群。主題和副本分布在物理集群中，但由于它們被表示為邏輯集群，因此應(yīng)用程序本身并不知道這種多樣性。

拉伸集群具有很強(qiáng)的一致性，并且更易于管理。由于應(yīng)用程序不知道多個(gè)集群的存在，因此與連接集群相比，它們更容易部署在拉伸集群上。

拉伸集群的缺點(diǎn)是它需要集群之間的同步連接。它們對于混合云部署來說并不理想，并且需要至少三個(gè)集群的Quorum 機(jī)制來避免“腦裂”的情況。

連接集群：異步復(fù)制

連接集群通過連接多個(gè)獨(dú)立的集群進(jìn)行部署。這些獨(dú)立的集群可以運(yùn)行在不同的區(qū)域或云平臺上，并進(jìn)行單獨(dú)管理。

連接集群模型的主要優(yōu)點(diǎn)是，在集群發(fā)生故障的情況下不會(huì)有停機(jī)時(shí)間，因?yàn)槠渌菏仟?dú)立運(yùn)行的。每個(gè)集群還可以針對其特定資源進(jìn)行優(yōu)化。

連接集群的主要缺點(diǎn)是它依賴于集群之間的異步連接。在集群之間復(fù)制的主題不是“寫時(shí)復(fù)制”，而是取決于最終的一致性。這可能導(dǎo)致在異步鏡像過程中丟失數(shù)據(jù)。

此外，必須修改跨連接集群工作的應(yīng)用程序，以識別多個(gè)集群。

在解決這個(gè)難題之前，簡要介紹一下市場上支持Kafka集群連接的常用工具。

開源Kafka自帶鏡像工具M(jìn)irror Maker。

Mirror Maker通過內(nèi)置生成器在不同的集群之間復(fù)制主題。通過這種方式，數(shù)據(jù)在集群之間進(jìn)行交叉復(fù)制，最終保持一致性，但不會(huì)中斷單個(gè)進(jìn)程。

值得注意的是，雖然Mirror Maker的概念很簡單，但對于IT組織來說，大規(guī)模地設(shè)置Mirror Maker可能是一個(gè)相當(dāng)大的挑戰(zhàn)。必須正確管理IP地址、命名約定、副本數(shù)量等，否則可能會(huì)導(dǎo)致所謂的“無限復(fù)制”，即主題被無限復(fù)制，導(dǎo)致最終崩潰。

Mirror Maker的另一個(gè)缺點(diǎn)是缺乏允許/不允許更新列表的動(dòng)態(tài)配置。Mirror Maker也不能正確同步主題屬性，這使得它在添加或刪除要復(fù)制的主題時(shí)成為大規(guī)模操作的難題。Mirror Maker試圖解決其中的一些挑戰(zhàn)，但許多IT商店仍然難以正確設(shè)置Mirror Maker。

其他用于Kafka復(fù)制的開源工具包括來自Salesforce的Mirus，來自Uber的uReplicator，以及來自Netflix的定制Flink。

對于商業(yè)許可選項(xiàng)，Confluent提供了兩個(gè)選項(xiàng)：Confluent Replicator和Cluster Linking。Confluent Replicator本質(zhì)上是一個(gè)Kafka Connect連接器，它提供了一種高性能和彈性的方式在集群之間復(fù)制主題數(shù)據(jù)。Cluster Linking是另一種內(nèi)部開發(fā)的產(chǎn)品，其目標(biāo)是在保留主題偏移的同時(shí)進(jìn)行多區(qū)域復(fù)制。

即便如此，Cluster Linking還是一種異步復(fù)制工具，數(shù)據(jù)必須跨越網(wǎng)絡(luò)邊界并穿越公共流量路徑。

現(xiàn)在應(yīng)該很清楚，Kafka復(fù)制是大規(guī)模生產(chǎn)應(yīng)用程序的關(guān)鍵策略。問題是選擇哪一個(gè)選項(xiàng)。

富有想象力的Kafka管理員很快就會(huì)意識到，根據(jù)應(yīng)用程序的性能和彈性需求，可能需要連接集群和拉伸集群，或者這些部署的組合。

然而，令人生畏的是，設(shè)置集群配置和跨多個(gè)集群大規(guī)模管理這些配置是指數(shù)級的挑戰(zhàn)。還有什么更優(yōu)雅的方式來解決這個(gè)難題呢?

答案是肯定的!

Avesha的KubeSlice是一種兩全其美的簡單方法。通過在集群或命名空間之間創(chuàng)建直接的服務(wù)連接，KubeSlice無需手動(dòng)配置Kafka集群之間的單個(gè)連接。

KubeSlice的核心是在集群之間創(chuàng)建一個(gè)安全的、同步的第三層網(wǎng)絡(luò)網(wǎng)關(guān)，在應(yīng)用程序或名稱空間級別進(jìn)行隔離。一旦設(shè)置好了，Kafka管理員就可以自由地在任何集群中部署Kafka代理。

每個(gè)代理都與通過片連接的其他每個(gè)代理具有同步連接，即使代理本身可能位于不同的集群上。這有效地在代理之間創(chuàng)建了一個(gè)拉伸集群，并提供了強(qiáng)一致性和低管理開銷的好處。

結(jié)語

對于那些可能想將Mirror Maker部署到集群中的人來說，這可以用最少的精力完成，因?yàn)榧褐g的連接被委托給KubeSlice。因此，Kafka應(yīng)用程序可以在同一部署中獲得同步（速度、彈性）和異步（獨(dú)立性、規(guī)模）復(fù)制的好處，并能夠根據(jù)需要混合和匹配這些功能。這適用于預(yù)處理數(shù)據(jù)中心、公共云或混合設(shè)置中的任何組合。

KubeSlice是一個(gè)無中斷的部署，這意味著不需要卸載任何已經(jīng)部署的工具。這只是建立一個(gè)切片并將Kafka部署添加到該切片上的問題。

本文提供了Apache Kafka的簡要概述，并觸及了一些更常見的用例。還介紹了當(dāng)前可用于跨多個(gè)集群擴(kuò)展Kafka部署的工具，并討論了每種工具的優(yōu)缺點(diǎn)。最后，本文還介紹了Kubeslice，這是一種新興的服務(wù)連接解決方案，它簡化了Kafka多集群部署，并消除了大規(guī)模跨多個(gè)集群配置Kafka復(fù)制帶來的麻煩。

原文標(biāo)題：Kafka Multi-Cluster Deployment on Kubernetes： Simplified!，作者：Ray Edwards