検索

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

download PDF

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

11.7.1. ブートソースの自動更新について

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

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

EnableCommonBootImageImport 機能ゲートが無効になると、DataSource オブジェクトがリセットされ、元の PVC を指さなくなります。管理者は、DataSource オブジェクト用に新しい PVC を作成し、その PVC にオペレーティングシステムイメージを設定することにより、ブートソースを手動で提供できます。

OpenShift Virtualization によって提供されていない カスタム ブートソースは、機能ゲートによって制御されません。HyperConverged カスタムリソース (CR) を編集して、それらを個別に管理する必要があります。この方法を使用して、システム定義の個々のブートソースを管理することもできます。

11.7.2. すべてのシステムブートソースの自動更新を有効または無効にする

機能ゲートを使用して、システム定義のすべてのブートソースの自動更新を制御します。

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

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

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

注記

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

手順

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

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

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

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

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

クラスターにデフォルトのストレージクラスがあることを確認してください。次に、カスタムブートソースの自動更新を有効にします。

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

HyperConverged カスタムリソース (CR) で新しいデフォルトのストレージクラスを指定します。

重要

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

手順

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

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  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
    #...
    1
    ストレージクラスを定義します。
  3. 現在のデフォルトのストレージクラスから storageclass.kubernetes.io/is-default-class アノテーションを削除します。

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

      $ oc get sc

      出力例

      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 値に置き換えます。

11.7.3.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: centos7-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:7-2009
              storage:
                resources:
                  requests:
                    storage: 10Gi
          managedDataSource: centos7 4
          retentionPolicy: "None" 5

    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 の名前に一致する必要があります。
    5
    cron ジョブが削除されたときにデータボリュームおよびデータソースを保持するには、All を使用します。cron ジョブが削除されたときにデータボリュームおよびデータソースを削除するには、None を使用します。
  3. ファイルを保存します。

11.7.4. 特定のブートソースの自動更新を無効にする

個々のブートソースの自動更新を無効にします。

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

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. ファイルを保存します。

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

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

手順

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

    $ oc get hco -n openshift-cnv kubevirt-hyperconverged -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-7-image-cron
        spec:
          garbageCollect: Outdated
          managedDataSource: centos7
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  url: docker://quay.io/containerdisks/centos:7-2009
              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-stream8
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  pullMethod: node
                  url: docker://quay.io/containerdisks/centos-stream:8
              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.