Strimzi Kafka Operator 中 Cruise Control 配置管理验证实战从配置热更新到动态部署/卸载的系统测试剖析【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator导读Cruise Control 是 Strimzi 为 Kafka 集群提供的自动化负载均衡与集群优化组件。本文以仓库内系统测试套件 CruiseControlConfigurationST 为核心深入剖析 Strimzi 如何端到端验证 Cruise Control 的配置管理能力——包括修改性能调优参数后仅滚动 Cruise Control 而不扰动 Kafka Broker以及在不删除内部 Topic 的前提下动态部署、卸载、重新部署 Cruise Control。读完本文你将掌握这套测试的设计思路、底层配置参数语义、验证手段以及如何在自己的 Kubernetes 环境中复现运行。一、测试套件定位验证什么、需要什么环境1.1 套件职责与声明根据测试套件的SuiteDoc注解见 CruiseControlConfigurationST.java本套件的职责描述为Description:This test suite, verify configuration of the Cruise Control component.即专门验证 Cruise Control 组件的配置行为。它覆盖两个核心场景| 测试方法 | 验证目标 | | - | - | |testConfigurationUpdate| 更新 Cruise Control 配置后Cruise Control Pod 滚动应用新配置而 Kafka Pod 不发生不必要的滚动 | |testDeployAndUnDeployCruiseControl| 动态部署、移除、再部署 Cruise Control验证系统稳定性与配置管理的正确性 |1.2 前置条件Cluster Operator套件声明的唯一前置步骤是安装并运行 Cluster Operator| Step | Action | Result | | - | - | - | | 1 | Set up the Cluster Operator | Cluster Operator is installed and running |这一点在源码中由BeforeAll阶段的setUp()方法落实——它调用SetupClusterOperator.getInstance().withDefaultConfiguration().install()安装默认配置的 Cluster Operator源码位置。1.3 测试标签与分类套件类与每个测试方法都声明了Tag(REGRESSION)和Tag(CRUISE_CONTROL)并标记ParallelNamespaceTest并行命名空间测试说明它可以与其他测试并行运行且归属于回归测试类别。在测试文档体系中它被收录在 cruise-control 标签页 下与 Cruise Control 的 API、Rebalance、日志、指标等测试共同构成完整的 Cruise Control 验证矩阵。二、testConfigurationUpdate配置更新后的精准滚动验证2.1 测试目标与完整步骤该测试的目标是验证 Cruise Control 配置更新后只有 Cruise Control 自身滚动Kafka 的 Broker/Controller Pod 不应当滚动。官方文档给出的完整步骤为| Step | Action | Result | | - | - | - | | 1 | Create broker and controller KafkaNodePools | Both KafkaNodePools are successfully created | | 2 | Create and wait for Kafka with Cruise Control | Kafka and Cruise Control are deployed successfully | | 3 | Take initial snapshots of Kafka and Cruise Control deployments | Snapshots of current deployments are stored | | 4 | Update Cruise Control configuration with new performance tuning options | Configuration update initiated | | 5 | Verify Cruise Control Pod rolls after configuration change | Cruise Control Pod restarts to apply new configurations | | 6 | Verify Kafka Pods did not roll after configuration change | Kafka Pods remain unchanged | | 7 | Verify new configurations are applied to Cruise Control in Kafka CR | New configurations are correctly applied |2.2 源码层面的执行细节在 CruiseControlConfigurationST.java 中测试的执行路径是创建 Broker 与 Controller 两类 KafkaNodePool各 3 副本通过KafkaNodePoolTemplates.brokerPool(...)与KafkaNodePoolTemplates.controllerPool(...)创建对应 KRaft 模式下的 dual-role 分离。部署带 Cruise Control 的 Kafka 集群使用KafkaTemplates.kafkaWithCruiseControl(...)生成 CR。记录基线快照PodUtils.podSnapshot记录 broker Pod 的 UID 快照DeploymentUtils.depSnapshot记录 Cruise Control Deployment 的副本快照作为后续滚动对比的基准。更新性能调优配置通过KafkaUtils.replace对 Kafka CR 执行原子替换写入如下 4 项参数见 CruiseControlConfigurationParameters.javaMapString, Object performanceTuningOpts new HashMap() {{ put(CruiseControlConfigurationParameters.CONCURRENT_INTRA_PARTITION_MOVEMENTS.getValue(), 2); put(CruiseControlConfigurationParameters.CONCURRENT_PARTITION_MOVEMENTS.getValue(), 5); put(CruiseControlConfigurationParameters.CONCURRENT_LEADER_MOVEMENTS.getValue(), 1000); put(CruiseControlConfigurationParameters.REPLICATION_THROTTLE.getValue(), -1); }};这四项参数对应的 Cruise Control 原生配置键为| 枚举 | 配置键 | 测试中写入的值 | 语义 | | - | - | - | - | |CONCURRENT_INTRA_PARTITION_MOVEMENTS|num.concurrent.intra.broker.partition.movements| 2 | 每个 Broker 上并发执行的 intra-broker 分区迁移数上限 | |CONCURRENT_PARTITION_MOVEMENTS|num.concurrent.partition.movements.per.broker| 5 | 每个 Broker 上并发执行的跨 Broker 分区迁移数上限 | |CONCURRENT_LEADER_MOVEMENTS|num.concurrent.leader.movements| 1000 | 并发 Leader 迁移数上限 | |REPLICATION_THROTTLE|default.replication.throttle| -1 | 默认复制限流值-1 表示不限流 |断言 Cruise Control Deployment 发生滚动DeploymentUtils.waitTillDepHasRolled等待 CC Deployment 的副本滚动完成。断言 Kafka 未发生滚动RollingUpdateUtils.waitForNoRollingUpdate校验 broker 快照未变化——这是整个测试最关键的断言证明 Cruise Control 的配置变更被隔离在 CC 组件内部不会触发 Kafka 集群无意义的全量滚动。在 ConfigMap 层面验证配置落盘读取 Cruise Control 的cruisecontrol.properties取自名为cluster-cruise-control-config的 ConfigMap将其加载为Properties再用 HamcresthasEntry逐一断言四项参数均已写入且值正确。2.3 底层原理为什么只滚动 Cruise Control从实现上看这一行为由 CruiseControl.java 与 CruiseControlConfiguration.java 共同保证默认属性使用有序 Map 生成DEFAULT_PROPERTIES_MAP被包装为Collections.unmodifiableSortedMap(new TreeMap(...))源码注释明确说明“map 必须排序使 Cruise Control 配置项顺序确定避免引起不必要的滚动更新”CruiseControlConfiguration.java。用户配置与默认值合并生成最终配置只有真正变化的配置才会导致 CC Deployment 的 ConfigMap 内容变化从而触发 CC 滚动Kafka Broker 的配置如 metrics reporter 配置只有在 CC 启停时才会变化因此本例中 Kafka Pod 完全不受影响。三、testDeployAndUnDeployCruiseControl动态部署与卸载的生命周期管理3.1 测试目标与完整步骤该测试验证的是在不停机、不删除 Cruise Control 内部 Topic 的前提下将 Cruise Control 从 Kafka 集群中移除再重新加回整个过程中集群配置被正确清理与恢复。官方文档步骤| Step | Action | Result | | - | - | - | | 1 | Create broker and controller KafkaNodePools | Both KafkaNodePools are successfully created | | 2 | Deploy Kafka with Cruise Control | Kafka cluster with Cruise Control is deployed | | 3 | Take a snapshot of broker pods | Snapshot of the current broker pods is taken | | 4 | Remove Cruise Control from Kafka | Cruise Control is removed from Kafka and configuration is updated | | 5 | Verify Cruise Control is removed | No Cruise Control related pods or configurations are found | | 6 | Create Admin client to verify Cruise Control topics | Admin client is created and Cruise Control topics are verified to exist | | 7 | Re-add Cruise Control to Kafka | Cruise Control is added back to Kafka | | 8 | Verify Cruise Control and related configurations | Cruise Control and its configurations are verified to be present |3.2 源码层面的执行细节见 CruiseControlConfigurationST.java。测试先创建 3 副本的 Broker/Controller NodePool并通过kafkaWithCruiseControl部署集群同时设置default.replication.factor3使后续创建的 CC Topic 也获得 3 副本。移除阶段通过KafkaUtils.replace将kafka.getSpec().setCruiseControl(null)随后依次断言Kafka CR 中 Cruise Control 已被清除getSpec().getCruiseControl()为nullCC Pod 消失waitUntilPodStabilityReplicasCount(..., 0)等待 CC Pod 副本归零Broker 配置中的 metric reporter 被移除assertThrows(WaitException.class, () - CruiseControlUtils.verifyCruiseControlMetricReporterConfigurationInKafkaConfigMapIsPresent(...))——即 Kafka ConfigMap 中不再包含cruise.control.metrics.*前缀的配置项读取时必然抛异常。验证 Topic 保留测试用KafkaAdminClientBuilder部署 Admin 客户端通过CruiseControlUtils.verifyThatCruiseControlTopicsArePresent确认三个 Cruise Control 内部 Topic 在卸载后依然存在于 Kafka 中关于这三个 Topic 见下文第四部分。重新部署阶段执行kafka.getSpec().setCruiseControl(new CruiseControlSpec())将 CC 加回等 broker 滚动完成后再次断言metric reporter 配置重新出现在 Kafka ConfigMap 中三个 Cruise Control Topic 仍存在。3.3 设计意图Topic 的生命周期策略这一测试揭示了一个重要的产品决策Cruise Control 卸载时其内部 Topicmetrics、model trainings、partition metrics samples不会被删除。从源码注释可以直接看到测试预期——“Cruise Control Topics will not be deleted and will stay in the Kafka cluster”源码。这样设计的好处是历史负载采样数据得以保留重新启用 Cruise Control 后可以无缝恢复其负载监控能力无需冷启动积累数据。四、配套验证工具 CruiseControlUtils 与内部 Topic 语义测试中大量复用 CruiseControlUtils.java它封装了 Cruise Control 的 API 调用与配置断言是理解该套件验证深度的钥匙。4.1 三个内部 Topic工具类中定义了 Cruise Control 的默认内部 Topic源码| 常量 | Topic 名称 | 分区数 | 副本数 | | - | - | - | - | |CRUISE_CONTROL_METRICS_TOPIC|strimzi.cruisecontrol.metrics| 1 | 跟随集群default.replication.factor测试中为 3 | |CRUISE_CONTROL_MODEL_TRAINING_SAMPLES_TOPIC|strimzi.cruisecontrol.modeltrainingsamples| 32 | 3 | |CRUISE_CONTROL_PARTITION_METRICS_SAMPLES_TOPIC|strimzi.cruisecontrol.partitionmetricsamples| 32 | 3 |对应的默认名称常量定义于 CruiseControlConfigurationParameters.java分别是DEFAULT_METRIC_REPORTER_TOPIC_NAME、DEFAULT_BROKER_METRIC_TOPIC_NAME、DEFAULT_PARTITION_METRIC_TOPIC_NAME。verifyThatCruiseControlTopicsArePresent不仅检查 Topic 存在还逐一校验分区数与副本数源码确保 CC 按预期规格创建了内部存储结构。4.2 metric reporter 配置断言verifyCruiseControlMetricReporterConfigurationInKafkaConfigMapIsPresent从 broker 的server.configKafka ConfigMap中筛选所有cruise.control.metrics前缀的配置项断言其满足cruise.control.metrics.topicstrimzi.cruisecontrol.metricscruise.control.metrics.topic.auto.createtruecruise.control.metrics.reporter.bootstrap.servers指向cluster-kafka-brokers:9091broker 内部通信端口安全协议、TLS 信任库${strimzisecrets:ns/cluster-trustbundle:cluster-ca.crt}、认证方式mTLS keystore 或 Service Account 的 SASL OAUTHBEARER与测试环境配置一致。这正是“卸载时清除、重装时恢复”断言的具体落点metric reporter 是 Cruise Control 与 Kafka 之间唯一的 broker 侧耦合点它的增删直接体现了配置管理的正确性。4.3 端口约定工具类还记录了 Cruise Control 的默认端口REST API 端口9090、指标端口9404并通过callApi在 CC Pod 内执行 curl 调用 API支持 HTTP/HTTPS、带/不带 admin 凭据为 API 类测试提供了基础能力。五、配置模型的源码级解析参数、默认值与目标过滤5.1 参数枚举全景operator-common/src/main/java/io/strimzi/operator/common/model/cruisecontrol/CruiseControlConfigurationParameters.java 是一个贯穿 operator-common、cluster-operator 与 systemtest 三个模块的核心枚举它把 Cruise Control 的原生配置键统一为类型安全常量。除性能调优参数外还包括| 类别 | 配置键示例 | 说明 | | - | - | - | | 采样窗口 |partition.metrics.window.ms、num.partition.metrics.windows、broker.metrics.window.ms、num.broker.metrics.windows| 负载监控器的指标聚合窗口大小与数量 | | 任务保留 |completed.user.task.retention.time.ms| 已完成用户任务的保留时长 | | Web 安全 |webserver.security.enable、webserver.auth.credentials.file、webserver.ssl.enable| API 鉴权与 TLS | | 采样 Topic |partition.metric.sample.store.topic、broker.metric.sample.store.topic、sample.store.topic.replication.factor| CC 内部存储结构 | | Goals |goals、default.goals、hard.goals、self.healing.goals、anomaly.detection.goals| 优化目标配置 | | Metrics reporter |cruise.control.metrics.reporter.*| broker 侧指标上报配置 |5.2 默认配置的生成逻辑CruiseControlConfiguration.java 的generateDefaultPropertiesMap在默认属性之上补充default.goals与hard.goals且会调用filterResourceGoalsWithoutCapacityConfig依据用户在 Kafka CR 中配置的容量capacity信息过滤目标——例如未配置入站网络容量时会移除NetworkInboundUsageDistributionGoal、NetworkInboundCapacityGoal与LeaderBytesInDistributionGoal源码。这一逻辑保证了默认 goals 始终与用户声明的容量配置自洽避免生成无法满足的优化目标。5.3 用户如何启用 Cruise Control生产中最常见的用法是在 Kafka CR 中声明cruiseControl段。仓库示例 kafka-cruise-control.yaml 展示了最简用法apiVersion: kafka.strimzi.io/v1 kind: Kafka metadata: name: my-cluster spec: # ... kafka 段、entityOperator 段等 cruiseControl: {}空对象即启用带全部默认值的 Cruise Control若需自定义则按测试中的写法在cruiseControl.config下提供键值对例如cruiseControl: config: num.concurrent.partition.movements.per.broker: 5 num.concurrent.intra.broker.partition.movements: 2 num.concurrent.leader.movements: 1000 default.replication.throttle: -1六、如何复现运行这套测试6.1 环境要求一个可用的 Kubernetes 集群本套件可并行运行于多个测试命名空间集群中已存在或可由测试安装的 Cluster OperatorBeforeAll会自动安装构建工具链Maven 与 JDK参考仓库根目录 Makefile.maven 中的mvn verify/mvn install流程。6.2 运行方式官方推荐的系统测试入口是 systemtest/scripts/run_tests.sh./systemtest/scripts/run_tests.sh io.strimzi.systemtest.cruisecontrol.CruiseControlConfigurationST systemtests脚本会以-pl systemtest -am构建 systemtest 模块及其依赖并注入-Dit.testTESTCASE指定测试类详见 run_tests.sh。也可以直接通过 Maven failsafe 运行mvn -B verify -pl systemtest -am -Psystemtests \ -DfailIfNoTestsfalse \ -Dit.testio.strimzi.systemtest.cruisecontrol.CruiseControlConfigurationST测试运行的整体规范集群准备、构建参数、报告收集可进一步参考 TESTING.md 与 DEV_GUIDE.md。七、相关测试与经验总结7.1 与 Cruise Control 测试矩阵的关系本套件是 Cruise Control 验证矩阵中的“配置管理”一环。从 cruise-control 标签页 可以看到围绕 Cruise Control 还覆盖了API 用户与基础请求CruiseControlApiST、Rebalance 状态流转与自动审批CruiseControlST、Broker 扩缩容期间行为、日志变更LogSettingST、指标暴露MetricsST等场景。CruiseControlConfigurationST与其互补前者关注“行为正确”本套件关注“配置正确”。7.2 可复用的工程实践从这套测试中可以提炼出三类可借鉴的验证模式变更影响面隔离断言testConfigurationUpdate同时断言“目标组件已滚动”与“非目标组件未滚动”用快照 diff 方式杜绝回归是配置类测试的标准范式动态启停的配置双向验证testDeployAndUnDeployCruiseControl对同一断言分别验证“存在”与“不存在”两种形态覆盖了清理逻辑移除后无残留配置与恢复逻辑重装后配置完整回归配置落盘级验证测试不止于 CR 层面的字段断言而是下沉到 ConfigMap 中实际生成的cruisecontrol.properties/server.config确保用户意图真正传递到了运行时配置。对于在生产环境中管理 Cruise Control 的开发者而言这套测试直观地回答了三个关键问题修改性能调优参数是否安全只会滚动 CC不影响 broker、能否在不删数据的前提下临时摘除 CC可以内部 Topic 会保留、重新启用后配置能否完整恢复能metric reporter 与内部 Topic 均回归。参考阅读测试实现CruiseControlConfigurationST.java验证工具CruiseControlUtils.java参数枚举CruiseControlConfigurationParameters.java配置默认值与目标过滤CruiseControlConfiguration.java组件模型CruiseControl.java部署示例kafka-cruise-control.yaml测试标签索引cruise-control.md【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Strimzi Kafka Operator 中 Cruise Control 配置管理验证实战：从配置热更新到动态部署/卸载的系统测试剖析
Strimzi Kafka Operator 中 Cruise Control 配置管理验证实战从配置热更新到动态部署/卸载的系统测试剖析【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator导读Cruise Control 是 Strimzi 为 Kafka 集群提供的自动化负载均衡与集群优化组件。本文以仓库内系统测试套件 CruiseControlConfigurationST 为核心深入剖析 Strimzi 如何端到端验证 Cruise Control 的配置管理能力——包括修改性能调优参数后仅滚动 Cruise Control 而不扰动 Kafka Broker以及在不删除内部 Topic 的前提下动态部署、卸载、重新部署 Cruise Control。读完本文你将掌握这套测试的设计思路、底层配置参数语义、验证手段以及如何在自己的 Kubernetes 环境中复现运行。一、测试套件定位验证什么、需要什么环境1.1 套件职责与声明根据测试套件的SuiteDoc注解见 CruiseControlConfigurationST.java本套件的职责描述为Description:This test suite, verify configuration of the Cruise Control component.即专门验证 Cruise Control 组件的配置行为。它覆盖两个核心场景| 测试方法 | 验证目标 | | - | - | |testConfigurationUpdate| 更新 Cruise Control 配置后Cruise Control Pod 滚动应用新配置而 Kafka Pod 不发生不必要的滚动 | |testDeployAndUnDeployCruiseControl| 动态部署、移除、再部署 Cruise Control验证系统稳定性与配置管理的正确性 |1.2 前置条件Cluster Operator套件声明的唯一前置步骤是安装并运行 Cluster Operator| Step | Action | Result | | - | - | - | | 1 | Set up the Cluster Operator | Cluster Operator is installed and running |这一点在源码中由BeforeAll阶段的setUp()方法落实——它调用SetupClusterOperator.getInstance().withDefaultConfiguration().install()安装默认配置的 Cluster Operator源码位置。1.3 测试标签与分类套件类与每个测试方法都声明了Tag(REGRESSION)和Tag(CRUISE_CONTROL)并标记ParallelNamespaceTest并行命名空间测试说明它可以与其他测试并行运行且归属于回归测试类别。在测试文档体系中它被收录在 cruise-control 标签页 下与 Cruise Control 的 API、Rebalance、日志、指标等测试共同构成完整的 Cruise Control 验证矩阵。二、testConfigurationUpdate配置更新后的精准滚动验证2.1 测试目标与完整步骤该测试的目标是验证 Cruise Control 配置更新后只有 Cruise Control 自身滚动Kafka 的 Broker/Controller Pod 不应当滚动。官方文档给出的完整步骤为| Step | Action | Result | | - | - | - | | 1 | Create broker and controller KafkaNodePools | Both KafkaNodePools are successfully created | | 2 | Create and wait for Kafka with Cruise Control | Kafka and Cruise Control are deployed successfully | | 3 | Take initial snapshots of Kafka and Cruise Control deployments | Snapshots of current deployments are stored | | 4 | Update Cruise Control configuration with new performance tuning options | Configuration update initiated | | 5 | Verify Cruise Control Pod rolls after configuration change | Cruise Control Pod restarts to apply new configurations | | 6 | Verify Kafka Pods did not roll after configuration change | Kafka Pods remain unchanged | | 7 | Verify new configurations are applied to Cruise Control in Kafka CR | New configurations are correctly applied |2.2 源码层面的执行细节在 CruiseControlConfigurationST.java 中测试的执行路径是创建 Broker 与 Controller 两类 KafkaNodePool各 3 副本通过KafkaNodePoolTemplates.brokerPool(...)与KafkaNodePoolTemplates.controllerPool(...)创建对应 KRaft 模式下的 dual-role 分离。部署带 Cruise Control 的 Kafka 集群使用KafkaTemplates.kafkaWithCruiseControl(...)生成 CR。记录基线快照PodUtils.podSnapshot记录 broker Pod 的 UID 快照DeploymentUtils.depSnapshot记录 Cruise Control Deployment 的副本快照作为后续滚动对比的基准。更新性能调优配置通过KafkaUtils.replace对 Kafka CR 执行原子替换写入如下 4 项参数见 CruiseControlConfigurationParameters.javaMapString, Object performanceTuningOpts new HashMap() {{ put(CruiseControlConfigurationParameters.CONCURRENT_INTRA_PARTITION_MOVEMENTS.getValue(), 2); put(CruiseControlConfigurationParameters.CONCURRENT_PARTITION_MOVEMENTS.getValue(), 5); put(CruiseControlConfigurationParameters.CONCURRENT_LEADER_MOVEMENTS.getValue(), 1000); put(CruiseControlConfigurationParameters.REPLICATION_THROTTLE.getValue(), -1); }};这四项参数对应的 Cruise Control 原生配置键为| 枚举 | 配置键 | 测试中写入的值 | 语义 | | - | - | - | - | |CONCURRENT_INTRA_PARTITION_MOVEMENTS|num.concurrent.intra.broker.partition.movements| 2 | 每个 Broker 上并发执行的 intra-broker 分区迁移数上限 | |CONCURRENT_PARTITION_MOVEMENTS|num.concurrent.partition.movements.per.broker| 5 | 每个 Broker 上并发执行的跨 Broker 分区迁移数上限 | |CONCURRENT_LEADER_MOVEMENTS|num.concurrent.leader.movements| 1000 | 并发 Leader 迁移数上限 | |REPLICATION_THROTTLE|default.replication.throttle| -1 | 默认复制限流值-1 表示不限流 |断言 Cruise Control Deployment 发生滚动DeploymentUtils.waitTillDepHasRolled等待 CC Deployment 的副本滚动完成。断言 Kafka 未发生滚动RollingUpdateUtils.waitForNoRollingUpdate校验 broker 快照未变化——这是整个测试最关键的断言证明 Cruise Control 的配置变更被隔离在 CC 组件内部不会触发 Kafka 集群无意义的全量滚动。在 ConfigMap 层面验证配置落盘读取 Cruise Control 的cruisecontrol.properties取自名为cluster-cruise-control-config的 ConfigMap将其加载为Properties再用 HamcresthasEntry逐一断言四项参数均已写入且值正确。2.3 底层原理为什么只滚动 Cruise Control从实现上看这一行为由 CruiseControl.java 与 CruiseControlConfiguration.java 共同保证默认属性使用有序 Map 生成DEFAULT_PROPERTIES_MAP被包装为Collections.unmodifiableSortedMap(new TreeMap(...))源码注释明确说明“map 必须排序使 Cruise Control 配置项顺序确定避免引起不必要的滚动更新”CruiseControlConfiguration.java。用户配置与默认值合并生成最终配置只有真正变化的配置才会导致 CC Deployment 的 ConfigMap 内容变化从而触发 CC 滚动Kafka Broker 的配置如 metrics reporter 配置只有在 CC 启停时才会变化因此本例中 Kafka Pod 完全不受影响。三、testDeployAndUnDeployCruiseControl动态部署与卸载的生命周期管理3.1 测试目标与完整步骤该测试验证的是在不停机、不删除 Cruise Control 内部 Topic 的前提下将 Cruise Control 从 Kafka 集群中移除再重新加回整个过程中集群配置被正确清理与恢复。官方文档步骤| Step | Action | Result | | - | - | - | | 1 | Create broker and controller KafkaNodePools | Both KafkaNodePools are successfully created | | 2 | Deploy Kafka with Cruise Control | Kafka cluster with Cruise Control is deployed | | 3 | Take a snapshot of broker pods | Snapshot of the current broker pods is taken | | 4 | Remove Cruise Control from Kafka | Cruise Control is removed from Kafka and configuration is updated | | 5 | Verify Cruise Control is removed | No Cruise Control related pods or configurations are found | | 6 | Create Admin client to verify Cruise Control topics | Admin client is created and Cruise Control topics are verified to exist | | 7 | Re-add Cruise Control to Kafka | Cruise Control is added back to Kafka | | 8 | Verify Cruise Control and related configurations | Cruise Control and its configurations are verified to be present |3.2 源码层面的执行细节见 CruiseControlConfigurationST.java。测试先创建 3 副本的 Broker/Controller NodePool并通过kafkaWithCruiseControl部署集群同时设置default.replication.factor3使后续创建的 CC Topic 也获得 3 副本。移除阶段通过KafkaUtils.replace将kafka.getSpec().setCruiseControl(null)随后依次断言Kafka CR 中 Cruise Control 已被清除getSpec().getCruiseControl()为nullCC Pod 消失waitUntilPodStabilityReplicasCount(..., 0)等待 CC Pod 副本归零Broker 配置中的 metric reporter 被移除assertThrows(WaitException.class, () - CruiseControlUtils.verifyCruiseControlMetricReporterConfigurationInKafkaConfigMapIsPresent(...))——即 Kafka ConfigMap 中不再包含cruise.control.metrics.*前缀的配置项读取时必然抛异常。验证 Topic 保留测试用KafkaAdminClientBuilder部署 Admin 客户端通过CruiseControlUtils.verifyThatCruiseControlTopicsArePresent确认三个 Cruise Control 内部 Topic 在卸载后依然存在于 Kafka 中关于这三个 Topic 见下文第四部分。重新部署阶段执行kafka.getSpec().setCruiseControl(new CruiseControlSpec())将 CC 加回等 broker 滚动完成后再次断言metric reporter 配置重新出现在 Kafka ConfigMap 中三个 Cruise Control Topic 仍存在。3.3 设计意图Topic 的生命周期策略这一测试揭示了一个重要的产品决策Cruise Control 卸载时其内部 Topicmetrics、model trainings、partition metrics samples不会被删除。从源码注释可以直接看到测试预期——“Cruise Control Topics will not be deleted and will stay in the Kafka cluster”源码。这样设计的好处是历史负载采样数据得以保留重新启用 Cruise Control 后可以无缝恢复其负载监控能力无需冷启动积累数据。四、配套验证工具 CruiseControlUtils 与内部 Topic 语义测试中大量复用 CruiseControlUtils.java它封装了 Cruise Control 的 API 调用与配置断言是理解该套件验证深度的钥匙。4.1 三个内部 Topic工具类中定义了 Cruise Control 的默认内部 Topic源码| 常量 | Topic 名称 | 分区数 | 副本数 | | - | - | - | - | |CRUISE_CONTROL_METRICS_TOPIC|strimzi.cruisecontrol.metrics| 1 | 跟随集群default.replication.factor测试中为 3 | |CRUISE_CONTROL_MODEL_TRAINING_SAMPLES_TOPIC|strimzi.cruisecontrol.modeltrainingsamples| 32 | 3 | |CRUISE_CONTROL_PARTITION_METRICS_SAMPLES_TOPIC|strimzi.cruisecontrol.partitionmetricsamples| 32 | 3 |对应的默认名称常量定义于 CruiseControlConfigurationParameters.java分别是DEFAULT_METRIC_REPORTER_TOPIC_NAME、DEFAULT_BROKER_METRIC_TOPIC_NAME、DEFAULT_PARTITION_METRIC_TOPIC_NAME。verifyThatCruiseControlTopicsArePresent不仅检查 Topic 存在还逐一校验分区数与副本数源码确保 CC 按预期规格创建了内部存储结构。4.2 metric reporter 配置断言verifyCruiseControlMetricReporterConfigurationInKafkaConfigMapIsPresent从 broker 的server.configKafka ConfigMap中筛选所有cruise.control.metrics前缀的配置项断言其满足cruise.control.metrics.topicstrimzi.cruisecontrol.metricscruise.control.metrics.topic.auto.createtruecruise.control.metrics.reporter.bootstrap.servers指向cluster-kafka-brokers:9091broker 内部通信端口安全协议、TLS 信任库${strimzisecrets:ns/cluster-trustbundle:cluster-ca.crt}、认证方式mTLS keystore 或 Service Account 的 SASL OAUTHBEARER与测试环境配置一致。这正是“卸载时清除、重装时恢复”断言的具体落点metric reporter 是 Cruise Control 与 Kafka 之间唯一的 broker 侧耦合点它的增删直接体现了配置管理的正确性。4.3 端口约定工具类还记录了 Cruise Control 的默认端口REST API 端口9090、指标端口9404并通过callApi在 CC Pod 内执行 curl 调用 API支持 HTTP/HTTPS、带/不带 admin 凭据为 API 类测试提供了基础能力。五、配置模型的源码级解析参数、默认值与目标过滤5.1 参数枚举全景operator-common/src/main/java/io/strimzi/operator/common/model/cruisecontrol/CruiseControlConfigurationParameters.java 是一个贯穿 operator-common、cluster-operator 与 systemtest 三个模块的核心枚举它把 Cruise Control 的原生配置键统一为类型安全常量。除性能调优参数外还包括| 类别 | 配置键示例 | 说明 | | - | - | - | | 采样窗口 |partition.metrics.window.ms、num.partition.metrics.windows、broker.metrics.window.ms、num.broker.metrics.windows| 负载监控器的指标聚合窗口大小与数量 | | 任务保留 |completed.user.task.retention.time.ms| 已完成用户任务的保留时长 | | Web 安全 |webserver.security.enable、webserver.auth.credentials.file、webserver.ssl.enable| API 鉴权与 TLS | | 采样 Topic |partition.metric.sample.store.topic、broker.metric.sample.store.topic、sample.store.topic.replication.factor| CC 内部存储结构 | | Goals |goals、default.goals、hard.goals、self.healing.goals、anomaly.detection.goals| 优化目标配置 | | Metrics reporter |cruise.control.metrics.reporter.*| broker 侧指标上报配置 |5.2 默认配置的生成逻辑CruiseControlConfiguration.java 的generateDefaultPropertiesMap在默认属性之上补充default.goals与hard.goals且会调用filterResourceGoalsWithoutCapacityConfig依据用户在 Kafka CR 中配置的容量capacity信息过滤目标——例如未配置入站网络容量时会移除NetworkInboundUsageDistributionGoal、NetworkInboundCapacityGoal与LeaderBytesInDistributionGoal源码。这一逻辑保证了默认 goals 始终与用户声明的容量配置自洽避免生成无法满足的优化目标。5.3 用户如何启用 Cruise Control生产中最常见的用法是在 Kafka CR 中声明cruiseControl段。仓库示例 kafka-cruise-control.yaml 展示了最简用法apiVersion: kafka.strimzi.io/v1 kind: Kafka metadata: name: my-cluster spec: # ... kafka 段、entityOperator 段等 cruiseControl: {}空对象即启用带全部默认值的 Cruise Control若需自定义则按测试中的写法在cruiseControl.config下提供键值对例如cruiseControl: config: num.concurrent.partition.movements.per.broker: 5 num.concurrent.intra.broker.partition.movements: 2 num.concurrent.leader.movements: 1000 default.replication.throttle: -1六、如何复现运行这套测试6.1 环境要求一个可用的 Kubernetes 集群本套件可并行运行于多个测试命名空间集群中已存在或可由测试安装的 Cluster OperatorBeforeAll会自动安装构建工具链Maven 与 JDK参考仓库根目录 Makefile.maven 中的mvn verify/mvn install流程。6.2 运行方式官方推荐的系统测试入口是 systemtest/scripts/run_tests.sh./systemtest/scripts/run_tests.sh io.strimzi.systemtest.cruisecontrol.CruiseControlConfigurationST systemtests脚本会以-pl systemtest -am构建 systemtest 模块及其依赖并注入-Dit.testTESTCASE指定测试类详见 run_tests.sh。也可以直接通过 Maven failsafe 运行mvn -B verify -pl systemtest -am -Psystemtests \ -DfailIfNoTestsfalse \ -Dit.testio.strimzi.systemtest.cruisecontrol.CruiseControlConfigurationST测试运行的整体规范集群准备、构建参数、报告收集可进一步参考 TESTING.md 与 DEV_GUIDE.md。七、相关测试与经验总结7.1 与 Cruise Control 测试矩阵的关系本套件是 Cruise Control 验证矩阵中的“配置管理”一环。从 cruise-control 标签页 可以看到围绕 Cruise Control 还覆盖了API 用户与基础请求CruiseControlApiST、Rebalance 状态流转与自动审批CruiseControlST、Broker 扩缩容期间行为、日志变更LogSettingST、指标暴露MetricsST等场景。CruiseControlConfigurationST与其互补前者关注“行为正确”本套件关注“配置正确”。7.2 可复用的工程实践从这套测试中可以提炼出三类可借鉴的验证模式变更影响面隔离断言testConfigurationUpdate同时断言“目标组件已滚动”与“非目标组件未滚动”用快照 diff 方式杜绝回归是配置类测试的标准范式动态启停的配置双向验证testDeployAndUnDeployCruiseControl对同一断言分别验证“存在”与“不存在”两种形态覆盖了清理逻辑移除后无残留配置与恢复逻辑重装后配置完整回归配置落盘级验证测试不止于 CR 层面的字段断言而是下沉到 ConfigMap 中实际生成的cruisecontrol.properties/server.config确保用户意图真正传递到了运行时配置。对于在生产环境中管理 Cruise Control 的开发者而言这套测试直观地回答了三个关键问题修改性能调优参数是否安全只会滚动 CC不影响 broker、能否在不删数据的前提下临时摘除 CC可以内部 Topic 会保留、重新启用后配置能否完整恢复能metric reporter 与内部 Topic 均回归。参考阅读测试实现CruiseControlConfigurationST.java验证工具CruiseControlUtils.java参数枚举CruiseControlConfigurationParameters.java配置默认值与目标过滤CruiseControlConfiguration.java组件模型CruiseControl.java部署示例kafka-cruise-control.yaml测试标签索引cruise-control.md【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考