亚马逊云科技在2026年8月20日宣布，Amazon Managed Streaming for Apache Kafka开始支持从Apache ZooKeeper原地迁移到KRaft。现有MSK集群可以保留原有基础设施和数据完成元数据管理架构升级，不需要另建集群后再执行数据复制。
这项更新解决了Kafka升级过程中最麻烦的一段工作。过去从ZooKeeper切换到KRaft常常需要准备新集群、复制主题数据、同步消费进度并安排客户端切换，现在MSK可以在原集群中完成控制平面的迁移。
KRaft接管Kafka集群元数据管理
ZooKeeper长期承担Kafka的集群协调与元数据管理工作，但它属于Kafka之外的独立系统，需要单独维护连接、权限和运行状态。KRaft基于Kafka Raft协议，把元数据交给Kafka控制器仲裁组管理。
迁移完成后，主题、分区、副本和控制器相关元数据由KRaft控制器维护，不再依赖ZooKeeper节点。MSK负责配置和管理这些控制器，用户不需要直接登录控制器执行日常管理操作。
此次发布的关键不是新集群支持KRaft，而是旧集群终于能够原地转换。对已经承载生产消息流的MSK环境而言，减少跨集群搬迁可以明显降低数据同步和客户端切换风险。
迁移前必须满足多项条件
官方要求源集群先运行Apache Kafka 3.9.x的ZooKeeper模式。版本更旧的集群需要先完成常规Kafka版本升级，并确认集群处于ACTIVE状态且没有等待执行的操作。
所有客户端和管理工具都应使用bootstrap server连接，不能继续依赖ZooKeeper连接字符串。迁移结束后ZooKeeper地址将不再可用，旧脚本、监控工具和主题管理工具需要提前排查。
当前还存在几项限制：kafka.t3.small代理实例不能执行迁移；同时开启公网访问与开放监控的集群不符合条件；动态配置advertised.listeners的环境也需要先处理。正式操作前应逐项完成兼容性检查，不能只看Kafka版本。
控制器创建与元数据搬迁由MSK完成
迁移启动后，MSK会先在现有集群中配置KRaft控制器。控制器准备完成后，服务把集群元数据从ZooKeeper迁移到KRaft仲裁组，并逐步调整代理节点，使其使用新的元数据管理方式。
当所有代理都成功注册到KRaft仲裁组后，MSK会停用ZooKeeper节点，并把集群的元数据管理模式更新为KRaft。整个过程不需要把主题数据复制到另一组代理，也不要求重新配置客户端应用。
官方说明集群在迁移期间保持可用，但迁移属于长时间操作，具体耗时会随着集群规模变化，可能持续数小时。业务仍应按照高可用方式连接多个代理，避免单一连接对滚动变更过于敏感。
迁移状态需要通过集群操作持续监控
管理员可以通过UpdateClusterKafkaVersion接口发起迁移，并使用DescribeClusterOperation检查任务进度。自动化平台应记录集群ARN、开始时间、目标版本和操作ID，便于定位长时间停留的步骤。
监控不能只看迁移任务是否完成。Kafka请求延迟、消息写入错误、消费积压、离线分区、控制器状态和代理CPU都应放在同一观察窗口内，才能确认业务流量没有受到异常影响。
迁移前后还应分别执行生产与消费验证，检查新消息写入、历史消息读取、消费者组重平衡和ACL管理。使用第三方Kafka管理工具的团队，需要确认工具已经通过Admin API工作，而不是在后台访问ZooKeeper。
生产集群应先做完整迁移演练
原地迁移减少了新集群和数据复制工作，但它仍然是控制平面的重大变化。团队应先选择业务影响较低、配置接近生产环境的集群演练，记录准备检查、实际耗时和监控指标变化。
迁移开始前需要冻结版本与配置调整，确认没有并行扩容、存储调整或代理类型变更。关键主题还应检查副本状态与最小同步副本设置，避免在集群本身已经不健康时叠加迁移操作。
Kafka版本降级不受支持，因此变更计划不能依赖简单回退版本。运维人员应预留足够的维护窗口和支持升级通道，并提前清理使用ZooKeeper地址的旧客户端，防止控制平面切换完成后才发现外围工具失去连接。
