云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载Operator SDK 的 scorecard 是用于对 Operator 运行通用测试套件的工具本指南以仓库中的设计提案 proposals/scorecard-plugin-system.md 为核心骨架结合当前仓库源码internal/scorecard、internal/cmd/operator-sdk/scorecard、images/scorecard-test-kuttl等系统讲解scorecard 插件系统的设计动机、可执行插件与 JSON 输出契约、测试结果数据模型与状态语义、以及内置测试与自研插件的落地方式。读完本文你将能够理解 scorecard 从“仅内置测试”到“可动态扩展测试”的演进路径掌握以脚本或二进制形式编写自定义 scorecard 测试并接入结果解析的标准姿势。背景为什么 scorecard 需要插件系统Operator SDK 的 scorecard 功能旨在让用户对 Operator 运行一组通用测试。在设计提案提出之前scorecard 只包含内置测试用户无法在不重新编译 SDK 的情况下增删测试项。这带来了两个实际问题用户自定义测试只能以内置代码的形式维护改动成本高、迭代慢复杂的端到端E2E风格测试难以用简单的内置检查表达用户需要更大的自由度。提案proposals/scorecard-plugin-system.md提出一个插件系统允许 SDK 维护者和用户在不把测试编译进 scorecard/SDK 二进制的前提下动态地添加和移除测试。核心手段是——把用户定义的测试实现为项目根目录下的可执行文件脚本或二进制scorecard 依次运行这些文件并以约定好的 JSON 格式读取测试结果。设计总览可执行文件 标准 JSON 输出插件系统的设计非常朴素而开放核心约定只有两条插件即可执行文件用户把可执行脚本或二进制放入项目根目录的指定目录例如root/scorecard/bin该路径可通过 flag 配置输出即 JSONscorecard 按顺序运行所有可执行文件每个插件需要把测试结果以 JSON 形式打印到 stdout若插件发生致命错误或没有返回合法 JSON 结果scorecard 会生成一个默认的失败 JSON 结果其中指明该二进制/脚本运行失败并附带该可执行文件打印到 stdout 的内容便于排查。这一设计使得第三方可以非常容易地创建 scorecard 插件同时 scorecard 侧解析与集成其他内置测试的逻辑保持简单——每个插件被视为一个独立的 suite测试套件整个 scorecard 的完整输出结果是一个ScorecardResult列表。从源码结构看这一思路与当前仓库中「内置测试镜像 Pod 执行 结果聚合」的运行时形态一脉相承scorecard 把每个测试当作一个独立的容器/进程执行再收集其输出统一解析插件系统只是把“测试来源”从内置镜像扩展到了任意可执行文件。结果数据模型复用 Kubernetes API 的序列化为了让 JSON 输出具备版本化演进能力插件系统的数据模型复用 Kubernetes API 的 marshalling/unmarshalling 机制通过标准化的metav1.TypeMeta字段为未来的测试定义和结果格式升级留出版本化空间。提案给出了如下 Go 结构体定义type ScorecardTest struct { metav1.TypeMeta json:,inline // Spec describes the attributes for the test. Spec *ScorecardTestSpec json:spec // Status describes the current state of the test and final results. // optional Status *ScorecardTestResults json:results,omitempty } type ScorecardTestSpec struct { // TestInfo is currently used for ScorecardTestSpec. TestInfo json:,inline } type ScorecardTestResults struct { // Log contains the scorecards current log. Log string json:log // Results is an array of ScorecardResult for each suite of the curent scorecard run. Results []ScorecardResult json:results } // ScorecardResult contains the combined results of a suite of tests type ScorecardResult struct { // Error is the number of tests that ended in the Error state Error int json:error // Pass is the number of tests that ended in the Pass state Pass int json:pass // PartialPass is the number of tests that ended in the PartialPass state PartialPass int json:partial_pass // Fail is the number of tests that ended in the Fail state Fail int json:fail // TotalTests is the total number of tests run in this suite TotalTests int json:total_tests // TotalScore is the total score of this quite as a percentage TotalScore int json:total_score_percent // Tests is an array containing a json-ified version of the TestResults for the suite Tests []*JSONTestResult json:tests } // JSONTestResult is a simplified version of the TestResult that only include the Name and Description of the Test field in TestResult type JSONTestResult struct { // State is the final state of the test State State // Name is the name of the test Name string // Description describes what the test does Description string // EarnedPoints is how many points the test received after running EarnedPoints int // MaximumPoints is the maximum number of points possible for the test MaximumPoints int // Suggestions is a list of suggestions for the user to improve their score (if applicable) Suggestions []string // Errors is a list of the errors that occurred during the test (this can include both fatal and non-fatal errors) Errors []error } // State is a type used to indicate the result state of a Test. type State string const ( // UnsetState is the default state for a TestResult. It must be updated by UpdateState or by the Test. UnsetState State unset // PassState occurs when a Tests ExpectedPoints MaximumPoints. PassState State pass // PartialPassState occurs when a Tests ExpectedPoints MaximumPoints and ExpectedPoints 0. PartialPassState State partial_pass // FailState occurs when a Tests ExpectedPoints 0. FailState State fail // ErrorState occurs when a Test encounters a fatal error and the reported points should not be considered. ErrorState State error )这些结构体语义清晰ScorecardResult是一个 suite 的聚合统计包含各状态Error / Pass / PartialPass / Fail的计数、总测试数total_tests、以及以百分比表示的套件总分total_score_percentJSONTestResult是单个测试的简化描述状态、名称、描述、获得分数EarnedPoints、最高分数MaximumPoints、改进建议列表以及错误列表State是测试结果的最终状态枚举其取值规则与得分直接挂钩得分等于满分 →pass得分大于 0 但小于满分 →partial_pass得分等于 0 →fail测试遇到致命错误分数不可信→error。在仓库实际演进中这一提案的数据模型已演化为github.com/operator-framework/api/pkg/apis/scorecard/v1alpha3包中的TestStatus、TestResult等类型。例如 internal/scorecard/scorecard.go 中的TestRunner接口直接以v1alpha3.TestConfiguration与v1alpha3.TestStatus作为运行和返回类型内置测试则通过 internal/scorecard/tests/olm.go 中的TestResult构造各状态结果并调用wrapResult包装为TestStatus。提案中的State枚举在 v1alpha3 中以同名的PassState、FailState、ErrorState等常量延续并在 scorecard.go 的convertErrorToStatus中用于把运行错误转换为失败结果。输出示例读懂一份插件测试结果提案给出了ScorecardResult对象scorecard 测试对象初始v1alpha1版本的完整 JSON 输出示例{ error: 0, pass: 1, partial_pass: 1, fail: 0, total_tests: 2, total_score_percent: 71, tests: [ { state: partial_pass, name: Operator Actions Reflected In Status, description: The operator updates the Custom Resources status when the application state is updated, earnedPoints: 2, maximumPoints: 3, suggestions: [ { suggestion: Operator should update status when scaling cluster down } ], errors: [] }, { state: pass, name: Verify health of cluster, description: The cluster created by the operator is working properly, earnedPoints: 1, maximumPoints: 1, suggestions: [], errors: [] } ] }这个示例直观展示了插件的输出契约聚合层给出该 suite 的总体分数71%与各状态计数测试层逐条给出状态、分数、建议和错误其中partial_pass的测试通过suggestions给出可操作的改进意见例如Operator should update status when scaling cluster downerrors为空数组表示没有发生错误。scorecard 侧可以据此把插件结果与内置测试结果统一聚合最终形成整个 scorecard 运行的完整结果列表。状态语义与得分规则理解State枚举是编写正确插件的基础五个状态的含义与触发条件如下状态取值触发条件含义UnsetStateunsetTestResult的默认状态必须由UpdateState或测试本身更新结果尚未定论PassStatepassExpectedPoints MaximumPoints测试满分通过PartialPassStatepartial_pass0 ExpectedPoints MaximumPoints部分通过得分不完整FailStatefailExpectedPoints 0测试失败ErrorStateerror测试遇到致命错误报告分数不应被采信从实现看当前仓库的内置测试遵循同样的语义。以 internal/scorecard/tests/basic.go 的CheckSpecTest为例它先预设PassState当获取自定义资源CR失败时把状态改为FailState并追加错误信息而 internal/scorecard/tests/olm.go 的BundleValidationTest在 bundle 格式校验失败时同样置为FailState并记录错误。这说明初始化为通过、遇到问题降级为失败/错误是 scorecard 测试的标准编写范式。从提案到实现当前仓库的 scorecard 运行机制虽然插件系统以项目根目录可执行文件为最初形态当前仓库的 scorecard 已经演进为配置驱动 Pod 运行的成熟机制理解它有助于把握插件系统的落点。核心组件如下配置加载config.yaml 驱动测试清单scorecard 的配置硬编码文件名与默认路径定义在 internal/scorecard/config.goConfigFileName config.yamlDefaultConfigDir tests/scorecard/LoadConfig从 bundle 中的tests/scorecard/config.yaml读取配置可用--configflag 覆盖路径解析为v1alpha3.Configuration。仓库自带的示例配置 internal/scorecard/testdata/bundle/tests/scorecard/config.yaml 展示了配置结构stages定义执行阶段每个 stage 可设置parallel决定是否并行tests列表中的每项通过image测试镜像、entrypoint入口命令及参数和labelssuite / test 标签描述一个测试kind: Configuration apiversion: scorecard.operatorframework.io/v1alpha3 metadata: name: config stages: - parallel: true tests: - image: quay.io/operator-framework/scorecard-test:dev entrypoint: - scorecard-test - basic-check-spec labels: suite: basic test: basic-check-spec-test - image: quay.io/operator-framework/scorecard-test:dev entrypoint: - scorecard-test - olm-bundle-validation labels: suite: olm test: olm-bundle-validation-test执行编排Scorecard 与 TestRunnerinternal/scorecard/scorecard.go 定义了核心抽象TestRunner接口Initialize/RunTest/Cleanup三段生命周期Scorecard结构体持有Config、Selector标签选择器、TestRunner等Scorecard.Run遍历所有 stage按stage.Parallel选择并行或串行执行每个测试的输出聚合为v1alpha3.TestList。selectTests通过标签选择器过滤要运行的测试setTestDefaults补齐未显式指定的存储挂载路径等默认值。实际运行时使用的是PodTestRunner每个测试创建一个 Pod 执行测试镜像必要时注入 Pod 安全上下文等待容器终止后收集测试输出最后统一清理 Pod 与 ConfigMap。这一每个测试独立进程/容器 标准输出解析的模型正是提案中插件打印 JSON 到 stdout、scorecard 统一解析思想的容器化延续。CLI 参数与插件系统相关的可配置项scorecard 子命令定义在 internal/cmd/operator-sdk/scorecard/cmd.go其 flag 设计与提案中插件路径可通过 flag 配置的思路一致。常用参数包括Flag简写默认值说明--config-c空取 bundle 内默认路径scorecard 配置文件路径--selector-l空标签选择器决定运行哪些测试--output-otext输出格式text/json/xunit--namespace-n空测试镜像运行的命名空间--service-account-sdefault测试使用的 ServiceAccount--wait-time-w30s等待测试完成的时长--list-Lfalse只列出将运行的测试--skip-cleanup-xfalse测试后跳过资源清理--storage-image-bscorecard-storage镜像scorecard Pod 使用的存储镜像--untar-image-uscorecard-untar镜像scorecard Pod 使用的解包镜像--test-output-ttest-output测试输出目录--pod-security—legacylegacy/restricted控制 Pod 安全上下文其中--output json会以json.MarshalIndent输出完整结果--output xunit会把各测试状态转换为 JUnit XML 格式见convertXunit将spec.image、spec.entrypoint、labels.test、labels.cluster-phase写入属性并区分 success / failure / error 用例。run()末尾的hasFailingTest检测到任何非pass状态的结果时进程以退出码 1 结束这与 CI 集成的诉求吻合。实战参考一个真实的结果转换型插件仓库中的 images/scorecard-test-kuttl/main.go 是实现插件输出契约的最佳范本。该二进制处理 kubectl-kuttl 产生的/tmp/kuttl-report.json把 kuttl 的测试输出转换为 scorecardv1alpha3.TestStatus格式读取并解析 kuttl 报告若打不开或解析失败调用printErrorStatus输出失败状态若报告中没有测试套件输出明确错误no kuttl test suite was found. kuttl may not have run successfully成功时通过getTestStatus把 kuttl 的 Testcase 列表映射为v1alpha3.TestStatus并以缩进 JSON 打印到 stdout——这正是插件系统要求的结果以 JSON 形式输出到 stdout。这展示了插件系统最典型的用法把第三方测试工具的产物翻译为 scorecard 的标准结果结构从而让 scorecard 的聚合、评分与输出逻辑对测试来源完全无感。总结Operator SDK scorecard 插件系统提案的核心价值在于可扩展以目录中的可执行文件为单位动态增删测试无需重新编译 SDK 二进制标准化复用 Kubernetes API 序列化体系通过TypeMeta与State枚举保证结果格式的可版本化演进易集成插件只负责运行测试 打印 JSON聚合、评分与展示交给 scorecard每个插件天然成为一个独立 suite。对于希望为 scorecard 贡献自定义测试的开发者遵循的路径是编写一个把测试结果序列化为标准 JSON 的可执行程序脚本或二进制将其放入插件目录确保正确实现PassState/PartialPassState/FailState/ErrorState的状态语义与得分规则即可无缝接入 scorecard 的测试编排与结果聚合流程。赞分享云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载相关推荐AMD显卡AI创作终极指南ComfyUI-Zluda完全解决方案AMD显卡AI创作终极指南ComfyUI Zluda完全解决方案 还在为AMD显卡在AI创作领域的性能瓶颈而苦恼吗ComfyUI Zluda为您带来了革命性云原生后端开发工具微服务Operator SDK Scorecard测试评估Operator质量Operator SDK Scorecard测试评估Operator质量 在Kubernetes Operator开发过程中确保Operator的质量和可靠云原生后端开发工具微服务HTTPie Desktop完整指南10个技巧让你的API测试效率翻倍HTTPie Desktop完整指南10个技巧让你的API测试效率翻倍 HTTPie Desktop是一款跨平台的API测试客户端专为简化REST、Grap上一篇CANN/asc-devkit带转置数据加载API下一篇brpc源码重构实践提升代码可维护性的关键步骤创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Operator SDK Scorecard 插件系统设计与实现解析
云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载Operator SDK 的 scorecard 是用于对 Operator 运行通用测试套件的工具本指南以仓库中的设计提案 proposals/scorecard-plugin-system.md 为核心骨架结合当前仓库源码internal/scorecard、internal/cmd/operator-sdk/scorecard、images/scorecard-test-kuttl等系统讲解scorecard 插件系统的设计动机、可执行插件与 JSON 输出契约、测试结果数据模型与状态语义、以及内置测试与自研插件的落地方式。读完本文你将能够理解 scorecard 从“仅内置测试”到“可动态扩展测试”的演进路径掌握以脚本或二进制形式编写自定义 scorecard 测试并接入结果解析的标准姿势。背景为什么 scorecard 需要插件系统Operator SDK 的 scorecard 功能旨在让用户对 Operator 运行一组通用测试。在设计提案提出之前scorecard 只包含内置测试用户无法在不重新编译 SDK 的情况下增删测试项。这带来了两个实际问题用户自定义测试只能以内置代码的形式维护改动成本高、迭代慢复杂的端到端E2E风格测试难以用简单的内置检查表达用户需要更大的自由度。提案proposals/scorecard-plugin-system.md提出一个插件系统允许 SDK 维护者和用户在不把测试编译进 scorecard/SDK 二进制的前提下动态地添加和移除测试。核心手段是——把用户定义的测试实现为项目根目录下的可执行文件脚本或二进制scorecard 依次运行这些文件并以约定好的 JSON 格式读取测试结果。设计总览可执行文件 标准 JSON 输出插件系统的设计非常朴素而开放核心约定只有两条插件即可执行文件用户把可执行脚本或二进制放入项目根目录的指定目录例如root/scorecard/bin该路径可通过 flag 配置输出即 JSONscorecard 按顺序运行所有可执行文件每个插件需要把测试结果以 JSON 形式打印到 stdout若插件发生致命错误或没有返回合法 JSON 结果scorecard 会生成一个默认的失败 JSON 结果其中指明该二进制/脚本运行失败并附带该可执行文件打印到 stdout 的内容便于排查。这一设计使得第三方可以非常容易地创建 scorecard 插件同时 scorecard 侧解析与集成其他内置测试的逻辑保持简单——每个插件被视为一个独立的 suite测试套件整个 scorecard 的完整输出结果是一个ScorecardResult列表。从源码结构看这一思路与当前仓库中「内置测试镜像 Pod 执行 结果聚合」的运行时形态一脉相承scorecard 把每个测试当作一个独立的容器/进程执行再收集其输出统一解析插件系统只是把“测试来源”从内置镜像扩展到了任意可执行文件。结果数据模型复用 Kubernetes API 的序列化为了让 JSON 输出具备版本化演进能力插件系统的数据模型复用 Kubernetes API 的 marshalling/unmarshalling 机制通过标准化的metav1.TypeMeta字段为未来的测试定义和结果格式升级留出版本化空间。提案给出了如下 Go 结构体定义type ScorecardTest struct { metav1.TypeMeta json:,inline // Spec describes the attributes for the test. Spec *ScorecardTestSpec json:spec // Status describes the current state of the test and final results. // optional Status *ScorecardTestResults json:results,omitempty } type ScorecardTestSpec struct { // TestInfo is currently used for ScorecardTestSpec. TestInfo json:,inline } type ScorecardTestResults struct { // Log contains the scorecards current log. Log string json:log // Results is an array of ScorecardResult for each suite of the curent scorecard run. Results []ScorecardResult json:results } // ScorecardResult contains the combined results of a suite of tests type ScorecardResult struct { // Error is the number of tests that ended in the Error state Error int json:error // Pass is the number of tests that ended in the Pass state Pass int json:pass // PartialPass is the number of tests that ended in the PartialPass state PartialPass int json:partial_pass // Fail is the number of tests that ended in the Fail state Fail int json:fail // TotalTests is the total number of tests run in this suite TotalTests int json:total_tests // TotalScore is the total score of this quite as a percentage TotalScore int json:total_score_percent // Tests is an array containing a json-ified version of the TestResults for the suite Tests []*JSONTestResult json:tests } // JSONTestResult is a simplified version of the TestResult that only include the Name and Description of the Test field in TestResult type JSONTestResult struct { // State is the final state of the test State State // Name is the name of the test Name string // Description describes what the test does Description string // EarnedPoints is how many points the test received after running EarnedPoints int // MaximumPoints is the maximum number of points possible for the test MaximumPoints int // Suggestions is a list of suggestions for the user to improve their score (if applicable) Suggestions []string // Errors is a list of the errors that occurred during the test (this can include both fatal and non-fatal errors) Errors []error } // State is a type used to indicate the result state of a Test. type State string const ( // UnsetState is the default state for a TestResult. It must be updated by UpdateState or by the Test. UnsetState State unset // PassState occurs when a Tests ExpectedPoints MaximumPoints. PassState State pass // PartialPassState occurs when a Tests ExpectedPoints MaximumPoints and ExpectedPoints 0. PartialPassState State partial_pass // FailState occurs when a Tests ExpectedPoints 0. FailState State fail // ErrorState occurs when a Test encounters a fatal error and the reported points should not be considered. ErrorState State error )这些结构体语义清晰ScorecardResult是一个 suite 的聚合统计包含各状态Error / Pass / PartialPass / Fail的计数、总测试数total_tests、以及以百分比表示的套件总分total_score_percentJSONTestResult是单个测试的简化描述状态、名称、描述、获得分数EarnedPoints、最高分数MaximumPoints、改进建议列表以及错误列表State是测试结果的最终状态枚举其取值规则与得分直接挂钩得分等于满分 →pass得分大于 0 但小于满分 →partial_pass得分等于 0 →fail测试遇到致命错误分数不可信→error。在仓库实际演进中这一提案的数据模型已演化为github.com/operator-framework/api/pkg/apis/scorecard/v1alpha3包中的TestStatus、TestResult等类型。例如 internal/scorecard/scorecard.go 中的TestRunner接口直接以v1alpha3.TestConfiguration与v1alpha3.TestStatus作为运行和返回类型内置测试则通过 internal/scorecard/tests/olm.go 中的TestResult构造各状态结果并调用wrapResult包装为TestStatus。提案中的State枚举在 v1alpha3 中以同名的PassState、FailState、ErrorState等常量延续并在 scorecard.go 的convertErrorToStatus中用于把运行错误转换为失败结果。输出示例读懂一份插件测试结果提案给出了ScorecardResult对象scorecard 测试对象初始v1alpha1版本的完整 JSON 输出示例{ error: 0, pass: 1, partial_pass: 1, fail: 0, total_tests: 2, total_score_percent: 71, tests: [ { state: partial_pass, name: Operator Actions Reflected In Status, description: The operator updates the Custom Resources status when the application state is updated, earnedPoints: 2, maximumPoints: 3, suggestions: [ { suggestion: Operator should update status when scaling cluster down } ], errors: [] }, { state: pass, name: Verify health of cluster, description: The cluster created by the operator is working properly, earnedPoints: 1, maximumPoints: 1, suggestions: [], errors: [] } ] }这个示例直观展示了插件的输出契约聚合层给出该 suite 的总体分数71%与各状态计数测试层逐条给出状态、分数、建议和错误其中partial_pass的测试通过suggestions给出可操作的改进意见例如Operator should update status when scaling cluster downerrors为空数组表示没有发生错误。scorecard 侧可以据此把插件结果与内置测试结果统一聚合最终形成整个 scorecard 运行的完整结果列表。状态语义与得分规则理解State枚举是编写正确插件的基础五个状态的含义与触发条件如下状态取值触发条件含义UnsetStateunsetTestResult的默认状态必须由UpdateState或测试本身更新结果尚未定论PassStatepassExpectedPoints MaximumPoints测试满分通过PartialPassStatepartial_pass0 ExpectedPoints MaximumPoints部分通过得分不完整FailStatefailExpectedPoints 0测试失败ErrorStateerror测试遇到致命错误报告分数不应被采信从实现看当前仓库的内置测试遵循同样的语义。以 internal/scorecard/tests/basic.go 的CheckSpecTest为例它先预设PassState当获取自定义资源CR失败时把状态改为FailState并追加错误信息而 internal/scorecard/tests/olm.go 的BundleValidationTest在 bundle 格式校验失败时同样置为FailState并记录错误。这说明初始化为通过、遇到问题降级为失败/错误是 scorecard 测试的标准编写范式。从提案到实现当前仓库的 scorecard 运行机制虽然插件系统以项目根目录可执行文件为最初形态当前仓库的 scorecard 已经演进为配置驱动 Pod 运行的成熟机制理解它有助于把握插件系统的落点。核心组件如下配置加载config.yaml 驱动测试清单scorecard 的配置硬编码文件名与默认路径定义在 internal/scorecard/config.goConfigFileName config.yamlDefaultConfigDir tests/scorecard/LoadConfig从 bundle 中的tests/scorecard/config.yaml读取配置可用--configflag 覆盖路径解析为v1alpha3.Configuration。仓库自带的示例配置 internal/scorecard/testdata/bundle/tests/scorecard/config.yaml 展示了配置结构stages定义执行阶段每个 stage 可设置parallel决定是否并行tests列表中的每项通过image测试镜像、entrypoint入口命令及参数和labelssuite / test 标签描述一个测试kind: Configuration apiversion: scorecard.operatorframework.io/v1alpha3 metadata: name: config stages: - parallel: true tests: - image: quay.io/operator-framework/scorecard-test:dev entrypoint: - scorecard-test - basic-check-spec labels: suite: basic test: basic-check-spec-test - image: quay.io/operator-framework/scorecard-test:dev entrypoint: - scorecard-test - olm-bundle-validation labels: suite: olm test: olm-bundle-validation-test执行编排Scorecard 与 TestRunnerinternal/scorecard/scorecard.go 定义了核心抽象TestRunner接口Initialize/RunTest/Cleanup三段生命周期Scorecard结构体持有Config、Selector标签选择器、TestRunner等Scorecard.Run遍历所有 stage按stage.Parallel选择并行或串行执行每个测试的输出聚合为v1alpha3.TestList。selectTests通过标签选择器过滤要运行的测试setTestDefaults补齐未显式指定的存储挂载路径等默认值。实际运行时使用的是PodTestRunner每个测试创建一个 Pod 执行测试镜像必要时注入 Pod 安全上下文等待容器终止后收集测试输出最后统一清理 Pod 与 ConfigMap。这一每个测试独立进程/容器 标准输出解析的模型正是提案中插件打印 JSON 到 stdout、scorecard 统一解析思想的容器化延续。CLI 参数与插件系统相关的可配置项scorecard 子命令定义在 internal/cmd/operator-sdk/scorecard/cmd.go其 flag 设计与提案中插件路径可通过 flag 配置的思路一致。常用参数包括Flag简写默认值说明--config-c空取 bundle 内默认路径scorecard 配置文件路径--selector-l空标签选择器决定运行哪些测试--output-otext输出格式text/json/xunit--namespace-n空测试镜像运行的命名空间--service-account-sdefault测试使用的 ServiceAccount--wait-time-w30s等待测试完成的时长--list-Lfalse只列出将运行的测试--skip-cleanup-xfalse测试后跳过资源清理--storage-image-bscorecard-storage镜像scorecard Pod 使用的存储镜像--untar-image-uscorecard-untar镜像scorecard Pod 使用的解包镜像--test-output-ttest-output测试输出目录--pod-security—legacylegacy/restricted控制 Pod 安全上下文其中--output json会以json.MarshalIndent输出完整结果--output xunit会把各测试状态转换为 JUnit XML 格式见convertXunit将spec.image、spec.entrypoint、labels.test、labels.cluster-phase写入属性并区分 success / failure / error 用例。run()末尾的hasFailingTest检测到任何非pass状态的结果时进程以退出码 1 结束这与 CI 集成的诉求吻合。实战参考一个真实的结果转换型插件仓库中的 images/scorecard-test-kuttl/main.go 是实现插件输出契约的最佳范本。该二进制处理 kubectl-kuttl 产生的/tmp/kuttl-report.json把 kuttl 的测试输出转换为 scorecardv1alpha3.TestStatus格式读取并解析 kuttl 报告若打不开或解析失败调用printErrorStatus输出失败状态若报告中没有测试套件输出明确错误no kuttl test suite was found. kuttl may not have run successfully成功时通过getTestStatus把 kuttl 的 Testcase 列表映射为v1alpha3.TestStatus并以缩进 JSON 打印到 stdout——这正是插件系统要求的结果以 JSON 形式输出到 stdout。这展示了插件系统最典型的用法把第三方测试工具的产物翻译为 scorecard 的标准结果结构从而让 scorecard 的聚合、评分与输出逻辑对测试来源完全无感。总结Operator SDK scorecard 插件系统提案的核心价值在于可扩展以目录中的可执行文件为单位动态增删测试无需重新编译 SDK 二进制标准化复用 Kubernetes API 序列化体系通过TypeMeta与State枚举保证结果格式的可版本化演进易集成插件只负责运行测试 打印 JSON聚合、评分与展示交给 scorecard每个插件天然成为一个独立 suite。对于希望为 scorecard 贡献自定义测试的开发者遵循的路径是编写一个把测试结果序列化为标准 JSON 的可执行程序脚本或二进制将其放入插件目录确保正确实现PassState/PartialPassState/FailState/ErrorState的状态语义与得分规则即可无缝接入 scorecard 的测试编排与结果聚合流程。赞分享云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载相关推荐AMD显卡AI创作终极指南ComfyUI-Zluda完全解决方案AMD显卡AI创作终极指南ComfyUI Zluda完全解决方案 还在为AMD显卡在AI创作领域的性能瓶颈而苦恼吗ComfyUI Zluda为您带来了革命性云原生后端开发工具微服务Operator SDK Scorecard测试评估Operator质量Operator SDK Scorecard测试评估Operator质量 在Kubernetes Operator开发过程中确保Operator的质量和可靠云原生后端开发工具微服务HTTPie Desktop完整指南10个技巧让你的API测试效率翻倍HTTPie Desktop完整指南10个技巧让你的API测试效率翻倍 HTTPie Desktop是一款跨平台的API测试客户端专为简化REST、Grap上一篇CANN/asc-devkit带转置数据加载API下一篇brpc源码重构实践提升代码可维护性的关键步骤创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
