5.6. CSI の自動移行

従来 OpenShift Container Platform に同梱されていた in-tree のストレージドライバーは非推奨となり、同等の Container Storage Interface (CSI) ドライバーに置き換えられます。OpenShift Container Platform では、サポートされている特定の in-tree ボリュームプラグインが同等の CSI ドライバーに自動移行されます。

5.6.1. 概要

in-tree(インツリー) ストレージプラグインを使用してプロビジョニングされ、この機能でサポートされるボリュームは、対応する Container Storage Interface (CSI) ドライバーに移行されます。このプロセスはデータ移行を実行しません。OpenShift Container Platform は、メモリー内の永続ボリュームオブジェクトしか変換しません。その結果、変換された永続ボリュームオブジェクトはディスクに保存されず、その内容も変更されません。

以下の in-tree(インツリー) から CSI ドライバーへの移行がサポートされます。

表5.2 in-tree/CSI ドライバーでサポートされる CSI 自動移行機能

in-tree/CSI ドライバーサポートレベルCSI の自動移行が自動的に有効になるか ?
  • Azure Disk
  • OpenStack Cinder
  • Amazon Web Services (AWS) Elastic Block Storage (EBS)
  • Google Compute Engine Persistent Disk (GCP PD)

Generally available (GA)

 Yes. For more information, see Automatic migration of in-tree volumes to CSI.

  • Azure File
  • VMware vSphere

Technology Preview (TP)

無効。有効にするには、CSI 自動移行の手動による有効化を参照してください。

また、vSphere の場合は、以下の情報を参照してください。

  • vSphere in-tree PV を使用した OpenShift Container Platform 4.12 から 4.13 への更新
  • vSphere in-tree PV を使用した OpenShift Container Platform 4.12 から 4.14 への更新

CSI 自動移行はシームレスに行ってください。この機能により、既存のすべての API オブジェクト (例: PersistentVolume、PersistentVolumeClaim、および StorageClass) を使用する方法が変更されることはありません。

in-tree の永続ボリューム (PV) または永続ボリューム要求 (PVC) の CSI 自動移行を有効にしても、元の in-tree ストレージプラグインがサポートしていない場合には、スナップショットや拡張などの新規の CSI ドライバー機能は有効にされません。

関連情報

5.6.2. in-tree ボリュームから CSI への自動移行

OpenShift Container Platform は、以下の in-tree ボリュームタイプの対応する Container Storage Interface (CSI) ドライバーへの自動のシームレスな移行をサポートします。

  • Azure Disk
  • OpenStack Cinder
  • Amazon Web Services (AWS) Elastic Block Storage (EBS)
  • Google Compute Engine Persistent Disk (GCP PD)

これらのボリュームタイプの CSI 移行は一般提供 (GA) であるとみなされ、手動の介入は必要ありません。

新規の OpenShift Container Platform 4.11 以降のインストールでは、デフォルトのストレージクラスは CSI ストレージクラスになります。このストレージクラスを使用してプロビジョニングされるすべてのボリュームは CSI 永続ボリューム (PV) です。

4.10 以前から 4.11 にアップグレードされたクラスターの場合、CSI ストレージクラスが作成され、アップグレード前にデフォルトのストレージクラスが設定されていない場合にはそれがデフォルトに設定されます。ごく稀なケースとして、同じ名前のストレージクラスがある場合、既存のストレージクラスは変更されません。既存の in-tree(インツリー) ストレージクラスはそのまま残り、既存の in-tree PV で機能するボリューム拡張などの特定の機能で必要になる場合があります。in-tree(インツリー) ストレージプラグインを参照するストレージクラスは機能し続けますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることが推奨されます。

5.6.3. CSI 自動移行の手動による有効化

開発またはステージング環境の OpenShift Container Platform クラスターで Container Storage Interface (CSI) の移行をテストする必要がある場合、以下の in-tree ボリュームタイプについて、In-tree から CSI への移行を手動で有効にする必要があります。

  • VMware vSphere Disk
  • Azure File
重要

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

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

移行後、デフォルトのストレージクラスは in-tree(インツリー) ストレージクラスのままになります。

今後の OpenShift Container Platform リリースでは、すべてのストレージ in-tree プラグインについて CSI 自動移行はデフォルトで有効になる予定です。そのため、今この機能をテストして問題を報告することが強く推奨されます。

注記

CSI 自動移行のドレイン (解放) を有効にしてから、クラスター内のすべてのノードを順番に再起動します。これには少し時間がかかる場合があります。

手順

  • 機能ゲートを有効にします (ノード → クラスターの操作 → 機能ゲートを使用した機能の有効化 を参照してください)。

    重要

    機能ゲートを使用してテクノロジープレビュー機能をオンにした後にそれらをオフにすることはできません。その結果、クラスターのアップグレードはできなくなります。

    以下の設定例により、現在テクノロジープレビュー (TP) ステータスにある、この機能でサポートされるすべての CSI ドライバーについて、CSI 自動移行が有効になります。 

    apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade 1
...
    1
    Azure File と VMware vSphere の自動移行を有効にします。

    CustomNoUpgrade featureSet と featuregates を以下のいずれかに設定して選択した CSI ドライバーの CSI 自動移行を指定できます。

    • CSIMigrationAzureFile
    • CSIMigrationvSphere

    以下の設定例では、vSphere CSI ドライバーへの自動移行のみを有効にします。 

    apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: CustomNoUpgrade
  customNoUpgrade:
    enabled:
      - CSIMigrationvSphere 1
    ...
    1
    vSphere のみの自動移行を有効にします。

関連情報

5.6.4. vSphere in-tree PV を使用した OpenShift Container Platform 4.12 から 4.13 への更新

vSphere in-tree 永続ボリューム (PV) を使用していて、OpenShift Container Platform 4.12 から 4.14 に更新する場合は、vSphere vCenter および ESXI ホストを 7.0 Update 3L または 8.0 Update 2 に更新します。更新しないと、OpenShift Container Platform の更新がブロックされます。vSphere の更新後、OpenShift Container Platform の更新が発生し、選択した場合にのみ vSphere の自動 Container Storage Interface (CSI)の移行が発生する可能性があります。

または、vSphere を更新したくない場合は、以下のコマンドを実行して管理者承認を実行することにより、OpenShift Container Platform の更新に進むことができます。 

oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.12-kube-126-vsphere-migration-in-4.14":"true"}}' --type=merge

4.12 から 4.13 にアップグレードされたクラスターに対して CSI 移行がまだ有効になっていないため、通常は、OpenShift Container Platform 4.12 から 4.13 への更新に対して要求された管理者承認を提供しても安全です。ただし、Red Hat は、すべての in-tree ボリュームを CSI ドライバーによってシームレスに管理できるように、4.14 への今後の更新のための vSphere 環境の更新の計画を開始することを推奨します。

重要

OpenShift Container Platform 4.13.10 以降に更新せ ず、vSphere を更新せ ず に移行を選択した場合( Additional resourcesでの CSI 自動移行の手動有効化 を参照)、既知の問題が発生する可能性があります。移行を選択する前に、このナレッジベースの記事 を慎重にお読みください。

関連情報

5.6.5. vSphere in-tree PV を使用した OpenShift Container Platform 4.12 から 4.14 への更新

vSphere in-tree 永続ボリューム (PV) を使用していて、OpenShift Container Platform 4.12 から 4.14 に更新する場合は、vSphere vCenter および ESXI ホストを 7.0 Update 3L または 8.0 Update 2 に更新します。更新しないと、OpenShift Container Platform の更新がブロックされます。vSphere の更新後、OpenShift Container Platform の更新が発生し、vSphere の自動 Container Storage Interface (CSI)の移行がデフォルトで自動的に実行されます。

vSphere を更新しない場合は、次のコマンドを 両方 実行して管理者承認を実行して、OpenShift Container Platform の更新を続行できます。 

oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.12-kube-126-vsphere-migration-in-4.14":"true"}}' --type=merge
oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-127-vsphere-migration-in-4.14":"true"}}' --type=merge
重要

vSphere を更新せずに OpenShift Container Platform 4.14 に更新すると、OpenShift Container Platform 4.14 で CSI 移行がデフォルトで有効にされているために既知の問題が発生する可能性があります。更新する前に、このナレッジベースの記事 を慎重にお読みください。

OpenShift Container Platform 4.12 から 4.14 への更新には、Extended Update Support (EUS) から EUS への更新が伴います。このタイプの更新による影響とその実行方法については、以下の 関連情報 セクションで EUS 間の更新 リンクを参照してください。

関連情報