在Kubernetes上运行Kafka

在Kubernetes上运行Kafka吗?我的反问是：没有它，Kafka会跑得更好吗?这就是为什么我要指出Kafka和Kubernetes之间的相互补充性以及你可能遇到的陷阱。

运行时

让我们先看一下基本的东西——运行时本身。

进程

Kafka brokers对CPU很友好。TLS可能会引入一些开销。如果Kafka客户端使用加密，则需要更多CPU，但这不会影响brokers。

内存

Kafka brokers是内存消耗大户。JVM堆通常可以限制为4-5 GB，但由于Kafka大量使用页面缓存，因此还需要足够的系统内存。在Kubernetes中，可以相应地设置容器资源限制和请求。

存储

容器中的存储是短暂的——重启后数据将丢失。可以对Kafka数据使用emptyDir卷，这将产生相同的效果：brokers的数据将在停机后丢失。您的消息在其他broker上作为副本还是可以使用的。因此，重新启动后，失败的broker必须得复制所有的数据，这可能是一个耗时过程。

这就是你应该使用持久存储的原因。使用XFS或ext4的非本地持久性块存储更合适。我警告你：不要使用NFS。NFS v3和v4都不会起作用。简而言之，Kafka broker会因为NFS“愚蠢重命名”问题而无法删除数据目录，自行终止。如果你仍然不相信我，那么请仔细阅读这篇博文。存储必须是非本地的，以便Kubernetes在重新启动或重新定位时可以更灵活地选择另一个节点。es网站包含一个非常好的教程，介绍如何使用清单设置ZooKeeper。由于ZooKeeper是Kafka的一部分，因此可以通过这个了解哪些Kubernetes概念被应用在这里。一旦理解，您也可以对Kafka集群使用相同的概念。

• Pod：Pod是Kubernetes中最小的可部署单元。它包含您的工作负载，它代表群集中的一个进程。一个Pod包含一个或多个容器。整体中的每个ZooKeeper服务器和Kafka集群中的每个Kafka broker都将在一个单独的Pod中运行。
• StatefulSet：StatefulSet是一个Kubernetes对象，用于处理需要协调的多个有状态工作负载。StatefulSets保证Pod的有序性和***性的。
• Headless Services：服务通过逻辑名称将Pod与客户端分离。Kubernetes负责负载平衡。但是，对于ZooKeeper和Kafka等有状态工作负载，客户端必须与特定实例进行通信。这就是 Headless Services发挥作用的地方：作为客户端，仍然可以获得逻辑名称，但不必直接访问Pod。
• 持久卷：如上所述，需要配置非本地持久块存储。

Yolean提供了一套全面的清单，可以帮助您开始使用Kubernetes上的Kafka。

Helm Charts

Helm是Kubernetes的包管理器，类似yum，apt，Homebrew或Chocolatey等OS包管理器。它允许您安装Helm Charts中描述的预定义软件包。精心设计的Helm Charts能简化所有参数正确配置的复杂任务，以便在Kubernetes上运行Kafka。有几张图表适用于Kafka的的可供选择：一个是处于演进状态的官方图表，一个来自Confluent，另一个来自Bitnami，仅举几例。

Operators

（编辑：开发网_郴州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!