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 のネットワーク接続定義を設定しました。

手順

  1. ServiceAccountRole、および 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
  2. チェックアップロールマニフェストを適用します。

    $ oc apply -n <target_namespace> -f <latency_roles>.yaml 1
    1
    <target_namespace> は、チェックアップを実行する namespace です。これは、NetworkAttachmentDefinition オブジェクトが存在する既存の namespace である必要があります。
  3. チェックアップの入力パラメーターを含む 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

    1
    NetworkAttachmentDefinition オブジェクトの名前。
    2
    オプション: 仮想マシン間の必要な最大待機時間 (ミリ秒単位)。測定されたレイテンシーがこの値を超えると、チェックアップは失敗します。
    3
    オプション: レイテンシーチェックの継続時間 (秒単位)。
    4
    オプション: 指定すると、このノードからターゲットノードまでの待ち時間が測定されます。ソースノードが指定されている場合、spec.param.target_node フィールドは空にすることはできません。
    5
    オプション: 指定すると、ソースノードからこのノードまでの待ち時間が測定されます。
  4. ターゲット namespace に config map マニフェストを適用します。

    $ oc apply -n <target_namespace> -f <latency_config_map>.yaml
  5. チェックアップを実行する 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-config

  6. Job マニフェストを適用します。チェックアップでは、ping ユーティリティーを使用して接続を確認し、レイテンシーを測定します。

    $ oc apply -n <target_namespace> -f <latency_job>.yaml
  7. ジョブが完了するまで待ちます。

    $ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m
  8. 以下のコマンドを実行して、レイテンシーチェックアップの結果を確認します。測定された最大レイテンシーが 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
    測定された最大レイテンシー (ナノ秒)。
  9. オプション: チェックアップが失敗した場合に詳細なジョブログを表示するには、次のコマンドを使用します。

    $ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
  10. 以下のコマンドを実行して、以前に作成したジョブおよび設定マップリソースを削除します。

    $ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
    $ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config
  11. オプション: 別のチェックアップを実行する予定がない場合は、チェックアップロールとフレームワークマニフェストファイルを削除します。

    $ oc delete -f <file_name>.yaml

14.11.3. 関連情報