Kubernetes設計的初衷是運行無狀態工作負載。這些通常採用微服務架構的工作負載，是輕量級，可水平擴展，遵循十二要素應用程序，可以處理環形斷路和隨機Monkey測試。
另一方面，Kafka本質上是一個分佈式數據庫。這意味著你必須處理狀態，它比微服務更重量級。Kubernetes支持有狀態的工作負載，但你必須謹慎對待它，正如Kelsey Hightower在最近的兩條推文中指出的那樣：
現在你應該在Kubernetes上運行Kafka嗎？我的反問是：沒有它，Kafka會跑得更好嗎？這就是為什麼我要指出Kafka和Kubernetes之間的相互補充性以及你可能遇到的陷阱。
一、運行時
讓我們先看一下基本的東西——運行時本身。
1、進程
Kafka brokers對CPU很友好。TLS可能會引入一些開銷。如果Kafka客戶端使用加密，則需要更多CPU，但這不會影響brokers。
2、內存
Kafka brokers是內存消耗大戶。JVM堆通常可以限制為4-5 GB，但由於Kafka大量使用頁面緩存，因此還需要足夠的系統內存。在Kubernetes中，可以相應地設置容器資源限制和請求。
3、存儲
容器中的存儲是短暫的——重啟後數據將丟失。可以對Kafka數據使用emptyDir卷，這將產生相同的效果：brokers的數據將在停機後丟失。您的消息在其他broker上作為副本還是可以使用的。因此，重新啟動後，失敗的broker必須得複製所有的數據，這可能是一個耗時過程。
這就是你應該使用持久存儲的原因。使用XFS或ext4的非本地持久性塊存儲更合適。我警告你：不要使用NFS。NFS v3和v4都不會起作用。
簡而言之，Kafka broker會因為NFS“愚蠢重命名”問題而無法刪除數據目錄，自行終止。如果你仍然不相信我，那麼請仔細閱讀這篇博文[1]。存儲必須是非本地的，以便Kubernetes在重新啟動或重新定位時可以更靈活地選擇另一個節點。
4、網絡
與大多數分佈式系統一樣，Kafka性能在很大程度上取決於低網絡延遲和高帶寬。不要試圖將所有代理放在同一節點上，因為這會降低可用性。
如果Kubernetes節點出現故障，那麼整個Kafka集群都會出現故障。不要跨數據中心擴展Kafka集群。這同樣適用於Kubernetes集群。不同的可用區域是一個很好的權衡。
二、配置
1、清單
Kubernetes網站包含一個非常好的教程[2]，介紹如何使用清單設置ZooKeeper。由於ZooKeeper是Kafka的一部分，因此可以通過這個瞭解哪些Kubernetes概念被應用在這裡。一旦理解，您也可以對Kafka集群使用相同的概念。
1）Pod
Pod是Kubernetes中最小的可部署單元。它包含您的工作負載，它代表群集中的一個進程。一個Pod包含一個或多個容器。整體中的每個ZooKeeper服務器和Kafka集群中的每個Kafka broker都將在一個單獨的Pod中運行。
2）StatefulSet
StatefulSet是一個Kubernetes對象，用於處理需要協調的多個有狀態工作負載。StatefulSets保證Pod的有序性和唯一性的。
3）Headless Services
服務通過邏輯名稱將Pod與客戶端分離。Kubernetes負責負載平衡。但是，對於ZooKeeper和Kafka等有狀態工作負載，客戶端必須與特定實例進行通信。這就是 Headless Services發揮作用的地方：作為客戶端，仍然可以獲得邏輯名稱，但不必直接訪問Pod。
4）持久卷
如上所述，需要配置非本地持久塊存儲。
Yolean[3]提供了一套全面的清單，可以幫助您開始使用Kubernetes上的Kafka。
2、Helm Charts
Helm是Kubernetes的包管理器，類似yum，apt，Homebrew或Chocolatey等OS包管理器。它允許您安裝Helm Charts中描述的預定義軟件包。
精心設計的Helm Charts能簡化所有參數正確配置的複雜任務，以便在Kubernetes上運行Kafka。有幾張圖表適用於Kafka的的可供選擇：一個是處於演進狀態的官方圖表[4]，一個來自Confluent，另一個來自Bitnami，僅舉幾例。
3、Operators
由於Helm的一些限制，另一種工具變得非常流行：Kubernetes Operators。Operators不僅可以為Kubernetes打包軟件，還可以為Kubernetes部署和管理一個軟件。
評價很高的Operators名單中提到Kafka有兩個，其中一個是Strimzi[5]，Strimzi使得在幾分鐘內啟動Kafka集群變得非常容易，幾乎不需要任何配置，它增加了一些漂亮的功能，如群集間點對點TLS加密。Confluent還宣佈即將推出新的Operator。
4、性能
運行性能測試以對Kafka安裝進行基準測試非常重要。在您遇到麻煩之前，它會為您提供有關可能的瓶頸的地方。
幸運的是，Kafka已經提供了兩個性能測試工具：kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。記得經常使用它們。作為參考，可以使用Jay Kreps的博客結果[6]，或者 Stéphane Maarek在 Amazon MSK的評論[7]。
三、運維
1、監控
可見性非常重要，否則您將不知道發生了什麼。如今，有一種不錯的工具可以用雲原生方式監控指標。Prometheus和Grafana是兩種流行的工具。Prometheus可以直接從JMX導出器收集所有Java進程（Kafka，ZooKeeper，Kafka Connect）的指標。添加cAdvisor指標可為提供有關Kubernetes資源使用情況的其他信息。
Strimzi為Kafka提供了一個優雅的Grafana儀表板示例。它以非常直觀的方式可視化關鍵指標，如未複製的和離線分區。它通過資源使用和性能以及穩定性指標來補充這些指標。因此，可以免費獲得基本的Kafka集群監控！
https://strimzi.io/docs/master/#kafka_dashboard
可以通過客戶端監控（消費者和生產者指標），使用Burrow滯後監控，使用Kafka Monitor[8]進行端到端監控，來完成這個任務。
2、日誌記錄
日誌記錄是另一個關鍵部分。確保Kafka安裝中的所有容器都記錄到標準輸出（stdout）和標準錯誤輸出（stderr），並確保Kubernetes集群將所有日誌聚合到中央日誌記錄設施中如Elasticsearch中。
3、健康檢查
Kubernetes使用活躍度和就緒探測器來確定Pod是否健康。如果活躍度探測失敗，Kubernetes將終止容器並在相應設置重啟策略時自動重啟。如果準備就緒探測失敗，那麼Kubernetes將通過服務從服務請求中刪除該Pod。這意味著在這種情況下不再需要人工干預，這是一大優點。
4、滾動更新
StatefulSets支持自動更新：滾動更新策略將一次更新一個Kafka Pod。通過這種方式，可以實現零停機時間，這是Kubernetes帶來的另一大優勢。
5、擴展
擴展Kafka集群並非易事。但是，Kubernetes可以很容易地將Pod縮放到一定數量的副本，這意味著可以聲明式地定義所需數量的Kafka brokers。困難的部分是在放大或縮小之前重新分配部分。同樣，Kubernetes可以幫助您完成這項任務。
6、管理
通過在Pod中打開shell，可以使用現有的shell腳本完成Kafka群集的管理任務，例如創建主題和重新分配分區。這不是一個很好的解決方案。Strimzi支持與另一個Operator管理主題。這還有改進的餘地。
7、備份和還原
現在Kafka的可用性還取決於Kubernetes的可用性。如果Kubernetes群集出現故障，那麼在最壞的情況下Kafka群集也會故障。
墨菲定律告訴我們，這也會發生在你身上，你會丟失數據。要降低此風險，請確保您具有備份想法。MirrorMaker是一種可選方案，另一種可能是利用S3進行連接備份，如Zalando的博客文章[9]所述。
四、結論
對於中小型Kafka集群，我肯定會選擇Kubernetes，因為它提供了更大的靈活性並簡化了操作。如果您在延遲和/或吞吐量方面具有非常高的非功能性要求，則不同的部署選項可能更有益。
>>>>
參考鏈接
[1]https://engineering.skybettingandgaming.com/2018/07/10/kafka-nfs/
[2]https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/
[3]https://github.com/Yolean/kubernetes-kafka
[4]https://github.com/helm/charts/tree/master/incubator/kafka
[5]https://strimzi.io/
[6]https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
[7]https://medium.com/@stephane.maarek/an-honest-review-of-aws-managed-apache-kafka-amazon-msk-94b1ff9459d8
[8]https://github.com/linkedin/kafka-monitor
-
[9]https://jobs.zalando.com/tech/blog/backing-up-kafka-zookeeper/
原文鏈接：https://blog.usejournal.com/kafka-on-kubernetes-a-good-fit-95251da55837
譯者丨姜俊厚
來源丨Docker訂閱號（ID：dockerone）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：editor@dbaplus.cn
>>>>
閱讀更多 dbaplus社群 的文章
