介紹

Kubernetes設(shè)計(jì)的初衷是運(yùn)行無(wú)狀態(tài)工作負(fù)載。這些通常采用微服務(wù)架構(gòu)的工作負(fù)載，是輕量級(jí)，可水平擴(kuò)展，遵循十二要素應(yīng)用程序，可以處理環(huán)形斷路和隨機(jī)Monkey測(cè)試。

另一方面，Kafka本質(zhì)上是一個(gè)分布式數(shù)據(jù)庫(kù)。這意味著你必須處理狀態(tài)，它比微服務(wù)更重量級(jí)。Kubernetes支持有狀態(tài)的工作負(fù)載，但你必須謹(jǐn)慎對(duì)待它，正如Kelsey Hightower在最近的兩條推文中指出的那樣：

現(xiàn)在你應(yīng)該在Kubernetes上運(yùn)行Kafka嗎?我的反問是：沒有它，Kafka會(huì)跑得更好嗎?這就是為什么我要指出Kafka和Kubernetes之間的相互補(bǔ)充性以及你可能遇到的陷阱。

運(yùn)行時(shí)

讓我們先看一下基本的東西——運(yùn)行時(shí)本身。

進(jìn)程

Kafka brokers對(duì)CPU很友好。TLS可能會(huì)引入一些開銷。如果Kafka客戶端使用加密，則需要更多CPU，但這不會(huì)影響brokers。

內(nèi)存

Kafka brokers是內(nèi)存消耗大戶。JVM堆通?？梢韵拗茷?-5 GB，但由于Kafka大量使用頁(yè)面緩存，因此還需要足夠的系統(tǒng)內(nèi)存。在Kubernetes中，可以相應(yīng)地設(shè)置容器資源限制和請(qǐng)求。

存儲(chǔ)

容器中的存儲(chǔ)是短暫的——重啟后數(shù)據(jù)將丟失?？梢詫?duì)Kafka數(shù)據(jù)使用emptyDir卷，這將產(chǎn)生相同的效果：brokers的數(shù)據(jù)將在停機(jī)后丟失。您的消息在其他broker上作為副本還是可以使用的。因此，重新啟動(dòng)后，失敗的broker必須得復(fù)制所有的數(shù)據(jù)，這可能是一個(gè)耗時(shí)過程。

這就是你應(yīng)該使用持久存儲(chǔ)的原因。使用XFS或ext4的非本地持久性塊存儲(chǔ)更合適。我警告你：不要使用NFS。NFS v3和v4都不會(huì)起作用。簡(jiǎn)而言之，Kafka broker會(huì)因?yàn)镹FS“愚蠢重命名”問題而無(wú)法刪除數(shù)據(jù)目錄，自行終止。如果你仍然不相信我，那么請(qǐng)仔細(xì)閱讀這篇博文。存儲(chǔ)必須是非本地的，以便Kubernetes在重新啟動(dòng)或重新定位時(shí)可以更靈活地選擇另一個(gè)節(jié)點(diǎn)。

網(wǎng)絡(luò)

與大多數(shù)分布式系統(tǒng)一樣，Kafka性能在很大程度上取決于低網(wǎng)絡(luò)延遲和高帶寬。不要試圖將所有代理放在同一節(jié)點(diǎn)上，因?yàn)檫@會(huì)降低可用性。如果Kubernetes節(jié)點(diǎn)出現(xiàn)故障，那么整個(gè)Kafka集群都會(huì)出現(xiàn)故障。不要跨數(shù)據(jù)中心擴(kuò)展Kafka集群。這同樣適用于Kubernetes集群。不同的可用區(qū)域是一個(gè)很好的權(quán)衡。

配置

清單

Kubernetes網(wǎng)站包含一個(gè)非常好的教程，介紹如何使用清單設(shè)置ZooKeeper。由于ZooKeeper是Kafka的一部分，因此可以通過這個(gè)了解哪些Kubernetes概念被應(yīng)用在這里。一旦理解，您也可以對(duì)Kafka集群使用相同的概念。

• Pod：Pod是Kubernetes中最小的可部署單元。它包含您的工作負(fù)載，它代表群集中的一個(gè)進(jìn)程。一個(gè)Pod包含一個(gè)或多個(gè)容器。整體中的每個(gè)ZooKeeper服務(wù)器和Kafka集群中的每個(gè)Kafka broker都將在一個(gè)單獨(dú)的Pod中運(yùn)行。
• StatefulSet：StatefulSet是一個(gè)Kubernetes對(duì)象，用于處理需要協(xié)調(diào)的多個(gè)有狀態(tài)工作負(fù)載。StatefulSets保證Pod的有序性和***性的。
• Headless Services：服務(wù)通過邏輯名稱將Pod與客戶端分離。Kubernetes負(fù)責(zé)負(fù)載平衡。但是，對(duì)于ZooKeeper和Kafka等有狀態(tài)工作負(fù)載，客戶端必須與特定實(shí)例進(jìn)行通信。這就是 Headless Services發(fā)揮作用的地方：作為客戶端，仍然可以獲得邏輯名稱，但不必直接訪問Pod。
• 持久卷：如上所述，需要配置非本地持久塊存儲(chǔ)。

Yolean提供了一套全面的清單，可以幫助您開始使用Kubernetes上的Kafka。

Helm Charts

Helm是Kubernetes的包管理器，類似yum，apt，Homebrew或Chocolatey等OS包管理器。它允許您安裝Helm Charts中描述的預(yù)定義軟件包。精心設(shè)計(jì)的Helm Charts能簡(jiǎn)化所有參數(shù)正確配置的復(fù)雜任務(wù)，以便在Kubernetes上運(yùn)行Kafka。有幾張圖表適用于Kafka的的可供選擇：一個(gè)是處于演進(jìn)狀態(tài)的官方圖表，一個(gè)來(lái)自Confluent，另一個(gè)來(lái)自Bitnami，僅舉幾例。

Operators

由于Helm的一些限制，另一種工具變得非常流行：Kubernetes Operators。Operators不僅可以為Kubernetes打包軟件，還可以為Kubernetes部署和管理一個(gè)軟件。

評(píng)價(jià)很高的Operators名單中提到Kafka有兩個(gè)，其中一個(gè)是Strimzi，Strimzi使得在幾分鐘內(nèi)啟動(dòng)Kafka集群變得非常容易，幾乎不需要任何配置，它增加了一些漂亮的功能，如群集間點(diǎn)對(duì)點(diǎn)TLS加密。Confluent還宣布即將推出新的Operator。

性能

運(yùn)行性能測(cè)試以對(duì)Kafka安裝進(jìn)行基準(zhǔn)測(cè)試非常重要。在您遇到麻煩之前，它會(huì)為您提供有關(guān)可能的瓶頸的地方。幸運(yùn)的是，Kafka已經(jīng)提供了兩個(gè)性能測(cè)試工具：kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。記得經(jīng)常使用它們。作為參考，可以使用Jay Kreps的博客結(jié)果，或者 Stéphane Maarek在 Amazon MSK的評(píng)論。

運(yùn)維

監(jiān)控

可見性非常重要，否則您將不知道發(fā)生了什么。如今，有一種不錯(cuò)的工具可以用云原生方式監(jiān)控指標(biāo)。Prometheus和Grafana是兩種流行的工具。Prometheus可以直接從JMX導(dǎo)出器收集所有Java進(jìn)程(Kafka，ZooKeeper，Kafka Connect)的指標(biāo)。添加cAdvisor指標(biāo)可為提供有關(guān)Kubernetes資源使用情況的其他信息。

Strimzi為Kafka提供了一個(gè)優(yōu)雅的Grafana儀表板示例。它以非常直觀的方式可視化關(guān)鍵指標(biāo)，如未復(fù)制的和離線分區(qū)。它通過資源使用和性能以及穩(wěn)定性指標(biāo)來(lái)補(bǔ)充這些指標(biāo)。因此，可以免費(fèi)獲得基本的Kafka集群監(jiān)控!

資料來(lái)源：https://strimzi.io/docs/master/#kafka_dashboard

可以通過客戶端監(jiān)控(消費(fèi)者和生產(chǎn)者指標(biāo))，使用Burrow滯后監(jiān)控，使用Kafka Monitor進(jìn)行端到端監(jiān)控，來(lái)完成這個(gè)任務(wù)

日志記錄

日志記錄是另一個(gè)關(guān)鍵部分。確保Kafka安裝中的所有容器都記錄到標(biāo)準(zhǔn)輸出(stdout)和標(biāo)準(zhǔn)錯(cuò)誤輸出(stderr)，并確保Kubernetes集群將所有日志聚合到中央日志記錄設(shè)施中如Elasticsearch中。

健康檢查

Kubernetes使用活躍度和就緒探測(cè)器來(lái)確定Pod是否健康。如果活躍度探測(cè)失敗，Kubernetes將終止容器并在相應(yīng)設(shè)置重啟策略時(shí)自動(dòng)重啟。如果準(zhǔn)備就緒探測(cè)失敗，那么Kubernetes將通過服務(wù)從服務(wù)請(qǐng)求中刪除該P(yáng)od。這意味著在這種情況下不再需要人工干預(yù)，這是一大優(yōu)點(diǎn)。

滾動(dòng)更新

StatefulSets支持自動(dòng)更新：滾動(dòng)更新策略將一次更新一個(gè)Kafka Pod。通過這種方式，可以實(shí)現(xiàn)零停機(jī)時(shí)間，這是Kubernetes帶來(lái)的另一大優(yōu)勢(shì)。

擴(kuò)展

擴(kuò)展Kafka集群并非易事。但是，Kubernetes可以很容易地將Pod縮放到一定數(shù)量的副本，這意味著可以聲明式地定義所需數(shù)量的Kafka brokers。困難的部分是在放大或縮小之前重新分配部分。同樣，Kubernetes可以幫助您完成這項(xiàng)任務(wù)。

管理

通過在Pod中打開shell，可以使用現(xiàn)有的shell腳本完成Kafka群集的管理任務(wù)，例如創(chuàng)建主題和重新分配分區(qū)。這不是一個(gè)很好的解決方案。Strimzi支持與另一個(gè)Operator管理主題。這還有改進(jìn)的余地。

備份和還原

現(xiàn)在Kafka的可用性還取決于Kubernetes的可用性。如果Kubernetes群集出現(xiàn)故障，那么在最壞的情況下Kafka群集也會(huì)故障。墨菲定律告訴我們，這也會(huì)發(fā)生在你身上，你會(huì)丟失數(shù)據(jù)。要降低此風(fēng)險(xiǎn)，請(qǐng)確保您具有備份想法。MirrorMaker是一種可選方案，另一種可能是利用S3進(jìn)行連接備份，如Zalando的博客文章所述。

結(jié)論

對(duì)于中小型Kafka集群，我肯定會(huì)選擇Kubernetes，因?yàn)樗峁┝烁蟮撵`活性并簡(jiǎn)化了操作。如果您在延遲和/或吞吐量方面具有非常高的非功能性要求，則不同的部署選項(xiàng)可能更有益。