欢迎，哈伯！
一次，我们是第一个
将Kafka主题
引入俄罗斯市场并继续对其发展进行
监控的公司。 特别是，Kafka和
Kubernetes之间的交互主题对我们
来说似乎很有趣。 去年10月在Confluent公司博客上发表了有关该主题的评论
文章 （相当谨慎），该
文章由Gwen Shapira撰写。 今天，我们要引起您的注意，约翰·吉格（Johann Gyger）在四月份发表了一篇新文章，尽管标题中没有问号，但他以更具实质性的方式考虑了该主题，并在正文中附有有趣的链接。 如果可以的话，请原谅我们“混沌猴子”的免费翻译！
引言
Kubernetes旨在处理无状态负载。 通常，此类工作负载以微服务架构的形式呈现，它们是轻量级的，非常适合水平扩展，遵循12因子应用程序的原理，并允许与断路器和混乱的猴子一起工作。
另一方面，Kafka实际上充当着分布式数据库。 因此，在工作时，您必须处理这种情况，它比微服务要重得多。 Kubernetes支持有状态负载，但是正如Kelsey Hightower在他的两条推文中指出的那样，应谨慎处理它们：
在某些人看来，如果将Kubernetes加载到有状态负载上，它将变成可以与RDS竞争的完全托管的数据库。 事实并非如此。 也许如果您只是努力工作，拧紧其他组件并吸引一组SRE工程师，则可以在Kubernetes上安装RDS。
我总是建议大家在Kubernetes上启动状态保留负载时要格外小心。 大多数对“我可以在Kubernetes上运行有状态的负载”感兴趣的人没有足够的使用Kubernetes的经验，常常没有他们所要求的负载。
那么，我应该在Kubernetes上运行Kafka吗？ 反问：如果没有Kubernetes，卡夫卡会更好吗？ 这就是为什么我要在本文中强调Kafka和Kubernetes如何相辅相成，以及在合并时会遇到什么陷阱。
交货时间
让我们谈谈基本的东西-运行时环境本身
过程当使用CPU时，Kafka代理很方便。 TLS可能会产生一些开销。 同时，如果Kafka客户端使用加密，则它们可以加载更多的CPU，但这不会影响代理。
记忆卡夫卡经纪人吞噬了记忆。 JVM堆大小通常很时髦，以限制4-5 GB，但由于Kafka非常积极地使用页面缓存，因此您还需要大量系统内存。 在Kubernetes中，适当设置资源和请求的容器限制。
数据仓库容器中的数据存储是临时的-重启后数据会丢失。 您可以将
emptyDir卷用于Kafka数据，其效果将相似：完成后，您的代理数据将丢失。 您的消息仍可以作为副本保存在其他代理上。 因此，重新启动后，发生故障的代理必须首先复制所有数据，并且此过程可能需要很多时间。
这就是为什么应该使用长期数据存储的原因。 使其成为XFS文件系统或更确切地说ext4的非本地长期存储。 不要使用NFS。 我警告过 NFS版本v3或v4将不起作用。 简而言之，如果Kafka代理由于NFS中存在的“愚蠢的重命名”问题而无法删除数据目录，它将终止。 如果我仍然没有说服您，
请非常仔细地
阅读本文 。 数据仓库必须是非本地的，以便Kubernetes在重新启动或重定位后可以更灵活地选择新节点。
联播网与大多数分布式系统一样，Kafka的性能很大程度上取决于最小的网络延迟和最大的带宽。 不要尝试将所有代理放置在同一节点上，因为这会降低可用性。 如果Kubernetes节点发生故障，则整个Kafka集群也将发生故障。 另外，请勿将Kafka群集分散在整个数据中心中。 Kubernetes集群也是如此。 在这种情况下，一个不错的折衷方案是选择不同的访问区域。
构型
共同宣言Kubernetes网站提供了一个
很好的指南 ，说明如何使用清单配置ZooKeeper。 由于ZooKeeper是Kafka的一部分，因此很容易开始熟悉Kubernetes的哪些概念在这里适用。 一旦弄清楚了，就可以对Kafka集群使用相同的概念。
- Sub ：sub是Kubernetes中最小的可部署单元。 窗格包含您的工作负载，并且窗格本身对应于集群中的进程。 炉膛包含一个或多个容器。 集成中的每个ZooKeeper服务器和Kafka集群中的每个代理将以单独的方式工作。
- StatefulSet ：StatefulSet是一个Kubernetes对象，可用于需要协调的多个有状态工作负载。 StatefulSet提供有关炉床顺序及其唯一性的保证。
- 无头服务 ：服务使您可以使用逻辑名将吊舱与客户端分离。 Kubernetes在这种情况下负责负载平衡。 但是，在维护有状态工作负载时（例如ZooKeeper和Kafka），客户端需要与特定实例交换信息。 这是方便无头服务的地方：在这种情况下，客户端仍将具有逻辑名称，但您不必直接进入底层。
- 长期存储卷：这些卷是配置非本地块长期存储所必需的，如上所述。
Yolean提供了一套全面的清单，可轻松在Kubernetes上开始使用Kafka。
舵图Helm是Kubernetes的软件包管理器，可以与OS的软件包管理器进行比较，例如yum，apt，Homebrew或Chocolatey。 使用它可以方便地安装Helm图中描述的预定义软件包。 精心选择的Helm图简化了艰巨的任务：如何正确配置所有参数以在Kubernetes上使用Kafka。 卡夫卡图有好几种：正式的图
处于孵化器状态 ，
Confluent的图 ，
Bitnami的图 。
经营者由于Helm具有某些缺点，因此另一种工具正变得越来越流行：Kubernetes运营商。 该运营商不仅为Kubernetes打包软件，而且还允许您部署和管理此类软件。
出色的运营商列表中提到了Kafka的两个运营商。
Strimzi就是其中之一。 在Strimzi的帮助下，几分钟之内即可轻松建立Kafka集群。 几乎不需要进行任何配置，此外，操作员本身还提供了一些不错的功能，例如，集群内部“点对点”类型的TLS加密。 Confluent还提供
了自己的运算符 。
性能表现通过为安装的Kafka实例提供控制点来测试性能，这一点非常重要。 这些测试将帮助您在问题开始之前确定潜在的瓶颈。 幸运的是，Kafka已经提供了两个性能测试工具：
kafka-producer-perf-test.sh和
kafka-consumer-perf-test.sh 。 积极使用它们。 作为参考，您可以参考Jay Kreps在
这篇文章中描述的结果，或者使用StéphaneMaarek Amazon MSK评论。
运作方式
监控方式系统的透明度非常重要-否则您将不了解系统中正在发生的事情。 如今，有一个可靠的工具包可以提供基于云原生风格的指标进行监控。 普罗米修斯（Prometheus）和格拉法纳（Grafana）是用于此目的的两种流行工具。 Prometheus可以使用JMX导出器以最简单的方式从所有Java进程（Kafka，Zookeeper，Kafka Connect）收集度量。 如果添加cAdvisor指标，则可以更好地了解Kubernetes中如何使用资源。
Strimzi有一个非常方便的Kafka Grafana仪表板示例。 它可视化关键指标，例如，有关复制不足的扇区或离线的扇区的指标。 那里的一切都很清楚。 这些指标由有关资源利用率和性能的信息以及稳定性指标补充。 这样，您就可以毫无理由地获得对Kafka集群的基本监视！
资料来源：
strimzi.io/docs/master/#kafka_dashboard最好用客户监视（针对消费者和生产者的度量标准）以及滞后监视（为此存在
Burrow ）和端到端监视来补充所有这些，为此，请使用
Kafka Monitor 。
记录中记录是另一个关键任务。 确保您在Kafka安装中的所有容器都已登录到
stdout和
stderr ，并确保您的Kubernetes集群将所有日志聚合在中央
日志记录基础架构中，例如
Elasticsearch 。
健康检查Kubernetes使用活动和就绪状态探针来检查您的Pod是否正常工作。 如果实时测试失败，Kubernetes将停止该容器，然后在相应设置重启策略的情况下自动重启它。 如果可用性检查失败，则Kubernetes会将其与请求服务隔离。 因此，在这种情况下，完全不再需要人工干预，这是一大优势。
推出更新StatefulSet支持自动更新：选择RollingUpdate策略时，Kafka下的每个策略都会依次更新。 这样，停机时间可以减少到零。
缩放比例扩展Kafka集群并非易事。 但是，在Kubernetes中，将Pod扩展到一定数量的副本非常容易，这意味着您可以声明性地标识任意数量的Kafka经纪人。 在这种情况下，最困难的是在放大之后或缩小之前重新分配扇区。 同样，Kubernetes将帮助您完成此任务。
行政管理与管理Kafka群集有关的任务（尤其是创建主题和重新分配扇区）可以使用现有的Shell脚本来完成，在Pod中打开命令行界面。 但是，这种解决方案并不是太漂亮。 Strimzi支持使用其他运算符管理主题。 这里需要修改。
备份与还原现在，Kafka的可用性将取决于Kubernetes的可用性。 如果您的Kubernetes集群崩溃，那么在最坏的情况下，Kafka集群也会崩溃。 根据墨菲的法律，这种情况会发生，并且您将丢失数据。 为了减少这种风险，请具有良好的备份概念。 您可以使用MirrorMaker，另一种选择是为此使用S3，如Zalando的这篇
文章中所述。
结论
在中小型Kafka集群上工作时，绝对建议使用Kubernetes，因为它提供了额外的灵活性并简化了与运营商的合作。 如果您对延迟和/或吞吐量有非常严格的非功能性要求，那么最好考虑其他一些部署选项。