Kafka 去 ZooKeeper 实战评估：KRaft 模式架构解析与生产落地决策指南

Kafka 4.0 已经彻底移除了 ZooKeeper，但生产上还有大量集群跑在 ZK 模式上------要不要迁 KRaft、什么时候迁、迁了会踩什么坑？本文基于一次内部技术评估整理：架构原理对比、九个维度逐项评估、核心配置示例、版本演进时间线，最后给出一棵"上不上 KRaft"的决策树。结论先行：新集群直接上，存量集群从 3.6 开始规划迁移，测试环境今天就该用起来。

一、KRaft 是什么：一句话讲清

KRaft = Kafka Raft 。用 Kafka 自己实现的 Raft 共识协议，取代 ZooKeeper 承担的元数据管理和控制器选举。简单说：以前 Kafka 依赖 ZooKeeper 存元数据、选主；现在这套能力内置成了 Kafka 自己的角色。

架构上的三个本质变化：

元数据变成了 Kafka 自己的内部主题 （__cluster_metadata），走 Raft 协议在 controller 节点间复制，不再依赖外部系统
Controller 故障转移更快------旧模式选主要等 ZK 会话超时再全量拉元数据（可能分钟级）；KRaft 的 controller 内存里就有全量元数据，秒级接管
组件少了一套------部署、监控、备份、安全加固都少一个对象

二、九个维度逐项评估（生产视角）

这是本文的核心表，来自一次面向生产环境的内部评估：

维度	ZooKeeper 方案	KRaft 方案
成熟度	十年以上生产实践检验	2021 年首次推出，2022 年 10 月官方宣布可用于生产；3.7/3.8/3.9 仍在完善细节
问题处理	社区经验丰富，坑都有现成答案	经验有限，新问题要自己趟
社区支持	完善	逐步完善中，官方重心已全面转向 KRaft
监控工具	全面支持（各种 exporter、管理台）	部分支持，工具链在补齐
运维工具	生态完善	需要更新适配
第三方组件	兼容性好	需要逐个验证（尤其依赖 zk 地址的老组件）
解决方案	成熟	在探索阶段
运维成本	可控（但要多养一套 zk 集群）	短期不确定，长期更低
学习成本	低	相对较高（Raft、controller quorum、新配置体系）

怎么读这张表：左边全是"现在"，右边全是"未来"。评估的分歧从来不是"KRaft 好不好"，而是"什么时候切过去收益大于风险"。

三、KRaft 核心配置长什么样

一台 broker+controller 混布节点的最小配置：

properties 复制代码

# 节点角色：broker、controller 或两者兼有
process.roles=broker,controller
node.id=1

# controller 仲裁列表（Raft 选民用，格式：node.id@host:port）
controller.quorum.voters=1@kafka01:9093,2@kafka02:9093,3@kafka03:9093

listeners=SASL_PLAINTEXT://:9092,CONTROLLER://:9093
controller.listener.names=CONTROLLER

log.dirs=/data/kafka

对比 ZK 模式消失的配置：zookeeper.connect 不需要了；新增的三样就是 process.roles、controller.quorum.voters、controller.listener.names。

认证体系与 ZK 模式通用------SASL 配置照搬即可，参考本站的 Kafka SASL 认证实战系列：（一）内置 ZooKeeper 场景、（二）外置 ZK 通道认证、（三）完整版 + ACL。其中第二、三篇里的 zk SASL/ACL 配置在 KRaft 模式下整篇不需要------这也是"少养一套组件"的直接红利。

四、版本演进时间线（决定你的迁移窗口）

版本	KRaft 里程碑
2.8	KRaft 抢先体验（不可用于生产；2.8.2 已停止该模式）
3.3	KRaft 正式生产可用（官方 2022-10）
3.4 - 3.5	ZK→KRaft 在线迁移能力推出（早期阶段）；3.5 起标注 ZK 已弃用
3.6	在线迁移可用于生产，存量集群迁移的正经起点
3.7 - 3.9	KRaft 补齐 JBOD 等能力、持续打磨；3.9 是最后一个支持 ZooKeeper 的版本
4.0	ZooKeeper 模式彻底移除，新集群只有 KRaft 一条路

两个关键判断：

3.6 是存量集群迁移的窗口起点------官方文档明确建议用户开始规划迁移并在测试环境演练
4.0 之后没有选择------升级到 4.0 的前提就是完成 KRaft 迁移，这事早晚会来

五、KRaft 的真实优势（不是吹的）

整体架构更简单：不需要单独的 zk 集群，只需补充 Kafka 端的 KRaft 配置
性能潜力大：元数据走事件触发机制，controller 故障转移从分钟级降到秒级
运维更简单：少了 zk 集群的部署、监控、扩容、安全加固，只关注 Kafka 自身
资源消耗更少：对比 zk 集群方案，减少了一层网络开销和一整套 JVM
分区数上限更高：旧模式 zk 是元数据规模瓶颈，KRaft 的元数据伸缩性好得多------大规模集群收益明显

六、生产落地决策树

按场景给建议：

新建集群

版本 4.0+：没有选择，KRaft
版本 3.7~3.9：建议直接上 KRaft------新集群没有历史包袱，绕过迁移成本，还能倒逼团队积累经验

存量 ZK 集群

版本 < 3.6：先升级版本（本身就是一个工程），把 3.6+ 作为迁移前置
版本 >= 3.6：开始规划迁移。先在测试环境完整演练：导出配置、跑在线迁移、验证客户端兼容性、演练回滚
迁移前必查清单：监控工具是否支持 KRaft、第三方组件（如老版本 EAGLE、自研管理台）是否有 zk 地址硬编码、SCRAM/ACL 配置迁移方案

测试环境

现在就用 KRaft。这也是我们内部评估的原始建议：小规模在测试环境使用 KRaft 方案，收集反馈、积累问题细节和经验------等生产要迁的时候，团队已经不是新兵了

七、评估中要注意的坑

坑	说明
2.8 试过 KRaft 被劝退的印象过时了	2.8 时代确实是半成品，3.3 之后成熟度完全不同，评估要以新版本为准
在线迁移不是一键无损	3.6 的迁移工具可用但仍需演练，尤其 ACL/配额/租户等高级特性
第三方工具链断层	依赖 zk 地址做服务发现的老组件要逐个排查改造
团队心智模型要更新	没有 zkCli 了，排障入口变成 metadata shell 和新的 metrics
JBOD 等特性有版本门槛	3.7 才支持 KRaft 下的 JBOD，老硬件规划要留意

总结

KRaft 的评估结论可以浓缩成三句话：方向没有争议 （4.0 已删掉 ZK，官方全部筹码在 KRaft）；节奏自己掌握 （3.6 起迁移可用，测试环境先行、新集群直上、存量按升级计划排期）；红利按规模兑现（集群越多、分区越多，少养 zk 的收益越大）。

你们生产上的 Kafka 什么版本了？开始迁 KRaft 了吗，还是在等 4.0 逼一把？评论区聊聊。

基于内部技术评估整理；版本信息以 Apache Kafka 官方发布说明为准。