2026/9/17 17:29:47
FEATURED · 精选文章 
Strimzi Kafka Operator Topic Operator 系统测试体系详解topic-operator 标签测试套件全解析【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator本文以 Strimzistrimzi-kafka-operator 仓库开发文档中的 topic-operator 标签页 为主线完整解读该标签下全部 14 个系统测试用例的覆盖范围、执行步骤与预期结果并结合 TopicST.java 与 TopicReplicasChangeST.java 等测试源码深入剖析 Topic Operator 在主题创建、变更、删除、故障恢复及性能容量场景下的行为边界。读完后你可以掌握如何用KafkaTopicCR 的 status/conditions 验证 Operator 行为、UTO 模式下的操作约束、与 Cruise Control 协作的副本因子变更机制以及容量/吞吐量性能测试的设计方法。一、标签文档的定位Topic Operator 测试覆盖清单development-docs/systemtests/labels/topic-operator.md 是系统测试文档站中按标签label聚合的索引页。其官方描述为These tests cover management of KafkaTopic resources by the Topic Operator. They verify topic creation, updates, deletion behavior, quota enforcement, and metrics to ensure reliable topic operations within a Kafka cluster.也就是说带topic-operator标签的测试共同覆盖Topic Operator 对KafkaTopic资源的全生命周期管理主题创建、更新、删除行为、配额约束以及指标metrics。该页的Tests清单为自动生成部分源文件中带有!-- generated part --注释共列出 14 个用例分布在 4 个测试类中| 测试类文档页 | 用例数 | 关注点 | | - | - | - | | TopicST | 8 | Topic Operator 通用功能与边界场景 | | TopicReplicasChangeST | 5 | 副本因子变更依赖 Cruise Control | | TopicOperatorPerformance | 1 | 容量上限capacity测试 | | TopicOperatorScalabilityPerformance | 1 | 并发场景下的吞吐量测试 |这 4 个页面同样是由测试源码中的注解生成的对应的实现文件为TopicST.java约 640 行TopicReplicasChangeST.java约 460 行TopicOperatorPerformance.javaTopicOperatorScalabilityPerformance.java二、测试环境共享 Kafka 集群的搭建方式理解各用例前先看测试套件的环境搭建。从 TopicST.java 的 setup() 方法 可以看到BeforeAll阶段会一次性部署供整个套件共享的环境安装 Cluster OperatorSetupClusterOperator.getInstance().withDefaultConfiguration().install()用 NodePool 方式部署 Kafka 集群3 个 broker 节点池 1 个 controller 节点池KafkaNodePoolTemplates.brokerPool(..., 3)与controllerPool(..., 1)在KafkaCR 的spec.entityOperator.topicOperator中设置reconciliationIntervalMs为TestConstants.RECONCILIATION_INTERVAL缩短调和周期以加速测试收敛部署一个scraper pod用于在集群内执行kafka-topics.sh等 CLI 命令核验主题真实状态与一个KafkaAdminClientDeployment提供AdminClient用于程序化断言主题是否存在。此外测试还会读取 Kafka CR 中配置的reconciliationIntervalMs并额外加 5 秒得到topicOperatorReconciliationIntervalMs作为等待下一轮调和的基准——这解释了为何多处断言前会先LockSupport.parkNanos(...)等待一段时间再复核 status 未变化。三、TopicST通用功能与边界场景详解3.1 创建/删除/重建循环testCreateDeleteCreate用例目标引自 TopicST.md反复创建、删除、重建KafkaTopic验证 CRD 层与 Kafka 层两侧的状态都正确。源码实现TopicST.java L153-L184的关键点创建一个replicas3的KafkaTopic用adminClient.listTopics()确认主题真实出现在 Kafka 中循环 10 次kubectl delete kafkatopic通过KubeResourceManager的 kubeCmdClient→ 等待删除 → 断言adminClient.listTopics()不再包含该主题 → 重新创建同名主题并等待就绪每轮之间插入 2 秒LockSupport.parkNanos避免操作过快导致状态竞争。3.2 副本数超过 broker 数testMoreReplicasThanAvailableBrokers创建一个replicas5, partitions5的主题而集群只有 3 个 broker。测试验证的核心是**Kafka 里不会创建该主题且错误会暴露到 CR status**断言hasTopicInCRK8s为真Kubernetes 里有 CRhasTopicInKafka为假Kafka 里没有主题等待KafkaTopic变为 NotReady 后读取status.conditions[0]断言其reason包含KafkaErrormessage匹配InvalidReplicationFactorException源码中同时保留了两版错误文案TopicST.java L117-L120Kafka 4.2 及以前为 ...only 3 broker(s) are registered.Kafka 4.3 及以后追加了 or some brokers have all their log directories cordoned.——这是随上游 Kafka 错误消息变化而做的兼容性断言最后删除坏主题再以replicas3重建验证两侧状态恢复正常。3.3 不支持的操作之后仍可创建新主题testCreateTopicAfterUnsupportedOperationKafka 本身不允许减少分区数或副本数。该用例TopicST.java L329-L369验证创建partitions3, replicas3的主题并等待 Ready将 spec 同时改为replicas1, partitions1等待 NotReady并断言 status 条件消息恰好为Decreasing partitions not supported在失败操作存在的前提下再创建一个全新的合法主题验证 Topic Operator 没有被卡死新主题正常 Ready清理两个主题。这一用例证明单个资源的调和失败不会阻塞 Operator 对其他KafkaTopic的处理。3.4 delete.topic.enablefalse 时的删除行为testDeleteTopicEnableFalse该用例TopicST.java L241-L314单独部署了一个独立 Kafka 集群IsolatedTest(Using more tha one Kafka cluster in one namespace)在kafka.config中设置delete.topic.enablefalse步骤为创建主题并确认真实存在用 producer/consumer Job 收发一批消息以DeletionPropagation.FOREGROUND方式删除KafkaTopic断言 status 中出现TopicDeletionDisabledException——即删除被 Kafka 拒绝错误如实反映到 CR再次消费证明期间数据未丢失通过KafkaUtils.replace将delete.topic.enable改为true等待 broker 滚动更新完成后删除主题验证删除成功。3.5 无效 min.insync.replicas 的状态处理testKafkaTopicChangingMinInSyncReplicas将主题的config[min.insync.replicas]设为非法值x断言TopicST.java L490-L513KafkaTopic进入 NotReady条件reasonKafkaErrormessage为Invalid value x for configuration min.insync.replicas再等待一个完整调和周期后复核错误状态持续存在错误不会被自愈地清空而是持续提示用户修复 spec。3.6 向不存在主题发消息触发自建testSendingMessagesToNonExistingTopic前提是该集群启用了 Kafka 的auto.create.topics。测试先确认目标主题不存在然后提交一个 producer/consumer Job 直接向该主题生产/消费消息最终断言主题出现在adminClient中TopicST.java L198-L225。它验证的是 Operator 生态与 Kafka 内建自动建主题能力共存的场景自动建出的主题不会与KafkaTopicCR 管理产生冲突。3.7 无标签的 KafkaTopic 会被忽略testTopicWithoutLabelsStrimzi 通过标签约定决定哪些资源由 Operator 管理。该用例TopicST.java L528-L577单独部署了一个reconciliationIntervalMs10_000的集群创建metadata.labels为空的KafkaTopic然后验证三点CR 在 Kubernetes 中存在但 Kafka 中不会出现该主题等待超过调和周期后复核Entity Operator 的topic-operator容器日志中不包含Created topic topicName字样删除 CR 后Kafka 内依然没有该主题。注意断言里用到了Labels.STRIMZI_NAME_LABEL来自 operator-common 模块来定位 Entity Operator Pod这从侧面印证了 Operator 生态中标签即管理边界的约定。四、UTO 模式下的行为约束与指标testKafkaTopicDifferentStatesInUTOMode这是 TopicST 中最能体现 Strimzi 设计取舍的用例TopicST.java L392-L476。所谓UTO 模式即不配置 Cruise Control、由 Topic Operator 直接执行变更的模式。测试逐步验证了该模式下哪些变更不允许以及 status 与 Prometheus 指标如何一致地反映这些约束| 变更动作 | 预期结果 | | - | - | | 修改spec.topicName| NotReadyreasonNotSupportedmessageChanging spec.topicName is not supported| | 增大replicas1→12 | NotReadymessageReplication factor change not supported无 CC 时 UTO 不支持改副本 | | 减小partitions| NotReadymessageDecreasing partitions not supported| | 恢复为合法默认值 | 重新 Ready |指标侧的断言同样值得注意strimzi_reconciliations_successful_total{kindKafkaTopic}、strimzi_reconciliations_duration_seconds_bucket{...}、strimzi_reconciliations_duration_seconds_max{...}、strimzi_reconciliations_total{...}均非空且 KafkaTopic 的资源计数 ≥ 1全部非法变更结束后strimzi_reconciliations_failed_total{kindKafkaTopic}≥ 3与上面 3 次失败变更一一对应。断言辅助方法assertKafkaTopicStatusTopicST.java L583-L597同时校验conditions的 type/status、reason、message以及observedGeneration是否随每次 spec 变更递增——这是验证 Operator 确实观察到了新版 spec 的标准手法。五、TopicReplicasChangeST副本因子变更与 Cruise Control 协作TopicReplicasChangeST 整个套件带有Tag(REGRESSION)和Tag(CRUISE_CONTROL)两个标签前置环境是带 Cruise Control 且 Topic Operator 快速调和的 Kafka 集群 scraper pod见 TopicReplicasChangeST.md 的 Before test execution steps。类注释明确说明了测试意图验证副本因子调高的正向/负向场景以及 Cruise Control 或 Entity Operator 崩溃期间的变更恢复能力。5.1 新建主题即超过 broker 数testMoreReplicasThanAvailableBrokersWithFreshKafkaTopic与 TopicST 中的同名兄弟用例相比这里多了对CC 协作链路的验证TopicReplicasChangeST.java L97-L140replicas5 3 brokers时主题只存在于 Kubernetesstatus reason 为KafkaErrormessage 为两版InvalidReplicationFactorException文案之一同样区分 Kafka 4.2/4.3 的错误措辞关键断言此时replicaChangestatus不存在——源码注释解释了原因UTO failed on reconciliation, so it does not create a POST request to CC即创建失败时根本不应向 Cruise Control 发起副本变更请求将replicas修正为 3 并等待调和后waitForReplicaChangeStatusNotPresent确认变更完成随后用verifyKafkaTopicAfterReplicationChange校验副本数与 generation最后通过sendAndRecvMessages收发真实消息证明主题可用。5.2 正向往返变更testKafkaTopicReplicaChangePositiveRoundTrip副本因子 2 → 3 → 2 的完整往返TopicReplicasChangeST.java L154 起。流程要点先waitUntilTopicObservationGenerationIsPresent并记录observedGeneration作为变更前的基线replace修改spec.replicas后调用waitUntilReplicaChangeResolved等待 Cruise Control 完成副本迁移任务再断言replicaChangestatus 消失verifyKafkaTopicAfterReplicationChange复核最终副本数、status 与 generation。先记录 observedGeneration、变更完成后校验其递增的模式贯穿整个套件是验证调和确实发生而非碰巧一致的关键。5.3 崩溃恢复Cruise Control 与 Entity OperatortestRecoveryOfReplicationChangeDuringCcCrash与testRecoveryOfReplicationChangeDuringEoCrash两个用例见 TopicReplicasChangeST.md验证组件级故障恢复| 用例 | 故障注入 | 预期恢复 | | - | - | - | | testRecoveryOfReplicationChangeDuringCcCrash | 在副本变更进行中杀掉 Cruise Control Pod | CC 恢复后变更继续完成replicaChangestatus 清除主题 Ready | | testRecoveryOfReplicationChangeDuringEoCrash | 在副本变更进行中杀掉 Entity Operator Pod | EO 恢复后副本因子仍被正确应用主题 Ready |这两个用例从系统层面证明了进行中的副本因子变更是幂等且可重入的是 Topic Operator 弹性resilience测试的核心。六、性能与容量测试标签页清单中的最后两个用例位于 performance 测试包文档页分别为 TopicOperatorPerformance.md 与 TopicOperatorScalabilityPerformance.md。6.1 testCapacity容量上限探测部署一个按指定 batch size 与 linger time 配置 Topic Operator 的 Kafka 集群每批创建 100 个KafkaTopic每个 12 分区、3 副本启动指标采集后持续加批直到 Topic Operator 调和失败从而逼近可管理主题的容量上限失败后用TestLogCollector按自定义资源清单收集范围受限的日志pods、deployments、configmaps、Kafka CR——文档特别指出这样做是为了避免收集数千个KafkaTopicCR 与 Secret清理全部主题并把性能数据持久化到 topic-operator 报告目录。6.2 testScalability吞吐量度量该用例明确区分了吞吐量与延迟度量的是N 个主题并行完成全部操作所需总时间THROUGHPUT而非单个主题的响应延迟LATENCY。设计如下对每组规模10、100、500、1000 个主题每个KafkaTopic分配一个独立线程每线程执行完整生命周期CREATE指定分区/副本→ MODIFY更新 topic 配置并等待调和→ DELETE全部线程完成后统计总耗时清理残留主题连同总调和时间等指标一起写入 topic-operator 报告目录。从这两套测试的设计可以看出仓库对性能数据的定位它们是可复现的基准benchmark流程关注随主题规模增长的调和吞吐与失败边界而不是发布营销式数字。七、文档与源码的联动标签页是如何生成的回看 topic-operator.md 可以发现两个工程事实Tests 清单是自动生成的!-- generated part --标记其内容与源码中的注解严格对应每个测试类上的SuiteDoc(description, labels)与每个方法上的TestDoc(description, steps, labels)注解如 TopicST.java L79-L84 的SuiteDoclabel 常量则来自TestDocsLabels.TOPIC_OPERATORsystemtest/src/test/java/io/strimzi/systemtest/docs/TestDocsLabels.java测试类通过 JUnit 5 的Tag区分执行批次功能用例带REGRESSION标签副本变更套件额外带CRUISE_CONTROL标签TopicReplicasChangeST.java L51-L52标签选择器相关定义见 LabelSelectors.java。因此阅读标签页实际上就是阅读一份由注解驱动、与源码保持同步的测试地图修改测试时同步更新TestDoc注解文档站即会重新生成对应页面与标签索引。八、小结topic-operator 标签页 背后的 14 个用例构成了对 Topic Operator 的完整验证矩阵功能正确性创建/删除循环、非法 spec 的拒绝与错误透出副本超 broker 数、非法min.insync.replicas、减少分区/改 topicName状态机一致性status.conditions的 reason/message 与observedGeneration、Prometheus 指标strimzi_reconciliations_*三处必须相互印证与 Cruise Control 的协作合法副本变更经 CC 任务完成创建失败时不得向 CC 发请求CC/EO 崩溃后变更可恢复管理与隔离语义无标签资源被忽略、delete.topic.enablefalse时删除受阻、自动建主题共存规模化验证容量上限探测与 10~1000 主题并发吞吐测试。对使用者而言这些测试也是最佳行为参考手册当你在线上遇到KafkaTopicNotReady 时本文引用的 reason/message 文案如KafkaError、NotSupported、Decreasing partitions not supported、TopicDeletionDisabledException正是 status 中会出现的原始信息可直接对照定位问题。【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Strimzi Kafka Operator Topic Operator 系统测试体系详解：topic-operator 标签测试套件全解析
Strimzi Kafka Operator Topic Operator 系统测试体系详解topic-operator 标签测试套件全解析【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator本文以 Strimzistrimzi-kafka-operator 仓库开发文档中的 topic-operator 标签页 为主线完整解读该标签下全部 14 个系统测试用例的覆盖范围、执行步骤与预期结果并结合 TopicST.java 与 TopicReplicasChangeST.java 等测试源码深入剖析 Topic Operator 在主题创建、变更、删除、故障恢复及性能容量场景下的行为边界。读完后你可以掌握如何用KafkaTopicCR 的 status/conditions 验证 Operator 行为、UTO 模式下的操作约束、与 Cruise Control 协作的副本因子变更机制以及容量/吞吐量性能测试的设计方法。一、标签文档的定位Topic Operator 测试覆盖清单development-docs/systemtests/labels/topic-operator.md 是系统测试文档站中按标签label聚合的索引页。其官方描述为These tests cover management of KafkaTopic resources by the Topic Operator. They verify topic creation, updates, deletion behavior, quota enforcement, and metrics to ensure reliable topic operations within a Kafka cluster.也就是说带topic-operator标签的测试共同覆盖Topic Operator 对KafkaTopic资源的全生命周期管理主题创建、更新、删除行为、配额约束以及指标metrics。该页的Tests清单为自动生成部分源文件中带有!-- generated part --注释共列出 14 个用例分布在 4 个测试类中| 测试类文档页 | 用例数 | 关注点 | | - | - | - | | TopicST | 8 | Topic Operator 通用功能与边界场景 | | TopicReplicasChangeST | 5 | 副本因子变更依赖 Cruise Control | | TopicOperatorPerformance | 1 | 容量上限capacity测试 | | TopicOperatorScalabilityPerformance | 1 | 并发场景下的吞吐量测试 |这 4 个页面同样是由测试源码中的注解生成的对应的实现文件为TopicST.java约 640 行TopicReplicasChangeST.java约 460 行TopicOperatorPerformance.javaTopicOperatorScalabilityPerformance.java二、测试环境共享 Kafka 集群的搭建方式理解各用例前先看测试套件的环境搭建。从 TopicST.java 的 setup() 方法 可以看到BeforeAll阶段会一次性部署供整个套件共享的环境安装 Cluster OperatorSetupClusterOperator.getInstance().withDefaultConfiguration().install()用 NodePool 方式部署 Kafka 集群3 个 broker 节点池 1 个 controller 节点池KafkaNodePoolTemplates.brokerPool(..., 3)与controllerPool(..., 1)在KafkaCR 的spec.entityOperator.topicOperator中设置reconciliationIntervalMs为TestConstants.RECONCILIATION_INTERVAL缩短调和周期以加速测试收敛部署一个scraper pod用于在集群内执行kafka-topics.sh等 CLI 命令核验主题真实状态与一个KafkaAdminClientDeployment提供AdminClient用于程序化断言主题是否存在。此外测试还会读取 Kafka CR 中配置的reconciliationIntervalMs并额外加 5 秒得到topicOperatorReconciliationIntervalMs作为等待下一轮调和的基准——这解释了为何多处断言前会先LockSupport.parkNanos(...)等待一段时间再复核 status 未变化。三、TopicST通用功能与边界场景详解3.1 创建/删除/重建循环testCreateDeleteCreate用例目标引自 TopicST.md反复创建、删除、重建KafkaTopic验证 CRD 层与 Kafka 层两侧的状态都正确。源码实现TopicST.java L153-L184的关键点创建一个replicas3的KafkaTopic用adminClient.listTopics()确认主题真实出现在 Kafka 中循环 10 次kubectl delete kafkatopic通过KubeResourceManager的 kubeCmdClient→ 等待删除 → 断言adminClient.listTopics()不再包含该主题 → 重新创建同名主题并等待就绪每轮之间插入 2 秒LockSupport.parkNanos避免操作过快导致状态竞争。3.2 副本数超过 broker 数testMoreReplicasThanAvailableBrokers创建一个replicas5, partitions5的主题而集群只有 3 个 broker。测试验证的核心是**Kafka 里不会创建该主题且错误会暴露到 CR status**断言hasTopicInCRK8s为真Kubernetes 里有 CRhasTopicInKafka为假Kafka 里没有主题等待KafkaTopic变为 NotReady 后读取status.conditions[0]断言其reason包含KafkaErrormessage匹配InvalidReplicationFactorException源码中同时保留了两版错误文案TopicST.java L117-L120Kafka 4.2 及以前为 ...only 3 broker(s) are registered.Kafka 4.3 及以后追加了 or some brokers have all their log directories cordoned.——这是随上游 Kafka 错误消息变化而做的兼容性断言最后删除坏主题再以replicas3重建验证两侧状态恢复正常。3.3 不支持的操作之后仍可创建新主题testCreateTopicAfterUnsupportedOperationKafka 本身不允许减少分区数或副本数。该用例TopicST.java L329-L369验证创建partitions3, replicas3的主题并等待 Ready将 spec 同时改为replicas1, partitions1等待 NotReady并断言 status 条件消息恰好为Decreasing partitions not supported在失败操作存在的前提下再创建一个全新的合法主题验证 Topic Operator 没有被卡死新主题正常 Ready清理两个主题。这一用例证明单个资源的调和失败不会阻塞 Operator 对其他KafkaTopic的处理。3.4 delete.topic.enablefalse 时的删除行为testDeleteTopicEnableFalse该用例TopicST.java L241-L314单独部署了一个独立 Kafka 集群IsolatedTest(Using more tha one Kafka cluster in one namespace)在kafka.config中设置delete.topic.enablefalse步骤为创建主题并确认真实存在用 producer/consumer Job 收发一批消息以DeletionPropagation.FOREGROUND方式删除KafkaTopic断言 status 中出现TopicDeletionDisabledException——即删除被 Kafka 拒绝错误如实反映到 CR再次消费证明期间数据未丢失通过KafkaUtils.replace将delete.topic.enable改为true等待 broker 滚动更新完成后删除主题验证删除成功。3.5 无效 min.insync.replicas 的状态处理testKafkaTopicChangingMinInSyncReplicas将主题的config[min.insync.replicas]设为非法值x断言TopicST.java L490-L513KafkaTopic进入 NotReady条件reasonKafkaErrormessage为Invalid value x for configuration min.insync.replicas再等待一个完整调和周期后复核错误状态持续存在错误不会被自愈地清空而是持续提示用户修复 spec。3.6 向不存在主题发消息触发自建testSendingMessagesToNonExistingTopic前提是该集群启用了 Kafka 的auto.create.topics。测试先确认目标主题不存在然后提交一个 producer/consumer Job 直接向该主题生产/消费消息最终断言主题出现在adminClient中TopicST.java L198-L225。它验证的是 Operator 生态与 Kafka 内建自动建主题能力共存的场景自动建出的主题不会与KafkaTopicCR 管理产生冲突。3.7 无标签的 KafkaTopic 会被忽略testTopicWithoutLabelsStrimzi 通过标签约定决定哪些资源由 Operator 管理。该用例TopicST.java L528-L577单独部署了一个reconciliationIntervalMs10_000的集群创建metadata.labels为空的KafkaTopic然后验证三点CR 在 Kubernetes 中存在但 Kafka 中不会出现该主题等待超过调和周期后复核Entity Operator 的topic-operator容器日志中不包含Created topic topicName字样删除 CR 后Kafka 内依然没有该主题。注意断言里用到了Labels.STRIMZI_NAME_LABEL来自 operator-common 模块来定位 Entity Operator Pod这从侧面印证了 Operator 生态中标签即管理边界的约定。四、UTO 模式下的行为约束与指标testKafkaTopicDifferentStatesInUTOMode这是 TopicST 中最能体现 Strimzi 设计取舍的用例TopicST.java L392-L476。所谓UTO 模式即不配置 Cruise Control、由 Topic Operator 直接执行变更的模式。测试逐步验证了该模式下哪些变更不允许以及 status 与 Prometheus 指标如何一致地反映这些约束| 变更动作 | 预期结果 | | - | - | | 修改spec.topicName| NotReadyreasonNotSupportedmessageChanging spec.topicName is not supported| | 增大replicas1→12 | NotReadymessageReplication factor change not supported无 CC 时 UTO 不支持改副本 | | 减小partitions| NotReadymessageDecreasing partitions not supported| | 恢复为合法默认值 | 重新 Ready |指标侧的断言同样值得注意strimzi_reconciliations_successful_total{kindKafkaTopic}、strimzi_reconciliations_duration_seconds_bucket{...}、strimzi_reconciliations_duration_seconds_max{...}、strimzi_reconciliations_total{...}均非空且 KafkaTopic 的资源计数 ≥ 1全部非法变更结束后strimzi_reconciliations_failed_total{kindKafkaTopic}≥ 3与上面 3 次失败变更一一对应。断言辅助方法assertKafkaTopicStatusTopicST.java L583-L597同时校验conditions的 type/status、reason、message以及observedGeneration是否随每次 spec 变更递增——这是验证 Operator 确实观察到了新版 spec 的标准手法。五、TopicReplicasChangeST副本因子变更与 Cruise Control 协作TopicReplicasChangeST 整个套件带有Tag(REGRESSION)和Tag(CRUISE_CONTROL)两个标签前置环境是带 Cruise Control 且 Topic Operator 快速调和的 Kafka 集群 scraper pod见 TopicReplicasChangeST.md 的 Before test execution steps。类注释明确说明了测试意图验证副本因子调高的正向/负向场景以及 Cruise Control 或 Entity Operator 崩溃期间的变更恢复能力。5.1 新建主题即超过 broker 数testMoreReplicasThanAvailableBrokersWithFreshKafkaTopic与 TopicST 中的同名兄弟用例相比这里多了对CC 协作链路的验证TopicReplicasChangeST.java L97-L140replicas5 3 brokers时主题只存在于 Kubernetesstatus reason 为KafkaErrormessage 为两版InvalidReplicationFactorException文案之一同样区分 Kafka 4.2/4.3 的错误措辞关键断言此时replicaChangestatus不存在——源码注释解释了原因UTO failed on reconciliation, so it does not create a POST request to CC即创建失败时根本不应向 Cruise Control 发起副本变更请求将replicas修正为 3 并等待调和后waitForReplicaChangeStatusNotPresent确认变更完成随后用verifyKafkaTopicAfterReplicationChange校验副本数与 generation最后通过sendAndRecvMessages收发真实消息证明主题可用。5.2 正向往返变更testKafkaTopicReplicaChangePositiveRoundTrip副本因子 2 → 3 → 2 的完整往返TopicReplicasChangeST.java L154 起。流程要点先waitUntilTopicObservationGenerationIsPresent并记录observedGeneration作为变更前的基线replace修改spec.replicas后调用waitUntilReplicaChangeResolved等待 Cruise Control 完成副本迁移任务再断言replicaChangestatus 消失verifyKafkaTopicAfterReplicationChange复核最终副本数、status 与 generation。先记录 observedGeneration、变更完成后校验其递增的模式贯穿整个套件是验证调和确实发生而非碰巧一致的关键。5.3 崩溃恢复Cruise Control 与 Entity OperatortestRecoveryOfReplicationChangeDuringCcCrash与testRecoveryOfReplicationChangeDuringEoCrash两个用例见 TopicReplicasChangeST.md验证组件级故障恢复| 用例 | 故障注入 | 预期恢复 | | - | - | - | | testRecoveryOfReplicationChangeDuringCcCrash | 在副本变更进行中杀掉 Cruise Control Pod | CC 恢复后变更继续完成replicaChangestatus 清除主题 Ready | | testRecoveryOfReplicationChangeDuringEoCrash | 在副本变更进行中杀掉 Entity Operator Pod | EO 恢复后副本因子仍被正确应用主题 Ready |这两个用例从系统层面证明了进行中的副本因子变更是幂等且可重入的是 Topic Operator 弹性resilience测试的核心。六、性能与容量测试标签页清单中的最后两个用例位于 performance 测试包文档页分别为 TopicOperatorPerformance.md 与 TopicOperatorScalabilityPerformance.md。6.1 testCapacity容量上限探测部署一个按指定 batch size 与 linger time 配置 Topic Operator 的 Kafka 集群每批创建 100 个KafkaTopic每个 12 分区、3 副本启动指标采集后持续加批直到 Topic Operator 调和失败从而逼近可管理主题的容量上限失败后用TestLogCollector按自定义资源清单收集范围受限的日志pods、deployments、configmaps、Kafka CR——文档特别指出这样做是为了避免收集数千个KafkaTopicCR 与 Secret清理全部主题并把性能数据持久化到 topic-operator 报告目录。6.2 testScalability吞吐量度量该用例明确区分了吞吐量与延迟度量的是N 个主题并行完成全部操作所需总时间THROUGHPUT而非单个主题的响应延迟LATENCY。设计如下对每组规模10、100、500、1000 个主题每个KafkaTopic分配一个独立线程每线程执行完整生命周期CREATE指定分区/副本→ MODIFY更新 topic 配置并等待调和→ DELETE全部线程完成后统计总耗时清理残留主题连同总调和时间等指标一起写入 topic-operator 报告目录。从这两套测试的设计可以看出仓库对性能数据的定位它们是可复现的基准benchmark流程关注随主题规模增长的调和吞吐与失败边界而不是发布营销式数字。七、文档与源码的联动标签页是如何生成的回看 topic-operator.md 可以发现两个工程事实Tests 清单是自动生成的!-- generated part --标记其内容与源码中的注解严格对应每个测试类上的SuiteDoc(description, labels)与每个方法上的TestDoc(description, steps, labels)注解如 TopicST.java L79-L84 的SuiteDoclabel 常量则来自TestDocsLabels.TOPIC_OPERATORsystemtest/src/test/java/io/strimzi/systemtest/docs/TestDocsLabels.java测试类通过 JUnit 5 的Tag区分执行批次功能用例带REGRESSION标签副本变更套件额外带CRUISE_CONTROL标签TopicReplicasChangeST.java L51-L52标签选择器相关定义见 LabelSelectors.java。因此阅读标签页实际上就是阅读一份由注解驱动、与源码保持同步的测试地图修改测试时同步更新TestDoc注解文档站即会重新生成对应页面与标签索引。八、小结topic-operator 标签页 背后的 14 个用例构成了对 Topic Operator 的完整验证矩阵功能正确性创建/删除循环、非法 spec 的拒绝与错误透出副本超 broker 数、非法min.insync.replicas、减少分区/改 topicName状态机一致性status.conditions的 reason/message 与observedGeneration、Prometheus 指标strimzi_reconciliations_*三处必须相互印证与 Cruise Control 的协作合法副本变更经 CC 任务完成创建失败时不得向 CC 发请求CC/EO 崩溃后变更可恢复管理与隔离语义无标签资源被忽略、delete.topic.enablefalse时删除受阻、自动建主题共存规模化验证容量上限探测与 10~1000 主题并发吞吐测试。对使用者而言这些测试也是最佳行为参考手册当你在线上遇到KafkaTopicNotReady 时本文引用的 reason/message 文案如KafkaError、NotSupported、Decreasing partitions not supported、TopicDeletionDisabledException正是 status 中会出现的原始信息可直接对照定位问题。【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
