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，因为它提供了额外的灵活性并简化了操作员体验。 如果您有非常显着的非功能性延迟和/或吞吐量要求，那么最好考虑其他部署选项。

来源： habr.com