Amazon MSK 支持 ZooKeeper 到 KRaft 就地升级

Apache Kafka 4.0 正式移除 ZooKeeper。如果你的Amazon Managed Streaming for Apache Kafka（Amazon MSK）预置集群仍运行在 ZooKeeper 元数据模式下，现在正是规划迁移的时候。Amazon MSK 现在支持从 ZooKeeper 到 KRaft 元数据模式的就地升级，因此你可以通过熟悉的版本升级工作流来现代化现有集群的元数据管理。

十多年来，Apache ZooKeeper 为 Kafka 提供了可靠的元数据管理，包括控制器选举、分区状态、broker 注册和主题配置。随着Apache Kafka 4.0，ZooKeeper 被正式移除，取而代之的是 KRaft，一种内嵌的基于 Raft 的共识协议，用于内部处理元数据管理。它将那些职责带入 Apache Kafka 本身，为 Kafka 的持续演进创造了更精简的基础。自 2024 年 5 月起，Amazon MSK 就支持 KRaft 模式集群，并且 Amazon MSK 上的所有 Kafka 4.x 版本都使用 KRaft。

通过就地升级，你可以保留集群数据和元数据，而 Amazon MSK 则管理控制平面过渡。在整个过程中，你的集群对生产和消费流量保持可用，如果你遵循最佳实践，则不会出现预期停机。通过使用现有的版本升级工作流，转向 KRaft 成为集群生命周期中的自然步骤。这为你的集群升级到 Kafka 4.x 及未来的 Kafka 版本做好准备。

前提条件

在启动升级之前，请查看以下要求，以确认你的集群已准备好进行过渡。

支持的源版本

集群必须运行在 Kafka 3.9.x 的 ZooKeeper 模式下才能使用就地升级。如果你的集群运行更早的版本，例如 3.6.0、3.7.x 或 3.8.x，请先完成标准就地版本升级到 3.9.x。然后你就可以启动升级到3.9.x.kraft。

Kafka 3.9 是此过渡的桥接版本，因为它同时支持 ZooKeeper 和 KRaft 模式。为了支持客户完成此迁移过程，Amazon MSK 为其 2025 年 4 月发布起的 3.9.x 版本提供至少两年的扩展支持。

客户端兼容性

The --zookeeper管理员标志在 Kafka 2.5 中已弃用，并在 3.0 中移除。升级前，请更新任何仍直接连接到 ZooKeeper 的应用程序或工具。

升级前检查清单

开始升级前，请确认以下事项：

• 对于标准 broker，集群必须部署在三个可用区中。Express broker 默认提供此配置。
• 集群运行在 ZooKeeper 模式的 Kafka 3.9.x。
• 标准 broker 在端口 2181（明文）和 2182（TLS）上暴露直接的 ZooKeeper 访问。升级前，请验证你已禁用集群上的 ZooKeeper 访问，并且你的任何应用程序都不依赖这些连接。
• 如果你之前使用动态覆盖在基于 ZooKeeper 的部署上配置了自定义域名（即通过kafka-configs.sh --alter修改advertised.listeners），请注意 KRaft 不支持此动态配置。如果你尝试使用已更改的advertised.listeners升级你的 MSK 集群到 KRaft，升级操作将失败。
• 如果你未来在 MSK 上使用 KRaft 实现自定义域名解决方案，我们建议你使用我们同时发布的 MSK 版本，该版本通过自定义域名支持静态配置custom.advertised.listeners属性，通过UpdateClusterConfigurationAPI 实现。

集群没有未复制的分区。集群在标准或表达 broker 集群的每 broker 分区限制内运行。对于运行在 KRaft 每集群 broker 数限制之上的集群，你可能需要额外的配额增加。如果你之前为 ZooKeeper 每集群 broker 数提出了配额增加，请在尝试升级前为 KRaft 限制再提交一次配额增加。集群有足够的预留容量来支持在服务客户端流量时进行滚动 broker 重启。作为最佳实践，请验证监控已准备好从 ZooKeeper 特定指标过渡到 KRaft 控制器指标。

• 迁移后，ZooKeeper 特定的Amazon CloudWatch指标，如ZookeeperRequestLatencyMsMean和ZookeeperSessionState将不再可用。
• 如果你使用开放监控，Kafka 也会停止发布 ZooKeeper 指标。请计划在迁移准备中更新或停用相关警报和仪表板。

升级如何工作

当你启动升级时，Amazon MSK 执行受管的多阶段迁移：

1. 控制器仲裁引导：Amazon MSK 在现有 ZooKeeper 基础设施旁边配置 KRaft 控制器节点。在此阶段，两个系统并行运行。
2. 元数据迁移：KRaft 控制器从 ZooKeeper 读取集群状态，并将其写入内部 KRaft 元数据日志。
3. Broker 过渡：Amazon MSK 执行滚动更新，并向 KRaft 控制器仲裁注册。在过渡期间，数据平面操作保持可用。
4. 验证和烘烤期：Amazon MSK 验证 KRaft 下的集群健康，包括分区领导权、复制状态和控制器响应能力。
5. ZooKeeper 退役：验证成功后，Amazon MSK 移除 ZooKeeper 基础设施，集群完全在 KRaft 模式下运行。

升级期间，集群进入UPDATING状态。你可以继续生产和消费数据，而 Amazon MSK 管理 API 操作暂时不可用，直到集群返回ACTIVE状态。

Amazon MSK 在过渡期间保持高标准的数据持久性。它在迁移的每个阶段使用严格的安全检查，以在向前和回滚场景中保护客户元数据。

内置恢复

Amazon MSK 在整个升级过程中监控集群健康状况。如果检测到阻止迁移完成的情况，它会自动将集群恢复到迁移前状态。恢复期间无需客户操作。

操作状态变为 "恢复到迁移前状态"，同时 Amazon MSK 恢复原始 Kafka 版本并重新连接 ZooKeeper。集群恢复到 "ACTIVE" 后，"describe-cluster-operation" API 会提供错误代码、失败原因和推荐的补救步骤。您可以使用这些信息在再次开始升级前解决问题。

如何执行升级

以下步骤将引导您使用 Amazon MSK 控制台完成升级过程。您也可以使用 AWS 命令行界面（AWS CLI）或 SDK 以编程方式执行这些步骤。

步骤 1：禁用 ZooKeeper 访问（仅标准代理）

注意： 此步骤仅适用于标准代理集群。Express 代理集群不暴露直接的 ZooKeeper 访问，可直接跳到步骤 2。

标准代理在端口 2181（明文）和 2182（TLS）上暴露直接的 ZooKeeper 访问。升级前，请验证您的应用程序是否都没有依赖这些连接。

导航到集群的 "属性" 选项卡，选择 "网络设置"，然后选择 "编辑 ZooKeeper 访问"。

图 1：从集群网络设置编辑 ZooKeeper 访问

在弹出的窗口中，确认 "ZooKeeper 访问" 设置为 "禁用"，然后选择 "保存"。

图 2：确认 ZooKeeper 访问已禁用

确认生产者、消费者和管理工具在无 ZooKeeper 连接的情况下继续正常运行。此步骤完全可逆。如果任何内容中断，请立即重新启用 ZooKeeper 访问。

图 3：验证无 ZooKeeper 访问时客户端流量持续运行

步骤 2：启动版本升级

在 Amazon MSK 控制台，在 "属性" 下，选择 "升级" 在 "Apache Kafka 版本" 部分。

图 4：从 Apache Kafka 版本部分启动版本升级

选择您的集群并启动版本升级到 "3.9.x"，将 "目标元数据模式" 设置为 "KRaft"。选择 "升级"。

图 5：选择 KRaft 作为目标元数据模式

您可以在集群属性页面监控升级进度。

图 6：在集群属性页面监控升级进度

步骤 3：监控升级进度

在 Amazon MSK 控制台的 "集群操作" 选项卡中跟踪进度，或使用 "describe-cluster-operation" API。

图 7：在集群操作选项卡上跟踪升级

步骤 4：验证 KRaft 集群

集群在 KRaft 模式下恢复到 "ACTIVE" 状态后：

• 验证主题、分区和消费者组是否存在。
• 确认生产者和消费者吞吐量与迁移前基线一致。
• 更新或禁用任何特定于 ZooKeeper 的监控警报。
• 更新操作文档和运行手册以反映 KRaft 模式。

图 8：升级后集群在 KRaft 模式下运行

升级完成后，您的集群将显示为活动状态，并启用 KRaft 作为元数据模式。

为 Amazon MSK 上的下一代 Kafka 做好准备

就地 ZooKeeper 到 KRaft 模式升级使准备现有 Amazon MSK 集群面向 Apache Kafka 的未来变得简单。除了消除外部元数据依赖之外，KRaft 还提供更快的故障转移时间和每个集群更高的分区限制。Amazon MSK 为您处理整个元数据转换、滚动代理更新、验证和恢复工作流。借助新的就地体验，您有一条清晰、简化的路径，可按照您的时间表进行升级，并解锁增强的可扩展性和弹性。

有关更多详细信息，请参阅 "Amazon MSK 开发者指南" 和 "支持的 Kafka 版本文档"。