13.10. クラスターチェックの実行
OpenShift Virtualization 4.11 には、クラスターのメンテナンスとトラブルシューティングに使用できる定義済みのチェックを実行するための診断フレームワークが含まれています。
OpenShift Container Platform クラスターチェックアップフレームワークは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
13.10.1. OpenShift Container Platform クラスターチェックアップフレームワークについて
チェックアップは、特定のクラスター機能が期待どおりに機能するかどうかを確認できる自動テストワークロードです。クラスター検査フレームワークは、ネイティブの Kubernetes リソースを使用して、チェックアップを設定および実行します。
事前定義されたチェックアップを使用することで、クラスター管理者はクラスターの保守性を向上させ、予期しない動作をトラブルシューティングし、エラーを最小限に抑え、時間を節約できます。また、チェックアップの結果を確認し、専門家と共有してさらに分析することもできます。ベンダーは、提供する機能やサービスのチェックアップを作成して公開し、顧客環境が正しく設定されていることを確認できます。
クラスターで事前定義されたチェックアップを実行するには、フレームワークの namespace とサービスアカウントの設定、サービスアカウントの ClusterRole オブジェクトと ClusterRoleBinding オブジェクトの作成、チェックアップの権限の有効化、入力 config map とチェックアップジョブの作成が含まれます。チェックアップは複数回実行できます。
以下が常に必要になります。
- チェックアップイメージを適用する前に、信頼できるソースからのものであることを確認します。
-
ClusterRoleオブジェクトを作成する前に、チェックアップのパーミッションを確認します。 -
設定マップ内の
ClusterRoleオブジェクトの名前を確認します。これは、フレームワークがこれらのアクセス許可をチェックアップインスタンスに自動的にバインドするためです。
13.10.2. セカンダリーネットワーク上の仮想マシンのネットワーク接続と遅延の確認
クラスター管理者は、定義済みのチェックを使用して、ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続されている仮想マシン (VM) 間の待機時間を測定します。
初めてチェックアップを実行するには、手順のステップに従います。
以前にチェックアップを実行したことがある場合は、手順のステップ 5 にスキップしてください。これは、フレームワークをインストールしてチェックアップのパーミッションを有効にする手順は必要ないためです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインしている。 - クラスターには少なくとも 2 つのワーカーノードがあります。
- Multus Container Network Interface (CNI) プラグインがクラスターにインストールされている。
- namespace のネットワーク接続定義を設定しました。
手順
フレームワークを設定するためのリソースを含む設定ファイルを作成します。これには、フレームワークの namespace とサービスアカウント、およびサービスアカウントのアクセス許可を定義する
ClusterRoleオブジェクトとClusterRoleBindingオブジェクトが含まれます。例13.3 フレームワークマニフェストファイルの例
--- apiVersion: v1 kind: Namespace metadata: name: kiagnose --- apiVersion: v1 kind: ServiceAccount metadata: name: kiagnose namespace: kiagnose --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kiagnose rules: - apiGroups: [ "" ] resources: [ "configmaps" ] verbs: - get - list - create - update - patch - apiGroups: [ "" ] resources: [ "namespaces" ] verbs: - get - list - create - delete - watch - apiGroups: [ "" ] resources: [ "serviceaccounts" ] verbs: - get - list - create - apiGroups: [ "rbac.authorization.k8s.io" ] resources: - roles - rolebindings - clusterrolebindings verbs: - get - list - create - delete - apiGroups: [ "rbac.authorization.k8s.io" ] resources: - clusterroles verbs: - get - list - create - bind - apiGroups: [ "batch" ] resources: [ "jobs" ] verbs: - get - list - create - delete - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kiagnose roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kiagnose subjects: - kind: ServiceAccount name: kiagnose namespace: kiagnose ...フレームワークマニフェストを適用します。
$ oc apply -f <framework_manifest>.yaml
検査でクラスター アクセスに必要なアクセス許可を持つ
ClusterRoleオブジェクトとRoleオブジェクトを含む設定ファイルを作成します。クラスターロールマニフェストファイルの例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole 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"]
チェックアップロールマニフェストを適用します。
$ oc apply -f <latency_roles>.yaml
チェックアップの入力パラメーターを含む
ConfigMapマニフェストを作成します。config map は、フレームワークがチェックアップを実行するための入力を提供し、チェックアップの結果も保存します。入力 config map の例
apiVersion: v1 kind: ConfigMap metadata: name: kubevirt-vm-latency-checkup namespace: kiagnose data: spec.image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup:v4.11.0 spec.timeout: 10m spec.clusterRoles: | kubevirt-vmis-manager spec.param.network_attachment_definition_namespace: "default" 1 spec.param.network_attachment_definition_name: "bridge-network" 2 spec.param.max_desired_latency_milliseconds: "10" 3 spec.param.sample_duration_seconds: "5" 4フレームワークの namespace に config map を作成します。
$ oc apply -f <latency_config_map>.yaml
チェックアップを実行する
Jobオブジェクトを作成します。ジョブマニフェストの例
apiVersion: batch/v1 kind: Job metadata: name: kubevirt-vm-latency-checkup namespace: kiagnose spec: backoffLimit: 0 template: spec: serviceAccount: kiagnose restartPolicy: Never containers: - name: framework image: registry.redhat.io/container-native-virtualization/checkup-framework:v4.11.0 env: - name: CONFIGMAP_NAMESPACE value: kiagnose - name: CONFIGMAP_NAME value: kubevirt-vm-latency-checkupJobマニフェストを適用します。チェックアップでは、ping ユーティリティーを使用して接続を確認し、レイテンシーを測定します。$ oc apply -f <latency_job>.yaml
ジョブが完了するまで待ちます。
$ oc wait --for=condition=complete --timeout=10m job.batch/kubevirt-vm-latency-checkup -n kiagnose
ConfigMapオブジェクトのステータスを取得して、レイテンシーチェックアップの結果を確認します。測定されたレイテンシーがspec.param.max_desired_latency_milliseconds属性の値より大きい場合、チェックアップは失敗し、エラーが返されます。$ oc get configmap kubevirt-vm-latency-checkup -n kiagnose -o yaml
出力 config map の例 (成功)
apiVersion: v1 kind: ConfigMap metadata: name: kubevirt-vm-latency-checkup namespace: kiagnose ... status.succeeded: "true" status.failureReason: "" status.result.minLatencyNanoSec: 2000 status.result.maxLatencyNanoSec: 3000 status.result.avgLatencyNanoSec: 2500 status.results.measurementDurationSec: 300 ...
以前に作成したフレームワークとチェックアップリソースを削除します。これには、ジョブ、config map、クラスターロール、およびフレームワークマニフェストファイルが含まれます。
注記別のチェックアップを実行する予定がある場合は、フレームワークとクラスターのロールのマニフェストファイルを削除しないでください。
$ oc delete -f <file_name>.yaml
