企业官网建设流程全解析

Strimzi User Operator 系统测试解析：KafkaUser 认证、ACL、配额与性能边界的验证体系

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

Strimzi 的 User Operator 负责管理 Kafka 集群中的KafkaUser资源，为每个用户自动签发 TLS 客户端证书、生成 SCRAM-SHA-512 凭据、维护 ACL 授权规则并应用 Kafka 配额。本文基于仓库中的测试标签文档 user-operator.md 及其关联的测试套件文档与源码，完整梳理 User Operator 系统测试（systemtest）覆盖了哪些能力、每个测试验证了什么，以及这些行为在 user-operator 模块源码中的对应实现，帮助读者理解该算子的功能边界与容量调优点。

一、标签文档定位：user-operator 标签覆盖哪些测试

user-operator.md 是系统测试标签索引页，其描述明确了该标签下所有测试的共同目标：

These tests cover management of KafkaUser resources by the User Operator. They verify user authentication mechanisms (TLS, SCRAM-SHA-512, external TLS), authorization with ACLs, quota enforcement, secret management with custom prefixes, and user lifecycle operations to ensure reliable user management within a Kafka cluster.

即验证六大能力：TLS / SCRAM-SHA-512 / 外部 TLS 三种认证机制、基于 ACL 的授权、配额（quota）强制、带自定义前缀的 Secret 管理，以及用户生命周期操作。文档列出了 11 个带该标签的测试，分属三个测试套件：

| 测试 | 所属套件 | 文档位置 | | - | - | - | | testCreatingUsersWithSecretPrefix、testScramUserWithQuotas、testTlsExternalUser、testTlsExternalUserWithQuotas、testTlsUserWithQuotas、testTlsValidityDays、testUpdateUser、testUserWithNameMoreThan64Chars、testUserWithQuotas | UserST | io.strimzi.systemtest.operators.user.UserST.md | | testCapacity | UserOperatorPerformance | io.strimzi.systemtest.performance.UserOperatorPerformance.md | | testLatencyUnderLoad、testScalability | UserOperatorScalabilityPerformance | io.strimzi.systemtest.performance.UserOperatorScalabilityPerformance.md |

测试套件源码位于 UserST.java，类级注解为@Tag(REGRESSION)与@Tag(USER)，说明这些用例属于回归测试集。套件的前置步骤（@SuiteDoc中声明）是：初始化共享测试存储并部署带必要配置的 Kafka 集群与 scraper pod。

二、功能回归测试（UserST）逐一拆解

2.1 三种认证机制与 ACL 授权

UserST 覆盖的认证类型对应 examples/user/kafka-user.yaml 中演示的KafkaUser资源形态：spec.authentication.type为tls，spec.authorization为simple并携带 ACL 规则（topic 的 Describe/Read/Write、group 的 Read 等）。

以testTlsExternalUser为例，其步骤为：部署启用 TLS 监听与 Simple ACL 授权的 Kafka 集群 → 创建带 ACL 的外部 TLS 用户 → 用自定义证书构造外部 TLS Secret → 使用该用户收发消息。源码中，TLS 用户 Secret 的生成逻辑见 KafkaUserModel.generateSecret：TLS 认证用户的 Secret 包含ca.crt、user.key、user.crt三个字段；当STRIMZI_PKCS12_KEYSTORE_GENERATION（默认true，见 UserOperatorConfig）开启时，额外生成user.p12和user.password两个 PKCS12 字段。SCRAM-SHA-512 用户的 Secret 则只包含password与sasl.jaas.config两个 Base64 字段。这与testUpdateUser的断言完全一致：TLS 用户 Secret 含ca.crt/user.crt/user.key，切换为 SCRAM 后只剩password字段且证书字段被移除。

testUpdateUser验证的正是这种认证方式切换的生命周期：创建 TLS 用户 → 校验 Secret 内容 → 更新为 SCRAM-SHA-512 → 校验新 Secret 内容 → 分别用两种认证方式完成消息收发。

2.2 TLS 用户名的 64 字符上限

testUserWithNameMoreThan64Chars的四个步骤：创建 64 字符名的 TLS 用户（成功 Ready）→ 创建 65 字符名的 SASL（SCRAM）用户（成功，SASL 用户不受此限制）→ 创建 65 字符名的 TLS 用户（失败）→ 校验错误条件。

测试代码在 UserST.testUserWithNameMoreThan64Chars 中断言错误条件消息包含only up to 64 characters，且 reason 为ExecutionException。这一限制的实现来源在 KafkaUserModel.validateTlsUsername：

private static void validateTlsUsername(KafkaUser user) { if (user.getSpec().getAuthentication() instanceof KafkaUserTlsClientAuthentication) { if (user.getMetadata().getName().length() > OpenSslCertIssuer.MAXIMUM_CN_LENGTH) { throw new InvalidResourceException("Users with TLS client authentication can have a username (name of the KafkaUser custom resource) only up to 64 characters long."); } } }

源码注释解释了原因：OpenSSL 对证书 CN 长度存在上限（OpenSslCertIssuer.MAXIMUM_CN_LENGTH即 64），因此只有 TLS 认证用户受此约束，SCRAM 用户的名称没有该限制——这正是测试中 65 字符 SASL 用户能创建成功、而 65 字符 TLS 用户被拒绝的原因。

2.3 证书有效期 validityDays / renewalDays

testTlsValidityDays验证每个KafkaUser内可配置 mTLS 的validityDays与renewalDays。测试步骤：创建不指定这两个值的 TLS 用户，校验 Secret 中证书默认有效期为 200 天（测试环境的 User Operator 配置值）→ 把.spec.authentication下的validityDays/renewalDays改为 40/20 → 证书自动续期 → 新证书有效期变为 40 天 → 用新证书再次收发消息验证连接可用。

对应源码在 KafkaUserModel.maybeGenerateCertificates，核心取值逻辑为：

int validityDays = kafkaUserTlsClientAuthentication.getValidityDays() != null ? kafkaUserTlsClientAuthentication.getValidityDays() : caValidityDays; int renewalDays = kafkaUserTlsClientAuthentication.getRenewalDays() != null ? kafkaUserTlsClientAuthentication.getRenewalDays() : caRenewalDays;

即用户级配置优先，缺省时回落到 Client CA 的默认配置（STRIMZI_CA_VALIDITY/STRIMZI_CA_RENEWAL环境变量，代码默认值分别为 365 天和 30 天，见 UserOperatorConfig）。

2.4 自定义 Secret 前缀

testCreatingUsersWithSecretPrefix的步骤：用自定义前缀重新配置 Cluster Operator → 创建 TLS 与 SCRAM-SHA-512 用户 → 校验用户 Secret 名称带上前缀 → 两种认证方式收发消息 → 更新用户并校验前缀 Secret 同步更新 → 删除用户并校验前缀 Secret 被清理。

前缀由 User Operator 的STRIMZI_SECRET_PREFIX环境变量控制（代码中默认空字符串，即不加工前缀，见 SECRET_PREFIX 定义），用于在生产环境中对用户 Secret 做命名空间级别的组织与隔离。

2.5 配额（Quotas）

配额相关用例包括testUserWithQuotas（辅助方法，按认证类型分别验证）、testTlsUserWithQuotas、testScramUserWithQuotas、testTlsExternalUserWithQuotas。核心流程：创建带配额配置的用户（producer rate、consumer rate、request percentage、controller mutation rate）→ 用 Kafka CLI 工具校验配额已在集群内生效 → 按认证类型收发消息 → 删除用户并确认配额被清理。

从源码结构看，配额操作由 QuotasOperator 执行，并通过微批量（micro-batching）机制 QuotasBatchReconciler 把多个用户的配额变更合并为少量 Kafka Admin API 调用，降低批量建用户时对集群的压力。

三、性能与容量测试

3.1 testCapacity：容量上限测量

testCapacity 的目标是找出 User Operator 能管理的最大 KafkaUser 数量。步骤：

1. 部署 Kafka 集群，User Operator 配置特定的线程池大小、缓存刷新间隔与批量参数；
2. 开始采集 User Operator 指标；
3. 以 100 个为一批创建 TLS 认证的 KafkaUser，等待其进入 Ready 状态；
4. 持续批量创建，直到 User Operator 无法完成协调（reconcile 失败），确定容量上限；
5. 使用 TestLogCollector 收集范围受限的日志（pods、deployments、configmaps、Kafka CR），通过自定义资源列表避免收集成百上千个 KafkaUser CR 与 Secret；
6. 清理所有 KafkaUser，把性能数据持久化到 user-operator 报告目录。

3.2 testScalability：并行吞吐量测量

testScalability 明确测量的是吞吐量（N 个用户并行处理完成所需总时间），而非单用户延迟。步骤：

1. 部署 Kafka 集群，User Operator 配置更高资源以承载负载；
2. 针对每个配置的用户数（10、100、200、500），为每个 KafkaUser 派生一个线程，并发执行完整生命周期；
3. 每个线程执行 CREATE：创建带 TLS 认证与 ACL 授权的 KafkaUser；
4. 每个线程执行 MODIFY：更新 ACL 规则并添加配额；
5. 每个线程执行 DELETE：删除 KafkaUser；
6. 等待全部线程完成，记录总耗时——即所有用户完成 create-modify-delete 生命周期的总时间（吞吐量指标）；
7. 清理残留用户，把性能指标（如总完成时间，即协调耗时）持久化到 user-operator 报告目录。

3.3 testLatencyUnderLoad：负载下的延迟统计

testLatencyUnderLoad 与吞吐量测试互补，测量单个用户修改的延迟如何随系统负载变化。步骤：

1. 部署 Kafka 集群，User Operator 配置更高资源，并将非默认的STRIMZI_WORK_QUEUE_SIZE设为 4096；
2. 对每个负载级别（已存在 1000、1500、2000 个用户），先创建 N 个 KafkaUser 建立基线负载；
3. 顺序执行 100 次单用户修改，独立测量每次修改的延迟；
4. 从 100 个测量值计算 min、max、平均、P50、P95、P99 分位数，观察延迟随存量用户数增加的退化曲线；
5. 清理用户，把延迟数据保存到 user-operator 报告目录。

STRIMZI_WORK_QUEUE_SIZE即 User Controller 工作队列大小（代码默认 1024，见 WORK_QUEUE_SIZE），性能测试将其调大到 4096 以避免队列本身成为瓶颈。

四、User Operator 关键配置参数速查

结合性能测试用到的调优参数，以下是从 UserOperatorConfig.java 中梳理出的与用户管理最相关的环境变量及其默认值：

| 环境变量 | 含义 | 默认值 | | - | - | - | |STRIMZI_SECRET_PREFIX| 用户 Secret 名称前缀（testCreatingUsersWithSecretPrefix被测对象） | 空 | |STRIMZI_CA_VALIDITY| 用户证书默认有效期（天） | 365 | |STRIMZI_CA_RENEWAL| 证书到期前多少天续期 | 30 | |STRIMZI_SCRAM_SHA_PASSWORD_LENGTH| SCRAM-SHA-512 密码长度 | 32 | |STRIMZI_WORK_QUEUE_SIZE| User Controller 工作队列大小（延迟测试中设为 4096） | 1024 | |STRIMZI_CONTROLLER_THREAD_POOL_SIZE| 协调用户使用的控制器线程池大小 | 50 | |STRIMZI_USER_OPERATIONS_THREAD_POOL_SIZE| KafkaUserOperator 及其协作者的用户操作线程池大小 | 4 | |STRIMZI_CACHE_REFRESH_INTERVAL_MS| Kafka Admin API 资源缓存刷新间隔 | 15000 | |STRIMZI_BATCH_QUEUE_SIZE| Admin API 微批量请求的最大队列 | 1024 | |STRIMZI_BATCH_MAXIMUM_BLOCK_SIZE| 微批量最大批量大小 | 100 | |STRIMZI_BATCH_MAXIMUM_BLOCK_TIME_MS| 微批量最大等待时间（毫秒） | 100 | |STRIMZI_PKCS12_KEYSTORE_GENERATION| 是否在用户 Secret 中生成 PKCS12 存储 | true | |STRIMZI_OPERATION_TIMEOUT_MS| 内部操作超时（毫秒） | 300000 | |STRIMZI_MAINTENANCE_TIME_WINDOWS| 维护窗口列表（分号分隔） | 空 |

批量参数（batch queue / block size / block time）正是testCapacity中"配置特定批量设置"所针对的调优面：User Operator 通过 batching 包 中描述的微批量机制，把大量 ACL 添加/删除、SCRAM 凭据写入、配额变更合并为少量 Admin API 调用，这是其支撑大规模用户管理的核心设计。

五、如何运行这些测试

系统测试通过 Maven 执行。run_tests.sh 的核心命令为：

# 在仓库根目录，TESTCASE 默认为 ".*ST"（全部系统测试），测试 profile 默认为 smoke mvn -B verify -pl systemtest -am -P"<profile>" \ -DfailIfNoTests=false -Djansi.force=true -Dstyle.color=always \ -DtrimStackTrace=false -Dit.test="<TESTCASE>"

实际使用中可以只运行 user-operator 相关套件，例如-Dit.test="*UserST*"并配合regression等 profile；运行前提是需要一个可用的 Kubernetes 集群，套件会先自动部署 Kafka 集群与 scraper pod（见 UserST.java 的类级注解与共享存储初始化）。测试执行细节另见 development-docs/TESTING.md。

六、小结

user-operator 标签文档 索引的 11 个测试构成了 User Operator 的完整验证矩阵：功能层面覆盖 TLS / SCRAM-SHA-512 / 外部 TLS 三种认证、ACL 授权、配额强制、Secret 前缀管理与认证方式切换等生命周期操作，并验证了 TLS 用户名 64 字符上限、validityDays/renewalDays用户级证书有效期等边界行为——这些行为均可在 KafkaUserModel.java 中找到对应实现；性能层面通过容量（逐批创建至失败）、吞吐量（10~500 用户并发全生命周期）与负载下延迟（1000~2000 存量用户的 P50/P95/P99）三类测试，量化 User Operator 的可承载规模，其调优抓手正是STRIMZI_WORK_QUEUE_SIZE、线程池与微批量参数等UserOperatorConfig中定义的环境变量。

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