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 検証エラーが生じないようにします。 - ソースおよびターゲットクラスターで内部レジストリーを公開する必要があります。
手順
内部レジストリーが OpenShift Container Platform 3 および 4 クラスターで公開されていることを確認します。
OpenShift イメージレジストリーは、デフォルトで OpenShift Container Platform 4 で公開されます。
-
非セキュアなレジストリーを使用している場合、レジストリーホスト値を
/etc/container/registries.conf
の[registries.insecure]
セクションの追加し、podman
で TLS 検証エラーが生じないようにします。 次のコマンドを実行して、OpenShift Container Platform 3 レジストリーにログインします。
$ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
次のコマンドを実行して、OpenShift Container Platform 4 レジストリーにログインします。
$ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
次のコマンドを実行して、OpenShift Container Platform 3 イメージをプルします。
$ podman pull <registry_url>:<port>/openshift/<image>
次のコマンドを実行して、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'
次のコマンドを実行して、OpenShift Container Platform 4 レジストリーの OpenShift Container Platform 3 イメージにタグを付けます。
$ podman tag <registry_url>:<port>/openshift/<image> \ 1 <registry_url>:<port>/openshift/<image> 2
以下のコマンドを実行して、イメージを OpenShift Container Platform 4 レジストリーにプッシュします。
$ podman push <registry_url>:<port>/openshift/<image> 1
- 1
- OpenShift Container Platform 4 クラスターを指定します。
次のコマンドを実行して、イメージに有効なイメージストリームがあることを確認します。
$ oc get imagestream -n openshift | grep <image>
出力例
NAME IMAGE REPOSITORY TAGS UPDATED my_image image-registry.openshift-image-registry.svc:5000/openshift/my_image latest 32 seconds ago
12.4.2. ボリュームの直接移行が完了しない
ボリュームの直接移行が完了しない場合、ターゲットクラスターにソースクラスターと同じ node-selector
アノテーションが含まれていない場合があります。
Migration Toolkit for Containers (MTC) は、SCC (Security Context Constraints) およびスケジューリング要件を保持するためにすべてのアノテーションで namespace を移行します。ボリュームの直接移行の際に、MTC はソースクラスターから移行された namespace のターゲットクラスターで Rsync 転送 Pod を作成します。ターゲットクラスター namespace にソースクラスター namespace と同じアノテーションがない場合、Rsync 転送 Pod はスケジュールできません。Rsync Pod は Pending
状態のままになります。
以下の手順に従って、この問題を特定し、修正できます。
手順
MigMigration
CR のステータスを確認します。$ oc describe migmigration <pod> -n openshift-migration
出力には、以下のようなステータス情報が含まれます。
出力例
Some or all transfer pods are not running for more than 10 mins on destination cluster
ソースクラスターで、移行した namespace の詳細を取得します。
$ oc get namespace <namespace> -o yaml 1
- 1
- 移行した namespace を指定します。
ターゲットクラスターで、移行した namespace を編集します。
$ oc edit namespace <namespace>
以下の例のように、欠落している
openshift.io/node-selector
アノテーションを移行した namespace に追加します。apiVersion: v1 kind: Namespace metadata: annotations: openshift.io/node-selector: "region=east" ...
- 移行計画を再度実行します。
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 Web コンソールへのネットワークアクセスが中断された。
-
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
12.4.3.4. Velero Pod ログのバックアップストレージの場所に関するエラー
Velero
Backup
カスタムリソースに、存在しないバックアップストレージロケーション (BSL) が含まれる場合、Velero
Pod ログには以下のエラーメッセージが表示される可能性があります。
$ oc logs <Velero_Pod> -n openshift-migration
出力例
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"
これらのエラーメッセージは無視できます。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
restic_timeout
のデフォルト値は 1 時間です。大規模な移行では、このパラメーターの値を大きくすることができます。値を高くすると、エラーメッセージが返されるタイミングが遅れる可能性があることに注意してください。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators に移動します。 - Migration Toolkit for Containers Operator をクリックします。
- MigrationController タブで、migration-controller をクリックします。
YAML タブで、以下のパラメーター値を更新します。
spec: restic_timeout: 1h 1
- 1
- 有効な単位は
h
(時間)、m
(分)、およびs
(秒) です (例:3h30m15s
)。
- 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
データ検証エラーによって移行プロセスが失敗することはありません。
Restore
CR を確認して、データ検証エラーのソースを特定できます。
手順
- ターゲットクラスターにログインします。
Restore
CR を表示します。$ oc describe <registry-example-migration-rvwcm> -n openshift-migration
出力では、
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
PodVolumeRestore
CR を表示します。$ oc describe <migration-example-rvwcm-98t49>
出力では、エラーをログに記録した
Restic
Pod を特定できます。出力例
completionTimestamp: 2020-05-01T20:49:12Z errors: 1 resticErrors: 1 ... resticPod: <restic-nr2v5>
Restic
Pod ログを表示し、エラーを見つけます。$ oc logs -f <restic-nr2v5>
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
Restic の補助グループを作成し、グループ ID を MigrationController
CR マニフェストに追加して、この問題を解決することができます。
手順
- NFS ストレージで Restic の補助グループを作成します。
-
NFS ディレクトリーに
setgid
ビットを設定して、グループの所有権が継承されるようにします。 restic_supplemental_groups
パラメーターを、ソースおよびターゲットクラスターのMigrationController
CR マニフェストに追加します。spec: restic_supplemental_groups: <group_id> 1
- 1
- 補助グループ ID を指定します。
-
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
- 異なるアベイラビリティーゾーンまたはアベイラビリティーセットにあるノードでボリュームの直接移行を実行する場合、移行した Pod は PVC にアクセスできないために移行が失敗する可能性があります。(BZ#1947487)