Grab 改进 Kubernetes 集群中的 Kafka 设置，无需人工干预就可轮换 Broker 节点

Grab 更新了其 Kubernetes 上的 Kafka 设置以提高容错性，并完全避免在 Kafka Broker 意外终止时需要进行人工干预。为解决最初设计的不足，Grab 的团队集成了 AWS 节点终止处理程序（Node Termination Handler，NTH），使用负载均衡器控制器进行目标组映射，并切换到 ELB 卷进行存储。

作为其 Coban 实时数据平台的一部分，Grab 已经在 Kubernetes (EKS) 上使用 Strimzi 在生产环境中运行 Apache Kafka 两年了。团队之前使用了 Strimzi（现已成为 CNCF 孵化项目），通过应用成熟的身份验证、授权和保密机制来提升 Kafka 集群的安全性。

除了由于维护或基础设施问题导致 AWS 意外终止 EKS 节点外，初始设置运行良好。在这种情况下，Kafka 客户端会突然遇到错误，因为 Broker 没有被优雅地降级。更糟糕的是，受影响的 Broker 实例无法在新配置的 EKS 工作节点上重新启动，因为 Kubernetes 仍然指向已经不存在的存储卷。因此，如果没有 Coban 工程师的干预，Kafka 集群将以降级状态运行，三个 Broker 节点中只有两个可用。

开发人员利用 AWS 节点终止处理程序（NTH）将对 Kafka 客户端的干扰降至最低，通过排空工作节点，使用 SIGTERM 信号触发 Kafka 进程优雅地关闭。Grab 团队选择使用队列处理器模式而不是实例元数据服务（IMDS）模式，因为它捕获了更广泛的事件集合，包括与可用区（AZ）和自动扩展组（ASG）有关的事件。

使用 AWS 节点终止处理程序（队列处理器）支持 Kafka 的优雅关闭（来源：Grab 工程博）

他们使用 AWS 负载均衡器控制器（LBC）动态映射网络负载均衡器（NLB）目标组来解决工作节点终止时网络连接中断的问题。工程师们通过增加健康检查频率并使用 Pod 就绪门（Pod Readiness Gate）控制器来配置 NLB，解决 NLB 将每个目标组标记为健康状态所需的时间过长的问题。

他们最后需要克服的一个最大的障碍是确保新配置的 Kafka 工作节点能够正确启动并访问数据存储卷。工程师们决定使用弹性块存储（EBS）卷而不是 NVMe 实例存储卷。使用 ESB 有许多好处，例如成本更低、将卷大小与实例规格解耦、更快的同步速度、快照备份以及在不停机的情况下增加容量。此外，他们将 EC2 实例类型从存储优化改为通用型或内存优化型。

通过对 Kubernetes 和 Strimzi 进行额外配置，能够在新集群上自动创建 EBS 卷，并在将 Kafka Pod 重定位到不同工作节点时在 EC2 实例之间附加 / 分离卷。

经过这些改进，EC2 实例退役以及任何需要对所有工作节点进行轮换的操作都可以在没有人工干预的情况下进行，这些操作变得更快速、更不容易出错。他们正在计划做进一步的改进，包括使用 NTH Webhook 主动启动新实例并通过 Slack 通知 NTH 发起的操作，以及推出 Karpenter，用以取代 Kubernetes Cluster Autoscaler。

查看英文原文：

https://www.infoq.com/news/2024/02/grab-kafka-kubernetes-aws-nth/