検索

14.3. モニタリング

download PDF

14.3.1. モニタリングの概要

次のツールを使用して、クラスターと仮想マシン (VM) の正常性を監視できます。

OpenShift Container Platform クラスター診断フレームワーク

OpenShift Container Platform クラスター診断フレームワークを使用してクラスターに対する自動テストを実行し、以下の状態を確認します。

  • セカンダリーネットワークインターフェイスに接続された 2 つの仮想マシン間のネットワーク接続とレイテンシー
  • パケット損失ゼロで Data Plane Development Kit (DPDK) ワークロードを実行する仮想マシン
重要

OpenShift Container Platform クラスターチェックアップフレームワークは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

仮想リソースの Prometheus クエリー
vCPU、ネットワーク、ストレージ、およびゲストメモリースワッピングの使用状況とライブマイグレーションの進行状況をクエリーします。
VM カスタムメトリクス
内部 VM メトリクスとプロセスを公開するように、node-exporter サービスを設定します。
xref:[VM ヘルスチェック]
レディネス、ライブネス、ゲストエージェントの ping プローブ、および VM のウォッチドッグを設定します。
重要

ゲストエージェント ping プローブは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

14.3.2. OpenShift Container Platform クラスター診断フレームワーク

OpenShift Virtualization には、クラスターのメンテナンスとトラブルシューティングに使用できる定義済みのチェックアップが含まれています。

重要

OpenShift Container Platform クラスターチェックアップフレームワークは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

14.3.2.1. OpenShift Container Platform クラスターチェックアップフレームワークについて

チェックアップは、特定のクラスター機能が期待どおりに機能するかどうかを確認できる自動テストワークロードです。クラスター検査フレームワークは、ネイティブの Kubernetes リソースを使用して、チェックアップを設定および実行します。

事前定義されたチェックアップを使用することで、クラスター管理者はクラスターの保守性を向上させ、予期しない動作をトラブルシューティングし、エラーを最小限に抑え、時間を節約できます。また、チェックアップの結果を確認し、専門家と共有してさらに分析することもできます。ベンダーは、提供する機能やサービスのチェックアップを作成して公開し、顧客環境が正しく設定されていることを確認できます。

既存の namespace で事前定義されたチェックアップを実行するには、チェックアップ用のサービスアカウントの設定、サービスアカウント用の Role および RoleBinding オブジェクトの作成、チェックアップのパーミッションの有効化、入力 config map とチェックアップジョブの作成が含まれます。チェックアップは複数回実行できます。

重要

以下が常に必要になります。

  • チェックアップイメージを適用する前に、信頼できるソースからのものであることを確認します。
  • Role および RoleBinding オブジェクトを作成する前に、チェックアップパーミッションを確認してください。

14.3.2.2. 仮想マシンのレイテンシーチェックアップ

定義済みのチェックアップを使用して、ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続されている 2 つの仮想マシン (VM) 間の待機時間を測定します。レイテンシーチェックアップでは ping ユーティリティーを使用します。

次の手順でレイテンシーチェックアップを実行します。

  1. サービスアカウント、ロール、ロールバインディングを作成して、レイテンシーチェックアップへのクラスターアクセス権を提供します。
  2. config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
  3. チェックアップを実行するジョブを作成します。
  4. config map で結果を確認します。
  5. オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
  6. 完了したら、レイテンシーチェックアップリソースを削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • クラスターには少なくとも 2 つのワーカーノードがあります。
  • Multus Container Network Interface (CNI) プラグインがクラスターにインストールされている。
  • namespace のネットワーク接続定義を設定しました。

手順

  1. レイテンシーチェックアップ用の ServiceAccountRoleRoleBinding マニフェストを作成します。

    例14.1 ロールマニフェストファイルの例

    ---
    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. ServiceAccountRoleRoleBinding マニフェストを適用します。

    $ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml 1
    1
    <target_namespace> は、チェックアップを実行する namespace です。これは、NetworkAttachmentDefinition オブジェクトが存在する既存の namespace である必要があります。
  3. チェックアップの入力パラメーターを含む ConfigMap マニフェストを作成します。

    入力 config map の例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: kubevirt-vm-latency-checkup-config
    data:
      spec.timeout: 5m
      spec.param.networkAttachmentDefinitionNamespace: <target_namespace>
      spec.param.networkAttachmentDefinitionName: "blue-network" 1
      spec.param.maxDesiredLatencyMilliseconds: "10" 2
      spec.param.sampleDurationSeconds: "5" 3
      spec.param.sourceNode: "worker1" 4
      spec.param.targetNode: "worker2" 5

    1
    NetworkAttachmentDefinition オブジェクトの名前。
    2
    オプション: 仮想マシン間の必要な最大待機時間 (ミリ秒単位)。測定されたレイテンシーがこの値を超えると、チェックアップは失敗します。
    3
    オプション: レイテンシーチェックの継続時間 (秒単位)。
    4
    オプション: 指定すると、このノードからターゲットノードまでの待ち時間が測定されます。ソースノードが指定されている場合、spec.param.targetNode フィールドは空にできません。
    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-rhel9:v4.13.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
                - name: POD_UID
                  valueFrom:
                    fieldRef:
                      fieldPath: metadata.uid

  6. Job マニフェストを適用します。

    $ 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.maxDesiredLatencyMilliseconds 属性の値よりも大きい場合、チェックアップは失敗し、エラーが返されます。

    $ 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.networkAttachmentDefinitionNamespace: <target_namespace>
      spec.param.networkAttachmentDefinitionName: "blue-network"
      spec.param.maxDesiredLatencyMilliseconds: "10"
      spec.param.sampleDurationSeconds: "5"
      spec.param.sourceNode: "worker1"
      spec.param.targetNode: "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. 以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。

    $ 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 <latency_sa_roles_rolebinding>.yaml

14.3.2.3. DPDK チェックアップ

事前定義されたチェックアップを使用して、OpenShift Container Platform クラスターノードが Data Plane Development Kit (DPDK) ワークロードがある仮想マシン (VM) をパケット損失ゼロで実行できるか確認します。DPDK チェックアップは、トラフィックジェネレーター Pod とテスト DPDK アプリケーションを実行している 仮想マシン間でトラフィックを実行します。

次の手順で DPDK チェックアップを実行します。

  1. DPDK チェックアップ用のサービスアカウント、ロール、ロールバインディング、およびトラフィックジェネレーター Pod のサービスアカウントを作成します。
  2. トラフィックジェネレーター Pod のセキュリティーコンテキスト制約リソースを作成します。
  3. config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
  4. チェックアップを実行するジョブを作成します。
  5. config map で結果を確認します。
  6. オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
  7. 完了したら、DPDK チェックリソースを削除します。

前提条件

  • cluster-admin 権限を持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • VM でパケット損失なしで DPDK アプリケーションを実行するようにコンピュートノードを設定しました。
重要

チェックによって作成されたトラフィックジェネレーター Pod には、昇格した権限があります。

  • root として実行されます。
  • ノードのファイルシステムにバインドマウントがあります。

トラフィックジェネレーターのコンテナーイメージは、アップストリームの Project Quay コンテナーレジストリーから取得されます。

手順

  1. DPDK チェックアップとトラフィックジェネレーター Pod 用の ServiceAccountroleroleBinding マニフェストを作成します。

    例14.2 サービスアカウント、ロール、ロールバインディングマニフェストファイルの例

    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: dpdk-checkup-sa
    ---
    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: dpdk-checkup-sa
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: kiagnose-configmap-access
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: kubevirt-dpdk-checker
    rules:
      - apiGroups: [ "kubevirt.io" ]
        resources: [ "virtualmachineinstances" ]
        verbs: [ "create", "get", "delete" ]
      - apiGroups: [ "subresources.kubevirt.io" ]
        resources: [ "virtualmachineinstances/console" ]
        verbs: [ "get" ]
      - apiGroups: [ "" ]
        resources: [ "pods" ]
        verbs: [ "create", "get", "delete" ]
      - apiGroups: [ "" ]
        resources: [ "pods/exec" ]
        verbs: [ "create" ]
      - apiGroups: [ "k8s.cni.cncf.io" ]
        resources: [ "network-attachment-definitions" ]
        verbs: [ "get" ]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: kubevirt-dpdk-checker
    subjects:
      - kind: ServiceAccount
        name: dpdk-checkup-sa
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: kubevirt-dpdk-checker
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: dpdk-checkup-traffic-gen-sa
  2. ServiceAccountRoleRoleBinding マニフェストを適用します。

    $ oc apply -n <target_namespace> -f <dpdk_sa_roles_rolebinding>.yaml
  3. トラフィックジェネレーター Pod の SecurityContextConstraints マニフェストを作成します。

    セキュリティーコンテキスト制約マニフェストの例

    apiVersion: security.openshift.io/v1
    kind: SecurityContextConstraints
    metadata:
      name: dpdk-checkup-traffic-gen
    allowHostDirVolumePlugin: true
    allowHostIPC: false
    allowHostNetwork: false
    allowHostPID: false
    allowHostPorts: false
    allowPrivilegeEscalation: false
    allowPrivilegedContainer: false
    allowedCapabilities:
    - IPC_LOCK
    - NET_ADMIN
    - NET_RAW
    - SYS_RESOURCE
    defaultAddCapabilities: null
    fsGroup:
      type: RunAsAny
    groups: []
    readOnlyRootFilesystem: false
    requiredDropCapabilities: null
    runAsUser:
      type: RunAsAny
    seLinuxContext:
      type: RunAsAny
    seccompProfiles:
    - runtime/default
    - unconfined
    supplementalGroups:
      type: RunAsAny
    users:
    - system:serviceaccount:dpdk-checkup-ns:dpdk-checkup-traffic-gen-sa

  4. SecurityContextConstraints マニフェストを適用します。

    $ oc apply -f <dpdk_scc>.yaml
  5. チェックアップの入力パラメーターを含む ConfigMap マニフェストを作成します。

    入力 config map の例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: dpdk-checkup-config
    data:
      spec.timeout: 10m
      spec.param.networkAttachmentDefinitionName: <network_name> 1
      spec.param.trafficGeneratorRuntimeClassName: <runtimeclass_name> 2
      spec.param.trafficGeneratorImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.1.1" 3
      spec.param.vmContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.1.1" 4

    1
    NetworkAttachmentDefinition オブジェクトの名前。
    2
    トラフィックジェネレーター Pod が使用する RuntimeClass リソース。
    3
    トラフィックジェネレーターのコンテナーイメージ。この例では、アップストリームの Project Quay Container Registry からイメージをプルしています。
    4
    VM のコンテナーディスクイメージ。この例では、アップストリームの Project Quay Container Registry からイメージをプルしています。
  6. ターゲット namespace に ConfigMap マニフェストを適用します。

    $ oc apply -n <target_namespace> -f <dpdk_config_map>.yaml
  7. チェックアップを実行する Job マニフェストを作成します。

    ジョブマニフェストの例

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: dpdk-checkup
    spec:
      backoffLimit: 0
      template:
        spec:
          serviceAccountName: dpdk-checkup-sa
          restartPolicy: Never
          containers:
            - name: dpdk-checkup
              image: registry.redhat.io/container-native-virtualization/kubevirt-dpdk-checkup-rhel9:v4.13.0
              imagePullPolicy: Always
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop: ["ALL"]
                runAsNonRoot: true
                seccompProfile:
                  type: "RuntimeDefault"
              env:
                - name: CONFIGMAP_NAMESPACE
                  value: <target-namespace>
                - name: CONFIGMAP_NAME
                  value: dpdk-checkup-config
                - name: POD_UID
                  valueFrom:
                    fieldRef:
                      fieldPath: metadata.uid

  8. Job マニフェストを適用します。

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

    $ oc wait job dpdk-checkup -n <target_namespace> --for condition=complete --timeout 10m
  10. 次のコマンドを実行して、検査の結果を確認します。

    $ oc get configmap dpdk-checkup-config -n <target_namespace> -o yaml

    出力 config map の例 (成功)

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: dpdk-checkup-config
    data:
      spec.timeout: 1h2m
      spec.param.NetworkAttachmentDefinitionName: "mlx-dpdk-network-1"
      spec.param.trafficGeneratorRuntimeClassName: performance-performance-zeus10
      spec.param.trafficGeneratorImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.1.1"
      spec.param.vmContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.1.1"
      status.succeeded: true
      status.failureReason: " "
      status.startTimestamp: 2022-12-21T09:33:06+00:00
      status.completionTimestamp: 2022-12-21T11:33:06+00:00
      status.result.actualTrafficGeneratorTargetNode: worker-dpdk1
      status.result.actualDPDKVMTargetNode: worker-dpdk2
      status.result.dropRate: 0

  11. 以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。

    $ oc delete job -n <target_namespace> dpdk-checkup
    $ oc delete config-map -n <target_namespace> dpdk-checkup-config
  12. オプション: 別のチェックアップを実行する予定がない場合は、ServiceAccountRoleRoleBinding マニフェストを削除します。

    $ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
14.3.2.3.1. DPDK チェックアップ config map パラメーター

次の表は、クラスター DPDK 準備状況チェックを実行するときに、入力 ConfigMap マニフェストの data スタンザに設定できる必須パラメーターとオプションパラメーターを示しています。

表14.3 DPDK チェックアップ config map パラメーター
パラメーター説明必須かどうか

spec.timeout

チェックアップが失敗するまでの時間 (分単位)。

True

spec.param.networkAttachmentDefinitionName

接続されている SR-IOV NIC の NetworkAttachmentDefinition オブジェクトの名前。

True

spec.param.trafficGeneratorRuntimeClassName

トラフィックジェネレーター Pod が使用する RuntimeClass リソース。

True

spec.param.trafficGeneratorImage

トラフィックジェネレーターのコンテナーイメージ。デフォルト値は quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:main です。

False

spec.param.trafficGeneratorNodeSelector

トラフィックジェネレーター Pod がスケジュールされるノード。DPDK トラフィックを許可するようにノードを設定する必要があります。

False

spec.param.trafficGeneratorPacketsPerSecond

1 秒あたりのパケット数 (キロ (k) または 100 万 (m) 単位)。デフォルト値は 14m です。

False

spec.param.trafficGeneratorEastMacAddress

トラフィックジェネレーター Pod または VM に接続されている NIC の MAC アドレス。デフォルト値は、50:xx:xx:xx:xx:01 の形式のランダムな MAC アドレスです。

False

spec.param.trafficGeneratorWestMacAddress

トラフィックジェネレーター Pod または VM に接続されている NIC の MAC アドレス。デフォルト値は、50:xx:xx:xx:xx:02 の形式のランダムな MAC アドレスです。

False

spec.param.vmContainerDiskImage

VM のコンテナーディスクイメージ。デフォルト値は quay.io/kiagnose/kubevirt-dpdk-checkup-vm:main です。

False

spec.param.DPDKLabelSelector

VM が実行されているノードのラベル。DPDK トラフィックを許可するようにノードを設定する必要があります。

False

spec.param.DPDKEastMacAddress

VM に接続されている NIC の MAC アドレス。デフォルト値は、60:xx:xx:xx:xx:01 の形式のランダムな MAC アドレスです。

False

spec.param.DPDKWestMacAddress

VM に接続されている NIC の MAC アドレス。デフォルト値は、60:xx:xx:xx:xx:02 の形式のランダムな MAC アドレスです。

False

spec.param.testDuration

トラフィックジェネレーターが実行される期間 (分単位)。デフォルト値は 5 分です。

False

spec.param.portBandwidthGB

SR-IOV NIC の最大帯域幅。デフォルト値は 10GB です。

False

spec.param.verbose

true に設定すると、検査ログの詳細度が上がります。デフォルト値は false です。

False

14.3.2.3.2. RHEL 仮想マシン用コンテナーディスクイメージのビルド

カスタムの Red Hat Enterprise Linux (RHEL) 8 OS イメージを qcow2 形式でビルドし、それを使用してコンテナーディスクイメージを作成できます。クラスターからアクセス可能なレジストリーにコンテナーディスクイメージを保存し、DPDK チェック config map の spec.param.vmContainerDiskImage 属性でイメージの場所を指定できます。

コンテナーディスクイメージをビルドするには、Image Builder 仮想マシン (VM) を作成する必要があります。Image Builder 仮想マシン は、カスタム RHEL イメージのビルドに使用できる RHEL 8 仮想マシンです。

前提条件

  • Image Builder 仮想マシンは RHEL 8.7 を実行でき、/var ディレクトリーに少なくとも 2 つの CPU コア、4 GiB RAM、20 GB の空き領域がある。
  • Image Builder ツールとその CLI (composer-cli) が仮想マシンにインストールされている。
  • virt-customize ツールがインストールされている。

    # dnf install libguestfs-tools
  • Podman CLI ツール (podman) がインストールされている。

手順

  1. RHEL 8.7 イメージをビルドできることを確認します。

    # composer-cli distros list
    注記

    非 root として composer-cli コマンドを実行するには、ユーザーを weldr または root グループに追加します。

    # usermod -a -G weldr user
    $ newgrp weldr
  2. 次のコマンドを入力して、インストールするパッケージ、カーネルのカスタマイズ、起動時に無効化するサービスを含むイメージブループリントファイルを TOML 形式で作成します。

    $ cat << EOF > dpdk-vm.toml
    name = "dpdk_image"
    description = "Image to use with the DPDK checkup"
    version = "0.0.1"
    distro = "rhel-87"
    
    [[packages]]
    name = "dpdk"
    
    [[packages]]
    name = "dpdk-tools"
    
    [[packages]]
    name = "driverctl"
    
    [[packages]]
    name = "tuned-profiles-cpu-partitioning"
    
    [customizations.kernel]
    append = "default_hugepagesz=1GB hugepagesz=1G hugepages=8 isolcpus=2-7"
    
    [customizations.services]
    disabled = ["NetworkManager-wait-online", "sshd"]
    EOF
  3. 次のコマンドを実行して、ブループリントファイルを Image Builder ツールにプッシュします。

    # composer-cli blueprints push dpdk-vm.toml
  4. ブループリント名と出力ファイル形式を指定して、システムイメージを生成します。作成プロセスを開始すると、イメージのユニバーサル一意識別子 (UUID) が表示されます。

    # composer-cli compose start dpdk_image qcow2
  5. 作成プロセスが完了するまで待ちます。作成ステータスが FINISHED になると次のステップに進めます。

    # composer-cli compose status
  6. 次のコマンドを入力し、UUID を指定して qcow2 イメージファイルをダウンロードします。

    # composer-cli compose image <UUID>
  7. 次のコマンドを実行して、カスタマイズスクリプトを作成します。

    $ cat <<EOF >customize-vm
    echo  isolated_cores=2-7 > /etc/tuned/cpu-partitioning-variables.conf
    tuned-adm profile cpu-partitioning
    echo "options vfio enable_unsafe_noiommu_mode=1" > /etc/modprobe.d/vfio-noiommu.conf
    EOF
    $ cat <<EOF >first-boot
    driverctl set-override 0000:06:00.0 vfio-pci
    driverctl set-override 0000:07:00.0 vfio-pci
    
    mkdir /mnt/huge
    mount /mnt/huge --source nodev -t hugetlbfs -o pagesize=1GB
    EOF
  8. virt-customize ツールを使用して、Image Builder ツールによって生成されたイメージをカスタマイズします。

    $ virt-customize -a <UUID>.qcow2 --run=customize-vm --firstboot=first-boot --selinux-relabel
  9. コンテナーディスクイメージのビルドに必要なすべてのコマンドを含む Dockerfile を作成するには、次のコマンドを入力します。

    $ cat << EOF > Dockerfile
    FROM scratch
    COPY <uuid>-disk.qcow2 /disk/
    EOF

    ここでは、以下のようになります。

    <uuid>-disk.qcow2
    カスタムイメージの名前を qcow2 形式で指定します。
  10. 次のコマンドを実行し、コンテナーをビルドしてタグを追加します。

    $ podman build . -t dpdk-rhel:latest
  11. 次のコマンドを実行して、クラスターからアクセスできるレジストリーにコンテナーディスクイメージをプッシュします。

    $ podman push dpdk-rhel:latest
  12. DPDK チェックアップ config map の spec.param.vmContainerDiskImage 属性で、コンテナーディスクイメージへのリンクを指定します。

14.3.2.4. 関連情報

14.3.3. 仮想リソースの Prometheus クエリー

OpenShift Virtualization は、vCPU、ネットワーク、ストレージ、ゲストメモリースワッピングなどのクラスターインフラストラクチャーリソースの消費を監視するために使用できるメトリックを提供します。メトリックを使用して、ライブマイグレーションのステータスを照会することもできます。

OpenShift Container Platform モニタリングダッシュボードを使用して仮想化メトリックをクエリーします。

14.3.3.1. 前提条件

  • vCPU メトリックを使用するには、schedstats=enable カーネル引数を MachineConfig オブジェクトに適用する必要があります。このカーネル引数を使用すると、デバッグとパフォーマンスチューニングに使用されるスケジューラーの統計が有効になり、スケジューラーに小規模な負荷を追加できます。詳細は、ノードへのカーネル引数の追加 を参照してください。
  • ゲストメモリースワップクエリーがデータを返すには、仮想ゲストでメモリースワップを有効にする必要があります。

14.3.3.2. メトリクスのクエリー

OpenShift Container Platform モニタリングダッシュボードでは、Prometheus のクエリー言語 (PromQL) クエリーを実行し、プロットに可視化されるメトリクスを検査できます。この機能により、クラスターの状態と、モニターしているユーザー定義のワークロードに関する情報が提供されます。

クラスター管理者は、すべての OpenShift Container Platform のコアプロジェクトおよびユーザー定義プロジェクトのメトリクスをクエリーできます。

開発者として、メトリクスのクエリー時にプロジェクト名を指定する必要があります。選択したプロジェクトのメトリクスを表示するには、必要な権限が必要です。

14.3.3.2.1. クラスター管理者としてのすべてのプロジェクトのメトリクスのクエリー

クラスター管理者またはすべてのプロジェクトの表示権限を持つユーザーとして、メトリクス UI ですべてのデフォルト OpenShift Container Platform およびユーザー定義プロジェクトのメトリクスにアクセスできます。

前提条件

  • cluster-admin クラスターロールまたはすべてのプロジェクトの表示権限を持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブから、Observe Metrics を選択します。
  2. 1 つ以上のクエリーを追加するには、次のいずれかを実行します。

    オプション説明

    カスタムクエリーを作成します。

    Prometheus Query Language (PromQL) クエリーを Expression フィールドに追加します。

    PromQL 式を入力すると、オートコンプリートの提案がドロップダウンリストに表示されます。これらの提案には、関数、メトリクス、ラベル、および時間トークンが含まれます。キーボードの矢印を使用して提案された項目のいずれかを選択し、Enter を押して項目を式に追加できます。また、マウスポインターを推奨項目の上に移動して、その項目の簡単な説明を表示することもできます。

    複数のクエリーを追加します。

    クエリーの追加 を選択します。

    既存のクエリーを複製します。

    オプションメニューを選択します kebab クエリーの横にある Duplicate query を選択します。

    クエリーの実行を無効にします。

    オプションメニューを選択します kebab クエリーの横にある Disable query を選択します。

  3. 作成したクエリーを実行するには、Run queries を選択します。クエリーからのメトリクスはプロットで可視化されます。クエリーが無効な場合は、UI にエラーメッセージが表示されます。

    注記

    大量のデータで動作するクエリーは、時系列グラフの描画時にタイムアウトするか、ブラウザーをオーバーロードする可能性があります。これを回避するには、Hide graph を選択し、メトリクステーブルのみを使用してクエリーを調整します。次に、使用できるクエリーを確認した後に、グラフを描画できるようにプロットを有効にします。

    注記

    デフォルトでは、クエリーテーブルに、すべてのメトリクスとその現在の値をリスト表示する拡張ビューが表示されます。˅ を選択すると、クエリーの拡張ビューを最小にすることができます。

  4. オプション: ページ URL には、実行したクエリーが含まれます。このクエリーのセットを再度使用できるようにするには、この URL を保存します。
  5. 視覚化されたメトリクスを調べます。最初に、有効な全クエリーの全メトリクスがプロットに表示されます。次のいずれかを実行して、表示するメトリクスを選択できます。

    オプション説明

    クエリーからすべてのメトリクスを非表示にします。

    オプションメニューをクリックします kebab クエリーを選択し、Hide all series をクリックします。

    特定のメトリクスを非表示にします。

    クエリーテーブルに移動し、メトリクス名の近くにある色付きの四角形をクリックします。

    プロットを拡大し、時間範囲を変更します。

    次のいずれかになります。

    • プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。
    • 左上隅のメニューを使用して、時間範囲を選択します。

    時間範囲をリセットします。

    Reset zoom を選択します。

    特定の時点でのすべてのクエリーの出力を表示します。

    その時点でプロット上にマウスカーソルを置きます。クエリーの出力はポップアップに表示されます。

    プロットを非表示にします。

    Hide graph を選択します。

14.3.3.2.2. 開発者が行うユーザー定義プロジェクトのメトリクスのクエリー

ユーザー定義のプロジェクトのメトリクスには、開発者またはプロジェクトの表示権限を持つユーザーとしてアクセスできます。

Developer パースペクティブには、選択したプロジェクトの事前に定義された CPU、メモリー、帯域幅、およびネットワークパケットのクエリーが含まれます。また、プロジェクトの CPU、メモリー、帯域幅、ネットワークパケット、およびアプリケーションメトリクスについてカスタム Prometheus Query Language (PromQL) クエリーを実行することもできます。

注記

開発者は Developer パースペクティブのみを使用でき、Administrator パースペクティブは使用できません。開発者は、1 度に 1 つのプロジェクトのメトリクスのみをクエリーできます。

前提条件

  • 開発者として、またはメトリクスで表示しているプロジェクトの表示権限を持つユーザーとしてクラスターへのアクセスがある。
  • ユーザー定義プロジェクトのモニタリングが有効化されている。
  • ユーザー定義プロジェクトにサービスをデプロイしている。
  • サービスのモニター方法を定義するために、サービスの ServiceMonitor カスタムリソース定義 (CRD) を作成している。

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブから、Observe Metrics を選択します。
  2. Project: 一覧でメトリクスで表示するプロジェクトを選択します。
  3. Select query 一覧からクエリーを選択するか、Show PromQL を選択して、選択したクエリーに基づいてカスタム PromQL クエリーを作成します。クエリーからのメトリクスはプロットで可視化されます。

    注記

    Developer パースペクティブでは、1 度に 1 つのクエリーのみを実行できます。

  4. 次のいずれかを実行して、視覚化されたメトリクスを調べます。

    オプション説明

    プロットを拡大し、時間範囲を変更します。

    次のいずれかになります。

    • プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。
    • 左上隅のメニューを使用して、時間範囲を選択します。

    時間範囲をリセットします。

    Reset zoom を選択します。

    特定の時点でのすべてのクエリーの出力を表示します。

    その時点でプロット上にマウスカーソルを置きます。クエリーの出力はポップアップに表示されます。

14.3.3.3. 仮想化メトリクス

以下のメトリクスの記述には、Prometheus Query Language (PromQL) クエリーのサンプルが含まれます。これらのメトリクスは API ではなく、バージョン間で変更される可能性があります。

注記

以下の例では、期間を指定する topk クエリーを使用します。その期間中に仮想マシンが削除された場合でも、クエリーの出力に依然として表示されます。

14.3.3.3.1. vCPU メトリック

以下のクエリーは、入出力 I/O) を待機している仮想マシンを特定します。

kubevirt_vmi_vcpu_wait_seconds
仮想マシンの vCPU の待機時間 (秒単位) を返します。タイプ: カウンター。

'0' より大きい値は、仮想 CPU は実行する用意ができているが、ホストスケジューラーがこれをまだ実行できないことを意味します。実行できない場合には I/O に問題があることを示しています。

注記

vCPU メトリックをクエリーするには、最初に schedstats=enable カーネル引数を MachineConfig オブジェクトに適用する必要があります。このカーネル引数を使用すると、デバッグとパフォーマンスチューニングに使用されるスケジューラーの統計が有効になり、スケジューラーに小規模な負荷を追加できます。

vCPU 待機時間クエリーの例

topk(3, sum by (name, namespace) (rate(kubevirt_vmi_vcpu_wait_seconds[6m]))) > 0 1

1
このクエリーは、6 分間の任意の全タイミングで I/O を待機する上位 3 の仮想マシンを返します。
14.3.3.3.2. ネットワークメトリック

以下のクエリーは、ネットワークを飽和状態にしている仮想マシンを特定できます。

kubevirt_vmi_network_receive_bytes_total
仮想マシンのネットワークで受信したトラフィックの合計量 (バイト単位) を返します。タイプ: カウンター。
kubevirt_vmi_network_transmit_bytes_total
仮想マシンのネットワーク上で送信されるトラフィックの合計量 (バイト単位) を返します。タイプ: カウンター。

ネットワークトラフィッククエリーの例

topk(3, sum by (name, namespace) (rate(kubevirt_vmi_network_receive_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_network_transmit_bytes_total[6m]))) > 0 1

1
このクエリーは、6 分間の任意のタイミングで最大のネットワークトラフィックを送信する上位 3 の仮想マシンを返します。
14.3.3.3.3. ストレージメトリクス
14.3.3.3.3.1. ストレージ関連のトラフィック

以下のクエリーは、大量のデータを書き込んでいる仮想マシンを特定できます。

kubevirt_vmi_storage_read_traffic_bytes_total
仮想マシンのストレージ関連トラフィックの合計量 (バイト単位) を返します。タイプ: カウンター。
kubevirt_vmi_storage_write_traffic_bytes_total
仮想マシンのストレージ関連トラフィックのストレージ書き込みの合計量 (バイト単位) を返します。タイプ: カウンター。

ストレージ関連のトラフィッククエリーの例

topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_read_traffic_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_write_traffic_bytes_total[6m]))) > 0 1

1
上記のクエリーは、6 分間の任意のタイミングで最も大きなストレージトラフィックを送信する上位 3 の仮想マシンを返します。
14.3.3.3.3.2. ストレージスナップショットデータ
kubevirt_vmsnapshot_disks_restored_from_source_total
ソース仮想マシンから復元された仮想マシンディスクの総数を返します。タイプ: ゲージ。
kubevirt_vmsnapshot_disks_restored_from_source_bytes
ソース仮想マシンから復元された容量をバイト単位で返します。タイプ: ゲージ。

ストレージスナップショットデータクエリーの例

kubevirt_vmsnapshot_disks_restored_from_source_total{vm_name="simple-vm", vm_namespace="default"} 1

1
このクエリーは、ソース仮想マシンから復元された仮想マシンディスクの総数を返します。
kubevirt_vmsnapshot_disks_restored_from_source_bytes{vm_name="simple-vm", vm_namespace="default"} 1
1
このクエリーは、ソース仮想マシンから復元された容量をバイト単位で返します。
14.3.3.3.3.3. I/O パフォーマンス

以下のクエリーで、ストレージデバイスの I/O パフォーマンスを判別できます。

kubevirt_vmi_storage_iops_read_total
仮想マシンが実行している 1 秒あたりの書き込み I/O 操作の量を返します。タイプ: カウンター。
kubevirt_vmi_storage_iops_write_total
仮想マシンが実行している 1 秒あたりの読み取り I/O 操作の量を返します。タイプ: カウンター。

I/O パフォーマンスクエリーの例

topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_read_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_write_total[6m]))) > 0 1

1
上記のクエリーは、6 分間の任意のタイミングで最も大きな I/O 操作を実行している上位 3 の仮想マシンを返します。
14.3.3.3.4. ゲストメモリーのスワップメトリクス

以下のクエリーにより、メモリースワップを最も多く実行しているスワップ対応ゲストを特定できます。

kubevirt_vmi_memory_swap_in_traffic_bytes_total
仮想ゲストがスワップされているメモリーの合計量 (バイト単位) を返します。タイプ: ゲージ。
kubevirt_vmi_memory_swap_out_traffic_bytes_total
仮想ゲストがスワップアウトされているメモリーの合計量 (バイト単位) を返します。タイプ: ゲージ。

メモリースワップクエリーの例

topk(3, sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_in_traffic_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_out_traffic_bytes_total[6m]))) > 0 1

1
上記のクエリーは、6 分間の任意のタイミングでゲストが最も大きなメモリースワップを実行している上位 3 の仮想マシンを返します。
注記

メモリースワップは、仮想マシンがメモリー不足の状態にあることを示します。仮想マシンのメモリー割り当てを増やすと、この問題を軽減できます。

14.3.3.3.5. ライブマイグレーションのメトリクス

次のメトリックをクエリーして、ライブマイグレーションのステータスを表示できます。

kubevirt_migrate_vmi_data_processed_bytes
新しい仮想マシン (VM) に移行されたゲストオペレーティングシステムデータの量。タイプ: ゲージ。
kubevirt_migrate_vmi_data_remaining_bytes
移行されていないゲストオペレーティングシステムデータの量。タイプ: ゲージ。
kubevirt_migrate_vmi_dirty_memory_rate_bytes
ゲスト OS でメモリーがダーティーになる速度。ダーティメモリーとは、変更されたがまだディスクに書き込まれていないデータです。タイプ: ゲージ。
kubevirt_migrate_vmi_pending_count
保留中の移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_scheduling_count
スケジュール移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_running_count
実行中の移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_succeeded
正常に完了した移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_failed
失敗した移行の数。タイプ: ゲージ。

14.3.3.4. 関連情報

14.3.4. 仮想マシンのカスタムメトリクスの公開

OpenShift Container Platform には、コアプラットフォームコンポーネントのモニタリングを提供する事前に設定され、事前にインストールされた自己更新型のモニタリングスタックが含まれます。このモニタリングスタックは、Prometheus モニタリングシステムをベースにしています。Prometheus は Time Series を使用するデータベースであり、メトリクスのルール評価エンジンです。

OpenShift Container Platform モニタリングスタックの使用のほかに、CLI を使用してユーザー定義プロジェクトのモニタリングを有効にし、node-exporter サービスで仮想マシン用に公開されるカスタムメトリックをクエリーできます。

14.3.4.1. ノードエクスポーターサービスの設定

node-exporter エージェントは、メトリクスを収集するクラスター内のすべての仮想マシンにデプロイされます。node-exporter エージェントをサービスとして設定し、仮想マシンに関連付けられた内部メトリクスおよびプロセスを公開します。

前提条件

  • OpenShift Container Platform CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • cluster-monitoring-config ConfigMap オブジェクトを openshift-monitoring プロジェクトに作成する。
  • enableUserWorkloadtrue に設定して、user-workload-monitoring-config ConfigMap オブジェクトを openshift-user-workload-monitoring プロジェクトに設定する。

手順

  1. Service YAML ファイルを作成します。以下の例では、このファイルは node-exporter-service.yaml という名前です。

    kind: Service
    apiVersion: v1
    metadata:
      name: node-exporter-service 1
      namespace: dynamation 2
      labels:
        servicetype: metrics 3
    spec:
      ports:
        - name: exmet 4
          protocol: TCP
          port: 9100 5
          targetPort: 9100 6
      type: ClusterIP
      selector:
        monitor: metrics 7
    1
    仮想マシンからメトリクスを公開する node-exporter サービス。
    2
    サービスが作成される namespace。
    3
    サービスのラベル。ServiceMonitor はこのラベルを使用してこのサービスを照会します。
    4
    ClusterIP サービスのポート 9100 でメトリクスを公開するポートに指定された名前。
    5
    リクエストをリッスンするために node-exporter-service によって使用されるターゲットポート。
    6
    monitor ラベルが設定された仮想マシンの TCP ポート番号。
    7
    仮想マシンの Pod を照会するために使用されるラベル。この例では、ラベル monitor のある仮想マシンの Pod と、metrics の値がマッチします。
  2. node-exporter サービスを作成します。

    $ oc create -f node-exporter-service.yaml

14.3.4.2. ノードエクスポーターサービスが設定された仮想マシンの設定

node-exporter ファイルを仮想マシンにダウンロードします。次に、仮想マシンの起動時に node-exporter サービスを実行する systemd サービスを作成します。

前提条件

  • コンポーネントの Pod は openshift-user-workload-monitoring プロジェクトで実行されます。
  • このユーザー定義プロジェクトをモニターする必要のあるユーザーに monitoring-edit ロールを付与します。

手順

  1. 仮想マシンにログインします。
  2. node-exporter ファイルのバージョンに適用されるディレクトリーパスを使用して、node-exporter ファイルを仮想マシンにダウンロードします。

    $ wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
  3. 実行ファイルを展開して、/usr/bin ディレクトリーに配置します。

    $ sudo tar xvf node_exporter-1.3.1.linux-amd64.tar.gz \
        --directory /usr/bin --strip 1 "*/node_exporter"
  4. ディレクトリーのパス/etc/systemd/systemnode_exporter.service ファイルを作成します。この systemd サービスファイルは、仮想マシンの再起動時に node-exporter サービスを実行します。

    [Unit]
    Description=Prometheus Metrics Exporter
    After=network.target
    StartLimitIntervalSec=0
    
    [Service]
    Type=simple
    Restart=always
    RestartSec=1
    User=root
    ExecStart=/usr/bin/node_exporter
    
    [Install]
    WantedBy=multi-user.target
  5. systemd サービスを有効にし、起動します。

    $ sudo systemctl enable node_exporter.service
    $ sudo systemctl start node_exporter.service

検証

  • node-exporter エージェントが仮想マシンからのメトリクスを報告していることを確認します。

    $ curl http://localhost:9100/metrics

    出力例

    go_gc_duration_seconds{quantile="0"} 1.5244e-05
    go_gc_duration_seconds{quantile="0.25"} 3.0449e-05
    go_gc_duration_seconds{quantile="0.5"} 3.7913e-05

14.3.4.3. 仮想マシンのカスタムモニタリングラベルの作成

単一サービスから複数の仮想マシンに対するクエリーを有効にするには、仮想マシンの YAML ファイルにカスタムラベルを追加します。

前提条件

  • OpenShift Container Platform CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 仮想マシンを停止および再起動するための Web コンソールへのアクセス権限がある。

手順

  1. 仮想マシン設定ファイルの template spec を編集します。この例では、ラベル monitor の値が metrics になります。

    spec:
      template:
        metadata:
          labels:
            monitor: metrics
  2. 仮想マシンを停止して再起動し、monitor ラベルに指定されたラベル名を持つ新しい Pod を作成します。
14.3.4.3.1. メトリクスを取得するための node-exporter サービスのクエリー

仮想マシンのメトリクスは、/metrics の正規名の下に HTTP サービスエンドポイント経由で公開されます。メトリクスのクエリー時に、Prometheus は仮想マシンによって公開されるメトリクスエンドポイントからメトリクスを直接収集し、これらのメトリクスを確認用に表示します。

前提条件

  • cluster-admin 権限を持つユーザーまたは monitoring-edit ロールを持つユーザーとしてクラスターにアクセスできる。
  • node-exporter サービスを設定して、ユーザー定義プロジェクトのモニタリングを有効にしている。

手順

  1. サービスの namespace を指定して、HTTP サービスエンドポイントを取得します。

    $ oc get service -n <namespace> <node-exporter-service>
  2. node-exporter サービスの利用可能なすべてのメトリクスを一覧表示するには、metrics リソースをクエリーします。

    $ curl http://<172.30.226.162:9100>/metrics | grep -vE "^#|^$"

    出力例

    node_arp_entries{device="eth0"} 1
    node_boot_time_seconds 1.643153218e+09
    node_context_switches_total 4.4938158e+07
    node_cooling_device_cur_state{name="0",type="Processor"} 0
    node_cooling_device_max_state{name="0",type="Processor"} 0
    node_cpu_guest_seconds_total{cpu="0",mode="nice"} 0
    node_cpu_guest_seconds_total{cpu="0",mode="user"} 0
    node_cpu_seconds_total{cpu="0",mode="idle"} 1.10586485e+06
    node_cpu_seconds_total{cpu="0",mode="iowait"} 37.61
    node_cpu_seconds_total{cpu="0",mode="irq"} 233.91
    node_cpu_seconds_total{cpu="0",mode="nice"} 551.47
    node_cpu_seconds_total{cpu="0",mode="softirq"} 87.3
    node_cpu_seconds_total{cpu="0",mode="steal"} 86.12
    node_cpu_seconds_total{cpu="0",mode="system"} 464.15
    node_cpu_seconds_total{cpu="0",mode="user"} 1075.2
    node_disk_discard_time_seconds_total{device="vda"} 0
    node_disk_discard_time_seconds_total{device="vdb"} 0
    node_disk_discarded_sectors_total{device="vda"} 0
    node_disk_discarded_sectors_total{device="vdb"} 0
    node_disk_discards_completed_total{device="vda"} 0
    node_disk_discards_completed_total{device="vdb"} 0
    node_disk_discards_merged_total{device="vda"} 0
    node_disk_discards_merged_total{device="vdb"} 0
    node_disk_info{device="vda",major="252",minor="0"} 1
    node_disk_info{device="vdb",major="252",minor="16"} 1
    node_disk_io_now{device="vda"} 0
    node_disk_io_now{device="vdb"} 0
    node_disk_io_time_seconds_total{device="vda"} 174
    node_disk_io_time_seconds_total{device="vdb"} 0.054
    node_disk_io_time_weighted_seconds_total{device="vda"} 259.79200000000003
    node_disk_io_time_weighted_seconds_total{device="vdb"} 0.039
    node_disk_read_bytes_total{device="vda"} 3.71867136e+08
    node_disk_read_bytes_total{device="vdb"} 366592
    node_disk_read_time_seconds_total{device="vda"} 19.128
    node_disk_read_time_seconds_total{device="vdb"} 0.039
    node_disk_reads_completed_total{device="vda"} 5619
    node_disk_reads_completed_total{device="vdb"} 96
    node_disk_reads_merged_total{device="vda"} 5
    node_disk_reads_merged_total{device="vdb"} 0
    node_disk_write_time_seconds_total{device="vda"} 240.66400000000002
    node_disk_write_time_seconds_total{device="vdb"} 0
    node_disk_writes_completed_total{device="vda"} 71584
    node_disk_writes_completed_total{device="vdb"} 0
    node_disk_writes_merged_total{device="vda"} 19761
    node_disk_writes_merged_total{device="vdb"} 0
    node_disk_written_bytes_total{device="vda"} 2.007924224e+09
    node_disk_written_bytes_total{device="vdb"} 0

14.3.4.4. ノードエクスポーターサービスの ServiceMonitor リソースの作成

Prometheus クライアントライブラリーを使用し、/metrics エンドポイントからメトリクスを収集して、node-exporter サービスが公開するメトリクスにアクセスし、表示できます。ServiceMonitor カスタムリソース定義 (CRD) を使用して、ノードエクスポーターサービスをモニターします。

前提条件

  • cluster-admin 権限を持つユーザーまたは monitoring-edit ロールを持つユーザーとしてクラスターにアクセスできる。
  • node-exporter サービスを設定して、ユーザー定義プロジェクトのモニタリングを有効にしている。

手順

  1. ServiceMonitor リソース設定の YAML ファイルを作成します。この例では、サービスモニターはラベル metrics が指定されたサービスとマッチし、30 秒ごとに exmet ポートをクエリーします。

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      labels:
        k8s-app: node-exporter-metrics-monitor
      name: node-exporter-metrics-monitor 1
      namespace: dynamation 2
    spec:
      endpoints:
      - interval: 30s 3
        port: exmet 4
        scheme: http
      selector:
        matchLabels:
          servicetype: metrics
    1
    ServiceMonitor の名前。
    2
    ServiceMonitor が作成される namespace。
    3
    ポートをクエリーする間隔。
    4
    30 秒ごとにクエリーされるポートの名前
  2. node-exporter サービスの ServiceMonitor 設定を作成します。

    $ oc create -f node-exporter-metrics-monitor.yaml
14.3.4.4.1. クラスター外のノードエクスポーターサービスへのアクセス

クラスター外の node-exporter サービスにアクセスし、公開されるメトリクスを表示できます。

前提条件

  • cluster-admin 権限を持つユーザーまたは monitoring-edit ロールを持つユーザーとしてクラスターにアクセスできる。
  • node-exporter サービスを設定して、ユーザー定義プロジェクトのモニタリングを有効にしている。

手順

  1. node-exporter サービスを公開します。

    $ oc expose service -n <namespace> <node_exporter_service_name>
  2. ルートの FQDN(完全修飾ドメイン名) を取得します。

    $ oc get route -o=custom-columns=NAME:.metadata.name,DNS:.spec.host

    出力例

    NAME                    DNS
    node-exporter-service   node-exporter-service-dynamation.apps.cluster.example.org

  3. curl コマンドを使用して、node-exporter サービスのメトリクスを表示します。

    $ curl -s http://node-exporter-service-dynamation.apps.cluster.example.org/metrics

    出力例

    go_gc_duration_seconds{quantile="0"} 1.5382e-05
    go_gc_duration_seconds{quantile="0.25"} 3.1163e-05
    go_gc_duration_seconds{quantile="0.5"} 3.8546e-05
    go_gc_duration_seconds{quantile="0.75"} 4.9139e-05
    go_gc_duration_seconds{quantile="1"} 0.000189423

14.3.4.5. 関連情報

14.3.5. 仮想マシンのヘルスチェック

VirtualMachine リソースで readiness プローブと liveness プローブを定義することにより、仮想マシン (VM) のヘルスチェックを設定できます。

14.3.5.1. readiness および liveness プローブについて

readiness プローブと liveness プローブを使用して、異常な仮想マシン (VM) を検出および処理します。VM の仕様に 1 つ以上のプローブを含めて、準備ができていない VM にトラフィックが到達しないようにし、VM が応答しなくなったときに新しい VM が作成されるようにすることができます。

readiness プローブ は、VM がサービス要求を受け入れることができるかどうかを判断します。プローブが失敗すると、VM は、準備状態になるまで、利用可能なエンドポイントのリストから削除されます。

liveness プローブ は、VM が応答しているかどうかを判断します。プローブが失敗すると、VM は削除され、応答性を復元するために、新しい VM が作成されます。

VirtualMachine オブジェクトの spec.readinessProbe フィールドと spec.livenessProbe フィールドを設定することで、readiness プローブと liveness プローブを設定できます。これらのフィールドは、以下のテストをサポートします。

HTTP GET
プローブは、Web フックを使用して VM の正常性を判断します。このテストは、HTTP の応答コードが 200 から 399 までの値の場合に正常と見なされます。完全に初期化されている場合に、HTTP ステータスコードを返すアプリケーションで HTTP GET テストを使用できます。
TCP ソケット
プローブは、VM へのソケットを開こうとします。プローブが接続を確立できる場合のみ、VM は正常であると見なされます。TCP ソケットテストは、初期化が完了するまでリスニングを開始しないアプリケーションで使用できます。
ゲストエージェントの ping
プローブは、guest-ping コマンドを使用して、QEMU ゲストエージェントが仮想マシンで実行されているかどうかを判断します。
14.3.5.1.1. HTTP readiness プローブの定義

仮想マシン (VM) 設定の spec.readinessProbe.httpGet フィールドを設定して、HTTP readiness プローブを定義します。

手順

  1. VM 設定ファイルに readiness プローブの詳細を含めます。

    HTTP GET テストを使用した readiness プローブの例

    # ...
    spec:
      readinessProbe:
        httpGet: 1
          port: 1500 2
          path: /healthz 3
          httpHeaders:
          - name: Custom-Header
            value: Awesome
        initialDelaySeconds: 120 4
        periodSeconds: 20 5
        timeoutSeconds: 10 6
        failureThreshold: 3 7
        successThreshold: 3 8
    # ...

    1
    VM に接続するために実行する HTTP GET 要求。
    2
    プローブがクエリーする VM のポート。上記の例では、プローブはポート 1500 をクエリーします。
    3
    HTTP サーバーでアクセスするパス。上記の例では、サーバーの /healthz パスのハンドラーが成功コードを返した場合、VM は正常であると見なされます。ハンドラーが失敗コードを返した場合、VM は使用可能なエンドポイントのリストから削除されます。
    4
    VM が起動してから準備プローブが開始されるまでの時間 (秒単位)。
    5
    プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は timeoutSeconds よりも大きくなければなりません。
    6
    プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブな秒数。デフォルト値は 1 です。この値は periodSeconds 未満である必要があります。
    7
    プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には Unready というマークが付けられます。
    8
    成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。
  2. 次のコマンドを実行して VM を作成します。

    $ oc create -f <file_name>.yaml
14.3.5.1.2. TCP readiness プローブの定義

仮想マシン (VM) 設定の spec.readinessProbe.tcpSocket フィールドを設定して、TCP readiness プローブを定義します。

手順

  1. TCP readiness プローブの詳細を VM 設定ファイルに追加します。

    TCP ソケットテストを含む readiness プローブの例

    # ...
    spec:
      readinessProbe:
        initialDelaySeconds: 120 1
        periodSeconds: 20 2
        tcpSocket: 3
          port: 1500 4
        timeoutSeconds: 10 5
    # ...

    1
    VM が起動してから準備プローブが開始されるまでの時間 (秒単位)。
    2
    プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は timeoutSeconds よりも大きくなければなりません。
    3
    実行する TCP アクション。
    4
    プローブがクエリーする VM のポート。
    5
    プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブな秒数。デフォルト値は 1 です。この値は periodSeconds 未満である必要があります。
  2. 次のコマンドを実行して VM を作成します。

    $ oc create -f <file_name>.yaml
14.3.5.1.3. HTTP liveness プローブの定義

仮想マシン (VM) 設定の spec.livenessProbe.httpGet フィールドを設定して、HTTP liveness プローブを定義します。readiness プローブと同様に、liveness プローブの HTTP および TCP テストの両方を定義できます。この手順では、HTTP GET テストを使用して liveness プローブのサンプルを設定します。

手順

  1. VM 設定ファイルに HTTP liveness プローブの詳細を含めます。

    HTTP GET テストを使用した liveness プローブの例

    # ...
    spec:
      livenessProbe:
        initialDelaySeconds: 120 1
        periodSeconds: 20 2
        httpGet: 3
          port: 1500 4
          path: /healthz 5
          httpHeaders:
          - name: Custom-Header
            value: Awesome
        timeoutSeconds: 10 6
    # ...

    1
    VM が起動してから liveness プローブが開始されるまでの時間 (秒単位)。
    2
    プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は timeoutSeconds よりも大きくなければなりません。
    3
    VM に接続するために実行する HTTP GET 要求。
    4
    プローブがクエリーする VM のポート。上記の例では、プローブはポート 1500 をクエリーします。VM は、cloud-init を介してポート 1500 に最小限の HTTP サーバーをインストールして実行します。
    5
    HTTP サーバーでアクセスするパス。上記の例では、サーバーの /healthz パスのハンドラーが成功コードを返した場合、VM は正常であると見なされます。ハンドラーが失敗コードを返した場合、VM は削除され、新しい VM が作成されます。
    6
    プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブな秒数。デフォルト値は 1 です。この値は periodSeconds 未満である必要があります。
  2. 次のコマンドを実行して VM を作成します。

    $ oc create -f <file_name>.yaml

14.3.5.2. ウォッチドッグの定義

次の手順を実行して、ゲスト OS の正常性を監視するウォッチドッグを定義できます。

  1. 仮想マシン (VM) のウォッチドッグデバイスを設定します。
  2. ゲストにウォッチドッグエージェントをインストールします。

ウォッチドッグデバイスはエージェントを監視し、ゲストオペレーティングシステムが応答しない場合、次のいずれかのアクションを実行します。

  • poweroff: VM の電源がすぐにオフになります。spec.runningtrue に設定されているか、spec.runStrategymanual に設定されていない場合、VM は再起動します。
  • reset: VM はその場で再起動し、ゲストオペレーティングシステムは反応できません。

    注記

    再起動時間が原因で liveness プローブがタイムアウトする場合があります。クラスターレベルの保護が liveness プローブの失敗を検出すると、VM が強制的に再スケジュールされ、再起動時間が長くなる可能性があります。

  • shutdown: すべてのサービスを停止することで、VM の電源を正常にオフにします。
注記

ウォッチドッグは、Windows VM では使用できません。

14.3.5.2.1. 仮想マシンのウォッチドッグデバイスの設定

仮想マシン (VM) のウォッチドッグデバイスを設定するとします。

前提条件

  • VM には、i6300esb ウォッチドッグデバイスのカーネルサポートが必要です。Red Hat Enterprise Linux(RHEL) イメージが、i6300esb をサポートしている。

手順

  1. 次の内容で YAML ファイルを作成します。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        kubevirt.io/vm: vm2-rhel84-watchdog
      name: <vm-name>
    spec:
      running: false
      template:
        metadata:
          labels:
            kubevirt.io/vm: vm2-rhel84-watchdog
        spec:
          domain:
            devices:
              watchdog:
                name: <watchdog>
                i6300esb:
                  action: "poweroff" 1
    # ...
    1
    poweroffreset、または shutdown を指定します。

    上記の例では、電源オフアクションを使用して、RHEL8 VM で i6300esb ウォッチドッグデバイスを設定し、デバイスを /dev/watchdog として公開します。

    このデバイスは、ウォッチドッグバイナリーで使用できるようになりました。

  2. 以下のコマンドを実行して、YAML ファイルをクラスターに適用します。

    $ oc apply -f <file_name>.yaml
重要

この手順は、ウォッチドッグ機能をテストするためにのみ提供されており、実稼働マシンでは実行しないでください。

  1. 以下のコマンドを実行して、VM がウォッチドッグデバイスに接続されていることを確認します。

    $ lspci | grep watchdog -i
  2. 以下のコマンドのいずれかを実行して、ウォッチドッグがアクティブであることを確認します。

    • カーネルパニックをトリガーします。

      # echo c > /proc/sysrq-trigger
    • ウォッチドッグサービスを停止します。

      # pkill -9 watchdog
14.3.5.2.2. ゲストへのウォッチドッグエージェントのインストール

ゲストにウォッチドッグエージェントをインストールし、watchdog サービスを開始します。

手順

  1. root ユーザーとして仮想マシンにログインします。
  2. watchdog ドッグパッケージとその依存関係をインストールします。

    # yum install watchdog
  3. /etc/watchdog.conf ファイルの次の行のコメントを外し、変更を保存します。

    #watchdog-device = /dev/watchdog
  4. 起動時に watchdog サービスを開始できるようにします。

    # systemctl enable --now watchdog.service

14.3.5.3. ゲストエージェントの ping プローブの定義

仮想マシン (VM) 設定の spec.readinessProbe.guestAgentPing フィールドを設定して、ゲストエージェント ping プローブを定義します。

重要

ゲストエージェント ping プローブは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

前提条件

  • 仮想マシンに QEMU ゲストエージェントをインストールして有効にする必要があります。

手順

  1. VM 設定ファイルにゲストエージェント ping プローブの詳細を含めます。以下に例を示します。

    ゲストエージェント ping プローブの例

    # ...
    spec:
      readinessProbe:
        guestAgentPing: {} 1
        initialDelaySeconds: 120 2
        periodSeconds: 20 3
        timeoutSeconds: 10 4
        failureThreshold: 3 5
        successThreshold: 3 6
    # ...

    1
    VM に接続するためのゲストエージェント ping プローブ。
    2
    オプション: VM が起動してからゲストエージェントプローブが開始されるまでの時間 (秒単位)。
    3
    オプション: プローブを実行する間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は timeoutSeconds よりも大きくなければなりません。
    4
    オプション: プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブの秒数。デフォルト値は 1 です。この値は periodSeconds 未満である必要があります。
    5
    オプション: プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には Unready というマークが付けられます。
    6
    オプション: 成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。
  2. 次のコマンドを実行して VM を作成します。

    $ oc create -f <file_name>.yaml

14.3.5.4. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.