Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

12.4. 一般的な問題および懸念事項

このセクションでは、移行時の問題を引き起こす可能性のある懸念事項および一般的な問題を説明します。

12.4.1. 非推奨の内部イメージの更新

アプリケーションが openshift namespace のイメージを使用する場合、イメージの必要なバージョンがターゲットクラスターに存在する必要があります。

OpenShift Container Platform 3 イメージが OpenShift Container Platform 4.12 で非推奨になる場合、podman を使用してイメージストリームタグを手動で更新できます。

前提条件

  • podman がインストールされている必要があります。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 非セキュアなレジストリーを使用している場合、レジストリーホスト値を /etc/container/registries.conf の [registries.insecure] セクションの追加し、podman で TLS 検証エラーが生じないようにします。
  • ソースおよびターゲットクラスターで内部レジストリーを公開する必要があります。

手順

  1. 内部レジストリーが OpenShift Container Platform 3 および 4 クラスターで公開されていることを確認します。

    OpenShift イメージレジストリーは、デフォルトで OpenShift Container Platform 4 で公開されます。

  2. 非セキュアなレジストリーを使用している場合、レジストリーホスト値を /etc/container/registries.conf の [registries.insecure] セクションの追加し、podman で TLS 検証エラーが生じないようにします。

  3. 次のコマンドを実行して、OpenShift Container Platform 3 レジストリーにログインします。 

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
    Copy to Clipboard

  4. 次のコマンドを実行して、OpenShift Container Platform 4 レジストリーにログインします。 

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
    Copy to Clipboard

  5. 次のコマンドを実行して、OpenShift Container Platform 3 イメージをプルします。 

    $ podman pull <registry_url>:<port>/openshift/<image>
    Copy to Clipboard

  6. 次のコマンドを実行して、OpenShift Container Platform 3 イメージをスキャンし、非推奨の namespace を見つけます。 

    $ oc get bc --all-namespaces --template='range .items
"BuildConfig:" .metadata.namespace/.metadata.name =>
"\t""ImageStream(FROM):" .spec.strategy.sourceStrategy.from.namespace/.spec.strategy.sourceStrategy.from.name
"\t""ImageStream(TO):" .spec.output.to.namespace/.spec.output.to.name
end'
    Copy to Clipboard

  7. 次のコマンドを実行して、OpenShift Container Platform 4 レジストリーの OpenShift Container Platform 3 イメージにタグを付けます。 

    $ podman tag <registry_url>:<port>/openshift/<image> \
    1 
    
  <registry_url>:<port>/openshift/<image>
    2
    Copy to Clipboard
    1
    OpenShift Container Platform 3 クラスターのレジストリー URL およびポートを指定します。
    2
    OpenShift Container Platform 4 クラスターのレジストリー URL およびポートを指定します。

  8. 以下のコマンドを実行して、イメージを OpenShift Container Platform 4 レジストリーにプッシュします。 

    $ podman push <registry_url>:<port>/openshift/<image>
    1
    Copy to Clipboard
    1
    OpenShift Container Platform 4 クラスターを指定します。

  9. 次のコマンドを実行して、イメージに有効なイメージストリームがあることを確認します。 

    $ oc get imagestream -n openshift | grep <image>
    Copy to Clipboard

    出力例

    NAME      IMAGE REPOSITORY                                                      TAGS    UPDATED
my_image  image-registry.openshift-image-registry.svc:5000/openshift/my_image  latest  32 seconds ago
    Copy to Clipboard

12.4.2. ボリュームの直接移行が完了しない

ボリュームの直接移行が完了しない場合、ターゲットクラスターにソースクラスターと同じ node-selector アノテーションが含まれていない場合があります。

Migration Toolkit for Containers (MTC) は、Security Context Constraints およびスケジューリング要件を保持するためにすべてのアノテーションで namespace を移行します。ボリュームの直接移行の際に、MTC はソースクラスターから移行された namespace のターゲットクラスターで Rsync 転送 Pod を作成します。ターゲットクラスター namespace にソースクラスター namespace と同じアノテーションがない場合、Rsync 転送 Pod はスケジュールできません。Rsync Pod は Pending 状態のままになります。

以下の手順に従って、この問題を特定し、修正できます。

手順

  1. MigMigration CR のステータスを確認します。 

    $ oc describe migmigration <pod> -n openshift-migration
    Copy to Clipboard

    出力には、以下のようなステータス情報が含まれます。

    出力例

    Some or all transfer pods are not running for more than 10 mins on destination cluster
    Copy to Clipboard

  2. ソースクラスターで、移行した namespace の詳細を取得します。 

    $ oc get namespace <namespace> -o yaml
    1
    Copy to Clipboard
    1
    移行した namespace を指定します。

  3. ターゲットクラスターで、移行した namespace を編集します。 

    $ oc edit namespace <namespace>
    Copy to Clipboard

  4. 以下の例のように、欠落している openshift.io/node-selector アノテーションを移行した namespace に追加します。 

    apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: "region=east"
...
    Copy to Clipboard
  5. 移行計画を再度実行します。

12.4.3. エラーメッセージおよび解決

このセクションでは、MTC (Migration Toolkit for Containers) で発生する可能性のある一般的なエラーメッセージと、それらの根本的な原因を解決する方法を説明します。

12.4.3.1. MTC コンソールへの初回アクセス時に CA 証明書エラーが表示されます。

MTC コンソールへの初回アクセスを試みる際に CA certificate error が表示される場合、クラスターのいずれかでの自己署名 CA 証明書の使用が原因である可能性があります。

この問題を解決するには、エラーメッセージに表示される oauth-authorization-server URL に移動し、証明書を受け入れます。この問題を永続的に解決するには、Web ブラウザーの信頼ストアに証明書を追加します。

証明書を受け入れた後に Unauthorized メッセージが表示される場合は、MTC コンソールに移動し、Web ページを更新します。

12.4.3.2. MTC コンソールの OAuth タイムアウトエラー

自己署名証明書を受け入れた後に connection has timed out メッセージが MTC コンソールに表示される場合、以下の原因が考えられます。

  • OAuth サーバーへのネットワークアクセスが中断された。
  • OpenShift Container Platform コンソールへのネットワークアクセスが中断された。
  • oauth-authorization-server URL へのアクセスをブロックするプロキシー設定。詳細は、MTC console inaccessible because of OAuth timeout error を参照してください。

タイムアウトの原因を特定できます。

  • ブラウザーの Web インスペクターで MTC コンソールの Web ページを検査します。
  • Migration UI Pod ログでエラーの有無を確認します。

12.4.3.3. 不明な認証局エラーで署名された証明書

自己署名証明書を使用して Migration Toolkit for Containers (MTC) のクラスターまたはレプリケーションリポジトリーのセキュリティーを保護する場合、証明書の検証は Certificate signed by unknown authority というエラーメッセージを出して失敗する可能性があります。

カスタム CA 証明書バンドルファイルを作成し、クラスターまたはレプリケーションリポジトリーの追加時に MTC の Web コンソールでこれをアップロードできます。

手順

リモートエンドポイントから CA 証明書をダウンロードし、これを CA バンドルファイルとして保存します。 

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \
1 

  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert>
2
Copy to Clipboard
1
エンドポイントのホスト FQDN およびポートを指定します (例: api.my-cluster.example.com:6443)。
2
CA バンドルファイルの名前を指定します。

12.4.3.4. Velero Pod ログのバックアップストレージの場所に関するエラー

Velero Backup カスタムリソースに、存在しないバックアップストレージロケーション (BSL) が含まれる場合、Velero Pod ログには以下のエラーメッセージが表示される可能性があります。 

$ oc logs <Velero_Pod> -n openshift-migration
Copy to Clipboard

出力例

level=error msg="Error checking repository for stale locks" error="error getting backup storage location: BackupStorageLocation.velero.io \"ts-dpa-1\" not found" error.file="/remote-source/src/github.com/vmware-tanzu/velero/pkg/restic/repository_manager.go:259"
Copy to Clipboard

これらのエラーメッセージは無視できます。BSL がなくても、移行は失敗しません。

12.4.3.5. Velero Pod ログの Pod ボリュームバックアップのタイムアウトエラー

Restic のタイムアウトにより移行が失敗する場合、以下のエラーが Velero Pod ログに表示されます。 

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1
Copy to Clipboard

restic_timeout のデフォルト値は 1 時間です。大規模な移行では、このパラメーターの値を大きくすることができます。値を高くすると、エラーメッセージが返されるタイミングが遅れる可能性があることに注意してください。

手順

  1. OpenShift Container Platform Web コンソールで、Operators Installed Operators に移動します。
  2. Migration Toolkit for Containers Operator をクリックします。
  3. MigrationController タブで、migration-controller をクリックします。

  4. YAML タブで、以下のパラメーター値を更新します。 

    spec:
  restic_timeout: 1h
    1
    Copy to Clipboard
    1
    有効な単位は h (時間)、m (分)、および s (秒) です (例: 3h30m15s)。
  5. Save をクリックします。

12.4.3.6. MigMigration カスタムリソースの Restic 検証エラー

ファイルシステムデータのコピー方法を使用して永続ボリュームを移行する際にデータ検証が失敗すると、以下のエラーが MigMigration CR に表示されます。

出力例

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details
1 

    status: "True"
    type: ResticVerifyErrors
2
Copy to Clipboard

1
エラーメッセージは Restore CR 名を識別します。
2
ResticVerifyErrors は、検証エラーが含まれる一般的なエラーの警告です。
注記

データ検証エラーによって移行プロセスが失敗することはありません。

Restore CR を確認して、データ検証エラーのソースを特定できます。

手順

  1. ターゲットクラスターにログインします。

  2. Restore CR を表示します。 

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration
    Copy to Clipboard

    出力では、PodVolumeRestore エラーのある永続ボリュームを特定できます。

    出力例

    status:
  phase: Completed
  podVolumeRestoreErrors:
  - kind: PodVolumeRestore
    name: <registry-example-migration-rvwcm-98t49>
    namespace: openshift-migration
  podVolumeRestoreResticErrors:
  - kind: PodVolumeRestore
    name: <registry-example-migration-rvwcm-98t49>
    namespace: openshift-migration
    Copy to Clipboard

  3. PodVolumeRestore CR を表示します。 

    $ oc describe <migration-example-rvwcm-98t49>
    Copy to Clipboard

    出力では、エラーをログに記録した Restic Pod を特定できます。

    出力例

      completionTimestamp: 2020-05-01T20:49:12Z
  errors: 1
  resticErrors: 1
  ...
  resticPod: <restic-nr2v5>
    Copy to Clipboard

  4. Restic Pod ログを表示し、エラーを見つけます。 

    $ oc logs -f <restic-nr2v5>
    Copy to Clipboard

12.4.3.7. root_squash を有効にして NFS ストレージから移行する場合の Restic パーミッションエラー

NFS ストレージからデータを移行していて、root_squash が有効にされている場合、Restic は nfsnobody にマップされ、これには移行を実行するパーミッションがありません。Restic Pod ログには以下のエラーが表示されます。

出力例

backup=openshift-migration/<backup_id> controller=pod-volume-backup error="fork/exec /usr/bin/restic: permission denied" error.file="/go/src/github.com/vmware-tanzu/velero/pkg/controller/pod_volume_backup_controller.go:280" error.function="github.com/vmware-tanzu/velero/pkg/controller.(*podVolumeBackupController).processBackup" logSource="pkg/controller/pod_volume_backup_controller.go:280" name=<backup_id> namespace=openshift-migration
Copy to Clipboard

Restic の補助グループを作成し、グループ ID を MigrationController CR マニフェストに追加して、この問題を解決することができます。

手順

  1. NFS ストレージで Restic の補助グループを作成します。
  2. NFS ディレクトリーに setgid ビットを設定して、グループの所有権が継承されるようにします。

  3. restic_supplemental_groups パラメーターを、ソースおよびターゲットクラスターの MigrationController CR マニフェストに追加します。 

    spec:
  restic_supplemental_groups: <group_id>
    1
    Copy to Clipboard
    1
    補助グループ ID を指定します。
  4. Restic Pod が再起動し、変更が適用されるまで待機します。

12.4.4. 既知の問題

このリリースには、以下の既知の問題があります。

  • 移行時に、MTC (Migration Toolkit for Containers) は以下の namespace アノテーションを保持します。

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups

    • openshift.io/sa.scc.uid-range

      これらのアノテーションは UID 範囲を保持し、コンテナーがターゲットクラスターのファイルシステムのパーミッションを保持できるようにします。移行された UID が、ターゲットクラスターの既存の namespace または今後の namespace 内の UID を重複させるリスクがあります。(BZ#1748440)

  • ほとんどのクラスタースコープのリソースは MTC で処理されません。アプリケーションがクラスタースコープのリソースを必要とする場合、ターゲットクラスターでそれらを手動で作成する必要がある場合があります。
  • 移行に失敗すると、移行計画は休止状態の Pod のカスタム PV 設定を保持しません。移行を手動でロールバックし、移行計画を削除し、PV 設定で新たな移行計画を作成する必要があります。(BZ#1784899)
  • Restic のタイムアウトにより大規模な移行が失敗する場合は、MigrationController カスタマーリソース (CR) マニフェストの restic_timeout パラメーターの値 (デフォルト: 1h) を増やすことができます。
  • ファイルシステムのコピー方法で移行される PV のデータ検証オプションを選択すると、パフォーマンスは大幅に遅くなります。

  • NFS ストレージからデータを移行していて、root_squash が有効になっている場合、Restic は nfsnobody にマップされます。移行に失敗し、パーミッションエラーが Restic Pod ログに表示されます。(BZ#1873641)

    Restic の補助グループを MigrationController CR マニフェストに追加することで、この問題を解決することができます。 

    spec:
...
  restic_supplemental_groups:
  - 5555
  - 6666
    Copy to Clipboard
  • 異なるアベイラビリティーゾーンまたはアベイラビリティーセットにあるノードでボリュームの直接移行を実行する場合、移行した Pod は PVC にアクセスできないために移行が失敗する可能性があります。(BZ#1947487)
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat