如何克隆Kafka/ZooKeeper集群用于测试及环境搭建？

一、故障恢复：备份YAML的有效性与补充措施 #

• 你备份的命名空间下所有YAML（包括Strimzi的Kafka、KafkaTopic、KafkaUser等CRD资源），在集群故障时重新应用可以恢复大部分集群配置，但要注意几个核心点：
  • 恢复时必须使用和原集群完全相同版本的Strimzi Operator，避免CRD版本不兼容导致资源解析失败。
  • YAML仅保存集群配置，不包含Kafka的消息数据。如果需要恢复消息，需配合Kafka的快照备份（比如用kafka-dump-log.sh导出，或Strimzi自带的KafkaBackup/KafkaRestore CRD）。
  • 恢复步骤：先部署同版本Strimzi Operator，再依次恢复Kafka集群CR、Topic、User等资源，最后按需恢复消息数据。

二、完整克隆现有Kafka集群 #

要实现配置+数据的完整克隆，可按以下步骤操作：

1. 配置克隆：
   • 导出原集群所有Strimzi相关CRD资源：kubectl get kafka,kafkatopic,kafkauser -n <原命名空间> -o yaml > cluster-resources.yaml
   • 修改YAML中的集群名称、命名空间（若克隆到新命名空间）、存储类（若目标环境存储不同）等字段，避免资源冲突。
2. 数据克隆：
   • 若使用Strimzi持久化存储（PVC），可先对每个Broker的PVC创建快照（需存储类支持），再在目标环境基于快照创建新PVC并关联到新集群Broker。
   • 无快照支持时，用Kafka自带工具：通过kafka-mirror-maker.sh将原集群所有Topic数据同步到新集群，或用kafka-reassign-partitions.sh生成分区副本分配计划实现数据迁移。
3. 验证：启动新集群后，检查Topic的分区、副本数，通过消费测试数据确认完整性。

三、搭建单元测试用的预发布环境 #

方案1：基于轻量K8s集群的模拟环境 #

• 用Minikube或Kind搭建本地单节点K8s集群，匹配生产环境的K8s运行场景：
  • 先部署对应版本的Strimzi Operator到本地K8s。
  • 调整原集群YAML配置：缩小Broker数量（如1个Broker）、降低存储容量（改用本地存储类）、关闭非必要监控组件，适配本地资源限制。
  • 应用修改后的YAML启动轻量Kafka集群，用于升级脚本的预测试。

方案2：Docker Compose部署Strimzi #

• 直接复制K8s YAML到Docker失败的原因是Strimzi原生面向K8s，需单独配置Docker Compose：
  • 基于Strimzi官方镜像编写Compose配置，调整kafka和zookeeper的基础参数（如版本、监听端口）匹配原集群。
  • 若要模拟多团队共用场景，可创建对应KafkaUser的认证配置，在Compose中挂载证书文件。
  • 启动后先测试升级脚本的执行流程，验证逻辑是否正常。

四、升级失败场景的测试建议 #

• 在测试集群（克隆集群或本地测试环境）中模拟故障场景：
  • 故意部署不兼容版本的Strimzi Operator，观察集群状态变化，再用备份YAML+原版本Operator执行恢复，验证恢复流程的可行性。
  • 模拟升级过程中节点宕机，检查Strimzi的自愈能力，同时验证手动恢复步骤的有效性。
  • 升级前执行kubectl get kafka <集群名> -n <命名空间> -o jsonpath='{.status.conditions}'确认集群处于Ready状态，升级后持续监控状态直至恢复Ready。

内容的提问来源于stack exchange，提问作者Sunny Kanda