13.4. OpenShift Update Service を使用しない非接続環境でのクラスターの更新
以下の手順を使用して、OpenShift Update Service にアクセスせずに切断された環境でクラスターを更新します。
13.4.1. 前提条件
-
ocコマンドツールインターフェイス (CLI) ツールがインストールされている。 - OpenShift Container Platform イメージリポジトリーのミラーリング で説明されているように、更新用のコンテナーイメージを使用してローカルのコンテナーイメージレジストリーをプロビジョニングしている。
-
admin権限を持つユーザーとしてクラスターにアクセスできる。RBAC の使用によるパーミッションの定義および適用 を参照してください。 - 更新が失敗し、クラスターを以前の状態に復元する 必要がある場合に備えて、最新の etcd バックアップ があります。
- すべてのマシン設定プール (MCP) が実行中であり、一時停止していないことを確認する。一時停止した MCP に関連付けられたノードは、更新プロセス中にスキップされます。カナリアロールアウト更新ストラテジーを実行している場合は、MCP を一時停止することができます。
- クラスターが手動で維持された認証情報を使用している場合は、新しいリリース用にクラウドプロバイダーリソースを更新します。これがクラスターの要件かどうかを判断する方法などについて、詳しくは 手動で維持された認証情報でクラスターを更新する準備 を参照してください。
-
Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合、アップグレードプロセス中に中断が発生する可能性があります。
PodDisruptionBudget で minAvailableが 1 に設定されている場合、削除プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudgetフィールドはノードのドレインを防ぐことができます。
Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合、アップグレードプロセス中に中断が発生する可能性があります。PodDisruptionBudget で minAvailable が 1 に設定されている場合、削除 プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget フィールドはノードのドレインを防ぐことができます。
13.4.2. MachineHealthCheck リソースの一時停止
アップグレードプロセスで、クラスター内のノードが一時的に利用できなくなる可能性があります。ワーカーノードの場合、マシンのヘルスチェックにより、このようなノードは正常ではないと識別され、それらが再起動される場合があります。このようなノードの再起動を回避するには、クラスターを更新する前にすべての MachineHealthCheck リソースを一時停止します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
一時停止する利用可能なすべての
MachineHealthCheckリソースを一覧表示するには、以下のコマンドを実行します。$ oc get machinehealthcheck -n openshift-machine-api
マシンヘルスチェックを一時停止するには、
cluster.x-k8s.io/paused=""アノテーションをMachineHealthCheckリソースに追加します。以下のコマンドを実行します。$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
注釈付きの
MachineHealthCheckリソースは以下の YAML ファイルのようになります。apiVersion: machine.openshift.io/v1beta1 kind: MachineHealthCheck metadata: name: example namespace: openshift-machine-api annotations: cluster.x-k8s.io/paused: "" spec: selector: matchLabels: role: worker unhealthyConditions: - type: "Ready" status: "Unknown" timeout: "300s" - type: "Ready" status: "False" timeout: "300s" maxUnhealthy: "40%" status: currentHealthy: 5 expectedMachines: 5重要クラスターの更新後にマシンヘルスチェックを再開します。チェックを再開するには、以下のコマンドを実行して
MachineHealthCheckリソースから pause アノテーションを削除します。$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-
13.4.3. リリースイメージダイジェストの取得
--to-image オプションを指定して oc adm upgrade コマンドを使用することで非接続環境でクラスターを更新する場合、ターゲットリリースイメージに対応する sha256 ダイジェストを参照する必要があります。
手順
インターネットに接続されているデバイスで、以下のコマンドを実行します。
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}{OCP_RELEASE_VERSION}では、更新する OpenShift Container Platform のバージョン (例:4.10.16) を指定します。{ARCHITECTURE}では、クラスターアーキテクチャー (例:x86_64、aarch64、s390x、ppc64le) を指定します。出力例
sha256:a8bfba3b6dddd1a2fbbead7dac65fe4fb8335089e4e7cae327f3bad334add31d
- クラスターの更新時に使用する sha256 ダイジェストをコピーします。
13.4.4. 切断されたクラスターの更新
切断されたクラスターを、リリースイメージをダウンロードした OpenShift Container Platform バージョンに更新します。
ローカルの OpenShift Update Service がある場合は、この手順ではなく、接続された Web コンソールまたは CLI の手順を使用して更新できます。
前提条件
- 新規リリースのイメージをレジストリーに対してミラーリングしている。
新規リリースのリリースイメージ署名 ConfigMap をクラスターに適用している。
注記リリースイメージ署名 config map を使用すると、Cluster Version Operator (CVO) は、実際のイメージ署名が想定された署名と一致するか検証し、リリースイメージの整合性を確保できます。
- ターゲットリリースイメージの sha256 ダイジェストを取得している。
-
OpenShift CLI (
oc) がインストールされている。 -
すべての
MachineHealthCheckリソースを一時停止している。
手順
クラスターを更新します。
$ oc adm upgrade --allow-explicit-upgrade --to-image ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}@<digest> 1- 1
<digest>値は、ターゲットリリースイメージの sha256 ダイジェスト (例:sha256:81154f5c03294534e1eaf0319bef7a601134f891689ccede5d705ef659aa8c92) です。
ミラーレジストリーに
ImageContentSourcePolicyを使用する場合、LOCAL_REGISTRYの代わりに正規レジストリー名を使用できます。注記ImageContentSourcePolicyオブジェクトを持つクラスターのグローバルプルシークレットのみを設定できます。プロジェクトにプルシークレットを追加することはできません。
13.4.5. イメージレジストリーのリポジトリーミラーリングの設定
コンテナーレジストリーリポジトリーのミラーリングを設定すると、次のタスクを実行できます。
- ソースイメージのレジストリーのリポジトリーからイメージをプルする要求をリダイレクトするように OpenShift Container Platform クラスターを設定し、これをミラーリングされたイメージレジストリーのリポジトリーで解決できるようにします。
- 各ターゲットリポジトリーに対して複数のミラーリングされたリポジトリーを特定し、1 つのミラーがダウンした場合に別のミラーを使用できるようにします。
OpenShift Container Platform のリポジトリーミラーリングには、以下の属性が含まれます。
- イメージプルには、レジストリーのダウンタイムに対する回復性があります。
- 切断された環境のクラスターは、quay.io などの重要な場所からイメージをプルし、会社のファイアウォールの背後にあるレジストリーに要求されたイメージを提供することができます。
- イメージのプル要求時にレジストリーへの接続が特定の順序で試行され、通常は永続レジストリーが最後に試行されます。
-
入力したミラー情報は、OpenShift Container Platform クラスターの全ノードの
/etc/containers/registries.confファイルに追加されます。 - ノードがソースリポジトリーからイメージの要求を行うと、要求されたコンテンツを見つけるまで、ミラーリングされた各リポジトリーに対する接続を順番に試行します。すべてのミラーで障害が発生した場合、クラスターはソースリポジトリーに対して試行します。成功すると、イメージはノードにプルされます。
リポジトリーミラーリングのセットアップは次の方法で実行できます。
OpenShift Container Platform のインストール時:
OpenShift Container Platform に必要なコンテナーイメージをプルし、それらのイメージを会社のファイアウォールの背後に配置することで、切断された環境にあるデータセンターに OpenShift Container Platform をインストールできます。
OpenShift Container Platform の新規インストール後:
OpenShift Container Platform のインストール中にミラーリングを設定しなかった場合は、以下のカスタムリソース (CR) オブジェクトのいずれかを使用して、インストール後に設定できます。
-
ImageDigestMirrorSet.この CR を使用すると、ダイジェスト仕様を使用して、ミラー化されたレジストリーからイメージを取得できます。 -
ImageTagMirrorSet。この CR を使用すると、イメージタグを使用して、ミラー化されたレジストリーからイメージを取得できます。
重要ImageContentSourcePolicy(ICSP) オブジェクトを使用してリポジトリーミラーリングを設定することは、非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。ImageContentSourcePolicyオブジェクトの作成に使用した既存の YAML ファイルがある場合は、oc adm migrate icspコマンドを使用して、それらのファイルをImageDigestMirrorSetYAML ファイルに変換できます。詳細については、次のセクションのイメージレジストリーリポジトリーミラーリング用の ImageContentSourcePolicy (ICSP) ファイルの変換を参照してください。-
これらのカスタムリソースオブジェクトは両方とも、次の情報を識別します。
- ミラーリングするコンテナーイメージリポジトリーのソース
- ソースリポジトリーから要求されたコンテンツを提供する各ミラーリポジトリーの個別のエントリー。
クラスターが ImageDigestMirrorSet または ImageTagMirrorSet オブジェクトを使用してリポジトリーミラーリングを設定する場合、ミラーリングされたレジストリーにはグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。
次の手順では、ImageDigestMirrorSet オブジェクトを作成するインストール後のミラー設定を作成します。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできることを確認します。 クラスターに
ImageContentSourcePolicyオブジェクトがないことを確認します。たとえば、次のコマンドを使用できます。$ oc get ImageContentSourcePolicy
出力例
No resources found
手順
ミラーリングされたリポジトリーを設定します。以下のいずれかを実行します。
- Repository Mirroring in Red Hat Quay で説明されているように、Red Hat Quay でミラーリングされたリポジトリーを設定します。Red Hat Quay を使用すると、あるリポジトリーから別のリポジトリーにイメージをコピーでき、これらのリポジトリーを一定期間繰り返し自動的に同期することもできます。
skopeoなどのツールを使用して、ソースディレクトリーからミラーリングされたリポジトリーにイメージを手動でコピーします。たとえば、Red Hat Enterprise Linux (RHEL 7 または RHEL 8) システムに skopeo RPM パッケージをインストールした後、以下の例に示すように
skopeoコマンドを使用します。$ skopeo copy \ docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \ docker://example.io/example/ubi-minimal
この例では、
example.ioいう名前のコンテナーイメージレジストリーとexampleという名前のイメージリポジトリーがあり、そこにregistry.access.redhat.comからubi9/ubi-minimalイメージをコピーします。レジストリーを作成した後、OpenShift Container Platform クラスターを設定して、ソースリポジトリーで作成される要求をミラーリングされたリポジトリーにリダイレクトできます。
- OpenShift Container Platform クラスターにログインします。
必要に応じて
ImageDigestMirrorSetまたはImageTagMirrorSetCR を作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。apiVersion: config.openshift.io/v1 1 kind: ImageDigestMirrorSet 2 metadata: name: ubi9repo spec: imageDigestMirrors: 3 - mirrors: - example.io/example/ubi-minimal 4 - example.com/example/ubi-minimal 5 source: registry.access.redhat.com/ubi9/ubi-minimal 6 mirrorSourcePolicy: AllowContactingSource 7 - mirrors: - mirror.example.com/redhat source: registry.redhat.io/openshift4 8 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.com source: registry.redhat.io 9 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net/image source: registry.example.com/example/myimage 10 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net source: registry.example.com/example 11 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net/registry-example-com source: registry.example.com 12 mirrorSourcePolicy: AllowContactingSource
- 1
- この CR で使用する API を示します。これは
config.openshift.io/v1である必要があります。 - 2
- プルタイプに応じてオブジェクトの種類を示します。
-
ImageDigestMirrorSet: ダイジェスト参照イメージをプルします。 -
ImageTagMirrorSet: タグ参照イメージをプルします。
-
- 3
- 次のいずれかのイメージプルメソッドのタイプを示します。
-
imageDigestMirrors:ImageDigestMirrorSetCR に使用します。 -
imageTagMirrors:ImageTagMirrorSetCR に使用します。
-
- 4
- ミラーリングされたイメージのレジストリーとリポジトリーの名前を示します。
- 5
- オプション: 各ターゲットリポジトリーのセカンダリーミラーリポジトリーを示します。1 つのミラーがダウンした場合、ターゲットリポジトリーは別のミラーを使用できます。
- 6
- イメージプル仕様で参照されるリポジトリーである、レジストリーおよびリポジトリーソースを示します。
- 7
- オプション: イメージのプルが失敗した場合のフォールバックポリシーを示します。
-
AllowContactingSource: ソースリポジトリーからのイメージのプルの継続的な試行を許可します。これはデフォルトになります。 -
NeverContactSource: ソースリポジトリーからのイメージのプルの継続的な試行を防ぎます。
-
- 8
- オプション: レジストリー内の namespace を示します。これにより、その namaspace で任意のイメージを使用できます。レジストリードメインをソースとして使用する場合、オブジェクトはレジストリーからすべてのリポジトリーに適用されます。
- 9
- オプション: レジストリーを示し、そのレジストリー内の任意のイメージを使用できるようにします。レジストリー名を指定すると、ソースレジストリーからミラーレジストリーまでのすべてのリポジトリーにオブジェクトが適用されます。
- 10
- イメージ
registry.example.com/example/myimage@sha256:…をミラーmirror.example.net/image@sha256:..からプルします。 - 11
- ミラー
mirror.example.net/image@sha256:…からソースレジストリー名前空間のイメージregistry.example.com/example/image@sha256:…をプルします。 - 12
- ミラーレジストリー
example.net/registry-example-com/myimage@sha256:…からイメージregistry.example.com/myimage@sha256をプルします。ImageContentSourcePolicyリソースは、ソースレジストリーからミラーレジストリーmirror.example.net/registry-example-comまでのすべてのリポジトリーに適用されます。
新規オブジェクトを作成します。
$ oc create -f registryrepomirror.yaml
オブジェクトが作成された後、新しい設定が各ノードにデプロイメントされると、Machine Config Operator (MCO) がノードを封鎖します。MCO は、
ImageTagMirrorSetオブジェクトのノードのみを再起動します。MCO はImageDigestMirrorSetオブジェクトのノードを再起動しません。ノードが uncordon されると、クラスターは、ソースリポジトリーへの要求に対してミラーリングされたリポジトリーの使用を開始します。ミラーリングされた設定が適用されていることを確認するには、ノードのいずれかで以下を実行します。
ノードの一覧を表示します。
$ oc get node
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-137-44.ec2.internal Ready worker 7m v1.26.0 ip-10-0-138-148.ec2.internal Ready master 11m v1.26.0 ip-10-0-139-122.ec2.internal Ready master 11m v1.26.0 ip-10-0-147-35.ec2.internal Ready worker 7m v1.26.0 ip-10-0-153-12.ec2.internal Ready worker 7m v1.26.0 ip-10-0-154-10.ec2.internal Ready master 11m v1.26.0
デバッグプロセスを開始し、ノードにアクセスします。
$ oc debug node/ip-10-0-147-35.ec2.internal
出力例
Starting pod/ip-10-0-147-35ec2internal-debug ... To use host binaries, run `chroot /host`
ルートディレクトリーを
/hostに変更します。sh-4.2# chroot /host
/etc/containers/registries.confファイルをチェックして、変更が行われたことを確認します。sh-4.2# cat /etc/containers/registries.conf
次の出力は、
ImageDigestMirrorSetオブジェクトとImageTagMirrorSetオブジェクトが適用されたregistries.confファイルを表しています。最後の 2 つのエントリーは、それぞれdigest-onlyおよびtag-onlyとマークされています。出力例
unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] short-name-mode = "" [[registry]] prefix = "" location = "registry.access.redhat.com/ubi9/ubi-minimal" 1 [[registry.mirror]] location = "example.io/example/ubi-minimal" 2 pull-from-mirror = "digest-only" 3 [[registry.mirror]] location = "example.com/example/ubi-minimal" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com" [[registry.mirror]] location = "mirror.example.net/registry-example-com" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com/example" [[registry.mirror]] location = "mirror.example.net" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com/example/myimage" [[registry.mirror]] location = "mirror.example.net/image" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.redhat.io" [[registry.mirror]] location = "mirror.example.com" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.redhat.io/openshift4" [[registry.mirror]] location = "mirror.example.com/redhat" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.access.redhat.com/ubi9/ubi-minimal" blocked = true 4 [[registry.mirror]] location = "example.io/example/ubi-minimal-tag" pull-from-mirror = "tag-only" 5
ソースからノードにイメージをプルし、ミラーによって解決されるかどうかを確認します。
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...
リポジトリーのミラーリングのトラブルシューティング
リポジトリーのミラーリング手順が説明どおりに機能しない場合は、リポジトリーミラーリングの動作方法についての以下の情報を使用して、問題のトラブルシューティングを行うことができます。
- 最初に機能するミラーは、プルされるイメージを指定するために使用されます。
- メインレジストリーは、他のミラーが機能していない場合にのみ使用されます。
-
システムコンテキストによって、
Insecureフラグがフォールバックとして使用されます。 -
/etc/containers/registries.confファイルの形式が最近変更されました。現在のバージョンはバージョン 2 で、TOML 形式です。 -
ImageDigestMirrorSetオブジェクトとImageTagMirrorSetオブジェクトの両方に同じリポジトリーを追加することはできません。
13.4.5.1. イメージレジストリーリポジトリーミラーリング用の ImageContentSourcePolicy (ICSP) ファイルの変換
ImageContentSourcePolicy (ICSP) オブジェクトを使用してリポジトリーミラーリングを設定することは、非推奨の機能です。この機能は引き続き OpenShift Container Platform に含まれており、引き続きサポートされます。ただし、この製品の将来のリリースでは削除される予定であり、新しいデプロイメントには推奨されません。
ICSP オブジェクトは、リポジトリーミラーリングを設定するために ImageDigestMirrorSet および ImageTagMirrorSet オブジェクトに置き換えられています。ImageContentSourcePolicy オブジェクトの作成に使用した既存の YAML ファイルがある場合は、oc adm migrate icsp コマンドを使用して、それらのファイルを ImageDigestMirrorSet YAML ファイルに変換できます。このコマンドは、API を現在のバージョンに更新し、kind 値を ImageDigestMirrorSet に変更し、spec.repositoryDigestMirrors を spec.imageDigestMirrors に変更します。ファイルの残りの部分は変更されません。
ImageDigestMirrorSet または ImageTagMirrorSet オブジェクトの詳細については、前のセクションのイメージレジストリーリポジトリーミラーリングの設定を参照してください。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできることを確認します。 -
クラスターに
ImageContentSourcePolicyオブジェクトがあることを確認します。
手順
次のコマンドを使用して、1 つ以上の
ImageContentSourcePolicyYAML ファイルをImageDigestMirrorSetYAML ファイルに変換します。$ oc adm migrate icsp <file_name>.yaml <file_name>.yaml <file_name>.yaml --dest-dir <path_to_the_directory>
ここでは、以下のようになります。
<file_name>-
ソース
ImageContentSourcePolicyYAML の名前を指定します。複数のファイル名をリストできます。 --dest-dir-
オプション: 出力
ImageDigestMirrorSetYAML のディレクトリーを指定します。設定されていない場合、ファイルは現在のディレクトリーに書き込まれます。
たとえば、次のコマンドは
icsp.yamlおよびicsp-2.yamlファイルを変換し、新しい YAML ファイルをidms-filesディレクトリーに保存します。$ oc adm migrate icsp icsp.yaml icsp-2.yaml --dest-dir idms-files
出力例
wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi8repo.5911620242173376087.yaml wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi9repo.6456931852378115011.yaml
次のコマンドを実行して CR オブジェクトを作成します。
$ oc create -f <path_to_the_directory>/<file-name>.yaml
ここでは、以下のようになります。
<path_to_the_directory>-
--dest-dirフラグを使用した場合は、ディレクトリーへのパスを指定します。 <file_name>-
ImageDigestMirrorSetYAML の名前を指定します。
13.4.6. クラスターノードの再起動の頻度を減らすために、ミラーイメージカタログの範囲を拡大
リポジトリーレベルまたはより幅広いレジストリーレベルでミラーリングされたイメージカタログのスコープを設定できます。幅広いスコープの ImageContentSourcePolicy リソースにより、リソースの変更に対応するためにノードが再起動する必要のある回数が減ります。
ImageContentSourcePolicy リソースのミラーイメージカタログの範囲を拡大するには、以下の手順を実行します。
前提条件
-
OpenShift Container Platform CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - 非接続クラスターで使用するようにミラーリングされたイメージカタログを設定する。
手順
<local_registry>,<pull_spec>, and<pull_secret_file>の値を指定して、以下のコマンドを実行します。$ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry
ここでは、以下のようになります。
- <local_registry>
-
非接続クラスター (例:
local.registry:5000) 用に設定したローカルレジストリーです。 - <pull_spec>
-
非接続レジストリーで設定されるプル仕様です (例:
redhat/redhat-operator-index:v4.13)。 - <pull_secret_file>
-
.jsonファイル形式のregistry.redhat.ioプルシークレットです。プルシークレットは、Red Hat Open Shift Cluster Manager から ダウンロードできます。
oc adm catalog mirrorコマンドは、/redhat-operator-index-manifestsディレクトリーを作成し、imageContentSourcePolicy.yaml、catalogSource.yaml、およびmapping.txtファイルを生成します。新しい
ImageContentSourcePolicyリソースをクラスターに適用します。$ oc apply -f imageContentSourcePolicy.yaml
検証
oc applyがImageContentSourcePolicyに変更を正常に適用していることを確認します。$ oc get ImageContentSourcePolicy -o yaml
出力例
apiVersion: v1 items: - apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"operator.openshift.io/v1alpha1","kind":"ImageContentSourcePolicy","metadata":{"annotations":{},"name":"redhat-operator-index"},"spec":{"repositoryDigestMirrors":[{"mirrors":["local.registry:5000"],"source":"registry.redhat.io"}]}} ...
ImageContentSourcePolicy リソースを更新した後に、OpenShift Container Platform は新しい設定を各ノードにデプロイし、クラスターはソースリポジトリーへの要求のためにミラーリングされたリポジトリーの使用を開始します。