This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.16.7. プラットフォーム検証のエンドツーエンドテストの実行
Cloud-native Network Functions (CNF) テストイメージは、CNF ペイロードの実行に必要な機能を検証するコンテナー化されたテストスイートです。このイメージを使用して、CNF ワークロードの実行に必要なすべてのコンポーネントがインストールされている CNF 対応の OpenShift クラスターを検証できます。
イメージで実行されるテストは、3 つの異なるフェーズに分かれます。
- 単純なクラスター検証
- セットアップ
- エンドツーエンドテスト
検証フェーズでは、テストに必要なすべての機能がクラスターに正しくデプロイされていることを確認します。
検証には以下が含まれます。
- テストするマシンに属するマシン設定プールのターゲット設定
- ノードでの SCTP の有効化
- マシン設定を使用した xt_u32 カーネルモジュールの有効化
- Performance Addon Operator がインストールされていること
- SR-IOV Operator がインストールされていること
- PTP Operator がインストールされていること
- OVN kubernetes の SDN としての使用
CNF-test コンテナーの一部であるレイテンシーテストでも、同じ検証が必要になります。レイテンシーテストの実行に関する詳細は、レイテンシーテストの実行セクションを参照してください。
テストは、実行されるたびに環境設定を実行する必要があります。これには、SR-IOV ノードポリシー、パフォーマンスプロファイル、または PTP プロファイルの作成などの項目が関係します。テストですでに設定されているクラスターを設定できるようにすると、クラスターの機能が影響を受ける可能性があります。また、SR-IOV ノードポリシーなどの設定項目への変更により、設定の変更が処理されるまで環境が一時的に利用できなくなる可能性があります。
16.7.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
-
テストエントリーポイントは
/usr/bin/test-run.shです。設定されたテストセットと実際の適合テストスイートの両方を実行します。最小要件として、これをボリューム経由でマウントされる kubeconfig ファイルおよび関連する$KUBECONFIG環境変数と共に指定します。 - このテストでは、特定の機能が Operator、クラスターで有効にされるフラグ、またはマシン設定の形式でクラスターで利用可能であることを前提としています。
テストによっては、変更を追加するための既存のマシン設定プールが必要です。これは、テストを実行する前にクラスター上に作成する必要があります。
デフォルトのワーカープールは
worker-cnfであり、以下のマニフェストを使用して作成できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ROLE_WORKER_CNF変数を使用して、ワーカープール名を上書きできます。docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e ROLE_WORKER_CNF=custom-worker-pool registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記現時点で、プールに属するノードですべてのテストが選択的に実行される訳ではありません。
16.7.2. テストの実行 リンクのコピーリンクがクリップボードにコピーされました!
kubeconfig ファイルが現在のフォルダーにある場合、テストスイートを実行するコマンドは以下のようになります。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
これにより、kubeconfig ファイルを実行中のコンテナー内から使用できます。
16.7.2.1. レイテンシーテストの実行 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.7 では、CNF-test コンテナーからレイテンシーテストを実行することもできます。レイテンシーテストでは、パフォーマンス、スループットおよびレイテンシーを判別できるようにレイテンシーの制限を設定することができます。
レイテンシーテストでは oslat ツールを実行します。これは、OS レベルのレイテンシーを検知するオープンソースプログラムです。詳細は、Red Hat ナレッジベースソリューションの How to measure OS and hardware latency on isolated CPU? を参照してください。
デフォルトで、レイテンシーテストは無効になります。レイテンシーテストを有効にするには、 LATENCY_TEST_RUN 変数を追加し、その値を true に設定する必要があります。例: LATENCY_TEST_RUN=true
さらに、レイテンシーテストに以下の環境変数を設定することもできます。
-
LATENCY_TEST_RUNTIME: レイテンシーテストの実行に必要な時間 (秒単位) を指定します。 -
OSLAT_MAXIMUM_LATENCY:oslatテストの実行時にすべてのバケットで予想される最大レイテンシー (マイクロ秒単位) を指定します。
レイテンシーテストを実行するには、以下のコマンドを実行します。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=600 -e OSLAT_MAXIMUM_LATENCY=20 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=600 -e OSLAT_MAXIMUM_LATENCY=20 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
レイテンシーテストは検出モードで実行する必要があります。詳細は、検出モードのセクションを参照してください。
以下のコマンドの使用による 10 秒のレイテンシーテストの結果サンプルの抜粋:
podman run --rm -v $KUBECONFIG:/kubeconfig:Z -e PERF_TEST_PROFILE=worker-cnf-2 -e KUBECONFIG=/kubeconfig -e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=10 -e OSLAT_MAXIMUM_LATENCY=20 -e DISCOVERY_MODE=true registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
[root@cnf12-installer ~]# podman run --rm -v $KUBECONFIG:/kubeconfig:Z -e PERF_TEST_PROFILE=worker-cnf-2 -e KUBECONFIG=/kubeconfig -e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=10 -e OSLAT_MAXIMUM_LATENCY=20 -e DISCOVERY_MODE=true registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
-ginkgo.focus="Latency"
running /0_config.test -ginkgo.focus=Latency
出力例
16.7.3. イメージパラメーター リンクのコピーリンクがクリップボードにコピーされました!
要件に応じて、テストは異なるイメージを使用できます。以下の環境変数を使用して変更できるテストで、以下の 2 つのイメージが使用されます。
-
CNF_TESTS_IMAGE -
DPDK_TESTS_IMAGE
たとえば、カスタムレジストリーを使用して CNF_TESTS_IMAGE を変更するには、以下のコマンドを実行します。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
16.7.3.1. ginkgo パラメーター リンクのコピーリンクがクリップボードにコピーされました!
テストスイートは、ginkgo BDD フレームワーク上に構築されます。これは、テストをフィルターするか、または省略するためのパラメーターを受け入れることを意味します。
-ginkgo.focus パラメーターを使用してテストセットをフィルターできます。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh -ginkgo.focus="performance|sctp"
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh -ginkgo.focus="performance|sctp"
-ginkgo.focus パラメーターを使用してのみレイテンシーテストを実行できます。
レイテンシーテストのみを実行するには、テストする必要があるパフォーマンスプロファイルの名前が含まれる -ginkgo.focus パラメーターと PERF_TEST_PROFILE 環境変数を指定する必要があります。以下に例を示します。
docker run --rm -v $KUBECONFIG:/kubeconfig -e KUBECONFIG=/kubeconfig -e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=600 -e OSLAT_MAXIMUM_LATENCY=20 -e PERF_TEST_PROFILE=<performance_profile_name> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\[config\]|\[performance\]\ Latency\ Test"
$ docker run --rm -v $KUBECONFIG:/kubeconfig -e KUBECONFIG=/kubeconfig -e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=600 -e OSLAT_MAXIMUM_LATENCY=20 -e PERF_TEST_PROFILE=<performance_profile_name> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\[config\]|\[performance\]\ Latency\ Test"
特定のテストでは、SR-IOV と SCTP の両方が必要になります。focus パラメーターの選択的な性質を考慮すると、このテストは sriov Matcher のみを配置してトリガーできます。テストが SR-IOV がインストールされているクラスターに対して実行されるものの、SCTP がはない場合、-ginkgo.skip=SCTP パラメーターを追加すると、テストは SCTP テストを省略します。
16.7.3.2. 利用可能な機能 リンクのコピーリンクがクリップボードにコピーされました!
フィルターに使用できる機能のセットは以下になります。
-
performance -
sriov -
ptp -
sctp -
xt_u32 -
dpdk
16.7.4. ドライラン リンクのコピーリンクがクリップボードにコピーされました!
このコマンドを使用してドライランモードで実行します。これは、テストスイートの内容を確認し、イメージが実行するすべてのテストの出力を提供します。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh -ginkgo.dryRun -ginkgo.v
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh -ginkgo.dryRun -ginkgo.v
16.7.5. 非接続モード リンクのコピーリンクがクリップボードにコピーされました!
CNF は、非接続クラスター、つまり外部レジストリーに到達できないクラスターでテストを実行してイメージのサポートをテストします。これは 2 つの手順で行います。
- ミラーリングの実行。
- テストに対してカスタムレジストリーからのイメージを使用するように指示します。
16.7.5.1. クラスターからアクセスできるカスタムレジストリーへのイメージのミラーリング リンクのコピーリンクがクリップボードにコピーされました!
mirror 実行可能ファイルはイメージに含まれ、テストをローカルレジストリーに対して実行するために必要なテストをミラーリングするために oc で必要な入力を提供します。
クラスターおよびインターネット経由で registry.redhat.io にアクセスできる中間マシンから、以下のコマンドを実行します。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/mirror -registry my.local.registry:5000/ | oc image mirror -f -
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/mirror -registry my.local.registry:5000/ | oc image mirror -f -
次に、イメージの取得に使用されるレジストリーを上書きする方法について、以下のセクションの手順に従います。
16.7.5.2. テストに対してカスタムレジストリーからのそれらのイメージを使用するように指示します。 リンクのコピーリンクがクリップボードにコピーされました!
これは、IMAGE_REGISTRY 環境変数を設定して実行されます。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY="my.local.registry:5000/" -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY="my.local.registry:5000/" -e CNF_TESTS_IMAGE="custom-cnf-tests-image:latests" registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
16.7.5.3. クラスター内部レジストリーへのミラーリング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター上の標準ワークロードとして実行される組み込まれたコンテナーイメージレジストリーを提供します。
手順
レジストリーをルートを使用して公開し、レジストリーへの外部アクセスを取得します。
oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーエンドポイントを取得します。
REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージを公開する namespace を作成します。
oc create ns cnftests
$ oc create ns cnftestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow イメージストリームを、テストに使用されるすべての namespace で利用可能にします。これは、テスト namespace が
cnftestsイメージストリームからイメージを取得できるようにするために必要です。oc policy add-role-to-user system:image-puller system:serviceaccount:sctptest:default --namespace=cnftests
$ oc policy add-role-to-user system:image-puller system:serviceaccount:sctptest:default --namespace=cnftestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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:cnf-features-testing:default --namespace=cnftestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
$ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc policy add-role-to-user system:image-puller system:serviceaccount:dpdk-testing:default --namespace=cnftests
$ oc policy add-role-to-user system:image-puller system:serviceaccount:dpdk-testing:default --namespace=cnftestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc policy add-role-to-user system:image-puller system:serviceaccount:sriov-conformance-testing:default --namespace=cnftests
$ oc policy add-role-to-user system:image-puller system:serviceaccount:sriov-conformance-testing:default --namespace=cnftestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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')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')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような
dockerauth.jsonを作成します。echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.jsonecho "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow ミラーリングを実行します。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/mirror -registry $REGISTRY/cnftests | oc image mirror --insecure=true -a=$(pwd)/dockerauth.json -f -
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/mirror -registry $REGISTRY/cnftests | oc image mirror --insecure=true -a=$(pwd)/dockerauth.json -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow テストを実行します。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.7.5.4. イメージの異なるセットのミラーリング リンクのコピーリンクがクリップボードにコピーされました!
手順
mirrorコマンドは、デフォルトで u/s イメージのミラーリングを試行します。これは、以下の形式のファイルをイメージに渡すことで上書きできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow これを
mirrorコマンドに渡します。たとえば、images.jsonとしてローカルに保存できます。以下のコマンドでは、ローカルパスはコンテナー内の/kubeconfigにマウントされ、これを mirror コマンドに渡すことができます。docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/mirror --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" | oc image mirror -f -
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/mirror --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" | oc image mirror -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.7.6. 検出モード リンクのコピーリンクがクリップボードにコピーされました!
検出モードでは、設定を変更せずにクラスターの機能を検証できます。既存の環境設定はテストに使用されます。テストは必要な設定項目の検索を試行し、それらの項目を使用してテストを実行します。特定のテストの実行に必要なリソースが見つからない場合、テストは省略され、ユーザーに適切なメッセージが表示されます。テストが完了すると、事前に設定された設定項目のクリーンアップは行われず、テスト環境は別のテストの実行にすぐに使用できます。
一部の設定項目は、テストで引き続き作成されます。これらの項目は、テストを実行するために必要な特定の項目です (例: SR-IOV ネットワーク)。これらの設定項目はカスタム namespace に作成され、テストの実行後にクリーンアップされます。
さらに、これによりテストの実行時間が削減されます。設定項目はすでに存在しているので、環境設定および安定化に追加の時間は取る必要はありません。
検出モードを有効にするには、以下のように DISCOVERY_MODE 環境変数を設定してテストに対して指示する必要があります。
docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
DISCOVERY_MODE=true registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh
16.7.6.1. 必要な環境設定の前提条件 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV テスト
ほとんどの SR-IOV テストには以下のリソースが必要です。
-
SriovNetworkNodePolicy -
SriovNetworkNodePolicyで指定されるリソースの 1 つ以上が割り当て可能な状態であること。リソース数が 5 以上の場合に十分であると見なされます。
テストによっては、追加の要件があります。
-
利用可能なポリシーリソースがあるノード上の未使用のデバイス。リンク状態が
DOWNであり、ブリッジスレーブではない。 -
MTU 値が
9000のSriovNetworkNodePolicy。
DPDK テスト
DPDK 関連のテストには、以下が必要です。
- パフォーマンスプロファイル
- SR-IOV ポリシー。
-
SRIOV ポリシーで利用可能なリソースが含まれ、
PerformanceProfileノードセレクターで利用可能なノード。
PTP テスト
-
スレーブ
PtpConfig(ptp4lOpts="-s" ,phc2sysOpts="-a -r")。 -
スレーブ
PtpConfigに一致するラベルの付いたノード。
SCTP テスト
-
SriovNetworkNodePolicy -
SriovNetworkNodePolicyおよび SCTP を有効にするMachineConfigの両方に一致するノード。
XT_U32 テスト
- XT_U32 を有効にするマシン設定を持つノード。
Performance Operator のテスト
各種のテストにはそれぞれ異なる要件があります。以下はその一部になります。
- パフォーマンスプロファイル
-
profile.Spec.CPU.Isolated = 1を持つパフォーマンスプロファイル。 -
profile.Spec.RealTimeKernel.Enabled == trueを持つパーマンスプロファイル。 - Huge Page が使用されていないノード。
16.7.6.2. テスト中に使用されるノードの制限 リンクのコピーリンクがクリップボードにコピーされました!
テストが実行されるノードは、NODES_SELECTOR 環境変数を指定して制限できます。テストによって作成されるリソースは、指定されるノードに制限されます。
docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
NODES_SELECTOR=node-role.kubernetes.io/worker-cnf registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh
16.7.6.3. 単一のパフォーマンスプロファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
DPDK テストで必要なリソースは、パフォーマンスのテストスイートで必要なリソースのレベルよりも高くなります。実行をより高速にするために、テストで使用されるパフォーマンスプロファイルは、DPDK テストスイートも提供するプロファイルを使用して上書きできます。
これを実行するには、コンテナー内にマウントできる以下のようなプロファイルを使用し、パフォーマンステストに対してこれをデプロイするように指示できます。
使用されるパフォーマンスプロファイルを上書きするには、マニフェストをコンテナー内にマウントし、PERFORMANCE_PROFILE_MANIFEST_OVERRIDE パラメーターを設定してテストに対して指示する必要があります。
docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh
16.7.6.4. パフォーマンスプロファイルのクリーンアップの無効化 リンクのコピーリンクがクリップボードにコピーされました!
検出モードで実行されない場合、スイートは作成されるすべてのアーティファクトおよび設定をクリーンアップします。これには、パフォーマンスプロファイルが含まれます。
パフォーマンスプロファイルを削除する際に、マシン設定プールが変更され、ノードが再起動されます。新規の繰り返しの後に、新規プロファイルが作成されます。これにより、長いテストサイクルが実行間に生じます。
このプロセスを迅速化するには、CLEAN_PERFORMANCE_PROFILE="false" を設定し、パフォーマンスプロファイルをクリーンアップしないようにテストに指示します。これにより、次の反復でこれを作成し、これが適用されるのを待機する必要がなくなります。
docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e
CLEAN_PERFORMANCE_PROFILE="false" registry.redhat.io/openshift-kni/cnf-tests /usr/bin/test-run.sh
16.7.7. トラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
クラスターはコンテナー内からアクセスできる必要があります。これを確認するには、以下を実行します。
docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig
$ docker run -v $(pwd)/:/kubeconfig -e KUBECONFIG=/kubeconfig/kubeconfig
registry.redhat.io/openshift-kni/cnf-tests oc get nodes
これが機能しない場合は、原因が DNS、MTU サイズ、またはファイアウォールの問題に関連している可能性があります。
16.7.8. テストレポート リンクのコピーリンクがクリップボードにコピーされました!
CNF エンドツーエンドテストにより、JUnit テスト出力とテスト失敗レポートという 2 つの出力が生成されます。
16.7.8.1. JUnit テスト出力 リンクのコピーリンクがクリップボードにコピーされました!
レポートがダンプされるパスと共に --junit パラメーターを渡すと、JUnit 準拠の XML が作成されます。
docker run -v $(pwd)/:/kubeconfig -v $(pwd)/junitdest:/path/to/junit -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh --junit /path/to/junit
$ docker run -v $(pwd)/:/kubeconfig -v $(pwd)/junitdest:/path/to/junit -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh --junit /path/to/junit
16.7.8.2. テスト失敗レポート リンクのコピーリンクがクリップボードにコピーされました!
クラスターの状態とトラブルシューティング用のリソースに関する情報が含まれるレポートは、レポートがダンプされるパスと共に --report パラメーターを渡すことで生成できます。
docker run -v $(pwd)/:/kubeconfig -v $(pwd)/reportdest:/path/to/report -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh --report /path/to/report
$ docker run -v $(pwd)/:/kubeconfig -v $(pwd)/reportdest:/path/to/report -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh --report /path/to/report
16.7.8.3. podman に関する注記 リンクのコピーリンクがクリップボードにコピーされました!
非 root として、また権限なしで podman を実行する場合、permission denied というエラーを出してパスのマウントに失敗する可能性があります。これを機能させるには、:Z をボリューム作成に追加します。たとえば、-v $(pwd)/:/kubeconfig:Z を使用して podman が SELinux のラベルを適切に書き換えることができます。
16.7.8.4. OpenShift Container Platform 4.4 での実行 リンクのコピーリンクがクリップボードにコピーされました!
以下を除き、CNF のエンドツーエンドのテストは OpenShift Container Platform 4.4 と互換性があります。
[test_id:28466][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through openshift-node-performance profile [test_id:28467][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through the openshift-node-performance profile
[test_id:28466][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through openshift-node-performance profile
[test_id:28467][crit:high][vendor:cnf-qe@redhat.com][level:acceptance] Should contain configuration injected through the openshift-node-performance profile
これらのテストを省略するには、-ginkgo.skip "28466|28467" パラメーターを追加します。
16.7.8.5. 単一のパフォーマンスプロファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
DPDK テストには、パフォーマンステストスイートに必要なリソースよりも多くのリソースが必要です。実行をより迅速にするには、DPDK テストスイートを提供するプロファイルを使用して、テストが使用するパフォーマンスプロファイルを上書きすることができます。
これを実行するには、コンテナー内にマウントできる以下のようなプロファイルを使用し、パフォーマンステストに対してこれをデプロイするように指示できます。
パフォーマンスプロファイルを上書きするには、マニフェストをコンテナー内にマウントし、PERFORMANCE_PROFILE_MANIFEST_OVERRIDE を設定してテストに対して指示する必要があります。
docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
$ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift4/cnf-tests-rhel8:v4.7 /usr/bin/test-run.sh
16.7.9. クラスターへの影響 リンクのコピーリンクがクリップボードにコピーされました!
機能によっては、テストスイートを実行すると、クラスターに異なる影響が及ぶ可能性があります。通常、SCTP テストのみではクラスター設定を変更しません。他のすべての機能は設定にさまざまな影響を与えます。
16.7.9.1. SCTP リンクのコピーリンクがクリップボードにコピーされました!
SCTP テストは、接続性をチェックするために異なるノードで異なる Pod を実行するのみです。クラスターへの影響は、2 つのノードでの単純な Pod の実行に関連します。
16.7.9.2. XT_U32 リンクのコピーリンクがクリップボードにコピーされました!
XT_U32 テストは異なるノードで Pod を実行し、xt_u32 を使用する iptables ルールをチェックします。クラスターへの影響は、2 つのノードでの単純な Pod の実行に関連します。
16.7.9.3. SR-IOV リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV テストには、SR-IOV ネットワーク設定での変更が必要になります。この場合、テストは異なるタイプの設定を作成し、破棄します。
これは、既存の SR-IOV ネットワーク設定がクラスターにインストールされている場合に影響を与える可能性があります。これらの設定の優先順位によっては競合が生じる可能性があるためです。
同時に、テストの結果は既存の設定による影響を受ける可能性があります。
16.7.9.4. PTP リンクのコピーリンクがクリップボードにコピーされました!
PTP テストは、PTP 設定をクラスターのノードセットに適用します。SR-IOV と同様に、これはすでに有効な既存の PTP 設定と競合する可能性があります。これにより予測不可能な結果が出される可能性があります。
16.7.9.5. パフォーマンス リンクのコピーリンクがクリップボードにコピーされました!
パフォーマンステストにより、パフォーマンスプロファイルがクラスターに適用されます。これにより、ノード設定の変更、CPU の予約、メモリー Huge Page の割り当て、およびカーネルパッケージのリアルタイムの設定が行われます。performance という名前の既存のプロファイルがクラスターですでに利用可能な場合、テストはこれをデプロイしません。
16.7.9.6. DPDK リンクのコピーリンクがクリップボードにコピーされました!
DPDK はパフォーマンスおよび SR-IOV 機能の両方に依存するため、テストスイートはパフォーマンスプロファイルと SR-IOV ネットワークの両方を設定します。そのため、これによる影響は SR-IOV テストおよびパフォーマンステストで説明されているものと同じになります。
16.7.9.7. クリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
テストスイートの実行後に、未解決のリソースすべてがクリーンアップされます。