kafka部署在kubernetes中的跨集群访问失效问题

背景介绍

kafka是一个分布式高吞吐的流处理平台。kafka每个的工作节点称为一个broker,broker之间通过zookeeper选主确定controller。生产数据时,数据根据分区分散在不同的broker上(topic创建多个分区时,分区会对broker列表轮转建立映射关系)。数据所在的broker称之为leader副本,leader副本提供读写功能,controller的broker会将leader副本复制到其他follower,follower只提供备份功能。这边就有一个问题?master和其他不同的broker之间如何通信呢,要是使用主机ip,在主机发生故障broker迁移到其他节点ip发生变化呢?kafka本身没有解决这个问题,默认情况下配置的是主机名进行通信,集群内节点配置/etc/hosts主机名解析,这样在一台broker down调之后新启动的broker则需要也使用老主机的主机名。生产和消费时如何访问呢,生产消费的主机实例也得配置/etc/hosts主机名解析。


image.png

在容器云时代,推荐的kafka部署架构是怎样?kafka推荐在k8s中通过helm方式部署,借助k8s的statefulset和headless service正好可以将kafka作为一个有状态应用部署。headless service会为kafka的每个实例生成一个集群内全局唯一的域名。

(env) zetyun@sd-k8s-master-1:~$ kubectl get pod -n gcp -owide|grep kafka
kafka-controller-0                    1/1     Running     0             53d     10.233.239.220   sd-k8s-work-3   <none>           <none>
kafka-controller-1                    1/1     Running     0             4d16h   10.233.23.175    sd-k8s-work-6   <none>           <none>
kafka-controller-2                    1/1     Running     0             53d     10.233.139.43    sd-k8s-work-5   <none>           <none>

实例对应域名:

10.233.139.43 kafka-controller-2.kafka-controller-headless.gcp.svc.cluster.local
10.233.23.175 kafka-controller-1.kafka-controller-headless.gcp.svc.cluster.local
10.233.239.220 kafka-controller-0.kafka-controller-headless.gcp.svc.cluster.local

kafka的配置文件(cat kafka/config/server.properties)

advertised.listeners=CLIENT://kafka-controller-0.kafka-controller-headless.gcp.svc.cluster.local:9092,INTERNAL://kafka-controller-0.kafka-controller-headless.gcp.svc.cluster.local:9094

看起来完美的解决了上面的问题,通过headless service域名解析不再需要配置/etc/hosts/主机名解析,集群内的pod都可以直接通过域名headless service域名对kafka生产或消费消息。有单个broker出现故障后(pod异常),statefulset会重新拉起一个相同pod名称的pod,自动化的进行了故障修改。
看起来是不是要大结局了?并没有,新的问题又出现了,集群外的服务如何向集群内的kafka生产或者消费消息呢?

解决思路:

这边有四个方案可供参考!

1.消息生产节点部署在k8s集群内

生产者作为k8s worker节点或者pod(容器pod或者虚拟机Pod))。客户端则可以直接使用k8s coredns域名解析即可。
-- 为了消息的时效性,以及减少丢消息的概率,一般消息生产者建议和kafka服务部署在同一个集群,甚至同一个节点,约近越好,尽量减少消息的转发。消息消费者可以在不同类型的客户端,不同的集群。

2.kafka hostnetwork方式部署

配置全局dns解析(能够覆盖slurm login节点)或者login节点配置/etc/hosts,两者都需要考虑实例故障后ip变化配置自动更新。

3.集群内部署kafka-proxy服务

1.借助kafka-proxy grepplabs/kafka-proxy 2.自研服务流程实现在kafka-agent(相比于前者可以增加平台认证))
-- kafka-proxy服务需要考虑单点故障,消息缓存丢失问题

4.kafka单实例部署

存在单点故障

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容