尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

OpenShift origin openshift/csi 套件:基于双清单配置的 CSI 驱动认证测试与 LUN 压力测试实战指南

发布时间:2026/9/25 2:27:25

资讯中心
01
ARTICLE

OpenShift origin openshift/csi 套件:基于双清单配置的 CSI 驱动认证测试与 LUN 压力测试实战指南

OpenShift origin openshift/csi 套件:基于双清单配置的 CSI 驱动认证测试与 LUN 压力测试实战指南
测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载本文围绕 test/extended/storage/csi/README.md 展开讲解 OpenShift origin 仓库中openshift/csi测试套件如何复用上 Kubernetes 上游存储测试、通过两个环境变量的 YAML 清单控制 CSI 驱动的功能测试范围以及 OpenShift 特有的LUNStressTest单节点 LUN 压力测试的设计原理与运行方法。读完本文你可以独立完成一套 CSI 驱动的认证测试编写上游/ OpenShift 两份清单、运行openshift-tests或tests容器镜像、用--dry-run/--run/run-test定位失败用例并理解这些测试在源码中的注册与执行链路。说明引自原文档本文档不受 Red Hat 支持其目的是帮助调试测试或 CSI 驱动本身。提交正式的 CSI 驱动测试结果应遵循 Red Hat 官方文档流程。一、openshift/csi 套件的定位复用上游存储测试 OpenShift 特有用例openshift/csi套件包含针对一个已安装 CSI 驱动的功能测试。它的核心思路是复用上游直接复用 Kubernetes 上游的test/e2e/storage/external存储测试框架及其 YAML 驱动清单测试项以External Storage [Driver: driver name]为前缀叠加 OpenShift 特有测试在上游测试之上追加若干 OpenShift 特定的测试套件源码位于 test/extended/storage/csi/csi.go目前主要有两类OpenShift CSI extended - SCSI LUN OverflowLUN 压力测试需 OpenShift 清单启用见 test/extended/storage/csi/scsi_overflow.goOpenShift CSI extended - CSI ClonePVC 克隆到更大卷的测试只要设置了上游清单就会自动注册见 test/extended/storage/csi/pvc_clone_larger.go。套件在 pkg/testsuites/standard_suites.go 中注册其选择器qualifier决定了哪些 ginkgo 测试属于本套件Qualifiers: []string{ name.contains(External Storage [Driver:) !name.contains([Disabled:) !name.contains([Flaky]) !name.contains([Disruptive]), },也就是说openshift/csi运行所有匹配External Storage [Driver:前缀、且未被标记为 Disabled/Flaky/Disruptive 的测试。二、两个清单文件与环境变量两个 YAML 文件控制“测试哪些 CSI 驱动功能、怎么测”。openshift-tests二进制接受两个环境变量常量定义见 pkg/clioptions/clusterdiscovery/csi.go环境变量是否必需作用TEST_CSI_DRIVER_FILES必需指向上游CSI 驱动测试清单文件格式遵循上游 kubernetes 仓库test/e2e/storage/external的 README将 master 替换为与集群对应的版本分支即可找到对应格式说明。TEST_OCP_CSI_DRIVER_FILES可选指向OpenShift 特有测试清单文件格式见下文。设置后会在上游测试之外额外运行 OCP 特有测试。从源码 pkg/clioptions/clusterdiscovery/csi.go 的InitCSITests还可以确认几点原文档未展开的实现细节两个变量都支持逗号分隔的多个清单文件会逐个加载每个上游清单中必须能解析出DriverInfo.Name驱动名OCP 清单中的Driver字段必须与某个上游清单对应否则直接报错env. var TEST_OCP_CSI_DRIVER_FILES must describe the same CSI drivers as TEST_CSI_DRIVER_FILES——即允许缺 OCP 清单CI 中常见但 OCP 清单里出现的驱动必须有对应上游清单上游清单所在目录会被注册为测试框架的文件源testfiles.AddFileSource以便在清单中用FromFile字段引用同目录下的 StorageClass 定义该初始化发生在测试二进制启动阶段pkg/test/extensions/binary.go 中构建 ginkgo 测试 spec 之前调用clusterdiscovery.InitCSITests()且 spec 过滤逻辑特意保留所有External Storage前缀的用例。OpenShift 特有清单的格式示例来自原文档Driver: CSI driver name LUNStressTest: PodsTotal: 260 Timeout: 40m其中Driver必须与某个上游清单中的驱动名一致。LUNStressTest是单节点压力测试的配置语义见下一节。清单的解析入口是 AddOpenShiftCSITests它先填入默认值再用runtime.DecodeInto把 YAML 解码进OpenShiftCSIDriverConfig结构体最后把测试套件追加到上游框架的testsuites.CSISuites全局列表中——因此它必须先于external.AddDriverDefinition真正遍历已注册套件并生成 ginkgo 测试的函数执行。三、LUNStressTest单节点 260 卷压力测试的原理LUNStressTest用于在单个节点上压测 CSI 驱动。测试会挑选一个随机的可调度节点并在其上创建配置的 Pod PVC 数量默认 260。每个 Pod 持有自己独立的 PVC需要 CSI 驱动动态供给源码 scsi_overflow.go 中先createSC创建 StorageClass再循环startTestPod创建pvc-Npod-N每个 Pod 只做一个非常简单的操作如ls -la /mnt/the_volume见 scsi_overflow.go 中Command: ls -la e2epod.VolumeMountPath1然后很快退出所有这些 Pod 会被相对快速地集中创建但测试并不期望它们全部并行运行期望 CSI 驱动在请求过多时返回超时和其他错误OpenShift/CSI sidecar 会以指数退避方式重试Kubernetes 应尊重 CSINode 中报告的 attach limit因此同一时刻运行的 Pod 数量不应超过该上限需要注意Kubernetes 曾存在一个调度器可能向单节点塞入超过 CSI 驱动支持数量的 Pod 的 bugkubernetes/kubernetes#126502scsi_overflow.go 的注释中同样引用了该 issue。测试期望 CSI 驱动足够健壮在超限时对ControllerPublish、NodeStage或NodePublish返回合理的错误。超时Timeout应留足以容纳 260 个卷的动态供给、attach、mount、unmount、detach 和 PV 删除的全周期该测试运行期间没有其他测试并行测试用例带[Serial]标记见 scsi_overflow.go让 CSI 驱动可以完全专注处理这次压力。参数说明参数含义默认值PodsTotal创建的 Pod 数量每个 Pod 一个卷。设为0可显式禁用该测试260csi.go 中DefaultLUNStressTestPodsTotalTimeout等待全部 Pod 完成的时长接受 Gotime.ParseDuration后缀如1h30m15s表示 1 小时 30 分 15 秒40mDefaultLUNStressTestTimeout官方强烈建议用 257 个及以上 Pod 进行测试并建议测试在 1 小时内完成。历史上出现过 CSI 驱动或 RHCOS 节点配置在处理 LUN 号大于 256 时出问题的案例。即使 CSI 驱动不使用 LUN这也是一次很有价值的压力测试它验证驱动能报告合理的 attach limit、并能承受一定负载。源码层面还可以确认测试的执行细节scsi_overflow.go用例名为should use many PVs on a single node [Serial][Timeout:timeout]Timeout值会同步传播为 ginkgo 的[Timeout:...]标注流程为GetRandomReadySchedulableNode选节点 →driver.PrepareTest准备配置 → 创建 StorageClass并要求驱动实现DynamicPVTestDriver即支持动态供给→ 一次性创建全部 PodstartTestPod不等待 Pod 启动→waitForPodsComplete以 10 秒轮询间隔等待所有 Pod 到达Succeeded阶段剩余等待时长为总 Timeout 减去创建 Pod 已消耗的时间若清单中LUNStressTest为nil或PodsTotal为 0测试会被g.Skip跳过PVC 容量取驱动SupportedSizeRange.Min未声明时回退为1Gi访问模式固定ReadWriteOnce并显式指定调度到被选中的节点。四、附赠的 OpenShift 特有测试PVC 克隆到更大的卷除了 LUN 压力测试只要设置了TEST_CSI_DRIVER_FILES无需 OCP 清单RegisterAlwaysOnCSISuites 就会注册pvcCloneLargerCSISuite套件名OpenShift CSI extended - CSI Clone测试模式覆盖DefaultFsDynamicPV与BlockVolModeDynamicPV两种卷模式。它验证“克隆 PVC 时目标卷大于源卷”的场景先向源 PVC 写入测试数据再以源容量 1Gi作为请求大小创建带dataSourceRef的克隆 PVC最后校验克隆卷中包含源数据实现见 pvc_clone_larger.go。该测试会自动按驱动能力跳过不支持CapPVCDataSource克隆、块模式下不支持CapBlock、或文件系统模式不支持从源端扩展文件系统CapFSResizeFromSourceNotSupported的驱动会被Skip。五、运行方式5.1 使用openshift-tests二进制自行编译openshift-tests二进制在本仓库执行make或从 OpenShift 镜像中提取。务必使用与你已安装的 OpenShift 版本对应的openshift-tests二进制设置KUBECONFIG环境变量指向你的客户端配置。设置TEST_CSI_DRIVER_FILES为上游清单。可选设置TEST_OCP_CSI_DRIVER_FILES为 OpenShift 测试清单。运行测试套件openshift-tests run openshift/csi。示例原文档export TEST_CSI_DRIVER_FILESupstream-manifest.yaml # this is mandatory export TEST_OCP_CSI_DRIVER_FILESocp-manifest.yaml # this is optional ./openshift-tests run openshift/csi | tee test.log5.2 使用 OpenShift 发布中的tests容器镜像这与上面运行openshift-tests二进制大致等价只是二进制位于容器镜像内。在当前目录准备好kubeconfig.yaml、上游测试清单以及可选的 OpenShift 测试清单找到与你的 OpenShift 集群版本对应的、包含openshift-tests的镜像$ oc adm release info --image-fortests quay.io/openshift-release-dev/ocp-v4.0-art-devsha256:8e43b259635d5adcef769f5f4359554395c900d7211915249ee66b5602fea5b9在tests容器镜像中运行openshift-tests把当前目录以/data挂载进容器并透传所有环境变量podman run -v pwd:/data:z --rm -it quay.io/openshift-release-dev/ocp-v4.0-art-devsha256:8e43b259635d5adcef769f5f4359554395c900d7211915249ee66b5602fea5b9 \ sh -c KUBECONFIG/data/kubeconfig.yaml TEST_CSI_DRIVER_FILES/data/upstream-manifest.yaml TEST_OCP_CSI_DRIVER_FILES/data/ocp-manifest.yaml /usr/bin/openshift-tests run openshift/csi --junit-dir /data/results5.3 调试技巧原文档 Tips 全量整理openshift-tests在跑任何测试之前会启动一组 monitors持续监控测试期间的整体集群健康确保某个测试不会把整个集群搞坏。这些 monitors 非常“话痨”会在当前目录产生大量文件openshift-tests run openshift/csi --dry-run可以列出将要运行的测试openshift-tests run openshift/csi --runregexp只运行匹配的特定测试可搭配--dry-run反复微调正则用--help查看更多命令行选项openshift-tests run-test full test name运行单个测试且不启动任何 monitor输出几乎无噪音是调试单个测试的最佳方式。full test name必须与--dry-run打印的内容完全一致包括所有空格请谨慎整行复制粘贴--dry-run输出含双引号。例如./openshift-tests run-test External Storage [Driver: cooldriver.coolstorage.com] [Testpattern: Pre-provisioned PV (ext4)] volumes should store data使用tests容器镜像时上述任意命令行参数同样可以透传给镜像内的openshift-tests。六、关键结论与适用前提本套件的适用前提是集群中已安装被测 CSI 驱动且你持有对应版本的openshift-tests二进制或tests镜像版本不匹配可能导致测试框架与集群 API 行为不一致上游清单是硬性要求没有TEST_CSI_DRIVER_FILES时InitCSITests不会注册任何 CSI 测试也不会注册 always-on 的 Clone 测试OCP 清单是增量项它通过AddOpenShiftCSITests在testsuites.CSISuites中注入 LUN 压力测试因此必须在驱动定义加载前完成——这也是源码中“Load OCP specific tests first”注释要保证的时序若你的目标是验证驱动在高并发 attach 下的稳健性尤其是 SCSI/LUN 编号边界把LUNStressTest.PodsTotal设为 257 以上、Timeout预留 1 小时以内是官方建议的认证强度。赞分享测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载相关推荐OpenShift Origin 扩展测试实战NVIDIA DRA动态资源分配GPU 调度验证套件OpenShift Origin 扩展测试实战NVIDIA DRA动态资源分配GPU 调度验证套件 本文基于 test/extended/node/dra测试云原生质量保障Debezium OpenShift 部署验证套件实战指南基于 Strimzi 的 Kafka Connect 集群端到端测试Debezium OpenShift 部署验证套件实战指南基于 Strimzi 的 Kafka Connect 集群端到端测试 本文基于 Debezium 仓后端变更数据捕获数据集成流处理OpenShift origin MonitorTests与测试套件并行运行的集群观测器原理与实现OpenShift origin MonitorTests与测试套件并行运行的集群观测器原理与实现 MonitorTests 是 OpenShift orig测试云原生质量保障上一篇KOReader 跨设备同步设置方法批注与阅读进度双端互通完整教程下一篇CapsNet-Keras 项目结构解析理解胶囊网络代码组织的黄金法则创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

◈

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

◐

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

▲

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。