Kubernetes 上的 Kafka 好用嗎？

你好，哈布爾！

曾經，我們是第一個將這個主題引入俄羅斯市場的 卡夫卡 並繼續 追踪 為其發展。 特別是，我們發現了Kafka與 Kubernetes。 可觀察（而且非常小心） 文章 這個主題早在去年 XNUMX 月就由 Gwen Shapira 發表在 Confluence 部落格上。 今天，我們想提請您注意 Johann Gyger 於 XNUMX 月發表的一篇最新文章，儘管標題中不無問號，但他以更實質性的方式審視了該主題，並在文本中附上了有趣的鏈接。 如果可以的話請原諒我們「混沌猴」的意譯！

介紹

Kubernetes 旨在處理無狀態工作負載。 通常，此類工作負載以微服務架構的形式呈現，它們是輕量級的，水平擴展良好，遵循12因素應用程式的原則，並且可以與斷路器和混沌猴子一起使用。

另一方面，Kafka 本質上充當分散式資料庫。 因此，在工作時，你必須處理狀態，它比微服務要重得多。 Kubernetes 支援有狀態負載，但正如 Kelsey Hightower 在兩則推文中指出的那樣，應該小心處理它們：

有些人認為，如果將 Kubernetes 納入有狀態工作負載，它就會成為與 RDS 相媲美的完全託管資料庫。 這是錯誤的。 也許，如果你夠努力，增加額外的元件並吸引 SRE 工程師團隊，你將能夠在 Kubernetes 之上建立 RDS。

我始終建議每個人在 Kubernetes 上運行有狀態工作負載時都要格外小心。 大多數詢問「我可以在 Kubernetes 上運行有狀態工作負載」的人都沒有足夠的 Kubernetes 經驗，而且通常對他們所詢問的工作負載沒有足夠的經驗。

那麼，您應該在 Kubernetes 上執行 Kafka 嗎？ 反問：如果沒有 Kubernetes，Kafka 會工作得更好嗎？ 這就是為什麼我想在本文中強調 Kafka 和 Kubernetes 如何相輔相成，以及將它們結合起來會帶來哪些陷阱。

完成時間

讓我們來談談基本的事情—運行時環境本身

過程

Kafka 代理對 CPU 是友善的。 TLS 可能會帶來一些開銷。 但是，如果 Kafka 用戶端使用加密，則可能會佔用更多 CPU 資源，但這不會影響代理。

Память

卡夫卡經紀人吃掉了內存。 JVM 堆大小通常限制為 4-5 GB，但由於 Kafka 大量使用頁面緩存，因此您還需要大量系統記憶體。 在 Kubernetes 中，相應地設定容器資源和請求限制。

資料儲存

容器中的資料儲存是短暫的 - 重新啟動時資料會遺失。 對於 Kafka 數據，您可以使用卷 emptyDir，效果類似：完成後您的經紀商資料將會遺失。 您的訊息仍然可以作為副本儲存在其他代理程式上。 因此，重新啟動後，發生故障的代理必須先複製所有數據，並且此過程可能會花費大量時間。

這就是為什麼您應該使用長期資料儲存。 讓它成為使用 XFS 檔案系統或更準確地說是 ext4 的非本地長期儲存。 不要使用 NFS。 我警告過你。 NFS 版本 v3 或 v4 將無法運作。 簡而言之，如果由於 NFS 中的「愚蠢重命名」問題而無法刪除資料目錄，Kafka Broker 就會崩潰。 如果我還沒有說服你，請非常小心地 閱讀這篇文章。 資料儲存應該是非本地的，以便 Kubernetes 在重啟或搬遷後可以更靈活地選擇新節點。

Сеть

與大多數分散式系統一樣，Kafka 的效能高度依賴將網路延遲保持在最低水準並將頻寬保持在最高水準。 不要嘗試將所有代理程式託管在同一節點上，因為這會降低可用性。 如果 Kubernetes 節點發生故障，整個 Kafka 叢集都會發生故障。 另外，不要將 Kafka 叢集分散到整個資料中心。 Kubernetes 叢集也是如此。 在這種情況下，一個好的折衷方案是選擇不同的可用區。

組態

定期宣言

Kubernetes 網站有 很好的指南 關於如何使用清單設定 ZooKeeper。 由於 ZooKeeper 是 Kafka 的一部分，因此這是一個開始熟悉此處應用的 Kubernetes 概念的好地方。 一旦了解這一點，您就可以在 Kafka 叢集中使用相同的概念。

• 下：Pod 是 Kubernetes 中最小的可部署單元。 pod 包含您的工作負載，pod 本身對應於叢集中的一個進程。 一個 Pod 包含一個或多個容器。 集合中的每個 ZooKeeper 伺服器和 Kafka 叢集中的每個代理程式都將在單獨的 Pod 中運行。
• 有狀態集：StatefulSet 是一個處理多個有狀態工作負載的 Kubernetes 對象，此類工作負載需要協調。 StatefulSet 提供有關 pod 的排序及其唯一性的保證。
• 無頭服務：服務可讓您使用邏輯名稱將 Pod 與客戶端分開。 在這種情況下，Kubernetes 負責負載平衡。 但是，在操作有狀態工作負載（例如 ZooKeeper 和 Kafka）時，用戶端需要與特定實例進行通訊。 這就是無頭服務派上用場的地方：在這種情況下，客戶端仍然有一個邏輯名稱，但您不必直接聯繫 Pod。
• 長期儲存量：配置上述非本機區塊持久性儲存需要這些磁碟區。

上 約蘭 提供一套全面的清單，幫助您開始在 Kubernetes 上使用 Kafka。

舵圖

Helm 是 Kubernetes 的套件管理器，可與 yum、apt、Homebrew 或 Chocolatey 等作業系統套件管理器進行比較。 它可以輕鬆安裝 Helm 圖表中所述的預定義軟體包。 精心挑選的 Helm 圖表使如何正確配置所有參數以在 Kubernetes 上使用 Kafka 的艱鉅任務變得容易。 Kafka圖有幾張：官方的位於 在培養箱條件下，有一個來自 匯合，還有一個 - 來自 Bitnami.

運營商

由於 Helm 存在某些缺點，另一種工具越來越受歡迎：Kubernetes Operator。 Operator 不僅為 Kubernetes 打包軟體，還允許您部署此類軟體並對其進行管理。

Всписке 了不起的營運商 提到了 Kafka 的兩個運算子。 其中之一—— 斯特里姆齊。 借助 Strimzi，您可以在幾分鐘內輕鬆啟動並運行 Kafka 叢集。 幾乎不需要任何配置，此外，運營商本身提供了一些不錯的功能，例如叢集內的點對點 TLS 加密。 Confluence 也提供 自己的營運商.

Производительность

透過對 Kafka 實例進行基準測試來測試效能非常重要。 此類測試將幫助您在問題出現之前發現潛在的瓶頸。 幸運的是，Kafka已經提供了兩種效能測試工具： kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh。 積極利用它們。 作為參考，您可以參考中所述的結果 這個帖子 Jay Kreps，或專注於 這篇評論 亞馬遜 MSK，作者：Stéphane Maarek。

操作

監控

系統的透明度非常重要——否則你將無法了解其中發生的情況。 如今，有一個可靠的工具包，可以以雲端原生方式提供基於指標的監控。 用於此目的的兩種流行工具是 Prometheus 和 Grafana。 Prometheus 可以使用 JMX 導出器以最簡單的方式從所有 Java 進程（Kafka、Zookeeper、Kafka Connect）收集指標。 如果新增cAdvisor指標，您可以更全面地了解Kubernetes中資源的使用方式。

Strimzi 有一個非常方便的 Kafka Grafana 儀表板範例。 它可視化關鍵指標，例如有關複製不足的扇區或離線扇區的關鍵指標。 那裡的一切都非常清楚。 這些指標由資源利用率和性能資訊以及穩定性指標進行補充。 這樣您就可以免費獲得基本的 Kafka 叢集監控！

來源： Streamzi.io/docs/master/#kafka_dashboard

最好透過客戶端監控（消費者和生產者的指標）以及延遲監控（為此有 地洞）和端對端監控 - 用於此用途 卡夫卡監控器.

記錄

日誌記錄是另一個關鍵任務。 確保 Kafka 安裝中的所有容器都已記錄到 stdout и stderr，並確保您的 Kubernetes 叢集將所有日誌聚合到中央日誌記錄基礎架構中，例如 Elasticsearch.

功能測試

Kubernetes 使用 liveness 和 readiness 探針來檢查您的 pod 是否正常運作。 如果活性檢查失敗，Kubernetes 將停止該容器，然後在相應設定了重新啟動策略的情況下自動重新啟動它。 如果準備檢查失敗，Kubernetes 會將 pod 與服務請求隔離。 因此，在這種情況下，根本不再需要手動幹預，這是一個很大的優點。

推出更新

StatefulSets支援自動更新：如果選擇RollingUpdate策略，Kafka下的每一個都會依序更新。 這樣，停機時間可以減少到零。

縮放

擴展 Kafka 叢集並不是一件容易的事。 然而，Kubernetes 使得將 pod 擴展到一定數量的副本變得非常容易，這意味著您可以根據需要以聲明方式定義任意數量的 Kafka 代理程式。 在這種情況下，最困難的事情是在擴大規模之後或縮小規模之前重新分配扇區。 同樣，Kubernetes 將幫助您完成這項任務。

管理

與管理 Kafka 叢集相關的任務（例如建立主題和重新指派磁區）可以透過在 pod 中開啟命令列介面，使用現有的 shell 腳本來完成。 然而，這個解決方案並不是很美觀。 Strimzi 支援使用不同的運算子來管理主題。 這裡還有一些改進的空間。

Резервноекопированиеиввосстановление

現在 Kafka 的可用性也將取決於 Kubernetes 的可用性。 如果您的 Kubernetes 叢集發生故障，那麼在最壞的情況下，您的 Kafka 叢集也會發生故障。 根據墨菲定律，這種情況肯定會發生，而且你會失去資料。 為了降低此類風險，需要有一個良好的備份概念。 您可以使用 MirrorMaker，另一個選擇是使用 S3，如此處所述 郵政 來自札蘭多。

結論

在使用中小型 Kafka 叢集時，絕對值得使用 Kubernetes，因為它提供了額外的靈活性並簡化了操作員體驗。 如果您有非常顯著的非功能性延遲和/或吞吐量要求，那麼最好考慮其他部署選項。

來源： www.habr.com