譯者 | 李睿
審校 | 重樓
Apache Kafka通常簡稱為Kafka，是由Apache軟件基金會維護的一個開源事件流平臺。Apache Kafka最初是在LinkedIn構(gòu)思的，由Jay Kreps、Neha Narkhede和Jun Rao合作創(chuàng)建，并于2011年作為開源項目發(fā)布。
如今，Kafka已成為最流行的事件流平臺之一，用于處理實時數(shù)據(jù)源。它被廣泛用于構(gòu)建可擴展、容錯和高性能的流式數(shù)據(jù)管道。
Kafka的用途在不斷擴大，主要的五個案例由Brij Pandey在隨附的圖片中很好地說明了這一點。
作為一個簡單的入門，了解Kafka平臺的組件及其工作方式非常重要。
Kafka是一個分布式事件流平臺，旨在有效地處理實時數(shù)據(jù)饋送。它基于發(fā)布-訂閱消息模型進行操作，并遵循分布式和容錯架構(gòu)。它維護一個持久、有序和分區(qū)的記錄序列，稱為“主題”。生產(chǎn)者編寫有關(guān)這些主題的數(shù)據(jù)，消費者從中讀取數(shù)據(jù)。這樣可以實現(xiàn)數(shù)據(jù)生產(chǎn)者和消費者之間的解耦，并允許多個應(yīng)用程序獨立地使用相同的數(shù)據(jù)流。
Kafka的關(guān)鍵組件包括：
- 主題和分區(qū)：Kafka將數(shù)據(jù)組織到主題中。每個主題都是一個記錄流，一個主題中的數(shù)據(jù)被分成多個分區(qū)。每個分區(qū)都是一個有序的、不可變的記錄序列。通過允許數(shù)據(jù)分布在多個Kafka代理上，分區(qū)實現(xiàn)了水平可擴展性和并行性。
- 生產(chǎn)者：生產(chǎn)者是向Kafka主題寫入數(shù)據(jù)的應(yīng)用程序。它們將記錄發(fā)布到特定的主題，然后將記錄存儲在主題的分區(qū)中。生產(chǎn)者可以顯式地將記錄發(fā)送到特定的分區(qū)，或者允許Kafka使用分區(qū)策略來確定分區(qū)。
- 消費者：消費者是從Kafka主題中讀取數(shù)據(jù)的應(yīng)用程序。它們訂閱一個或多個主題，并使用分配給它們的分區(qū)中的記錄。消費者組用于擴展消費，主題中的每個分區(qū)只能由組中的一個消費者使用。這允許多個消費者并行地處理來自同一主題的不同分區(qū)的數(shù)據(jù)。
- 代理：Kafka作為一個服務(wù)器集群運行，每個服務(wù)器稱為一個代理。代理負(fù)責(zé)處理來自生產(chǎn)者和消費者的讀寫請求，以及管理主題分區(qū)。Kafka集群可以有多個代理來分配負(fù)載并確保容錯性。
- 分區(qū)/復(fù)制：為了實現(xiàn)容錯性和數(shù)據(jù)持久性，Kafka允許為主題分區(qū)配置復(fù)制。每個分區(qū)可以有多個副本，其中一個副本指定為領(lǐng)導(dǎo)者，其他副本指定為跟隨者。領(lǐng)導(dǎo)者副本處理該分區(qū)的所有讀寫請求，而跟隨者副本從領(lǐng)導(dǎo)者副本復(fù)制數(shù)據(jù)以保持同步。如果領(lǐng)導(dǎo)者副本的代理發(fā)生故障，其中一個跟隨者副本將自動成為新的領(lǐng)導(dǎo)者副本，以確保持續(xù)運行。
- 偏移量管理：Kafka維護每個分區(qū)的偏移量概念。偏移量表示分區(qū)內(nèi)記錄的唯一標(biāo)識符。消費者跟蹤他們當(dāng)前的偏移量，允許他們在失敗或重新處理的情況下從他們離開的地方恢復(fù)消費。
- ZooKeeper：雖然不是Kafka本身的一部分，但ZooKeeper經(jīng)常用于管理元數(shù)據(jù)和協(xié)調(diào)Kafka集群中的代理。它有助于領(lǐng)導(dǎo)者的選舉、主題和分區(qū)信息，以及管理消費者群體的協(xié)調(diào)。[注：Zookeeper元數(shù)據(jù)管理工具將很快被Kafka Raft(Kraft是一種內(nèi)部管理元數(shù)據(jù)的協(xié)議)所取代]
總的來說，Kafka的設(shè)計和架構(gòu)使它成為一個高度可擴展、容錯和高效的平臺，可以處理大量的實時數(shù)據(jù)流。它已經(jīng)成為許多數(shù)據(jù)驅(qū)動的應(yīng)用程序和數(shù)據(jù)基礎(chǔ)設(shè)施中的核心組件，促進了數(shù)據(jù)集成、事件處理和流分析。
一個典型的Kafka架構(gòu)如下圖所示：
Kafka集群是指將多個Kafka代理作為一個組一起運行以形成Kafka集群的實踐。集群是Kafka架構(gòu)的一個基本方面，它提供了一些好處，包括可擴展性、容錯和高可用性。Kafka集群用于處理大規(guī)模數(shù)據(jù)流，并確保系統(tǒng)即使面對故障也能保持運行。
在集群中，Kafka主題被劃分為多個分區(qū)，以實現(xiàn)可擴展性和并行性。每個分區(qū)都是一個線性有序的、不可變的記錄序列。因此，分區(qū)允許數(shù)據(jù)跨集群中的多個代理分發(fā)。
需要注意的是，一個最小的Kafka集群由三個Kafka代理組成，每個代理都可以運行在單獨的服務(wù)器上(虛擬或物理)。三節(jié)點指導(dǎo)是為了避免在代理失敗的情況下出現(xiàn)腦裂(Split-BrAIn)的情況。
Kafka和Kube.NETes
隨著越來越多的企業(yè)采用Kafka，在Kubernetes上部署Kafka的興趣也越來越大。
事實上，Dynatrace最近發(fā)布的《2023年Kubernetes In the Wild報告》表明，40%以上的大型組織在Kubernetes中運行他們的開源消息傳遞平臺，其中大部分是Kafka。
該報告還大膽宣稱，“Kubernetes正在成為云計算的‘操作系統(tǒng)’”。
因此，Kafka管理員必須了解Kafka和Kubernetes之間的相互作用，以及如何適當(dāng)?shù)貙崿F(xiàn)這些相互作用。
多集群Kafka的案例
在單個Kubernetes集群設(shè)置中運行Kafka集群相當(dāng)簡單，并且在理論上可以根據(jù)需要實現(xiàn)可擴展性。然而在生產(chǎn)中，其畫面可能會變得有點模糊。
應(yīng)該在Kafka和Kubernetes之間區(qū)分集群這個術(shù)語的使用。Kubernetes部署還使用術(shù)語集群來指定一組連接的節(jié)點，稱為Kubernetes集群。當(dāng)Kafka工作負(fù)載部署在Kubernetes上時，最終會得到一個在Kubernetes集群中運行的Kafka集群，但與這一討論更相關(guān)的是，也可能有一個跨越多個Kubernetes集群的Kafka集群，以實現(xiàn)彈性、性能、數(shù)據(jù)主權(quán)等。
首先，Kafka并不是為多租戶設(shè)置而設(shè)計的。在技術(shù)方面，Kafka不理解Kubernetes名稱空間或資源隔離等概念。在特定主題中，沒有簡單的機制來強制多個用戶組之間的安全訪問限制。
此外，不同的工作負(fù)載可能具有不同的更新頻率和規(guī)模需求，例如，批處理應(yīng)用程序與實時應(yīng)用程序。將兩個工作負(fù)載組合到一個集群中可能會產(chǎn)生不利影響，或者消耗的資源遠(yuǎn)遠(yuǎn)超過所需的資源。
數(shù)據(jù)主權(quán)和合規(guī)性也會對在特定區(qū)域或應(yīng)用程序中共同定位數(shù)據(jù)和主題施加限制。
當(dāng)然，彈性是多個Kafka集群背后的另一個強大驅(qū)動力。雖然Kafka集群是為主題容錯而設(shè)計的，但仍然需要為整個集群的災(zāi)難性故障做好準(zhǔn)備。在這種情況下，對完全復(fù)制集群的需求支持適當(dāng)?shù)臉I(yè)務(wù)連續(xù)性規(guī)劃。
對于正在將工作負(fù)載遷移到云端或有混合云策略的企業(yè)，可能希望設(shè)置多個Kafka集群，并隨著時間的推移執(zhí)行有計劃的工作負(fù)載遷移，而不是冒險的全面Kafka遷移。
在實踐中，很多企業(yè)發(fā)現(xiàn)自己不得不創(chuàng)建多個Kafka集群，但這些集群需要彼此交互，這只是其中的幾個原因。
多集群Kafka
為了使多個Kafka集群相互連接，必須將一個集群中的關(guān)鍵項復(fù)制到另一個集群。其中包括主題、偏移量和元數(shù)據(jù)。在Kafka術(shù)語中，這種復(fù)制被認(rèn)為是鏡像。
有兩種方法可以實現(xiàn)多集群設(shè)置：拉伸集群或連接集群。
擴展集群：同步復(fù)制
拉伸集群是跨多個物理集群“拉伸”的邏輯集群。主題和副本分布在物理集群中，但由于它們被表示為邏輯集群，因此應(yīng)用程序本身并不知道這種多樣性。
拉伸集群具有很強的一致性，并且更易于管理。由于應(yīng)用程序不知道多個集群的存在，因此與連接集群相比，它們更容易部署在拉伸集群上。
拉伸集群的缺點是它需要集群之間的同步連接。它們對于混合云部署來說并不理想，并且需要至少三個集群的Quorum 機制來避免“腦裂”的情況。
連接集群：異步復(fù)制
連接集群通過連接多個獨立的集群進行部署。這些獨立的集群可以運行在不同的區(qū)域或云平臺上，并進行單獨管理。
連接集群模型的主要優(yōu)點是，在集群發(fā)生故障的情況下不會有停機時間，因為其他集群是獨立運行的。每個集群還可以針對其特定資源進行優(yōu)化。
連接集群的主要缺點是它依賴于集群之間的異步連接。在集群之間復(fù)制的主題不是“寫時復(fù)制”，而是取決于最終的一致性。這可能導(dǎo)致在異步鏡像過程中丟失數(shù)據(jù)。
此外，必須修改跨連接集群工作的應(yīng)用程序，以識別多個集群。
在解決這個難題之前，簡要介紹一下市場上支持Kafka集群連接的常用工具。
開源Kafka自帶鏡像工具Mirror Maker。
Mirror Maker通過內(nèi)置生成器在不同的集群之間復(fù)制主題。通過這種方式，數(shù)據(jù)在集群之間進行交叉復(fù)制，最終保持一致性，但不會中斷單個進程。
值得注意的是，雖然Mirror Maker的概念很簡單，但對于IT組織來說，大規(guī)模地設(shè)置Mirror Maker可能是一個相當(dāng)大的挑戰(zhàn)。必須正確管理IP地址、命名約定、副本數(shù)量等，否則可能會導(dǎo)致所謂的“無限復(fù)制”，即主題被無限復(fù)制，導(dǎo)致最終崩潰。
Mirror Maker的另一個缺點是缺乏允許/不允許更新列表的動態(tài)配置。Mirror Maker也不能正確同步主題屬性，這使得它在添加或刪除要復(fù)制的主題時成為大規(guī)模操作的難題。Mirror Maker試圖解決其中的一些挑戰(zhàn)，但許多IT商店仍然難以正確設(shè)置Mirror Maker。
其他用于Kafka復(fù)制的開源工具包括來自Salesforce的Mirus，來自Uber的uReplicator，以及來自Netflix的定制Flink。
對于商業(yè)許可選項，Confluent提供了兩個選項：Confluent Replicator和Cluster Linking。Confluent Replicator本質(zhì)上是一個Kafka Connect連接器，它提供了一種高性能和彈性的方式在集群之間復(fù)制主題數(shù)據(jù)。Cluster Linking是另一種內(nèi)部開發(fā)的產(chǎn)品，其目標(biāo)是在保留主題偏移的同時進行多區(qū)域復(fù)制。
即便如此，Cluster Linking還是一種異步復(fù)制工具，數(shù)據(jù)必須跨越網(wǎng)絡(luò)邊界并穿越公共流量路徑。
現(xiàn)在應(yīng)該很清楚，Kafka復(fù)制是大規(guī)模生產(chǎn)應(yīng)用程序的關(guān)鍵策略。問題是選擇哪一個選項。
富有想象力的Kafka管理員很快就會意識到，根據(jù)應(yīng)用程序的性能和彈性需求，可能需要連接集群和拉伸集群，或者這些部署的組合。
然而，令人生畏的是，設(shè)置集群配置和跨多個集群大規(guī)模管理這些配置是指數(shù)級的挑戰(zhàn)。還有什么更優(yōu)雅的方式來解決這個難題呢?
答案是肯定的!
Avesha的KubeSlice是一種兩全其美的簡單方法。通過在集群或命名空間之間創(chuàng)建直接的服務(wù)連接，KubeSlice無需手動配置Kafka集群之間的單個連接。
KubeSlice的核心是在集群之間創(chuàng)建一個安全的、同步的第三層網(wǎng)絡(luò)網(wǎng)關(guān)，在應(yīng)用程序或名稱空間級別進行隔離。一旦設(shè)置好了，Kafka管理員就可以自由地在任何集群中部署Kafka代理。
每個代理都與通過片連接的其他每個代理具有同步連接，即使代理本身可能位于不同的集群上。這有效地在代理之間創(chuàng)建了一個拉伸集群，并提供了強一致性和低管理開銷的好處。
結(jié)語
對于那些可能想將Mirror Maker部署到集群中的人來說，這可以用最少的精力完成，因為集群之間的連接被委托給KubeSlice。因此，Kafka應(yīng)用程序可以在同一部署中獲得同步（速度、彈性）和異步（獨立性、規(guī)模）復(fù)制的好處，并能夠根據(jù)需要混合和匹配這些功能。這適用于預(yù)處理數(shù)據(jù)中心、公共云或混合設(shè)置中的任何組合。
KubeSlice是一個無中斷的部署，這意味著不需要卸載任何已經(jīng)部署的工具。這只是建立一個切片并將Kafka部署添加到該切片上的問題。
本文提供了Apache Kafka的簡要概述，并觸及了一些更常見的用例。還介紹了當(dāng)前可用于跨多個集群擴展Kafka部署的工具，并討論了每種工具的優(yōu)缺點。最后，本文還介紹了Kubeslice，這是一種新興的服務(wù)連接解決方案，它簡化了Kafka多集群部署，并消除了大規(guī)模跨多個集群配置Kafka復(fù)制帶來的麻煩。
原文標(biāo)題：Kafka Multi-Cluster Deployment on Kubernetes： Simplified!，作者：Ray Edwards
