背景介绍

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单实例部署

存在单点故障