8.3. ブートソースの自動更新の管理


次のブートソースの自動更新を管理できます。

ブートソースにより、ユーザーは仮想マシン (VM) をよりアクセスしやすく効率的に作成できるようになります。ブートソースの自動更新が有効になっている場合、コンテナー化データインポーター (CDI) はイメージをインポート、ポーリング、更新して、新しい仮想マシン用にクローンを作成できるようにします。デフォルトでは、CDI は Red Hat ブートソースを自動的に更新します。

8.3.1. Red Hat ブートソースの更新の管理

enableCommonBootImageImport 機能ゲートを無効にすることで、システム定義のすべてのブートソースの自動更新をオプトアウトできます。この機能ゲートを無効にすると、すべての DataImportCron オブジェクトが削除されます。この場合、オペレーティングシステムイメージを保存する以前にインポートされたブートソースオブジェクトは削除されませんが、管理者はこれらのオブジェクトを手動で削除できます。

enableCommonBootImageImport 機能ゲートが無効になると、DataSource オブジェクトがリセットされ、元のブートソースを指さなくなります。管理者は、DataSource オブジェクトの永続ボリューム要求 (PVC) またはボリュームスナップショットを新規作成し、それにオペレーティングシステムイメージを追加することで、ブートソースを手動で提供できます。

8.3.1.1. すべてのシステム定義のブートソースの自動更新の管理

ブートソースの自動インポートと更新を無効にすると、リソースの使用量が削減される可能性があります。切断された環境では、ブートソースの自動更新を無効にすると、CDIDataImportCronOutdated アラートがログをいっぱいにするのを防ぎます。

すべてのシステム定義のブートソースの自動更新を無効にするには、値を false に設定して、enableCommonBootImageImport 機能ゲートをオフにします。この値を true に設定すると、機能ゲートが再度有効になり、自動更新が再びオンになります。

注記

カスタムブートソースは、この設定の影響を受けません。

手順

  • HyperConverged カスタムリソース (CR) を編集して、ブートソースの自動更新の機能ゲートを切り替えます。

    • ブートソースの自動更新を無効にするには、HyperConverged CR の spec.featureGates.enableCommonBootImageImport フィールドを false に設定します。以下に例を示します。

      $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
        --type json -p '[{"op": "replace", "path": \
        "/spec/featureGates/enableCommonBootImageImport", \
        "value": false}]'
    • ブートソースの自動更新を再び有効にするには、HyperConverged CR の spec.featureGates.enableCommonBootImageImport フィールドを true に設定します。以下に例を示します。

      $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
        --type json -p '[{"op": "replace", "path": \
        "/spec/featureGates/enableCommonBootImageImport", \
        "value": true}]'

8.3.2. カスタムブートソースの更新の管理

OpenShift Virtualization によって提供されていない カスタム ブートソースは、機能ゲートによって制御されません。HyperConverged カスタムリソース (CR) を編集して、それらを個別に管理する必要があります。

重要

ストレージプロファイルを設定する必要があります。そうしないと、クラスターはカスタムブートソースの自動更新を受信できません。詳細は、ストレージプロファイルの設定 を参照してください。

8.3.2.1. カスタムブートソース更新用のストレージクラスの設定

HyperConverged カスタムリソース (CR) を編集することで、デフォルトのストレージクラスをオーバーライドできます。

重要

ブートソースは、デフォルトのストレージクラスを使用してストレージから作成されます。クラスターにデフォルトのストレージクラスがない場合は、カスタムブートソースの自動更新を設定する前に、デフォルトのストレージクラスを定義する必要があります。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. storageClassName フィールドに値を入力して、新しいストレージクラスを定義します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: rhel8-image-cron
        spec:
          template:
            spec:
              storageClassName: <new_storage_class> 1
          schedule: "0 */12 * * *" 2
          managedDataSource: <data_source> 3
    # ...
    1
    ストレージクラスを定義します。
    2
    必須: cron 形式で指定したジョブのスケジュール。
    3
    必須: 使用するデータソース。
    For the custom image to be detected as an available boot source, the value of the `spec.dataVolumeTemplates.spec.sourceRef.name` parameter in the VM template must match this value.
  3. 現在のデフォルトのストレージクラスから storageclass.kubernetes.io/is-default-class アノテーションを削除します。

    1. 次のコマンドを実行して、現在のデフォルトのストレージクラスの名前を取得します。

      $ oc get storageclass

      出力例

      NAME                          PROVISIONER                      RECLAIMPOLICY  VOLUMEBINDINGMODE    ALLOWVOLUMEEXPANSION  AGE
      csi-manila-ceph               manila.csi.openstack.org         Delete         Immediate            false                 11d
      hostpath-csi-basic (default)  kubevirt.io.hostpath-provisioner Delete         WaitForFirstConsumer false                 11d 1

      1
      この例では、現在のデフォルトのストレージクラスの名前は hostpath-csi-basic です。
    2. 次のコマンドを実行して、現在のデフォルトのストレージクラスからアノテーションを削除します。

      $ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' 1
      1
      <current_default_storage_class> をデフォルトのストレージクラスの storageClassName 値に置き換えます。
  4. 次のコマンドを実行して、新しいストレージクラスをデフォルトとして設定します。

    $ oc patch storageclass <new_storage_class> -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' 1
    1
    <new_storage_class>HyperConverged CR に追加した storageClassName 値に置き換えます。

8.3.2.2. カスタムブートソースの自動更新を有効にする

OpenShift Virtualization は、デフォルトでシステム定義のブートソースを自動的に更新しますが、カスタムブートソースは自動的に更新しません。HyperConverged カスタムリソース (CR) を編集して、自動更新を手動で有効にする必要があります。

前提条件

  • クラスターにはデフォルトのストレージクラスがあります。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. 適切なテンプレートおよびブートソースを dataImportCronTemplates セクションで追加して、HyperConverged CR を編集します。以下に例を示します。

    カスタムリソースの例

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: centos-stream9-image-cron
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
        spec:
          schedule: "0 */12 * * *" 2
          template:
            spec:
              source:
                registry: 3
                  url: docker://quay.io/containerdisks/centos-stream:9
              storage:
                resources:
                  requests:
                    storage: 30Gi
          garbageCollect: Outdated
          managedDataSource: centos-stream9 4

    1
    このアノテーションは、volumeBindingModeWaitForFirstConsumer に設定されたストレージクラスに必要です。
    2
    cron 形式で指定されるジョブのスケジュール。
    3
    レジストリーソースからデータボリュームを作成するのに使用します。node docker キャッシュに基づくデフォルトの node pullMethod ではなく、デフォルトの pod pullMethod を使用します。node docker キャッシュはレジストリーイメージがContainer.Image で利用可能な場合に便利ですが、CDI インポーターはこれにアクセスすることは許可されていません。
    4
    利用可能なブートソースとして検出するカスタムイメージの場合、イメージの managedDataSource の名前が、仮想マシンテンプレート YAML ファイルの spec.dataVolumeTemplates.spec.sourceRef.name にあるテンプレートの DataSource の名前に一致する必要があります。
  3. ファイルを保存します。

8.3.2.3. ボリュームスナップショットのブートソースを有効にする

オペレーティングシステムのベースイメージを保存するストレージクラスに関連付けられた StorageProfile のパラメーターを設定して、ボリュームスナップショットのブートソースを有効にします。DataImportCron は、元々 PVC ソースのみを維持するように設計されていましたが、特定のストレージタイプでは VolumeSnapshot ソースの方が PVC ソースよりも拡張性に優れています。

注記

ストレージプロファイルでは、単一のスナップショットからクローンを作成する場合により適切に拡張できることが証明されているボリュームスナップショットを使用してください。

前提条件

  • オペレーティングシステムイメージを含むボリュームスナップショットにアクセスできる。
  • ストレージはスナップショットをサポートしている。

手順

  1. 次のコマンドを実行して、ブートソースのプロビジョニングに使用されるストレージクラスに対応するストレージプロファイルオブジェクトを開きます。

    $ oc edit storageprofile <storage_class>
  2. StorageProfiledataImportCronSourceFormat 仕様を確認して、仮想マシンがデフォルトで PVC またはボリュームスナップショットを使用しているか確認します。
  3. 必要に応じて、dataImportCronSourceFormat 仕様を snapshot に更新して、ストレージプロファイルを編集します。

    ストレージプロファイルの例

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: StorageProfile
    metadata:
    # ...
    spec:
      dataImportCronSourceFormat: snapshot

検証

  1. ブートソースのプロビジョニングに使用されるストレージクラスに対応するストレージプロファイルオブジェクトを開きます。

    $ oc get storageprofile <storage_class>  -oyaml
  2. StorageProfiledataImportCronSourceFormat 仕様が 'snapshot' に設定されていること、および DataImportCron が指す DataSource オブジェクトがボリュームスナップショットを参照していることを確認します。

これで、これらのブートソースを使用して仮想マシンを作成できるようになりました。

8.3.3. 単一ブートソースの自動更新を無効にする

HyperConverged カスタムリソース (CR) を編集することで、カスタムブートソースかシステム定義ブートソースかに関係なく、個々のブートソースの自動更新を無効にできます。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. spec.dataImportCronTemplates フィールドを編集して、個々のブートソースの自動更新を無効にします。

    カスタムブートソース
    • spec.dataImportCronTemplates フィールドからブートソースを削除します。カスタムブートソースの自動更新はデフォルトで無効になっています。
    システム定義のブートソース
    1. ブートソースを spec.dataImportCronTemplates に追加します。

      注記

      システム定義のブートソースの自動更新はデフォルトで有効になっていますが、これらのブートソースは追加しない限り CR にリストされません。

    2. dataimportcrontemplate.kubevirt.io/enable アノテーションの値を 'false' に設定します。

      以下に例を示します。

      apiVersion: hco.kubevirt.io/v1beta1
      kind: HyperConverged
      metadata:
        name: kubevirt-hyperconverged
      spec:
        dataImportCronTemplates:
        - metadata:
            annotations:
              dataimportcrontemplate.kubevirt.io/enable: 'false'
            name: rhel8-image-cron
      # ...
  3. ファイルを保存します。

8.3.4. ブートソースのステータスの確認

HyperConverged カスタムリソース (CR) を表示することで、ブートソースがシステム定義であるかカスタムであるかを判断できます。

手順

  1. 次のコマンドを実行して、HyperConverged CR の内容を表示します。

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o yaml

    出力例

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
    # ...
    status:
    # ...
      dataImportCronTemplates:
      - metadata:
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true"
          name: centos-9-image-cron
        spec:
          garbageCollect: Outdated
          managedDataSource: centos-stream9
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  url: docker://quay.io/containerdisks/centos-stream:9
              storage:
                resources:
                  requests:
                    storage: 30Gi
            status: {}
        status:
          commonTemplate: true 1
    # ...
      - metadata:
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true"
          name: user-defined-dic
        spec:
          garbageCollect: Outdated
          managedDataSource: user-defined-centos-stream9
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  pullMethod: node
                  url: docker://quay.io/containerdisks/centos-stream:9
              storage:
                resources:
                  requests:
                    storage: 30Gi
            status: {}
        status: {} 2
    # ...

    1
    システム定義のブートソースを示します。
    2
    カスタムブートソースを示します。
  2. status.dataImportCronTemplates.status フィールドを確認して、ブートソースのステータスを確認します。

    • フィールドに commonTemplate: true が含まれている場合、それはシステム定義のブートソースです。
    • status.dataImportCronTemplates.status フィールドの値が {} の場合、それはカスタムブートソースです。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.