Google Cloud于2026年10月9日说明，新建的Managed Service for Apache Kafka集群使用了不同格式的引导地址和Broker URL。这会影响把地址模板写死在客户端配置、部署脚本或防火墙规则中的团队。
公告说的是新集群的地址格式变化，并没有要求现有集群统一更换地址。最稳妥的做法是从目标集群读取实际地址。
地址变化与集群生命周期的关系
官方文档说明，引导地址在单个集群的生命周期内保持固定，但不同集群之间的URL格式可能不同。因此，新建或重建集群时，不应把旧环境里的域名规则直接套到新环境。
部署时把实际返回的bootstrap地址作为配置来源，可避免手工拼接地址造成连接失败，也利于审查环境之间的差异。
控制台可以直接复制所需地址
在托管Kafka的Clusters页面进入目标集群，再打开Configurations标签。采用SASL认证时查看Bootstrap URL；采用双向TLS认证时查看mTLS Bootstrap URL，二者不要混用。
先确认客户端认证方式，再复制相应地址。把SASL端点填入mTLS客户端，不能靠自动重试修复认证配置问题。
自动化可从集群属性读取
Google Cloud文档给出的命令是gcloud managed-kafka clusters describe，并可分别从bootstrapAddress或bootstrapAddressMTLS字段提取SASL与mTLS地址。脚本应以集群ID和区域查询对应环境，而不是维护猜测的域名模板。
更换或新建集群时，先读取地址并更新配置管理中的目标值，再让客户端滚动连接，避免多个环境交叉指向错误集群。
公网访问仍使用同一引导地址
对于启用公网访问的集群，官方说明同一个引导地址会根据客户端位置通过分视图DNS解析到公网或私网IP。内外部客户端都应使用该集群引导地址。
不要把发现用DNS记录当作Kafka客户端地址。官方将这些记录留给外部出站防火墙的配置用途；客户端与防火墙的配置来源应分开处理。
切换前逐项验证网络与认证
上线检查可核对集群配置页的地址、客户端认证方式、DNS解析位置和防火墙放行范围，再用受控客户端验证连接和元数据发现。Broker URL格式也发生变化，应避免依赖固定命名模式的监控或脚本。
能连上引导地址不代表所有Broker访问路径都正确；应进一步验证实际生产者和消费者的连接、读写与故障重连。
