譯者 | 李睿

審校 | 重樓

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

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

Kafka的用途在不斷擴大，主要的五個案例由Brij Pandey在隨附的圖片中很好地說明了這一點。

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

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

Kafka的關鍵組件包括：

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

總的來說，Kafka的設計和架構使它成為一個高度可擴展、容錯和高效的平臺，可以處理大量的實時數(shù)據流。它已經成為許多數(shù)據驅動的應用程序和數(shù)據基礎設施中的核心組件，促進了數(shù)據集成、事件處理和流分析。

一個典型的Kafka架構如下圖所示：

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

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

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

Kafka和Kubernetes

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

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

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

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

多集群Kafka的案例

在單個Kubernetes集群設置中運行Kafka集群相當簡單，并且在理論上可以根據需要實現(xiàn)可擴展性。然而在生產中，其畫面可能會變得有點模糊。

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

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

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

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

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

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

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

多集群Kafka

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

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

擴展集群：同步復制

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

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

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

連接集群：異步復制

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

連接集群模型的主要優(yōu)點是，在集群發(fā)生故障的情況下不會有停機時間，因為其他集群是獨立運行的。每個集群還可以針對其特定資源進行優(yōu)化。

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

此外，必須修改跨連接集群工作的應用程序，以識別多個集群。

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

開源Kafka自帶鏡像工具Mirror Maker。

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

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

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

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

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

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

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

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

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

答案是肯定的!

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

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

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

結語

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

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

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

原文標題：Kafka Multi-Cluster Deployment on Kubernetes： Simplified!，作者：Ray Edwards