Strimzi Kafka 多版本系统测试深度解析KafkaVersionsST 如何验证每个受支持的 Kafka 版本【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator导读KafkaVersionsST 是 Strimzi Kafka Operator 系统测试套件systemtest中负责按受支持 Kafka 版本逐一遍历、验证集群基础功能的冒烟级smoke测试套件。它以 kafka-versions.yaml 中标记为supported: true的每个 Kafka 版本为参数完整验证集群部署 → Topic Operator / User Operator 就绪 → PLAINSCRAM-SHA 与 TLS 双通道消息收发这条生产核心链路。阅读本文后你将理解 Strimzi 多版本兼容性测试的整体设计、testKafkaWithVersion的每一步断言逻辑、Kafka 版本清单文件的结构与解析机制并能独立在本地运行该套件。一、套件定位面向每个受支持版本的基础功能冒烟验证KafkaVersionsST.md 将本套件的职责定义为验证每个受支持的 Kafka 版本的基础功能basic functionality。它归属于 kafka 测试标签该标签下的测试共同覆盖动态配置、监听器、节点池、版本升级、配额、分层存储等核心 Kafka 能力。对应到源码套件声明于 KafkaVersionsST.javaTag(KAFKA_SMOKE) SuiteDoc( description Desc(Verifies the basic functionality for each supported Kafka version.), beforeTestSteps { Step(value Deploy Cluster Operator with default installation., expected Cluster Operator is deployed.) }, labels { Label(value TestDocsLabels.KAFKA) } ) public class KafkaVersionsST extends AbstractST {其中KAFKA_SMOKE定义于 TestTags.java值为kafkasmoke表明这是一组需要在功能变更合入前快速跑通的冒烟测试——因为新版本能否正常部署是所有其他能力验证的前提。测试前置条件根据文档中Before test execution steps表格套件唯一的全局前置步骤是| 步骤 | 动作 | 预期结果 | | - | - | - | | 1 | 使用默认配置部署 Cluster Operator | Cluster Operator 已成功部署 |该步骤由BeforeAll void setup()实现KafkaVersionsST.java使用SetupClusterOperator.getInstance().withDefaultConfiguration().install()完成即沿用系统测试框架的默认安装配置不做额外定制。二、testKafkaWithVersion逐版本验证核心测试方法的全流程testKafkaWithVersion是本套件的唯一测试方法KafkaVersionsST.java其定义中的关键注解是ParameterizedTest(name Kafka version: {0}.version()) MethodSource(io.strimzi.systemtest.utils.TestKafkaVersion#getSupportedKafkaVersions)这是一个 JUnit 5 参数化测试参数来源TestKafkaVersion#getSupportedKafkaVersions会返回kafka-versions.yaml中所有supported: true的版本因此每新增/移除一个受支持版本该测试的用例数会自动随之增减无需修改测试代码。测试名会带上具体版本例如Kafka version: 4.3.1.version()便于在 CI 报告中快速定位失败版本。文档给出了该方法的 5 步验证流程| 步骤 | 动作 | 预期结果 | | - | - | - | | 1 | 以指定版本部署 Kafka 集群 | Kafka 集群无任何问题地完成部署 | | 2 | 验证 Topic Operator 创建 | Topic Operator 工作正常 | | 3 | 验证 User Operator 创建 | User Operator 与 SCRAM-SHA 及 ACL 配合工作正常 | | 4 | 通过 PLAIN SCRAM-SHA 发送并接收消息 | 消息收发成功 | | 5 | 通过 TLS 发送并接收消息 | 消息收发成功 |下面结合源码逐步拆解这 5 步背后的具体实现。第 1 步以指定版本部署 Kafka 集群含 Node Pool测试首先创建 3 副本的 Broker 节点池与 Controller 节点池KafkaVersionsST.javaKubeResourceManager.get().createResourceWithWait( KafkaNodePoolTemplates.brokerPool(testStorage.getNamespaceName(), testStorage.getBrokerPoolName(), testStorage.getClusterName(), 3).build(), KafkaNodePoolTemplates.controllerPool(testStorage.getNamespaceName(), testStorage.getControllerPoolName(), testStorage.getClusterName(), 3).build() );随后创建Kafka自定义资源关键配置点如下KafkaVersionsST.javaKafkaTemplates.kafka(testStorage.getNamespaceName(), testStorage.getClusterName(), 3) .editOrNewSpec() .editOrNewKafka() .withVersion(testKafkaVersion.version()) // 参数化注入目标版本 .addToConfig(auto.create.topics.enable, true) // 允许客户端自动建 topic .withNewKafkaAuthorizationSimple() // 启用 Simple 授权 .endKafkaAuthorizationSimple() .withListeners( new GenericKafkaListenerBuilder() .withName(TestConstants.PLAIN_LISTENER_DEFAULT_NAME) // plain 监听器 .withPort(9092) .withType(KafkaListenerType.INTERNAL) .withTls(false) .withNewKafkaListenerAuthenticationScramSha512Auth() .endKafkaListenerAuthenticationScramSha512Auth() .build(), new GenericKafkaListenerBuilder() .withName(TestConstants.TLS_LISTENER_DEFAULT_NAME) // tls 监听器 .withPort(9093) .withType(KafkaListenerType.INTERNAL) .withTls(true) .withNewKafkaListenerAuthenticationTlsAuth() .endKafkaListenerAuthenticationTlsAuth() .build() ) .endKafka() .endSpec() .build();需要特别说明的是withVersion(testKafkaVersion.version())这里写入Kafka资源的spec.kafka.version字段是 Strimzi 选择容器镜像与运行参数的核心依据。createResourceWithWait会阻塞等待集群真正达到 Ready 状态因此部署成功本身就隐含了版本兼容性检查——例如该版本的 Kafka 镜像能否正常启动、Controller/Broker 节点能否形成 KRaft 仲裁组等。从运行时实现看Cluster Operator 在 KafkaVersion.java 的Lookup类中加载 classpath 上的kafka-versions.yaml并据此校验Kafka资源里声明的版本是否受支持、映射到哪个容器镜像。同时parseKafkaVersions会强制约束版本清单中不允许出现重复版本也不允许出现多个default: trueKafkaVersion.java。第 2 步验证 Topic Operator测试通过KafkaTopicTemplates.topic(testStorage).build()创建 Topic 资源并等待就绪KafkaVersionsST.java。Topic Operator 需要把KafkaTopic自定义资源翻译成真实的 Kafka topic这一步验证的是Entity Operator 中的 Topic Operator 在该 Kafka 版本上能正常同步 topic 元数据。第 3 步验证 User OperatorSCRAM-SHA 凭据 ACL测试创建了三个具有不同权限模型的KafkaUserKafkaVersionsST.java用于后续两路消息收发的鉴权验证writeUserSCRAM-SHA 用户拥有对目标 topic 的WRITE、DESCRIBE、CREATE操作CREATE是为配合auto.create.topics.enable: true让生产者在 topic 不存在时自动创建readUserSCRAM-SHA 用户拥有对目标 topic 的READ、DESCRIBE操作以及对消费组的READ操作tlsReadWriteUserTLS 证书认证用户同时具备读写权限。这一步验证了 User Operator 在该 Kafka 版本上能够正确生成 SCRAM-SHA 凭据 Secret、签发 TLS 客户端证书并将 ACL 规则同步到 Kafka 的 Simple Authorizer 中。第 4 步PLAIN SCRAM-SHA 消息收发测试通过系统测试专用的 Kafka 客户端构建器创建生产/消费 JobKafkaVersionsST.javafinal KafkaProducerClient kafkaProducerPlainScramShaWrite new KafkaProducerClientBuilder() .withName(testStorage.getProducerName()) .withNamespaceName(testStorage.getNamespaceName()) .withTopicName(testStorage.getTopicName()) .withBootstrapAddress(KafkaResources.plainBootstrapAddress(testStorage.getClusterName())) .withMessageCount(testStorage.getMessageCount()) .withAuthentication(ClientsAuthentication.configurePlainScramSha(testStorage.getNamespaceName(), kafkaUserWrite)) .build();生产者使用writeUser的 SCRAM-SHA-512 凭据连接 PLAIN9092监听器写入messageCount条消息随后消费者使用readUser在随机生成的消费组上读取并断言全部消息成功消费ClientUtils.waitForClientSuccess(testStorage.getNamespaceName(), testStorage.getProducerName(), testStorage.getMessageCount()); ClientUtils.waitForClientSuccess(testStorage.getNamespaceName(), testStorage.getConsumerName(), testStorage.getMessageCount());这一步同时覆盖了 PLAIN 监听器、SCRAM-SHA 认证、Simple 授权 ACL 在目标 Kafka 版本上的端到端可用性。第 5 步TLS 消息收发最后使用tlsReadWriteUser通过KafkaProducerConsumerBuilder同时创建生产与消费 Job连接 TLS9093监听器完成读写KafkaVersionsST.java并以waitForClientsSuccess断言两侧同时成功。这一步验证了 TLS 监听器、TLS 客户端证书认证在该版本上的可用性。三、版本数据源kafka-versions.yaml 与版本解析机制所有受支持版本集中维护在仓库根目录的 kafka-versions.yaml 中。该文件注释明确说明它是变更受支持 Kafka 版本时唯一需要更新的单一事实来源同时影响编译期与运行期Docker 镜像构建、Helm chart 中的KAFKA_IMAGE_MAP、配置模型生成、Cluster Operator 运行时加载的KafkaVersion、以及make docu_versions生成的文档片段。字段说明| 字段 | 含义 | | - | - | |version| 在Kafka/KafkaConnect/KafkaMirrorMaker2自定义资源中使用的版本号 | |maven-version| 构建时使用的 Apache Kafka Maven 制品版本未设置时默认与version相同用于自定义 Kafka 构建场景 | |metadata| 该版本默认使用的 Kafka 协议 metadata 版本 | |url/checksum| Kafka 二进制发行包的下载地址及 SHA512 校验和 | |third-party-libs| 该版本使用的第三方依赖库目录如4.3.x | |supported|true表示当前受支持不支持的版本保留在文件中用于历史追溯 | |default|true表示用户未显式指定版本时的默认版本全文件只允许一个 |以当前仓库为例标记为supported: true的是 Kafka 4.2.0、4.2.1、4.3.0以及default: true的 4.3.1kafka-versions.yaml更早的 2.1.0 到 4.1.2 等版本均以supported: false保留。测试侧的版本解析系统测试通过 TestKafkaVersion.java 读取该 YAML 文件静态块在类加载时解析kafka-versions.yaml过滤出所有supported: true的版本并排序TestKafkaVersion.javagetSupportedKafkaVersions()即返回该列表作为参数化测试的数据源。若文件中没有任何受支持版本测试框架会直接抛异常拒绝启动。此外该类还实现了点分版本比较compareDottedVersions与isUpgrade判断为升级类测试提供基础。运行期校验在 Cluster Operator 侧KafkaVersion.java 运行时解析同一份清单为每个Kafka资源匹配版本对应的镜像并完成默认版本的唯一性校验。因此KafkaVersionsST的每个参数化用例本质上也在验证运行期版本映射与镜像拉取这一完整链路。四、支持的版本策略与版本增删关于哪些版本应该被支持仓库根目录的 KAFKA_VERSION_SUPPORT.md 给出了两条维护规则至少支持最近两个 major/minor 版本的 Apache Kafka例如加入 2.4.x 支持时可以移除 2.2.x相邻两个 Strimzi 大/小版本之间至少保留一个共同的 Kafka 版本以保证 Strimzi 与 Kafka 版本都能平滑升级。当需要新增或移除版本时development-docs/KAFKA_VERSIONS.md 提供了完整操作清单新增版本需更新kafka-versions.yaml、为新 minor 版本准备docker-images下的第三方依赖目录、同步文档attributes.adoc与示例资源、更新pom.xml中的 Kafka 版本等移除版本则只需将supported置为false不要删除条目。该文件还介绍了自 Strimzi 1.1.0 起支持的自定义 Kafka 版本能力——通过在kafka-versions.yaml中声明maven-version、自定义url/checksum即可让集群 Operator 使用带补丁的 Kafka 构建。可以看到无论是新增、移除还是自定义版本KafkaVersionsST都是版本变更后必须通过的回归验证关卡。五、如何运行 KafkaVersionsST系统测试基于 Maven 与 JUnit 5套件本身继承自AbstractST。运行该套件前需确保已具备可用的 Kubernetes/OpenShift 集群可参考仓库内的 TESTING.md 了解系统测试的环境准备与执行方式。典型的定向执行命令如下在systemtest模块目录下mvn verify -pl systemtest -DtestKafkaVersionsST或按标签过滤冒烟类测试mvn verify -pl systemtest -Dgroupskafkasmoke参数化测试会在 JUnit 报告中为每个受支持版本生成独立用例如Kafka version: 4.3.1.version()便于区分失败项。若新增版本后套件失败通常需要回溯检查镜像是否已构建并推送到仓库、kafka-versions.yaml中supported/default标记是否正确、对应版本的第三方依赖目录是否就绪。六、小结KafkaVersionsST 是 Strimzi 多版本兼容性保障体系中的第一道防线它以参数化测试的形式把 kafka-versions.yaml 中每个受支持版本都跑一遍部署 → 双 Operator 就绪 → PLAIN/SCRAM-SHA 与 TLS 双通道收发的完整链路。结合 TestKafkaVersion.java 的版本解析与 KafkaVersion.java 的运行时校验开发者可以在合入新版本支持前快速获得该版本在 Kubernetes 上能否正常运转的明确信号——这正是 Strimzi 承诺Apache Kafka running on Kubernetes时最底层的质量保障。延伸阅读kafka 测试标签文档了解 kafka 标签下全部测试的完整清单KafkaVersionsST 源码本文所有断言的实现出处kafka-versions.yaml受支持版本的单一事实来源KAFKA_VERSION_SUPPORT.md版本支持策略development-docs/KAFKA_VERSIONS.md新增/移除/自定义 Kafka 版本的操作手册【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Strimzi Kafka 多版本系统测试深度解析：KafkaVersionsST 如何验证每个受支持的 Kafka 版本
Strimzi Kafka 多版本系统测试深度解析KafkaVersionsST 如何验证每个受支持的 Kafka 版本【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator导读KafkaVersionsST 是 Strimzi Kafka Operator 系统测试套件systemtest中负责按受支持 Kafka 版本逐一遍历、验证集群基础功能的冒烟级smoke测试套件。它以 kafka-versions.yaml 中标记为supported: true的每个 Kafka 版本为参数完整验证集群部署 → Topic Operator / User Operator 就绪 → PLAINSCRAM-SHA 与 TLS 双通道消息收发这条生产核心链路。阅读本文后你将理解 Strimzi 多版本兼容性测试的整体设计、testKafkaWithVersion的每一步断言逻辑、Kafka 版本清单文件的结构与解析机制并能独立在本地运行该套件。一、套件定位面向每个受支持版本的基础功能冒烟验证KafkaVersionsST.md 将本套件的职责定义为验证每个受支持的 Kafka 版本的基础功能basic functionality。它归属于 kafka 测试标签该标签下的测试共同覆盖动态配置、监听器、节点池、版本升级、配额、分层存储等核心 Kafka 能力。对应到源码套件声明于 KafkaVersionsST.javaTag(KAFKA_SMOKE) SuiteDoc( description Desc(Verifies the basic functionality for each supported Kafka version.), beforeTestSteps { Step(value Deploy Cluster Operator with default installation., expected Cluster Operator is deployed.) }, labels { Label(value TestDocsLabels.KAFKA) } ) public class KafkaVersionsST extends AbstractST {其中KAFKA_SMOKE定义于 TestTags.java值为kafkasmoke表明这是一组需要在功能变更合入前快速跑通的冒烟测试——因为新版本能否正常部署是所有其他能力验证的前提。测试前置条件根据文档中Before test execution steps表格套件唯一的全局前置步骤是| 步骤 | 动作 | 预期结果 | | - | - | - | | 1 | 使用默认配置部署 Cluster Operator | Cluster Operator 已成功部署 |该步骤由BeforeAll void setup()实现KafkaVersionsST.java使用SetupClusterOperator.getInstance().withDefaultConfiguration().install()完成即沿用系统测试框架的默认安装配置不做额外定制。二、testKafkaWithVersion逐版本验证核心测试方法的全流程testKafkaWithVersion是本套件的唯一测试方法KafkaVersionsST.java其定义中的关键注解是ParameterizedTest(name Kafka version: {0}.version()) MethodSource(io.strimzi.systemtest.utils.TestKafkaVersion#getSupportedKafkaVersions)这是一个 JUnit 5 参数化测试参数来源TestKafkaVersion#getSupportedKafkaVersions会返回kafka-versions.yaml中所有supported: true的版本因此每新增/移除一个受支持版本该测试的用例数会自动随之增减无需修改测试代码。测试名会带上具体版本例如Kafka version: 4.3.1.version()便于在 CI 报告中快速定位失败版本。文档给出了该方法的 5 步验证流程| 步骤 | 动作 | 预期结果 | | - | - | - | | 1 | 以指定版本部署 Kafka 集群 | Kafka 集群无任何问题地完成部署 | | 2 | 验证 Topic Operator 创建 | Topic Operator 工作正常 | | 3 | 验证 User Operator 创建 | User Operator 与 SCRAM-SHA 及 ACL 配合工作正常 | | 4 | 通过 PLAIN SCRAM-SHA 发送并接收消息 | 消息收发成功 | | 5 | 通过 TLS 发送并接收消息 | 消息收发成功 |下面结合源码逐步拆解这 5 步背后的具体实现。第 1 步以指定版本部署 Kafka 集群含 Node Pool测试首先创建 3 副本的 Broker 节点池与 Controller 节点池KafkaVersionsST.javaKubeResourceManager.get().createResourceWithWait( KafkaNodePoolTemplates.brokerPool(testStorage.getNamespaceName(), testStorage.getBrokerPoolName(), testStorage.getClusterName(), 3).build(), KafkaNodePoolTemplates.controllerPool(testStorage.getNamespaceName(), testStorage.getControllerPoolName(), testStorage.getClusterName(), 3).build() );随后创建Kafka自定义资源关键配置点如下KafkaVersionsST.javaKafkaTemplates.kafka(testStorage.getNamespaceName(), testStorage.getClusterName(), 3) .editOrNewSpec() .editOrNewKafka() .withVersion(testKafkaVersion.version()) // 参数化注入目标版本 .addToConfig(auto.create.topics.enable, true) // 允许客户端自动建 topic .withNewKafkaAuthorizationSimple() // 启用 Simple 授权 .endKafkaAuthorizationSimple() .withListeners( new GenericKafkaListenerBuilder() .withName(TestConstants.PLAIN_LISTENER_DEFAULT_NAME) // plain 监听器 .withPort(9092) .withType(KafkaListenerType.INTERNAL) .withTls(false) .withNewKafkaListenerAuthenticationScramSha512Auth() .endKafkaListenerAuthenticationScramSha512Auth() .build(), new GenericKafkaListenerBuilder() .withName(TestConstants.TLS_LISTENER_DEFAULT_NAME) // tls 监听器 .withPort(9093) .withType(KafkaListenerType.INTERNAL) .withTls(true) .withNewKafkaListenerAuthenticationTlsAuth() .endKafkaListenerAuthenticationTlsAuth() .build() ) .endKafka() .endSpec() .build();需要特别说明的是withVersion(testKafkaVersion.version())这里写入Kafka资源的spec.kafka.version字段是 Strimzi 选择容器镜像与运行参数的核心依据。createResourceWithWait会阻塞等待集群真正达到 Ready 状态因此部署成功本身就隐含了版本兼容性检查——例如该版本的 Kafka 镜像能否正常启动、Controller/Broker 节点能否形成 KRaft 仲裁组等。从运行时实现看Cluster Operator 在 KafkaVersion.java 的Lookup类中加载 classpath 上的kafka-versions.yaml并据此校验Kafka资源里声明的版本是否受支持、映射到哪个容器镜像。同时parseKafkaVersions会强制约束版本清单中不允许出现重复版本也不允许出现多个default: trueKafkaVersion.java。第 2 步验证 Topic Operator测试通过KafkaTopicTemplates.topic(testStorage).build()创建 Topic 资源并等待就绪KafkaVersionsST.java。Topic Operator 需要把KafkaTopic自定义资源翻译成真实的 Kafka topic这一步验证的是Entity Operator 中的 Topic Operator 在该 Kafka 版本上能正常同步 topic 元数据。第 3 步验证 User OperatorSCRAM-SHA 凭据 ACL测试创建了三个具有不同权限模型的KafkaUserKafkaVersionsST.java用于后续两路消息收发的鉴权验证writeUserSCRAM-SHA 用户拥有对目标 topic 的WRITE、DESCRIBE、CREATE操作CREATE是为配合auto.create.topics.enable: true让生产者在 topic 不存在时自动创建readUserSCRAM-SHA 用户拥有对目标 topic 的READ、DESCRIBE操作以及对消费组的READ操作tlsReadWriteUserTLS 证书认证用户同时具备读写权限。这一步验证了 User Operator 在该 Kafka 版本上能够正确生成 SCRAM-SHA 凭据 Secret、签发 TLS 客户端证书并将 ACL 规则同步到 Kafka 的 Simple Authorizer 中。第 4 步PLAIN SCRAM-SHA 消息收发测试通过系统测试专用的 Kafka 客户端构建器创建生产/消费 JobKafkaVersionsST.javafinal KafkaProducerClient kafkaProducerPlainScramShaWrite new KafkaProducerClientBuilder() .withName(testStorage.getProducerName()) .withNamespaceName(testStorage.getNamespaceName()) .withTopicName(testStorage.getTopicName()) .withBootstrapAddress(KafkaResources.plainBootstrapAddress(testStorage.getClusterName())) .withMessageCount(testStorage.getMessageCount()) .withAuthentication(ClientsAuthentication.configurePlainScramSha(testStorage.getNamespaceName(), kafkaUserWrite)) .build();生产者使用writeUser的 SCRAM-SHA-512 凭据连接 PLAIN9092监听器写入messageCount条消息随后消费者使用readUser在随机生成的消费组上读取并断言全部消息成功消费ClientUtils.waitForClientSuccess(testStorage.getNamespaceName(), testStorage.getProducerName(), testStorage.getMessageCount()); ClientUtils.waitForClientSuccess(testStorage.getNamespaceName(), testStorage.getConsumerName(), testStorage.getMessageCount());这一步同时覆盖了 PLAIN 监听器、SCRAM-SHA 认证、Simple 授权 ACL 在目标 Kafka 版本上的端到端可用性。第 5 步TLS 消息收发最后使用tlsReadWriteUser通过KafkaProducerConsumerBuilder同时创建生产与消费 Job连接 TLS9093监听器完成读写KafkaVersionsST.java并以waitForClientsSuccess断言两侧同时成功。这一步验证了 TLS 监听器、TLS 客户端证书认证在该版本上的可用性。三、版本数据源kafka-versions.yaml 与版本解析机制所有受支持版本集中维护在仓库根目录的 kafka-versions.yaml 中。该文件注释明确说明它是变更受支持 Kafka 版本时唯一需要更新的单一事实来源同时影响编译期与运行期Docker 镜像构建、Helm chart 中的KAFKA_IMAGE_MAP、配置模型生成、Cluster Operator 运行时加载的KafkaVersion、以及make docu_versions生成的文档片段。字段说明| 字段 | 含义 | | - | - | |version| 在Kafka/KafkaConnect/KafkaMirrorMaker2自定义资源中使用的版本号 | |maven-version| 构建时使用的 Apache Kafka Maven 制品版本未设置时默认与version相同用于自定义 Kafka 构建场景 | |metadata| 该版本默认使用的 Kafka 协议 metadata 版本 | |url/checksum| Kafka 二进制发行包的下载地址及 SHA512 校验和 | |third-party-libs| 该版本使用的第三方依赖库目录如4.3.x | |supported|true表示当前受支持不支持的版本保留在文件中用于历史追溯 | |default|true表示用户未显式指定版本时的默认版本全文件只允许一个 |以当前仓库为例标记为supported: true的是 Kafka 4.2.0、4.2.1、4.3.0以及default: true的 4.3.1kafka-versions.yaml更早的 2.1.0 到 4.1.2 等版本均以supported: false保留。测试侧的版本解析系统测试通过 TestKafkaVersion.java 读取该 YAML 文件静态块在类加载时解析kafka-versions.yaml过滤出所有supported: true的版本并排序TestKafkaVersion.javagetSupportedKafkaVersions()即返回该列表作为参数化测试的数据源。若文件中没有任何受支持版本测试框架会直接抛异常拒绝启动。此外该类还实现了点分版本比较compareDottedVersions与isUpgrade判断为升级类测试提供基础。运行期校验在 Cluster Operator 侧KafkaVersion.java 运行时解析同一份清单为每个Kafka资源匹配版本对应的镜像并完成默认版本的唯一性校验。因此KafkaVersionsST的每个参数化用例本质上也在验证运行期版本映射与镜像拉取这一完整链路。四、支持的版本策略与版本增删关于哪些版本应该被支持仓库根目录的 KAFKA_VERSION_SUPPORT.md 给出了两条维护规则至少支持最近两个 major/minor 版本的 Apache Kafka例如加入 2.4.x 支持时可以移除 2.2.x相邻两个 Strimzi 大/小版本之间至少保留一个共同的 Kafka 版本以保证 Strimzi 与 Kafka 版本都能平滑升级。当需要新增或移除版本时development-docs/KAFKA_VERSIONS.md 提供了完整操作清单新增版本需更新kafka-versions.yaml、为新 minor 版本准备docker-images下的第三方依赖目录、同步文档attributes.adoc与示例资源、更新pom.xml中的 Kafka 版本等移除版本则只需将supported置为false不要删除条目。该文件还介绍了自 Strimzi 1.1.0 起支持的自定义 Kafka 版本能力——通过在kafka-versions.yaml中声明maven-version、自定义url/checksum即可让集群 Operator 使用带补丁的 Kafka 构建。可以看到无论是新增、移除还是自定义版本KafkaVersionsST都是版本变更后必须通过的回归验证关卡。五、如何运行 KafkaVersionsST系统测试基于 Maven 与 JUnit 5套件本身继承自AbstractST。运行该套件前需确保已具备可用的 Kubernetes/OpenShift 集群可参考仓库内的 TESTING.md 了解系统测试的环境准备与执行方式。典型的定向执行命令如下在systemtest模块目录下mvn verify -pl systemtest -DtestKafkaVersionsST或按标签过滤冒烟类测试mvn verify -pl systemtest -Dgroupskafkasmoke参数化测试会在 JUnit 报告中为每个受支持版本生成独立用例如Kafka version: 4.3.1.version()便于区分失败项。若新增版本后套件失败通常需要回溯检查镜像是否已构建并推送到仓库、kafka-versions.yaml中supported/default标记是否正确、对应版本的第三方依赖目录是否就绪。六、小结KafkaVersionsST 是 Strimzi 多版本兼容性保障体系中的第一道防线它以参数化测试的形式把 kafka-versions.yaml 中每个受支持版本都跑一遍部署 → 双 Operator 就绪 → PLAIN/SCRAM-SHA 与 TLS 双通道收发的完整链路。结合 TestKafkaVersion.java 的版本解析与 KafkaVersion.java 的运行时校验开发者可以在合入新版本支持前快速获得该版本在 Kubernetes 上能否正常运转的明确信号——这正是 Strimzi 承诺Apache Kafka running on Kubernetes时最底层的质量保障。延伸阅读kafka 测试标签文档了解 kafka 标签下全部测试的完整清单KafkaVersionsST 源码本文所有断言的实现出处kafka-versions.yaml受支持版本的单一事实来源KAFKA_VERSION_SUPPORT.md版本支持策略development-docs/KAFKA_VERSIONS.md新增/移除/自定义 Kafka 版本的操作手册【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
