譯者 | 李睿

審校 | 重樓

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

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

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

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

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

Kafka的關鍵組件包括：

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

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

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

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

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

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

Kafka和Kubernetes

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

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

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

因此，Kafka管理員必須了解Kafka和Kubernetes之間的相互作用，以及如何適當地實現這些相互作用。

多集群Kafka的案例

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

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

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

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

數據主權和合規性也會對在特定區域或應用程序中共同定位數據和主題施加限制。

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

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

在實踐中，很多企業發現自己不得不創建多個Kafka集群，但這些集群需要彼此交互，這只是其中的幾個原因。

多集群Kafka

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

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

擴展集群：同步復制

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

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

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

連接集群：異步復制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

然而，令人生畏的是，設置集群配置和跨多個集群大規模管理這些配置是指數級的挑戰。還有什么更優雅的方式來解決這個難題呢?

答案是肯定的!

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

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

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

結語

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

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

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

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