Strimzi Kafka Operator connect 标签系统测试索引:测试范围、自动生成机制与运行方式

Strimzi Kafka Operator connect 标签系统测试索引:测试范围、自动生成机制与运行方式

【免费下载链接】strimzi-kafka-operator Apache Kafka® running on Kubernetes 项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator

本文以 Strimzi Kafka Operator 仓库中的系统测试标签索引文档 connect.md 为主体,完整梳理该标签下覆盖的 34 个 Kafka Connect 系统测试的测试范围与场景划分,并结合同仓库的 systemtest/pom.xml、标签常量定义与测试源码,讲清这份索引的自动生成机制与使用方法。读完后,你将能够:准确判断某个 Connect 相关行为变更应回归哪些系统测试、通过标签筛选并运行对应测试集,以及理解每个测试项背后验证的 Kafka Connect 能力边界(插件构建、扩缩容、认证安全、偏移量管理等)。

一、这份文档是什么:connect 测试标签索引

connect.md 是 Strimzi 系统测试(systemtest)子项目中按“标签(label)”组织的一组测试索引页之一,与同目录下的 bridge.md、kafka.md、metrics.md、security.md 等 12 份标签索引文件并列存放于 development-docs/systemtests/labels/ 目录。

文档由两部分构成:

清单中的每个条目都指向按测试类组织的单页文档,例如:

• io.strimzi.systemtest.connect.ConnectST.md——Kafka Connect 主测试套件,含部署/滚动更新/卸载、扩缩容、认证、偏移量管理等 19 个测试;
• io.strimzi.systemtest.connect.ConnectBuilderST.md——Connect Builder 插件构建与镜像推送测试,含 7 个测试;
• 以及散落在其他测试类中但同样与 Connect 相关、被打上 connect 标签的测试,如 CustomResourceStatusST.md、MetricsST.md、LogSettingST.md、ClusterOperatorRbacST.md、MultipleClusterOperatorsST.md、ReconciliationST.md。

这种“一个标签聚合跨测试类的相关用例”的组织方式,使回归时不必关心测试分布在哪个类里,只需按业务主题(这里是 connect)整组筛选。

二、自动生成机制:test-docs-generator 插件

2.1 插件配置

在 systemtest/pom.xml#L312-L331 中,Maven 构建绑定了 io.skodjob:test-docs-generator-maven-plugin,其关键配置为:

<plugin>
<groupId>io.skodjob</groupId>
<artifactId>test-docs-generator-maven-plugin</artifactId>
<version>${skodjob-doc.version}</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>test-docs-generator</goal>
</goals>
</execution>
</executions>
<configuration>
<testsPath>${project.basedir}/src/test/java/io/strimzi/systemtest</testsPath>
<docsPath>${strimziRootDirectory}/development-docs/systemtests/</docsPath>
<generateFmf>false</generateFmf>
<generateDirs>false</generateDirs>
<includeDependencies>true</includeDependencies>
</configuration>
</plugin>

由此可以确认以下实现事实:

• 生成时机:插件绑定在 install 阶段,即执行 mvn install 构建 systemtest 模块时,扫描 testsPath(systemtest/src/test/java/io/strimzi/systemtest)下的测试源码,将结果写入 docsPath(仓库根目录下的 development-docs/systemtests/)。
• 输出形态:每个测试类生成一份 <全限定类名>.md 文档页(含 Description、前置步骤、Steps 步骤表和 Labels),每个标签生成一份 labels/<标签名>.md 聚合索引。connect.md 正是 connect 标签的产物。
• includeDependencies=true 意味着测试所依赖的前置条件等描述也会一并纳入生成文档。

这也解释了为什么文档里带有 <!– generated part –> 注释——它是生成器写入的分界标记,开发者修改测试代码后重新构建即可刷新索引,而无需手工维护链接清单。

2.2 标签常量与注解:connect 标签的声明位置

标签在源码中有两处平行的定义,分工不同:

public interface TestDocsLabels {
String KAFKA = "kafka";
String BRIDGE = "bridge";
String CONNECT = "connect";
…
}

该类注释说明这些常量用于 @SuiteDoc#labels() 或 @TestDoc#labels() 注解,即专供文档生成器读取。

在测试类中,标签通过 skodjob 注解声明。以 ConnectST.java#L120-L126 为例,类上带 @SuiteDoc 与 @Label(value = TestDocsLabels.CONNECT);每个测试方法上则带 @TestDoc 及相同的 @Label(value = TestDocsLabels.CONNECT)。正是这些注解驱动了 connect.md 中测试清单的生成——文档里出现的 34 个测试名,与源码中打了 connect 标签的测试方法一一对应,例如 ConnectST 中的 testDeployRollUndeploy(第 148 行)、testConnectorOffsetManagement(第 1809 行)等。

三、测试范围:34 个测试按主题拆解

将索引中的 34 个测试按验证目标归类,可以得到如下全景,这也是“connect 标签”对 Kafka Connect 能力覆盖面的真实写照。

3.1 生命周期、扩缩容与多节点

• testDeployRollUndeploy(ConnectST.java#L148):部署、手动滚动更新、卸载的完整生命周期。其单页文档(ConnectST.md)的套件描述为“验证 Kafka Connect 组件的部署、手动滚动更新与卸载”,前置步骤是部署一个用于访问其他 Pod 的 scraper Pod;
• testKafkaConnectScaleUpScaleDown:副本数横向扩缩容;
• testScaleConnectWithoutConnectorToZero / testScaleConnectWithConnectorToZero:分别在没有连接器、有连接器两种情况下把 KafkaConnect 缩容到 0,验证连接器状态与数据在缩容/扩容过程中的行为;
• testScaleConnectAndConnectorSubresource:同时调整 KafkaConnect 副本与 KafkaConnector 任务的 subresource 配置;
• testMultiNodeKafkaConnectWithConnectorCreation:多节点 KafkaConnect 集群上创建连接器的行为。

3.2 插件管理与 Connect Builder

Connect Builder 是 Strimzi 用于按声明式规格(KafkaConnect 中的插件配置)自动构建 Connect 镜像的功能,对应测试集中在 ConnectBuilderST.java:

• testBuildFailsWithWrongChecksumOfArtifact(L191):制品 checksum 错误时构建必须失败,验证完整性校验;
• testBuildWithJarTgzAndZip(L276):同时提供 jar、tgz、zip 多种形态的插件制品;
• testBuildPluginUsingMavenCoordinatesArtifacts(L645):以 Maven 坐标形式声明插件制品并构建;
• testBuildOtherPluginTypeWithAndWithoutFileName(L574):其他插件类型、带与不带文件名的两种声明方式;
• testMountPluginUsingImageVolume(L348):通过镜像卷挂载插件(mountedPlugin 类场景),而非打进镜像;
• testPushIntoImageStream(L417):将构建产物推送到 ImageStream(OpenShift 场景);
• testUpdateConnectWithAnotherPlugin(L472):已有 Connect 部署后更换插件的更新流程;
• testKafkaConnectAndConnectorFileSinkPlugin(ConnectST.java#L374):使用 File Sink 连接器验证插件加载与数据落盘,是多个测试复用的基础场景。

3.3 安全与认证

覆盖 TLS、SCRAM-SHA 与“奇怪用户名”等边界场景:

• testKafkaConnectWithPlainAndScramShaAuthentication(ConnectST.java#L273):PLAIN 与 SCRAM-SHA 两种客户端认证;
• testSecretsWithKafkaConnectWithTlsAndTlsClientAuthentication(L551)与 testSecretsWithKafkaConnectWithTlsAndScramShaAuthentication(L661):分别验证 TLS + 双向 TLS 客户端认证、TLS + SCRAM-SHA 的 Secret 处理;
• testConnectTlsAuthWithWeirdUserName(L1059)与 testConnectScramShaAuthWithWeirdUserName(L1155):用户名包含特殊字符时的认证正确性;
• testKafkaConnectWithScramShaAuthenticationRolledAfterPasswordChanged(L1659):密码变更后通过滚动重启使新凭据生效。

3.4 连接器运行时:偏移量管理与任务自动重启

这是两个最能体现 Strimzi 对 KafkaConnector 资源语义扩展的测试:

testConnectorOffsetManagement(ConnectST.java#L1809)。据 ConnectST.md 中对该测试的完整步骤描述,它验证偏移量管理的三种操作 list、alter、reset,关键机制包括:

• 通过 KafkaConnector 上的 strimzi.io/connector-offsets 注解触发操作(取值 list / alter / reset),操作完成后注解会被移除;
• list 时由集群 Operator 创建一个 ConfigMap 存放偏移量,需在 .spec.listOffsets.toConfigMap 指定;alter 时从 ConfigMap 读入,需在 .spec.alterOffsets.fromConfigMap 指定;
• 执行 alter 和 reset 前连接器必须处于停止状态(.spec.state),否则会在连接器 status 中产生警告且偏移量不会更新;
• 测试流程:创建 KafkaConnect + File Sink 连接器 → 生产/消费 100 条消息 → list 后校验 ConfigMap 中偏移量 → 把 ConfigMap 偏移量改为 20、停连接器、alter → 等注解移除后经 Connect REST API 校验偏移量确为 20 → 再 reset → 校验 API 返回偏移量已清空。

testConnectorTaskAutoRestart(ConnectST.java#L764):验证 Kafka Connect 任务失败后自动重启功能,属于 KafkaConnector 的 autoRestart 配置行为。

3.5 横切关注点:指标、日志、状态、RBAC 与多 Operator

connect 标签的价值也体现在这些“不属于 Connect 专属套件、但涉及 Connect”的用例上:

• 指标:testKafkaConnectAndConnectorMetrics(MetricsST.md)——KafkaConnect 与连接器的 Prometheus 指标;
• 日志:testConnectLogSetting(LogSettingST.md)——动态修改 Connect 组件日志级别;
• CR 状态:testKafkaConnectAndConnectorStatus 与 testKafkaConnectorWithoutClusterConfig(CustomResourceStatusST.md)——KafkaConnect/KafkaConnector 的 status 子资源,以及缺少集群配置时连接器的行为;
• RBAC:testCRBDeletionErrorIsIgnoredWhenRackAwarenessIsNotEnabled / testCRBDeletionErrorsWhenRackAwarenessIsEnabled(ClusterOperatorRbacST.md)——rack awareness 开/关两种情况下删除 ClusterRoleBinding 时的错误处理;
• 多集群 Operator 与暂停调和:testMultipleCOsInDifferentNamespaces(MultipleClusterOperatorsST.md)、testPauseReconciliationInKafkaAndKafkaConnectWithConnector(ReconciliationST.md);
• JVM 与资源、卷挂载:testJvmAndResources(ConnectST.java#L445)验证 JVM 参数与资源限制的下发;testMountingSecretAndConfigMapAsVolumesAndEnvVars(L1445)验证把 Secret/ConfigMap 挂为卷与环境变量两种方式;testCustomAndUpdatedValues(L869)验证自定义配置值的新增与更新。

四、如何使用:按标签定位用例与运行测试

4.1 定位与阅读测试细节

索引文档只给出“有哪些测试”,每个测试的详细描述与步骤表在其所属测试类的文档页中。阅读路径为:

注意该标签页是构建产物:修改了测试注解或文档元数据后,重新执行 systemtest 模块的 Maven 构建(插件绑定在 install 阶段)即可重新生成索引,手工编辑 <!– generated part –> 之后的内容会在下次构建时被覆盖。

4.2 按标签运行测试

源码中 TestTags.java#L102 定义的 CONNECT = "connect" 是 JUnit 分组标签;systemtest/pom.xml#L347-L369 则展示了通过 Surefire groups 属性按 profile(如 acceptance、regression)过滤测试的运行模式。可以推断,以相同方式使用 Surefire 的 -Dgroups=connect 参数,即可只运行打了 connect 标签的整套用例,用于聚焦 Kafka Connect 的回归验证(具体参数名以仓库 CI 脚本 run_tests.sh 的约定为准)。

五、延伸:继续深入的仓库路径

• 标签索引全族(12 个主题):development-docs/systemtests/labels/;
• 各 Connect 测试类的完整步骤文档:io.strimzi.systemtest.connect.ConnectST.md、io.strimzi.systemtest.connect.ConnectBuilderST.md;
• 测试源码:ConnectST.java、ConnectBuilderST.java;
• 标签与分组常量:TestDocsLabels.java、TestTags.java;
• 生成器插件配置:systemtest/pom.xml#L312-L331;
• 系统测试整体说明:development-docs/TESTING.md。

【免费下载链接】strimzi-kafka-operator Apache Kafka® running on Kubernetes 项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考