Grab更新Kubernetes上的Kafka设置以提升容错性

Grab最近更新了其在Kubernetes上的Kafka设置，以提高系统的容错性，并在Kafka broker意外终止时完全消除人工干预的需求。为了解决初始设计的不足，团队集成了AWS Node Termination Handler (NTH)、使用Load Balancer Controller进行目标组映射，并转向使用ELB卷进行存储。

背景与挑战

Grab在其Coban实时数据平台中使用Apache Kafka和Kubernetes（EKS）已有两年时间，主要依赖于Strimzi。尽管初始设置运行良好，但在EKS节点因维护或基础设施问题被AWS意外终止时，Kafka客户端会突然遇到错误，因为broker未能优雅降级。此外，受影响的broker实例无法在新配置的EKS worker节点上重启，因为Kubernetes仍然指向不再存在的存储卷。这导致Kafka集群在只有两个broker节点可用的情况下运行，需要工程师手动干预。

解决方案

AWS Node Termination Handler (NTH)

团队采用AWS Node Termination Handler (NTH)来最小化对Kafka客户端的中断。NTH通过排空worker节点触发Kafka进程的优雅关闭（发送SIGTERM信号）。团队选择使用Queue Processor模式而非Instance Metadata Service (IMDS)模式，因为前者能捕获更广泛的事件，包括与可用区（AZ）和自动扩展组（ASG）相关的事件。

AWS Load Balancer Controller (LBC)

为了解决worker节点终止时的网络连接问题，团队使用AWS Load Balancer Controller (LBC)动态映射Network Load Balancer (NLB)目标组。通过增加健康检查频率并配置Pod Readiness Gate，工程师解决了NLB标记目标组为健康状态耗时过长的问题。

Elastic Block Storage (EBS)

团队使用Elastic Block Storage (EBS)卷替代NVMe实例存储卷，以确保新配置的Kafka worker节点能正确启动并访问数据存储卷。EBS具有成本更低、卷大小与实例规格解耦、同步时间更快、支持快照备份和无需停机的容量扩展等优势。此外，团队将EC2实例类型从存储优化型更改为通用型或内存优化型。

结果与未来计划

通过这些改进，EC2实例的退役和所有需要轮换worker节点的操作都可以在无需人工干预的情况下进行，使这些操作更快且更少出错。团队计划进一步改进，包括使用NTH webhook主动启动新实例并发送Slack通知，以及推出Karpenter以替代Kubernetes Cluster Autoscaler。