14.11. クラスターチェックの実行
OpenShift Virtualization には、クラスターのメンテナンスとトラブルシューティングに使用できる定義済みのチェックアップが含まれています。
OpenShift Container Platform クラスターチェックアップフレームワークは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
14.11.1. OpenShift Container Platform クラスターチェックアップフレームワークについて
チェックアップは、特定のクラスター機能が期待どおりに機能するかどうかを確認できる自動テストワークロードです。クラスター検査フレームワークは、ネイティブの Kubernetes リソースを使用して、チェックアップを設定および実行します。
事前定義されたチェックアップを使用することで、クラスター管理者はクラスターの保守性を向上させ、予期しない動作をトラブルシューティングし、エラーを最小限に抑え、時間を節約できます。また、チェックアップの結果を確認し、専門家と共有してさらに分析することもできます。ベンダーは、提供する機能やサービスのチェックアップを作成して公開し、顧客環境が正しく設定されていることを確認できます。
既存の namespace で事前定義されたチェックアップを実行するには、チェックアップ用のサービスアカウントの設定、サービスアカウント用の Role および RoleBinding オブジェクトの作成、チェックアップのパーミッションの有効化、入力 config map とチェックアップジョブの作成が含まれます。チェックアップは複数回実行できます。
以下が常に必要になります。
- チェックアップイメージを適用する前に、信頼できるソースからのものであることを確認します。
-
RoleおよびRoleBindingオブジェクトを作成する前に、チェックアップパーミッションを確認してください。
14.11.2. セカンダリーネットワーク上の仮想マシンのネットワーク接続と遅延の確認
定義済みのチェックアップを使用して、ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続されている 2 つの仮想マシン (VM) 間の待機時間を測定します。
初めてチェックアップを実行するには、手順のステップに従います。
以前にチェックアップを実行したことがある場合は、手順のステップ 5 にスキップしてください。これは、フレームワークをインストールしてチェックアップのパーミッションを有効にする手順は必要ないためです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターには少なくとも 2 つのワーカーノードがあります。
- Multus Container Network Interface (CNI) プラグインがクラスターにインストールされている。
- namespace のネットワーク接続定義を設定しました。
手順
ServiceAccount、Role、およびRoleBindingオブジェクトを含むマニフェストファイルを作成し、チェックアップでクラスターアクセスに必要なパーミッションを設定します。例14.3 ロールマニフェストファイルの例
--- apiVersion: v1 kind: ServiceAccount metadata: name: vm-latency-checkup-sa --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kubevirt-vm-latency-checker rules: - apiGroups: ["kubevirt.io"] resources: ["virtualmachineinstances"] verbs: ["get", "create", "delete"] - apiGroups: ["subresources.kubevirt.io"] resources: ["virtualmachineinstances/console"] verbs: ["get"] - apiGroups: ["k8s.cni.cncf.io"] resources: ["network-attachment-definitions"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kubevirt-vm-latency-checker subjects: - kind: ServiceAccount name: vm-latency-checkup-sa roleRef: kind: Role name: kubevirt-vm-latency-checker apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kiagnose-configmap-access rules: - apiGroups: [ "" ] resources: [ "configmaps" ] verbs: ["get", "update"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kiagnose-configmap-access subjects: - kind: ServiceAccount name: vm-latency-checkup-sa roleRef: kind: Role name: kiagnose-configmap-access apiGroup: rbac.authorization.k8s.io
チェックアップロールマニフェストを適用します。
$ oc apply -n <target_namespace> -f <latency_roles>.yaml 1- 1
<target_namespace>は、チェックアップを実行する namespace です。これは、NetworkAttachmentDefinitionオブジェクトが存在する既存の namespace である必要があります。
チェックアップの入力パラメーターを含む
ConfigMapマニフェストを作成します。config map は、フレームワークがチェックアップを実行するための入力を提供し、チェックアップの結果も保存します。入力 config map の例
apiVersion: v1 kind: ConfigMap metadata: name: kubevirt-vm-latency-checkup-config data: spec.timeout: 5m spec.param.network_attachment_definition_namespace: <target_namespace> spec.param.network_attachment_definition_name: "blue-network" 1 spec.param.max_desired_latency_milliseconds: "10" 2 spec.param.sample_duration_seconds: "5" 3 spec.param.source_node: "worker1" 4 spec.param.target_node: "worker2" 5
ターゲット namespace に config map マニフェストを適用します。
$ oc apply -n <target_namespace> -f <latency_config_map>.yaml
チェックアップを実行する
Jobオブジェクトを作成します。ジョブマニフェストの例
apiVersion: batch/v1 kind: Job metadata: name: kubevirt-vm-latency-checkup spec: backoffLimit: 0 template: spec: serviceAccountName: vm-latency-checkup-sa restartPolicy: Never containers: - name: vm-latency-checkup image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup:v4.12.0 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] runAsNonRoot: true seccompProfile: type: "RuntimeDefault" env: - name: CONFIGMAP_NAMESPACE value: <target_namespace> - name: CONFIGMAP_NAME value: kubevirt-vm-latency-checkup-configJobマニフェストを適用します。チェックアップでは、ping ユーティリティーを使用して接続を確認し、レイテンシーを測定します。$ oc apply -n <target_namespace> -f <latency_job>.yaml
ジョブが完了するまで待ちます。
$ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m
以下のコマンドを実行して、レイテンシーチェックアップの結果を確認します。測定された最大レイテンシーが
spec.param.max_desired_latency_milliseconds属性の値よりも大きい場合、チェックアップは失敗し、エラーが返されます。$ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml
出力 config map の例 (成功)
apiVersion: v1 kind: ConfigMap metadata: name: kubevirt-vm-latency-checkup-config namespace: <target_namespace> data: spec.timeout: 5m spec.param.network_attachment_definition_namespace: <target_namespace> spec.param.network_attachment_definition_name: "blue-network" spec.param.max_desired_latency_milliseconds: "10" spec.param.sample_duration_seconds: "5" spec.param.source_node: "worker1" spec.param.target_node: "worker2" status.succeeded: "true" status.failureReason: "" status.completionTimestamp: "2022-01-01T09:00:00Z" status.startTimestamp: "2022-01-01T09:00:07Z" status.result.avgLatencyNanoSec: "177000" status.result.maxLatencyNanoSec: "244000" 1 status.result.measurementDurationSec: "5" status.result.minLatencyNanoSec: "135000" status.result.sourceNode: "worker1" status.result.targetNode: "worker2"- 1
- 測定された最大レイテンシー (ナノ秒)。
オプション: チェックアップが失敗した場合に詳細なジョブログを表示するには、次のコマンドを使用します。
$ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
以下のコマンドを実行して、以前に作成したジョブおよび設定マップリソースを削除します。
$ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
$ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config
オプション: 別のチェックアップを実行する予定がない場合は、チェックアップロールとフレームワークマニフェストファイルを削除します。
$ oc delete -f <file_name>.yaml
