指定测试开始运行后的时间（以秒为单位）。您可以使用此变量来允许 CPU 管理器协调循环更新默认 CPU 池。默认值为 0。
×
执行平台验证的延迟测试
您可以使用云原生网络功能 (CNF) 测试镜像在启用 CNF 的 OpenShift Container Platform 集群上运行延迟测试，其中安装了运行 CNF 工作负载所需的所有组件。运行延迟测试以验证工作负载的节点调整。
cnf-tests 容器镜像位于 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17。
运行延迟测试的先决条件
在运行延迟测试之前，您的集群必须满足以下要求：
-
您已应用所有必需的 CNF 配置。这包括根据参考设计规范 (RDS) 或您的特定要求的
PerformanceProfile集群和其他配置。 -
您已使用
podman login命令使用您的客户门户凭据登录到registry.redhat.io。
其他资源
测量延迟
cnf-tests 镜像使用三种工具来测量系统的延迟：
-
hwlatdetect -
cyclictest -
oslat
每个工具都有其特定的用途。按顺序使用这些工具以获得可靠的测试结果。
- hwlatdetect
-
测量裸机硬件可以达到的基线。在进行下一个延迟测试之前，请确保
hwlatdetect报告的延迟满足所需阈值，因为您无法通过操作系统调整来修复硬件延迟峰值。 - cyclictest
-
在
hwlatdetect通过验证后，验证实时内核调度程序延迟。cyclictest工具调度重复计时器并测量所需触发时间和实际触发时间之间的差异。差异可以发现由中断或进程优先级引起的调整基本问题。该工具必须在实时内核上运行。 - oslat
-
其行为类似于 CPU 密集型 DPDK 应用程序，并测量对模拟 CPU 密集型数据处理的繁忙循环的所有中断和干扰。
测试引入以下环境变量：
| 环境变量 | 描述 | ||
|---|---|---|---|
|
|||
|
指定运行延迟测试的 Pod 使用的 CPU 数量。如果未设置此变量，则默认配置包括所有隔离的 CPU。 |
||
|
指定延迟测试必须运行的时间（以秒为单位）。默认值为 300 秒。
|
||
|
指定工作负载和操作系统可接受的最大硬件延迟（微秒）。如果您未设置 |
||
|
指定 |
||
|
指定 |
||
|
统一变量，指定可接受的最大延迟（微秒）。适用于所有可用的延迟工具。 |
|
特定于延迟工具的变量优先于统一变量。例如，如果将 |
运行延迟测试
运行集群延迟测试以验证您云原生网络功能 (CNF) 工作负载的节点调优。
|
以非 root 或非特权用户身份执行 |
此过程运行三个单独的测试：hwlatdetect、cyclictest和oslat。有关这些单独测试的详细信息，请参阅其各自的部分。
步骤
-
在包含
kubeconfig文件的目录中打开 shell 提示符。您通过卷挂载当前目录中的
kubeconfig文件及其相关的$KUBECONFIG环境变量来提供测试镜像。这允许运行中的容器从容器内部使用kubeconfig文件。在以下命令中，您的本地
kubeconfig被挂载到 cnf-tests 容器中的 kubeconfig/kubeconfig，从而允许访问集群。 -
要运行延迟测试，请运行以下命令，并根据需要替换变量值。
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=600\ -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 /usr/bin/test-run.sh \ --ginkgo.v --ginkgo.timeout="24h"LATENCY_TEST_RUNTIME 以秒为单位显示，在本例中为 600 秒（10 分钟）。当观察到的最大延迟低于 MAXIMUM_LATENCY (20 μs) 时，测试成功运行。
如果结果超过延迟阈值，则测试失败。
-
可选：追加
--ginkgo.dry-run标志以干运行模式运行延迟测试。这对于检查测试运行的命令很有用。 -
可选：追加
--ginkgo.v标志以提高详细程度运行测试。 -
可选：追加
--ginkgo.timeout="24h"标志以确保 Ginkgo 2.0 测试套件在延迟测试完成前不会超时。在测试较短的时间段内，可以使用此处显示的时间段来运行测试。但是，为了进行最终验证并获得有效结果，测试应至少运行 12 小时（43200 秒）。
运行 hwlatdetect
hwlatdetect工具在具有 Red Hat Enterprise Linux (RHEL) 9.x 正式订阅的rt-kernel包中可用。
|
以非 root 或非特权用户身份执行 |
先决条件
-
您已查看运行延迟测试的先决条件。
步骤
-
要运行
hwlatdetect测试，请运行以下命令，并根据需要替换变量值。$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ /usr/bin/test-run.sh --ginkgo.focus="hwlatdetect" --ginkgo.v --ginkgo.timeout="24h"hwlatdetect测试运行 10 分钟（600 秒）。当观察到的最大延迟低于MAXIMUM_LATENCY（20 μs）时，测试成功运行。如果结果超过延迟阈值，则测试失败。
在测试较短的时间段内，可以使用此处显示的时间段来运行测试。但是，为了进行最终验证并获得有效结果，测试应至少运行 12 小时（43200 秒）。
示例失败输出running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=hwlatdetect I0908 15:25:20.023712 27 request.go:601] Waited for 1.046586367s due to client-side throttling, not priority and fairness, request: GET:https://api.hlxcl6.lab.eng.tlv2.redhat.com:6443/apis/imageregistry.operator.openshift.io/v1?timeout=32s Running Suite: CNF Features e2e integration tests ================================================= Random Seed: 1662650718 Will run 1 of 3 specs [...] • Failure [283.574 seconds] [performance] Latency Test /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62 with the hwlatdetect image /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:228 should succeed [It] /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:236 Log file created at: 2022/09/08 15:25:27 Running on machine: hwlatdetect-b6n4n Binary: Built with gc go1.17.12 for linux/amd64 Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg I0908 15:25:27.160620 1 node.go:39] Environment information: /proc/cmdline: BOOT_IMAGE=(hd1,gpt3)/ostree/rhcos-c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/vmlinuz-4.18.0-372.19.1.el8_6.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=metal ostree=/ostree/boot.1/rhcos/c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/0 ip=dhcp root=UUID=5f80c283-f6e6-4a27-9b47-a287157483b2 rw rootflags=prjquota boot=UUID=773bf59a-bafd-48fc-9a87-f62252d739d3 skew_tick=1 nohz=on rcu_nocbs=0-3 tuned.non_isolcpus=0000ffff,ffffffff,fffffff0 systemd.cpu_affinity=4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79 intel_iommu=on iommu=pt isolcpus=managed_irq,0-3 nohz_full=0-3 tsc=nowatchdog nosoftlockup nmi_watchdog=0 mce=off skew_tick=1 rcutree.kthread_prio=11 + + I0908 15:25:27.160830 1 node.go:46] Environment information: kernel version 4.18.0-372.19.1.el8_6.x86_64 I0908 15:25:27.160857 1 main.go:50] running the hwlatdetect command with arguments [/usr/bin/hwlatdetect --threshold 1 --hardlimit 1 --duration 100 --window 10000000us --width 950000us] F0908 15:27:10.603523 1 main.go:53] failed to run hwlatdetect command; out: hwlatdetect: test duration 100 seconds detector: tracer parameters: Latency threshold: 1us (1) Sample window: 10000000us Sample width: 950000us Non-sampling period: 9050000us Output File: None Starting test test finished Max Latency: 326us (2) Samples recorded: 5 Samples exceeding threshold: 5 ts: 1662650739.017274507, inner:6, outer:6 ts: 1662650749.257272414, inner:14, outer:326 ts: 1662650779.977272835, inner:314, outer:12 ts: 1662650800.457272384, inner:3, outer:9 ts: 1662650810.697273520, inner:3, outer:2 [...] JUnit report was created: /junit.xml/cnftests-junit.xml Summarizing 1 Failure: [Fail] [performance] Latency Test with the hwlatdetect image [It] should succeed /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:476 Ran 1 of 194 Specs in 365.797 seconds FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped --- FAIL: TestTest (366.08s) FAIL1 您可以使用 MAXIMUM_LATENCY或HWLATDETECT_MAXIMUM_LATENCY环境变量来配置延迟阈值。2 测试期间测量的最大延迟值。
示例 hwlatdetect 测试结果
您可以捕获以下类型的结果：
-
每次运行后收集的粗略结果，以创建测试过程中所做任何更改的影响历史记录。
-
具有最佳结果和配置设置的粗略测试的组合集。
良好结果示例
hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None
Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0如果样本超过指定的阈值，则hwlatdetect工具才会提供输出。
不良结果示例
hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None
Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63hwlatdetect的输出显示多个样本超过阈值。但是，根据以下因素，相同的输出可能表示不同的结果：
-
测试持续时间
-
CPU 核心数
-
主机固件设置
|
在进行下一个延迟测试之前，请确保 并非所有延迟峰值都与硬件相关。确保您调整主机固件以满足您的工作负载要求。有关更多信息，请参阅设置固件参数以进行系统调优。 |
运行 cyclictest
cyclictest工具测量指定 CPU 上的实时内核调度程序延迟。
|
以非 root 或非特权用户身份执行 |
先决条件
-
您已查看运行延迟测试的先决条件。
步骤
-
要执行
cyclictest，请运行以下命令，并根据需要替换变量值。$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ /usr/bin/test-run.sh --ginkgo.focus="cyclictest" --ginkgo.v --ginkgo.timeout="24h"该命令运行
cyclictest工具 10 分钟（600 秒）。当观察到的最大延迟低于MAXIMUM_LATENCY（在此示例中为 20 μs）时，测试成功运行。对于电信 RAN 工作负载，通常不接受 20 μs 及以上的延迟峰值。如果结果超过延迟阈值，则测试失败。
在测试较短的时间段内，可以使用此处显示的时间段来运行测试。但是，为了进行最终验证并获得有效结果，测试应至少运行 12 小时（43200 秒）。
示例失败输出running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=cyclictest I0908 13:01:59.193776 27 request.go:601] Waited for 1.046228824s due to client-side throttling, not priority and fairness, request: GET:https://api.compute-1.example.com:6443/apis/packages.operators.coreos.com/v1?timeout=32s Running Suite: CNF Features e2e integration tests ================================================= Random Seed: 1662642118 Will run 1 of 3 specs [...] Summarizing 1 Failure: [Fail] [performance] Latency Test with the cyclictest image [It] should succeed /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:220 Ran 1 of 194 Specs in 161.151 seconds FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped --- FAIL: TestTest (161.48s) FAIL
示例 cyclictest 结果
对于不同的工作负载，相同的输出可能表示不同的结果。例如，对于 4G DU 工作负载，高达 18μs 的峰值是可以接受的，但对于 5G DU 工作负载则不行。
良好结果示例
running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000
000001 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000
000002 579506 535967 418614 573648 532870 529897 489306 558076 582350 585188 583793 223781 532480 569130 472250 576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:不良结果示例
running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000
000001 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000
000002 564632 579686 354911 563036 492543 521983 515884 378266 592621 463547 482764 591976 590409 588145 589556 353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917运行 oslat
oslat测试模拟一个 CPU 密集型 DPDK 应用程序，并测量所有中断和干扰，以测试集群如何处理 CPU 密集型数据处理。
|
以非 root 或非特权用户身份执行 |
先决条件
-
您已查看运行延迟测试的先决条件。
步骤
-
要执行
oslat测试，请运行以下命令，并根据需要替换变量值。$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ /usr/bin/test-run.sh --ginkgo.focus="oslat" --ginkgo.v --ginkgo.timeout="24h"LATENCY_TEST_CPUS指定要使用oslat命令测试的 CPU 数量。该命令运行
oslat工具 10 分钟（600 秒）。当观察到的最大延迟低于MAXIMUM_LATENCY（20 μs）时，测试成功运行。如果结果超过延迟阈值，则测试失败。
在测试较短的时间段内，可以使用此处显示的时间段来运行测试。但是，为了进行最终验证并获得有效结果，测试应至少运行 12 小时（43200 秒）。
示例失败输出running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=oslat I0908 12:51:55.999393 27 request.go:601] Waited for 1.044848101s due to client-side throttling, not priority and fairness, request: GET:https://compute-1.example.com:6443/apis/machineconfiguration.openshift.io/v1?timeout=32s Running Suite: CNF Features e2e integration tests ================================================= Random Seed: 1662641514 Will run 1 of 3 specs [...] • Failure [77.833 seconds] [performance] Latency Test /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62 with the oslat image /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:128 should succeed [It] /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:153 The current latency 304 is bigger than the expected one 1 : (1) [...] Summarizing 1 Failure: [Fail] [performance] Latency Test with the oslat image [It] should succeed /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:177 Ran 1 of 194 Specs in 161.091 seconds FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped --- FAIL: TestTest (161.42s) FAIL1 在此示例中，测量的延迟超过最大允许值。
生成延迟测试失败报告
使用以下步骤生成 JUnit 延迟测试输出和测试失败报告。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。
步骤
-
通过传递带有报告转储路径的
--report参数，创建一个包含有关集群状态和资源的信息的测试失败报告，以便进行故障排除。$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \ -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ /usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v其中
- <report_folder_path>
-
是生成报告的文件夹的路径。
生成 JUnit 延迟测试报告
使用以下步骤生成 JUnit 延迟测试输出和测试失败报告。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。
步骤
-
通过传递
--junit参数以及报告的存储路径来创建一个符合 JUnit 规范的 XML 报告。您必须在运行此命令之前创建
junit文件夹。$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junit:/junit \ -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ /usr/bin/test-run.sh --ginkgo.junit-report junit/<file-name>.xml --ginkgo.v其中
junit-
是存储 JUnit 报告的文件夹。
在单节点 OpenShift 集群上运行延迟测试
您可以在单节点 OpenShift 集群上运行延迟测试。
|
当以非 root 或非特权用户身份执行 |
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 -
您已使用节点调优操作符应用了集群性能配置文件。
步骤
-
要在单节点 OpenShift 集群上运行延迟测试，请运行以下命令：
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"每个测试的默认运行时间为 300 秒。为了获得有效的延迟测试结果，请通过更新
LATENCY_TEST_RUNTIME变量至少运行测试 12 小时。要运行桶延迟验证步骤，必须指定最大延迟。有关最大延迟变量的详细信息，请参见“测量延迟”部分中的表格。测试套件运行完成后，所有悬空资源都会被清理。
在断开连接的集群中运行延迟测试
CNF 测试镜像可以在无法访问外部注册表的断开连接的集群中运行测试。这需要两个步骤：
-
将
cnf-tests镜像镜像到自定义断开连接的注册表。 -
指示测试从自定义断开连接的注册表中使用镜像。
将镜像镜像到集群可访问的自定义注册表
镜像中提供了一个mirror可执行文件，用于提供oc镜像测试镜像到本地注册表所需的输入。
-
从可以访问集群和registry.redhat.io的中间机器运行此命令。
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -其中
- <disconnected_registry>
-
是您已配置的断开连接的镜像注册表，例如
my.local.registry:5000/。
-
将
cnf-tests镜像镜像到断开连接的注册表后，必须覆盖运行测试时用于获取镜像的原始注册表，例如：podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e IMAGE_REGISTRY="<disconnected_registry>" \ -e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.17" \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ <disconnected_registry>/cnf-tests-rhel8:v4.17 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
配置测试以从自定义注册表使用镜像
您可以使用自定义测试镜像和镜像注册表（使用CNF_TESTS_IMAGE和IMAGE_REGISTRY变量）运行延迟测试。
-
要配置延迟测试以使用自定义测试镜像和镜像注册表，请运行以下命令：
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e IMAGE_REGISTRY="<custom_image_registry>" \ -e CNF_TESTS_IMAGE="<custom_cnf-tests_image>" \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"其中
- <custom_image_registry>
-
是自定义镜像注册表，例如
custom.registry:5000/。 - <custom_cnf-tests_image>
-
是自定义 cnf-tests 镜像，例如
custom-cnf-tests-image:latest。
将镜像镜像到集群 OpenShift 镜像注册表
OpenShift Container Platform 提供了一个内置的容器镜像注册表，它作为集群上的标准工作负载运行。
步骤
-
通过使用路由公开注册表来获取外部访问权限。
$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge -
通过运行以下命令获取注册表端点：
$ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}') -
创建用于公开镜像的命名空间：
$ oc create ns cnftests -
使镜像流可用于所有用于测试的命名空间。这是为了允许测试命名空间从
cnf-tests镜像流中获取镜像。运行以下命令：$ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests$ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests -
通过运行以下命令检索 docker 密钥名称和授权令牌：
$ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}$ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth') -
创建一个
dockerauth.json文件，例如：$ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json -
执行镜像镜像：
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:4.17 \ /usr/bin/mirror -registry $REGISTRY/cnftests | oc image mirror --insecure=true \ -a=$(pwd)/dockerauth.json -f - -
运行测试：
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
镜像不同的测试镜像集
您可以选择更改为延迟测试镜像的默认上游镜像。
步骤
-
mirror命令默认尝试镜像上游镜像。这可以通过将具有以下格式的文件传递给镜像来覆盖：[ { "registry": "public.registry.io:5000", "image": "imageforcnftests:4.17" } ] -
将文件传递给
mirror命令，例如将其本地保存为images.json。使用以下命令，本地路径将挂载到容器内的/kubeconfig中，并且可以将其传递给镜像命令。$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 /usr/bin/mirror \ --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \ | oc image mirror -f -
cnf-tests 容器错误排查
要运行延迟测试，集群必须可以从cnf-tests容器内访问。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。
步骤
-
通过运行以下命令验证集群是否可以从
cnf-tests容器内部访问：$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17 \ oc get nodes如果此命令不起作用，则可能发生与跨 DNS、MTU 大小或防火墙访问相关的错误。