3.6. 非接続環境でのクラスターの更新
3.6.1. 非接続環境でのクラスターの更新について
非接続環境とは、クラスターノードがインターネットにアクセスできない環境です。このため、レジストリーにはインストールイメージを設定する必要があります。レジストリーホストがインターネットとクラスターの両方にアクセスできない場合、その環境から切断されたファイルシステムにイメージをミラーリングし、そのホストまたはリムーバブルメディアを非接続環境に置きます。ローカルコンテナーレジストリーとクラスターがミラーレジストリーのホストに接続されている場合、リリースイメージをローカルレジストリーに直接プッシュできます。
切断されたネットワーク内の複数のクラスターのミラーリングされたイメージをホストするには、1 つのコンテナーイメージレジストリーで十分です。
3.6.1.1. OpenShift Container Platform イメージのミラーリング
非接続環境でクラスターを更新するには、クラスター環境がターゲット更新に必要なイメージおよびリソースを持つミラーレジストリーにアクセスできる必要があります。以下のページでは、非接続クラスターのリポジトリーにイメージをミラーリングする手順を説明します。
3.6.1.2. 非接続環境でのクラスターの更新の実行
以下のいずれかの手順を使用して、切断された OpenShift Container Platform クラスターを更新できます。
3.6.1.3. クラスターからの OpenShift Update Service のアンインストール
以下の手順を使用して、OpenShift Update Service (OSUS) のローカルコピーをクラスターからアンインストールできます。
3.6.2. OpenShift Container Platform イメージのミラーリング
非接続環境でクラスターを更新する前に、コンテナーイメージをミラーレジストリーにミラーリングする必要があります。接続された環境でこの手順を使用して、外部コンテンツに関する組織の制限を満たしている承認済みコンテナーイメージのみをクラスターで実行するようにすることもできます。
ミラーレジストリーは、クラスターの実行中に常に実行されている必要があります。
以下に示す手順は、ミラーレジストリーにイメージをミラーリングする大まかなワークフローです。
-
リリースイメージの取得およびプッシュに使用されるすべてのデバイスに OpenShift CLI (
oc
) をインストールします。 - レジストリープルシークレットをダウンロードし、クラスターに追加します。
oc-mirror OpenShift CLI (
oc
) プラグイン を使用する場合:- リリースイメージの取得およびプッシュに使用されるすべてのデバイスに oc-mirror プラグインをインストールします。
- ミラーリングするリリースイメージを決定する際に、使用するプラグイン用のイメージセット設定ファイルを作成します。この設定ファイルは後で編集して、プラグインがミラーリングするリリースイメージを変更できます。
- ターゲットのリリースイメージをミラーレジストリーに直接ミラーリングするかリムーバブルメディアにミラーリングしてからミラーレジストリーにミラーリングします。
- oc-mirror プラグインが生成したリソースを使用するようにクラスターを設定します。
- 必要に応じてこれらの手順を繰り返し、ミラーレジストリーを更新します。
oc adm release mirror
コマンド を使用する場合:- 使用している環境とミラーリングするリリースイメージに対応する環境変数を設定します。
- ターゲットのリリースイメージをミラーレジストリーに直接ミラーリングするかリムーバブルメディアにミラーリングしてからミラーレジストリーにミラーリングします。
- 必要に応じてこれらの手順を繰り返し、ミラーレジストリーを更新します。
oc adm release mirror
コマンドを使用する場合と比較して、oc-mirror プラグインには次の利点があります。
- コンテナーイメージ以外のコンテンツをミラーリングできます。
- 初めてイメージをミラーリングした後は、レジストリー内のイメージを簡単に更新できます。
- oc-mirror プラグインは、Quay からリリースペイロードをミラーリングする自動化された方法を提供し、非接続環境で実行されている OpenShift Update Service 用の最新のグラフデータイメージを構築します。
3.6.2.1. oc-mirror プラグインを使用したリソースのミラーリング
oc-mirror OpenShift CLI (oc
) プラグインを使用して、完全なまたは部分的な非接続環境でイメージをミラーレジストリーにミラーリングできます。公式の Red Hat レジストリーから必要なイメージをダウンロードするには、インターネット接続のあるシステムから oc-mirror を実行する必要があります。
詳細は、oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
3.6.2.2. oc adm release mirror コマンドを使用したイメージのミラーリング
oc adm release mirror
コマンドを使用して、イメージをミラーレジストリーにミラーリングできます。
3.6.2.2.1. 前提条件
Red Hat Quay など、OpenShift Container Platform クラスターをホストする場所に Docker v2-2 をサポートするコンテナーイメージレジストリーを持っている。
注記Red Hat Quay を使用する場合は、oc-mirror プラグインでバージョン 3.6 以降を使用する必要があります。Red Hat Quay のライセンスをお持ちの場合は、概念実証のため に、または Quay Operator を使用 して Red Hat Quay をデプロイする方法を記載したドキュメントを参照してください。レジストリーの選択とインストールについてさらにサポートが必要な場合は、営業担当者または Red Hat サポートにお問い合わせください。
コンテナーイメージレジストリーの既存のソリューションがない場合は、OpenShift Container Platform サブスクリプションに含まれる Red Hat OpenShift のミラーレジストリー を使用できます。Red Hat OpenShift のミラーレジストリー は、非接続インストールおよび更新で OpenShift Container Platform コンテナーイメージをミラーリングするために使用できる小規模なコンテナーレジストリーです。
3.6.2.2.2. ミラーホストの準備
ミラー手順を実行する前に、ホストを準備して、コンテンツを取得し、リモートの場所にプッシュできるようにする必要があります。
3.6.2.2.2.1. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.14 のすべてのコマンドを実行することはできません。新しいバージョンの oc
をダウンロードしてインストールしてください。非接続環境でのクラスターを更新する場合は、更新する予定の oc
バージョンをインストールします。
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.14 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。$ oc <command>
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.14 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。C:\> oc <command>
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.14 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.14 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。$ oc <command>
3.6.2.2.2.2. イメージのミラーリングを可能にする認証情報の設定
Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリーの認証情報ファイルを作成します。
クラスターのインストール時に、このイメージレジストリー認証情報ファイルをプルシークレットとして使用しないでください。クラスターのインストール時にこのファイルを指定すると、クラスター内のすべてのマシンにミラーレジストリーへの書き込みアクセスが付与されます。
このプロセスでは、ミラーレジストリーのコンテナーイメージレジストリーへの書き込みアクセスがあり、認証情報をレジストリープルシークレットに追加する必要があります。
前提条件
- 非接続環境で使用するミラーレジストリーを設定しました。
- イメージをミラーリングするミラーレジストリー上のイメージリポジトリーの場所を特定している。
- イメージのイメージリポジトリーへのアップロードを許可するミラーレジストリーアカウントをプロビジョニングしている。
手順
インストールホストで以下の手順を実行します。
-
registry.redhat.io
プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。 JSON 形式でプルシークレットのコピーを作成します。
$ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 1
- 1
- プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。
ファイルの内容は以下の例のようになります。
{ "auths": { "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
オプション: oc-mirror プラグインを使用している場合は、ファイルを
~/.docker/config.json
または$XDG_RUNTIME_DIR/containers/auth.json
として保存します。.docker
または$XDG_RUNTIME_DIR/containers
ディレクトリーが存在しない場合は、次のコマンドを入力して作成します。$ mkdir -p <directory_name>
この場合の
<directory_name>
は、~/.docker
または$XDG_RUNTIME_DIR/containers
のいずれかです。次のコマンドを入力して、プルシークレットを適切なディレクトリーにコピーします。
$ cp <path>/<pull_secret_file_in_json> <directory_name>/<auth_file>
この場合の
<directory_name>
は~/.docker
または$XDG_RUNTIME_DIR/containers
、<auth_file>
はconfig.json
またはauth.json
のいずれかです。
ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。
$ echo -n '<user_name>:<password>' | base64 -w0 1 BGVtbYk3ZHAtqXs=
- 1
<user_name>
および<password>
には、レジストリーに設定したユーザー名およびパスワードを指定します。
JSON ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。
"auths": { "<mirror_registry>": { 1 "auth": "<credentials>", 2 "email": "you@example.com" } },
ファイルは以下の例のようになります。
{ "auths": { "registry.example.com": { "auth": "BGVtbYk3ZHAtqXs=", "email": "you@example.com" }, "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
3.6.2.2.3. ミラーレジストリーへのイメージのミラーリング
OpenShift Update Service アプリケーションによる過度のメモリー使用を回避するには、以下の手順で説明するように、リリースイメージを別のリポジトリーにミラーリングする必要があります。
前提条件
- 非接続環境で使用するミラーレジストリーを設定し、設定した証明書と認証情報にアクセスできるようになりました。
- Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を組み込むように変更している。
- 自己署名証明書を使用する場合は、証明書にサブジェクトの別名を指定しています。
手順
- Red Hat OpenShift Container Platform Update Graph visualizer および update planner を使用して、あるバージョンから別のバージョンへの更新を計画します。OpenShift Update Graph はチャネルのグラフと、現行バージョンと意図されるクラスターのバージョン間に更新パスがあることを確認する方法を提供します。
必要な環境変数を設定します。
リリースバージョンをエクスポートします。
$ export OCP_RELEASE=<release_version>
<release_version>
について、更新する OpenShift Container Platform のバージョンに対応するタグを指定します (例:4.5.4
)。ローカルレジストリー名とホストポートをエクスポートします。
$ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
<local_registry_host_name>
については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port>
については、コンテンツの送信に使用するポートを指定します。ローカルリポジトリー名をエクスポートします。
$ LOCAL_REPOSITORY='<local_repository_name>'
<local_repository_name>
については、ocp4/openshift4
などのレジストリーに作成するリポジトリーの名前を指定します。OpenShift Update Service を使用している場合は、追加のローカルリポジトリー名をエクスポートして、リリースイメージを含めます。
$ LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'
<local_release_images_repository_name>
については、ocp4/openshift4-release-images
などのレジストリーに作成するリポジトリーの名前を指定します。ミラーリングするリポジトリーの名前をエクスポートします。
$ PRODUCT_REPO='openshift-release-dev'
実稼働環境のリリースの場合には、
openshift-release-dev
を指定する必要があります。パスをレジストリープルシークレットにエクスポートします。
$ LOCAL_SECRET_JSON='<path_to_pull_secret>'
<path_to_pull_secret>
については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。注記クラスターが
ImageContentSourcePolicy
オブジェクトを使用してリポジトリーのミラーリングを設定する場合、ミラーリングされたレジストリーにグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。リリースミラーをエクスポートします。
$ RELEASE_NAME="ocp-release"
実稼働環境のリリースは、
ocp-release
を指定する必要があります。クラスターのアーキテクチャーのタイプをエクスポートします。
$ ARCHITECTURE=<cluster_architecture> 1
- 1
x86_64
、aarch64
、s390x
、またはppc64le
など、クラスターのアーキテクチャーを指定します。
ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。
$ REMOVABLE_MEDIA_PATH=<path> 1
- 1
- 最初のスラッシュ (/) 文字を含む完全パスを指定します。
ミラーリングするイメージおよび設定マニフェストを確認します。
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
バージョンイメージをミラーレジストリーにミラーリングします。
ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。
- リムーバブルメディアをインターネットに接続しているシステムに接続します。
イメージおよび設定マニフェストをリムーバブルメディア上のディレクトリーにミラーリングします。
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
注記このコマンドは、ミラーリングされたリリースイメージ署名 config map も、リムーバブルメディアに保存します。
メディアを非接続環境に移動し、イメージをローカルコンテナーレジストリーにアップロードします。
$ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1
- 1
REMOVABLE_MEDIA_PATH
の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。
-
oc
コマンドラインインターフェイス (CLI) を使用して、更新しているクラスターにログインします。 ミラーリングされたリリースイメージ署名設定マップを接続されたクラスターに適用します。
$ oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file> 1
- 1
<image_signature_file>
について、ファイルのパスおよび名前を指定します (例:signature-sha256-81154f5c03294534.yaml
)。
OpenShift Update Service を使用している場合は、リリースイメージを別のリポジトリーにミラーリングします。
$ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
ローカルコンテナーレジストリーとクラスターがミラーホストに接続されている場合は、次の操作を行います。
次のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュし、config map をクラスターに適用します。
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --apply-release-image-signature
注記--apply-release-image-signature
オプションが含まれる場合は、イメージ署名の検証用に設定マップを作成しません。OpenShift Update Service を使用している場合は、リリースイメージを別のリポジトリーにミラーリングします。
$ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
3.6.3. OpenShift Update Service を使用した非接続環境でのクラスターの更新
接続されたクラスターと同じように更新するには、次の手順を使用して、非接続環境で OpenShift Update Service (OSUS) をインストールおよび設定できます。
以下の手順は、OSUS を使用して非接続環境でクラスターを更新する大まかな方法を示しています。
- セキュアなレジストリーへのアクセスを設定します。
- グローバルクラスタープルシークレットを更新して、ミラーレジストリーにアクセスします。
- OSUS Operator をインストールします。
- OpenShift Update Service のグラフデータコンテナーイメージを作成します。
- OSUS アプリケーションをインストールし、環境内で OpenShift Update Service を使用するようにクラスターを設定します。
- 接続されたクラスターの場合と同様に、ドキュメントに記載されているサポートされている更新手順を実行します。
3.6.3.1. 非接続環境での OpenShift Update Service の使用
OpenShift Update Service (OSUS) は、OpenShift Container Platform クラスターに更新の推奨事項を提供します。Red Hat は OpenShift Update Service をパブリックにホストし、接続された環境内のクラスターは、パブリック API を介してサービスに接続して更新の推奨事項を取得できます。
ただし、非接続環境のクラスターは、これらのパブリック API にアクセスして更新情報を取得することはできません。非接続環境で同じように更新を行うには、OpenShift Update Service をインストールして設定し、非接続環境で使用できるようにします。
単一の OSUS インスタンスは、数千のクラスターに推奨事項を提供できます。レプリカ値を変更することで、OSUS を水平方向に拡張して、より多くのクラスターに対応できます。したがって、ほとんどの接続されていないユースケースでは、1 つの OSUS インスタンスで十分です。たとえば、Red Hat は、接続されたクラスター全体に対して 1 つの OSUS インスタンスだけをホストします。
更新の推奨事項を異なる環境で個別に保持したい場合は、環境ごとに 1 つの OSUS インスタンスを実行できます。たとえば、テスト環境とステージ環境が別々にある場合、バージョン A がテスト環境でまだテストされていない場合、ステージ環境のクラスターがバージョン A への更新推奨を受け取らないようにすることができます。
次のセクションでは、OSUS インスタンスをインストールし、更新の推奨事項をクラスターに提供するように設定する方法を説明します。
3.6.3.2. 前提条件
-
oc
コマンドツールインターフェイス (CLI) ツールがインストールされている。 - OpenShift Container Platform イメージのミラーリング で説明されているように、更新用のコンテナーイメージを使用して、環境内にコンテナーイメージレジストリーをプロビジョニングする必要があります。
3.6.3.3. OpenShift Update Service 向けのセキュリティー保護されたレジストリーへのアクセス設定
リリースイメージが、HTTPS X.509 証明書がカスタム認証局により署名されたレジストリーに含まれている場合は、イメージレジストリーアクセスのトラストストアの追加設定 の手順を完了し、更新サービスに以下の変更を加えます。
OpenShift Update Service Operator では、設定マップのキー名 updateservice-registry
がレジストリー CA 証明書に必要です。
更新サービス向けのイメージレジストリー CA の設定マップの例
apiVersion: v1 kind: ConfigMap metadata: name: my-registry-ca data: updateservice-registry: | 1 -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- registry-with-port.example.com..5000: | 2 -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----
3.6.3.4. グローバルクラスターのプルシークレットの更新
現在のプルシークレットを置き換えるか、新しいプルシークレットを追加することで、クラスターのグローバルプルシークレットを更新できます。
ユーザーがインストール中に使用したレジストリーとは別のレジストリーを使用してイメージを保存する場合は、この手順が必要です。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
オプション: 既存のプルシークレットに新しいプルシークレットを追加するには、以下の手順を実行します。
以下のコマンドを入力してプルシークレットをダウンロードします。
$ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1
- 1
- プルシークレットファイルへのパスを指定します。
以下のコマンドを実行して、新しいプルシークレットを追加します。
$ oc registry login --registry="<registry>" \ 1 --auth-basic="<username>:<password>" \ 2 --to=<pull_secret_location> 3
または、プルシークレットファイルを手動で更新することもできます。
以下のコマンドを実行して、クラスターのグローバルプルシークレットを更新します。
$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1
- 1
- 新規プルシークレットファイルへのパスを指定します。
この更新はすべてのノードにロールアウトされます。これには、クラスターのサイズに応じて多少時間がかかる場合があります。
注記OpenShift Container Platform 4.7.4 の時点で、グローバルプルシークレットへの変更によってノードドレインまたは再起動がトリガーされなくなりました。
3.6.3.5. OpenShift Update Service のインストール
OpenShift Update Service をインストールするには、まず OpenShift Container Platform Web コンソールまたは CLI を使用して OpenShift Update Service Operator をインストールする必要があります。
非接続環境 (非接続クラスターとして知られる) にインストールされているクラスターの場合には、デフォルトで Operator Lifecycle Manager はリモートレジストリーでホストされる Red Hat が提供する OperatorHub ソースにアクセスできません。それらのリモートソースには完全なインターネット接続が必要であるためです。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
3.6.3.5.1. Web コンソールを使用した OpenShift Update Service Operator のインストール
Web コンソールを使用して、OpenShift Update Service Operator をインストールできます。
手順
Web コンソールで Operators
OperatorHub をクリックします。 注記Update Service
と Filter by keyword… フィールドに入力し、素早く Operator を見つけます。利用可能な Operator のリストから OpenShift Update Service を選択し、Install をクリックします。
- Update channel を選択します。
- Version を選択します。
- A specific namespace on the cluster が Installation Mode で選択します。
-
Installed Namespace の namespace を選択するか、推奨される namespace
openshift-update-service
を受け入れます。 Update approval strategy を選択します。
- Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
- Manual ストラテジーには、クラスター管理者が Operator の更新を承認する必要があります。
- Install をクリックします。
-
Operators
Installed Operators に移動し、OpenShift Update Service Operator がインストールされていることを確認します。 - OpenShift Update Service が選択した namespace に、Status が Succeeded でリストされていることを確認します。
3.6.3.5.2. CLI を使用した OpenShift Update Service Operator のインストール
OpenShift CLI (oc
) を使用して、OpenShift Update Service Operator をインストールできます。
手順
OpenShift Update Service Operator の namespace を作成します。
OpenShift Update Service Operator の
namespace
オブジェクト YAML ファイル (update-service-namespace.yaml
など) を作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-update-service annotations: openshift.io/node-selector: "" labels: openshift.io/cluster-monitoring: "true" 1
- 1
openshift.io/cluster-monitoring
ラベルを設定して、k この namespace で Operator が推奨するクラスターのモニタリングを有効にします。
namespace を作成します。
$ oc create -f <filename>.yaml
以下に例を示します。
$ oc create -f update-service-namespace.yaml
以下のオブジェクトを作成して OpenShift Update Service Operator をインストールします。
OperatorGroup
オブジェクト YAML ファイルを作成します (例:update-service-operator-group.yaml
)。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: update-service-operator-group namespace: openshift-update-service spec: targetNamespaces: - openshift-update-service
OperatorGroup
オブジェクトを作成します。$ oc -n openshift-update-service create -f <filename>.yaml
以下に例を示します。
$ oc -n openshift-update-service create -f update-service-operator-group.yaml
Subscription
オブジェクト YAML ファイルを作成します (例:update-service-subscription.yaml
)。Subscription の例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: update-service-subscription namespace: openshift-update-service spec: channel: v1 installPlanApproval: "Automatic" source: "redhat-operators" 1 sourceNamespace: "openshift-marketplace" name: "cincinnati-operator"
- 1
- Operator を提供するカタログソースの名前を指定します。カスタム Operator Lifecycle Manager (OLM) を使用しないクラスターの場合には、
redhat-operators
を指定します。OpenShift Container Platform クラスターが非接続環境にインストールされている場合、Operator Lifecycle Manager (OLM) を設定したときに作成されたCatalogSource
オブジェクトの名前を指定します。
Subscription
オブジェクトを作成します。$ oc create -f <filename>.yaml
以下に例を示します。
$ oc -n openshift-update-service create -f update-service-subscription.yaml
OpenShift Update Service Operator は
openshift-update-service
namespace にインストールされ、openshift-update-service
namespace をターゲットにします。
Operator のインストールを確認します。
$ oc -n openshift-update-service get clusterserviceversions
出力例
NAME DISPLAY VERSION REPLACES PHASE update-service-operator.v4.6.0 OpenShift Update Service 4.6.0 Succeeded ...
OpenShift Update Service Operator が記載されている場合には、インストールが成功しています。バージョン番号は表示されているものと異なる場合があります。
3.6.3.6. OpenShift Update Service グラフデータコンテナーイメージの作成
OpenShift Update Service には、OpenShift Update Service がチャネルメンバーシップに関する情報を取得し、更新エッジをブロックするグラフデータコンテナーイメージが必要です。通常、グラフデータは更新グラフデータリポジトリーから直接取得します。インターネット接続が利用できない場合には、グラフデータを OpenShift Update Service で利用できるようにする別の方法として init コンテナーからこの情報を読み込むことができます。init コンテナーのロールとして、グラフデータのローカルコピーを提供し、Pod の初期化時に init コンテナーはデータをサービスがアクセスできるボリュームにコピーすることが挙げられます。
oc-mirror OpenShift CLI (oc
) プラグインは、ミラーリングするリリースイメージに加えて、このグラフデータコンテナーイメージを作成します。oc-mirror プラグインを使用してリリースイメージをミラーリングした場合は、この手順を省略できます。
手順
以下を含む Dockerfile (
./Dockerfile
など) を作成します。FROM registry.access.redhat.com/ubi9/ubi:latest RUN curl -L -o cincinnati-graph-data.tar.gz https://api.openshift.com/api/upgrades_info/graph-data RUN mkdir -p /var/lib/cincinnati-graph-data && tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/cincinnati-graph-data/ --no-overwrite-dir --no-same-owner CMD ["/bin/bash", "-c" ,"exec cp -rp /var/lib/cincinnati-graph-data/* /var/lib/cincinnati/graph-data"]
上記の手順で作成した docker ファイルを使用して、グラフデータコンテナーイメージ (例:
registry.example.com/openshift/graph-data:latest
) を構築します。$ podman build -f ./Dockerfile -t registry.example.com/openshift/graph-data:latest
前の手順で作成したグラフデータコンテナーイメージを、OpenShift Update Service (例:
registry.example.com/openshift/graph-data:latest
) からアクセスできるリポジトリーにプッシュします。$ podman push registry.example.com/openshift/graph-data:latest
注記非接続環境でグラフデータイメージをレジストリーにプッシュするには、前の手順で作成したグラフデータコンテナーイメージを、OpenShift Update Service からアクセス可能なリポジトリーにコピーします。利用可能なオプションは、
oc image mirror --help
を実行します。
3.6.3.7. OpenShift Update Service アプリケーションの作成
OpenShift Container Platform Web コンソールまたは CLI を使用し、OpenShift Update Service アプリケーションを作成できます。
3.6.3.7.1. Web コンソールを使用した OpenShift Update Service アプリケーションの作成
OpenShift Container Platform Web コンソールを使用して、OpenShift Update Service Operator で OpenShift Update Service アプリケーションを作成できます。
前提条件
- OpenShift Update Service Operator がインストールされている。
- OpenShift Update Service のグラフデータコンテナーイメージを作成して、OpenShift Update Service がアクセスできるリポジトリーにプッシュしている。
- 現在のリリースと更新ターゲットリリースは、非接続環境のレジストリーにミラーリングされています。
手順
-
Web コンソールで Operators
Installed Operators をクリックします。 - インストールされた Operator のリストから OpenShift Update Service を選択します。
- Update Service タブをクリックします。
- Create UpdateService をクリックします。
-
service
など、Name フィールドに名前を入力します。 -
Graph Data Image フィールドに「OpenShift Update Service グラフデータコンテナーイメージの作成」で作成した graph-data コンテナーイメージにローカルの pullspec を入力します (例:
registry.example.com/openshift/graph-data:latest
)。 -
Releases フィールドに、「OpenShift Container Platform イメージリポジトリーのミラーリング」でリリースイメージを含むように作成したレジストリーとリポジトリー (例:
registry.example.com/ocp4/openshift4-release-images
) を入力します。 -
Replicas フィールドに
2
と入力します。 - Create をクリックして OpenShift Update Service アプリケーションを作成します。
OpenShift Update Service アプリケーションを検証します。
- Update Service タブの UpdateServices リストから、作成した Update Service アプリケーションをクリックします。
- Resources タブをクリックします。
- 各アプリケーションリソースのステータスが Created であることを確認します。
3.6.3.7.2. CLI を使用した OpenShift Update Service アプリケーションの作成
OpenShift CLI (oc
) を使用して、OpenShift Update Service アプリケーションを作成できます。
前提条件
- OpenShift Update Service Operator がインストールされている。
- OpenShift Update Service のグラフデータコンテナーイメージを作成して、OpenShift Update Service がアクセスできるリポジトリーにプッシュしている。
- 現在のリリースと更新ターゲットリリースは、非接続環境のレジストリーにミラーリングされています。
手順
OpenShift Update Service ターゲット namespace を設定します (例:
openshift-update-service
)。$ NAMESPACE=openshift-update-service
namespace は Operator グループの
targetNamespaces
値と一致する必要があります。OpenShift Update Service アプリケーションの名前 (例:
service
) を設定します。$ NAME=service
「OpenShift Container Platform イメージリポジトリーのミラーリング」と同じ方法で、リリースイメージのレジストリーおよびリポジトリーを設定します (例:
registry.example.com/ocp4/openshift4-release-images
)。$ RELEASE_IMAGES=registry.example.com/ocp4/openshift4-release-images
「OpenShift Update Service グラフデータコンテナーイメージの作成」で作成したグラフデータコンテナーイメージに、ローカルの pullspec を入力します (例:
registry.example.com/openshift/graph-data:latest
)。$ GRAPH_DATA_IMAGE=registry.example.com/openshift/graph-data:latest
OpenShift Update Service アプリケーションオブジェクトを作成します。
$ oc -n "${NAMESPACE}" create -f - <<EOF apiVersion: updateservice.operator.openshift.io/v1 kind: UpdateService metadata: name: ${NAME} spec: replicas: 2 releases: ${RELEASE_IMAGES} graphDataImage: ${GRAPH_DATA_IMAGE} EOF
OpenShift Update Service アプリケーションを検証します。
以下のコマンドを使用してポリシーエンジンルートを取得します。
$ while sleep 1; do POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"; SCHEME="${POLICY_ENGINE_GRAPH_URI%%:*}"; if test "${SCHEME}" = http -o "${SCHEME}" = https; then break; fi; done
コマンドが成功するまでポーリングが必要になる場合があります。
ポリシーエンジンからグラフを取得します。
チャネル
に有効なバージョンを指定してください。たとえば、OpenShift Container Platform 4.14 で実行している場合は、stable-4.14
を使用します。$ while sleep 10; do HTTP_CODE="$(curl --header Accept:application/json --output /dev/stderr --write-out "%{http_code}" "${POLICY_ENGINE_GRAPH_URI}?channel=stable-4.6")"; if test "${HTTP_CODE}" -eq 200; then break; fi; echo "${HTTP_CODE}"; done
これにより、グラフ要求が成功するまでポーリングされます。ただし、ミラーリングしたリリースイメージによっては、生成されるグラフが空白の場合があります。
ポリシーエンジンのルート名は、RFC-1123 に基づき、63 文字以上を指定できません。host must conform to DNS 1123 naming convention and must be no more than 63 characters
が原因で、ReconcileCompleted
のステータスが false
、理由が CreateRouteFailed
となっている場合には、更新サービスをもう少し短い名前で作成してみてください。
3.6.3.8. Cluster Version Operator (CVO) の設定
OpenShift Update Service Operator をインストールして、OpenShift Update Service アプリケーションを作成した後に、Cluster Version Operator (CVO) を更新して、環境にインストールされている OpenShift Update Service からグラフデータを取得できるようになります。
前提条件
- OpenShift Update Service Operator がインストールされている。
- OpenShift Update Service のグラフデータコンテナーイメージを作成して、OpenShift Update Service がアクセスできるリポジトリーにプッシュしている。
- 現在のリリースと更新ターゲットリリースは、非接続環境のレジストリーにミラーリングされています。
- OpenShift Update Service アプリケーションが作成されている。
手順
OpenShift Update Service ターゲット namespace を設定します (例:
openshift-update-service
)。$ NAMESPACE=openshift-update-service
OpenShift Update Service アプリケーションの名前 (例:
service
) を設定します。$ NAME=service
ポリシーエンジンルートを取得します。
$ POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
プルグラフデータのパッチを設定します。
$ PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
CVO にパッチを適用し、環境で OpenShift Update Service を使用します。
$ oc patch clusterversion version -p $PATCH --type merge
クラスター全体のプロキシーの設定 を参照して、更新サーバーを信頼するように CA を設定してください。
3.6.3.9. 次のステップ
クラスターを更新する前に、次の条件が満たされていることを確認してください。
- Cluster Version Operator (CVO) が、インストールされた OpenShift Update Service アプリケーションを使用するように設定されている。
新しいリリースのリリースイメージ署名 config map がクラスターに適用されている。
注記Cluster Version Operator (CVO) は、リリースイメージ署名が期待される結果と一致することを検証し、リリースイメージが変更されていないかを確認するためにリリースイメージ署名を使用します。
- 現在のリリースと更新ターゲットリリースのイメージは、非接続環境のレジストリーにミラーリングされている。
- 最近のグラフデータコンテナーイメージがレジストリーにミラーリングされている。
最新バージョンの OpenShift Update Service Operator がインストールされている。
注記OpenShift Update Service Operator を最近インストールまたは更新していない場合は、さらに新しいバージョンが利用できる可能性があります。非接続環境で OLM カタログを更新する方法の詳細は、制限されたネットワーク上で Operator Lifecycle Manager を使用する を参照してください。
インストールされた OpenShift Update Service とローカルミラーレジストリーを使用するようにクラスターを設定したら、次のいずれかの更新方法を使用できます。
3.6.4. OpenShift Update Service を使用しない非接続環境でのクラスターの更新
以下の手順を使用して、OpenShift Update Service にアクセスせずに非接続環境でクラスターを更新します。
3.6.4.1. 前提条件
-
oc
コマンドツールインターフェイス (CLI) ツールがインストールされている。 - OpenShift Container Platform イメージのミラーリング で説明されているように、更新用のコンテナーイメージを使用してローカルのコンテナーイメージレジストリーをプロビジョニングしている。
-
admin
権限を持つユーザーとしてクラスターにアクセスできる。RBAC の使用によるパーミッションの定義および適用 を参照してください。 - 更新が失敗し、クラスターを以前の状態に復元する 必要がある場合に備えて、最新の etcd バックアップ を用意している。
- Operator Lifecycle Manager (OLM) を通じて以前にインストールされたすべての Operator を、ターゲットリリースと互換性のあるバージョンに更新している。Operator を更新することで、デフォルトの OperatorHub カタログが、クラスターの更新時に現行のマイナーバージョンから次のマイナーバージョンに切り替わる際、確実に有効な更新パスがあるようにします。インストール済み Operator の更新 を参照し、互換性を確認する方法の詳細を確認して、インストール済みの Operator を必要に応じて更新してください。
- すべてのマシン設定プール (MCP) が実行中であり、一時停止していないことを確認する。一時停止した MCP に関連付けられたノードは、更新プロセス中にスキップされます。カナリアロールアウト更新ストラテジーを実行している場合は、MCP を一時停止できる。
- クラスターが手動で維持された認証情報を使用している場合は、新しいリリース用にクラウドプロバイダーリソースを更新します。これがクラスターの要件かどうかを判断する方法などの詳細は、手動で維持された認証情報でクラスターを更新する準備 を参照してください。
-
Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。
PodDisruptionBudget で minAvailable
が 1 に設定されている場合、削除
プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget
フィールドはノードのドレインを防ぐことができます。
Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。PodDisruptionBudget で minAvailable
が 1 に設定されている場合、削除
プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget
フィールドはノードのドレインを防ぐことができます。
3.6.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-
3.6.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 ダイジェストをコピーします。
3.6.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 <defined_registry>/<defined_repository>@<digest>
ここでは、以下のようになります。
<defined_registry>
- イメージのミラーリング先であるミラーレジストリーの名前を指定します。
<defined_repository>
- ミラーレジストリーで使用するイメージリポジトリーの名前を指定します。
<digest>
-
ターゲットリリースイメージの sha256 ダイジェストを指定します (例:
sha256:81154f5c03294534e1eaf0319bef7a601134f891689ccede5d705ef659aa8c92
)。
注記- ミラーレジストリーとリポジトリー名の定義を確認するには、「OpenShift Container Platform イメージのミラーリング」を参照してください。
-
ImageContentSourcePolicy
またはImageDigestMirrorSet
を使用した場合は、定義した名前の代わりに標準的なレジストリー名とリポジトリー名を使用できます。標準的なレジストリー名はquay.io
、標準的なリポジトリー名はopenshift-release-dev/ocp-release
です。 -
ImageContentSourcePolicy
オブジェクトを持つクラスターのグローバルプルシークレットのみを設定できます。プロジェクトにプルシークレットを追加することはできません。
3.6.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
(IDMS)。このオブジェクトを使用すると、ダイジェスト仕様を使用して、ミラーリングされたレジストリーからイメージを取得できます。IDMS CR を使用すると、イメージのプルが失敗した場合に、ソースレジストリーからのプルの継続的な試行を許可または停止するフォールバックポリシーを設定できます。 -
ImageTagMirrorSet
(ITMS)。このオブジェクトを使用すると、イメージタグを使用して、ミラーリングされたレジストリーからイメージをプルできます。ITMS CR を使用すると、イメージのプルが失敗した場合に、ソースレジストリーからのプルの継続的な試行を許可または停止するフォールバックポリシーを設定できます。 -
ImageContentSourcePolicy
(ICSP)。このオブジェクトを使用すると、ダイジェスト仕様を使用して、ミラーリングされたレジストリーからイメージを取得できます。ミラーが機能しない場合、ICSP は常にソースレジストリーにフォールバックします。
重要ImageContentSourcePolicy
(ICSP) オブジェクトを使用してリポジトリーミラーリングを設定することは、非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。ImageContentSourcePolicy
オブジェクトの作成に使用した既存の YAML ファイルがある場合は、oc adm migrate icsp
コマンドを使用して、それらのファイルをImageDigestMirrorSet
YAML ファイルに変換できます。詳細は、次のセクションの「イメージレジストリーリポジトリーミラーリング用の ImageContentSourcePolicy (ICSP) ファイルの変換」を参照してください。-
これらのカスタムリソースオブジェクトはそれぞれ、次の情報を識別します。
- ミラーリングするコンテナーイメージリポジトリーのソース
- ソースリポジトリーから要求されたコンテンツを提供する各ミラーリポジトリーの個別のエントリー。
新しいクラスターの場合は、必要に応じて IDMS、ITMS、および ICSP CR オブジェクトを使用できます。ただし、IDMS と ITMS の使用を推奨します。
クラスターをアップグレードした場合、既存の ICSP オブジェクトは安定を維持し、IDMS オブジェクトと ICSP オブジェクトの両方がサポートされるようになります。ICSP オブジェクトを使用するワークロードは、引き続き期待どおりに機能します。一方、IDMS CR で導入されたフォールバックポリシーを利用する場合は、oc adm migrate icsp
コマンドを使用して、現在のワークロードを IDMS オブジェクトに移行できます。これについては、後述の イメージレジストリーリポジトリーミラーリング用の ImageContentSourcePolicy (ICSP) ファイルの変換 セクションで説明しています。IDMS オブジェクトへの移行に、クラスターの再起動は必要ありません。
クラスターで ImageDigestMirrorSet
、ImageTagMirrorSet
、または ImageContentSourcePolicy
オブジェクトを使用してリポジトリーミラーリングを設定する場合、ミラーリングされたレジストリーにはグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。
3.6.4.5.1. イメージレジストリーのリポジトリーミラーリングの設定
インストール後のミラー設定カスタムリソース (CR) を作成して、ソースイメージレジストリーからミラーリングされたイメージレジストリーにイメージプル要求をリダイレクトできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
ミラーリングされたリポジトリーを設定します。以下のいずれかを実行します。
- 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 クラスターにログインします。
次の例のいずれかを使用して、インストール後のミラー設定 CR を作成します。
必要に応じて
ImageDigestMirrorSet
またはImageTagMirrorSet
CR を作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。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
:ImageDigestMirrorSet
CR に使用します。 -
imageTagMirrors
:ImageTagMirrorSet
CR に使用します。
-
- 4
- ミラーリングされたイメージのレジストリーとリポジトリーの名前を示します。
- 5
- オプション: 各ターゲットリポジトリーのセカンダリーミラーリポジトリーを示します。1 つのミラーがダウンした場合、ターゲットリポジトリーは別のミラーを使用できます。
- 6
- イメージプル仕様で参照されるリポジトリーである、レジストリーおよびリポジトリーソースを示します。
- 7
- オプション: イメージのプルが失敗した場合のフォールバックポリシーを示します。
-
AllowContactingSource
: ソースリポジトリーからのイメージのプルの継続的な試行を許可します。これはデフォルトになります。 -
NeverContactSource
: ソースリポジトリーからのイメージのプルの継続的な試行を防ぎます。
-
- 8
- オプション: レジストリー内の namespace を示します。これにより、その namespace で任意のイメージを使用できます。レジストリードメインをソースとして使用する場合、オブジェクトはレジストリーからすべてのリポジトリーに適用されます。
- 9
- オプション: レジストリーを示し、そのレジストリー内の任意のイメージを使用できるようにします。レジストリー名を指定すると、ソースレジストリーからミラーレジストリーまでのすべてのリポジトリーにオブジェクトが適用されます。
- 10
- イメージ
registry.example.com/example/myimage@sha256:…
をミラーmirror.example.net/image@sha256:..
からプルします。 - 11
- ミラー
mirror.example.net/image@sha256:…
からソースレジストリー namespace のイメージregistry.example.com/example/image@sha256:…
をプルします。 - 12
- ミラーレジストリー
example.net/registry-example-com/myimage@sha256:…
からイメージregistry.example.com/myimage@sha256
をプルします。
ImageContentSourcePolicy
カスタムリソースを作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: mirror-ocp spec: repositoryDigestMirrors: - mirrors: - mirror.registry.com:443/ocp/release 1 source: quay.io/openshift-release-dev/ocp-release 2 - mirrors: - mirror.registry.com:443/ocp/release source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
新規オブジェクトを作成します。
$ oc create -f registryrepomirror.yaml
オブジェクトの作成後、Machine Config Operator (MCO) は
ImageTagMirrorSet
オブジェクトのみのノードをドレインします。MCO は、ImageDigestMirrorSet
オブジェクトとImageContentSourcePolicy
オブジェクトのノードをドレインしません。ミラーリングされた設定が適用されていることを確認するには、ノードのいずれかで以下を実行します。
ノードの一覧を表示します。
$ oc get node
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-137-44.ec2.internal Ready worker 7m v1.28.5 ip-10-0-138-148.ec2.internal Ready master 11m v1.28.5 ip-10-0-139-122.ec2.internal Ready master 11m v1.28.5 ip-10-0-147-35.ec2.internal Ready worker 7m v1.28.5 ip-10-0-153-12.ec2.internal Ready worker 7m v1.28.5 ip-10-0-154-10.ec2.internal Ready master 11m v1.28.5
デバッグプロセスを開始し、ノードにアクセスします。
$ 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
次の出力は、インストール後のミラー設定 CR が適用された
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 形式です。
3.6.4.5.2. イメージレジストリーリポジトリーミラーリング用の 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
に変更します。ファイルの残りの部分は変更されません。
移行によって registries.conf
ファイルは変更されないため、クラスターを再起動する必要はありません。
ImageDigestMirrorSet
または ImageTagMirrorSet
オブジェクトの詳細は、前のセクションの「イメージレジストリーリポジトリーミラーリングの設定」を参照してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
クラスターに
ImageContentSourcePolicy
オブジェクトがあることを確認します。
手順
次のコマンドを使用して、1 つ以上の
ImageContentSourcePolicy
YAML ファイルをImageDigestMirrorSet
YAML ファイルに変換します。$ oc adm migrate icsp <file_name>.yaml <file_name>.yaml <file_name>.yaml --dest-dir <path_to_the_directory>
ここでは、以下のようになります。
<file_name>
-
ソース
ImageContentSourcePolicy
YAML の名前を指定します。複数のファイル名をリストできます。 --dest-dir
-
オプション: 出力
ImageDigestMirrorSet
YAML のディレクトリーを指定します。設定されていない場合、ファイルは現在のディレクトリーに書き込まれます。
たとえば、次のコマンドは
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>
-
ImageDigestMirrorSet
YAML の名前を指定します。
- IDMS オブジェクトがロールアウトされた後、ICSP オブジェクトを削除します。
3.6.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.14
)。 - <pull_secret_file>
-
.json
ファイル形式のregistry.redhat.io
プルシークレットです。プルシークレットは、Red Hat OpenShift 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 は新しい設定を各ノードにデプロイし、クラスターはソースリポジトリーへの要求のためにミラーリングされたリポジトリーの使用を開始します。
3.6.4.7. 関連情報
3.6.5. クラスターからの OpenShift Update Service のアンインストール
OpenShift Update Service (OSUS) のローカルコピーをクラスターから削除するには、最初に OSUS アプリケーションを削除してから、OSUS Operator をアンインストールする必要があります。
3.6.5.1. OpenShift Update Service アプリケーションの削除
OpenShift Container Platform Web コンソールまたは CLI を使用して OpenShift Update Service アプリケーションを削除できます。
3.6.5.1.1. Web コンソールを使用した OpenShift Update Service アプリケーションの削除
OpenShift Container Platform Web コンソールを使用して、OpenShift Update Service Operator で OpenShift Update Service アプリケーションを削除できます。
前提条件
- OpenShift Update Service Operator がインストールされている。
手順
-
Web コンソールで Operators
Installed Operators をクリックします。 - インストールされた Operator のリストから OpenShift Update Service を選択します。
- Update Service タブをクリックします。
- インストールされた OpenShift Update Service アプリケーションのリストから、削除するアプリケーションを選択して、Delete UpdateService をクリックします。
- Delete UpdateService? 確認ダイアログで、Delete をクリックし、削除を確定します。
3.6.5.1.2. CLI を使用した OpenShift Update Service アプリケーションの削除
OpenShift CLI (oc
) を使用して、OpenShift Update Service アプリケーションを削除できます。
手順
OpenShift Update Service アプリケーションを作成した namespace を使用して OpenShift Update Service アプリケーション名を取得します (例:
openshift-update-service
)。$ oc get updateservice -n openshift-update-service
出力例
NAME AGE service 6s
直前の手順の
NAME
の値を使用して OpenShift Update Service アプリケーションと、OpenShift Update Service アプリケーションを作成した namespace (例:openshift-update-service
) を削除します。$ oc delete updateservice service -n openshift-update-service
出力例
updateservice.updateservice.operator.openshift.io "service" deleted
3.6.5.2. OpenShift Update Service Operator のアンインストール
OpenShift Container Platform Web コンソールまたは CLI を使用して、OpenShift Update Service Operator をアンインストールできます。
3.6.5.2.1. Web コンソールを使用した OpenShift Update Service Operator のアンインストール
OpenShift Container Platform Web コンソールを使用して OpenShift Update Service Operator をアンインストールすることができます。
前提条件
- OpenShift Update Service アプリケーションがすべて削除されている。
手順
-
Web コンソールで Operators
Installed Operators をクリックします。 - インストールされた Operator のリストから OpenShift Update Service を選択し、Uninstall Operator をクリックします。
- Uninstall Operator? 確認ダイアログから Uninstall をクリックし、アンインストールを確定します。
3.6.5.2.2. CLI を使用した OpenShift Update Service Operator のアンインストール
OpenShift CLI (oc
) を使用して、OpenShift Update Service Operator をアンインストールできます。
前提条件
- OpenShift Update Service アプリケーションがすべて削除されている。
手順
OpenShift Update Service Operator (例:
openshift-update-service
) が含まれるプロジェクトに切り替えます。$ oc project openshift-update-service
出力例
Now using project "openshift-update-service" on server "https://example.com:6443".
OpenShift Update Service Operator Operator グループの名前を取得します。
$ oc get operatorgroup
出力例
NAME AGE openshift-update-service-fprx2 4m41s
Operator グループを削除します (例:
openshift-update-service-fprx2
)。$ oc delete operatorgroup openshift-update-service-fprx2
出力例
operatorgroup.operators.coreos.com "openshift-update-service-fprx2" deleted
OpenShift Update Service Operator サブスクリプションの名前を取得します。
$ oc get subscription
出力例
NAME PACKAGE SOURCE CHANNEL update-service-operator update-service-operator updateservice-index-catalog v1
直前の手順で
Name
の値を使用して、currentCSV
フィールドで、サブスクライブされた OpenShift Update Service Operator の現行バージョンを確認します。$ oc get subscription update-service-operator -o yaml | grep " currentCSV"
出力例
currentCSV: update-service-operator.v0.0.1
サブスクリプション (例:
update-service-operator
) を削除します。$ oc delete subscription update-service-operator
出力例
subscription.operators.coreos.com "update-service-operator" deleted
直前の手順の
currentCSV
値を使用し、OpenShift Update Service Operator の CSV を削除します。$ oc delete clusterserviceversion update-service-operator.v0.0.1
出力例
clusterserviceversion.operators.coreos.com "update-service-operator.v0.0.1" deleted