1. ターゲットバージョンは、ClusterVersion リソースの spec.desiredUpdate.version フィールドに保存され、Web コンソールまたは CLI から管理されます。
2. Cluster Version Operator (CVO) は、ClusterVersion リソースの desiredUpdate が現在のクラスターのバージョンとは異なることを検出します。OpenShift Update Service からのグラフデータを使用して、CVO は必要なクラスターバージョンをリリースイメージのプル仕様に解決します。
3. CVO は、リリースイメージの整合性と信頼性を検証します。Red Hat は、イメージ SHA ダイジェストを一意で不変のリリースイメージ識別子として使用し、公開されたリリースイメージに関する暗号署名されたステートメントを事前定義された場所に公開します。CVO はビルトイン公開鍵のリストを使用して、チェックされたリリースイメージに一致するステートメントの存在と署名を検証します。
4. CVO は、openshift-cluster-version namespace に version-$version-$hash という名前のジョブを作成します。このジョブはリリースイメージを実行しているコンテナーを使用するため、クラスターはコンテナーランタイムを通じてイメージをダウンロードします。次に、ジョブはマニフェストとメタデータをリリースイメージから CVO がアクセス可能な共有ボリュームに展開します。
5. CVO は、展開されたマニフェストとメタデータを検証します。
6. CVO はいくつかの前提条件をチェックして、クラスター内で問題のある状態が検出されないことを確認します。特定の状態により、更新が続行できない場合があります。これらの状態は、CVO 自体によって決定されるか、Operator が更新に問題ありと判断するクラスターの詳細を検出する個々のクラスター Operator によって報告されます。
7. CVO は、承認されたリリースを status.desired に記録し、新しい更新に関する status.history エントリーを作成します。
8. CVO は、リリースイメージからマニフェストの調整を開始します。クラスター Operator は Runlevels と呼ばれる別のステージで更新され、CVO は次のレベルに進む前に Runlevel 内のすべての Operator が更新を完了するようにします。
9. CVO 自体のマニフェストはプロセスの早い段階で適用されます。CVO デプロイメントが適用されると、現在の CVO Pod が停止し、新しいバージョンを使用する CVO Pod が開始されます。新しい CVO は、残りのマニフェストの調整を進めます。
10. 更新は、コントロールプレーン全体が新しいバージョンに更新されるまで続行されます。個々のクラスター Operator は、クラスターのドメインで更新タスクを実行することがあり、その場合は実行中に、Progressing=True 状態を通して状態を報告します。
11. Machine Config Operator (MCO) マニフェストはプロセスの最後に適用されます。その後、更新された MCO は、すべてのノードのシステム設定とオペレーティングシステムの更新を開始します。各ノードは、再びワークロードの受け入れを開始する前に、ドレイン、更新、および再起動される可能性があります。

1. ノードを遮断してドレインします。

   注記

   ノードが遮断されている場合、ワークロードをそのノードにスケジュールすることはできません。

2. ノードのシステム設定およびオペレーティングシステム (OS) を更新します。
3. ノードを再起動します。
4. ノードの遮断を解除します。

1. MCO はノード 1、2、3 を遮断し、それらのドレインを開始します。
2. ノード 2 は、ドレインを完了して再起動すると再び使用可能になります。MCO はノード 4 を遮断し、そのドレインを開始します。
3. ノード 1 は、ドレインを完了して再起動すると再び使用可能になります。MCO はノード 5 を遮断し、そのドレインを開始します。
4. ノード 3 は、ドレインを完了して再起動すると再び使用可能になります。
5. ノード 5 は、ドレインを完了して再起動すると再び使用可能になります。
6. ノード 4 は、ドレインを完了して再起動すると再び使用可能になります。

1. すべてのノードを遮断してドレインする
2. オペレーティングシステム (OS) を更新する
3. ノードを再起動します。
4. すべてのノードのコードを解除し、ノードでワークロードをスケジュールします

手順

1. Web コンソールの管理者パースペクティブを使用して、任意の Operator Lifecycle Manager (OLM) Operator を、目的の更新バージョンと互換性のあるバージョンに更新します。このアクションを実行する方法は、インストール済み Operator の更新を参照してください。

2. すべてのマシン設定プールが Up to date のステータスを表示し、マシン設定プールが UPDATING のステータスを表示していないことを確認します。

   すべてのマシン設定プールのステータスを表示するには、Compute → MachineConfigPools をクリックし、Update status 列の内容を確認します。

   注記

   マシン設定プールのステータスが Updating の場合は、このステータスが Up to date に変わるまでお待ちください。このプロセスには数分かかる場合があります。

3. チャネルを eus-<4.y+2> に設定します。

   チャネルを設定するには、Administration → Cluster Settings → Channel をクリックします。現在のハイパーリンクチャネルをクリックすると、チャネルを編集できます。

4. マスタープール以外のすべてのワーカーマシンプールを一時停止します。このアクションは、Compute ページの MachineConfigPools タブで実行できます。一時停止するマシン設定プールの横にある縦リーダーを選択し、Pause updates をクリックします。
5. バージョン <4.y+1> に更新し、Save ステップまで完了します。これらのアクションを実行する方法は、関連情報の「Web コンソールを使用したクラスターの更新」を参照してください。
6. クラスターの 最後に完了したバージョン を表示して、<4.y+1> の更新が完了していることを確認します。この情報は、Cluster Settings ページの Details タブにあります。
7. 必要に応じて、Web コンソールの管理者パースペクティブを使用して OLM オペレーターをアップグレードします。これらのアクションを実行する方法は、インストール済み Operator の更新を参照してください。
8. バージョン <4.y+2> に更新し、Save ステップまで完了します。これらのアクションを実行する方法は、関連情報の「Web コンソールを使用したクラスターの更新」を参照してください。
9. クラスターの 最後に完了したバージョン を表示して、<4.y+2> の更新が完了していることを確認します。この情報は、Cluster Settings ページの Details タブにあります。

10. 以前一時停止したすべてのマシン設定プールの一時停止を解除します。このアクションは、Compute ページの MachineConfigPools タブで実行できます。一時停止を解除するマシン設定プールの横にある縦リーダーを選択し、Unpause updates をクリックします。

    重要

    プールの一時停止が解除されていない場合、クラスターは今後のマイナーバージョンへの更新が許可されず、証明書のローテーションなどの保守タスクが禁止されます。これにより、クラスターは将来の劣化のリスクにさらされます。

11. 以前に一時停止したプールが更新され、クラスターがバージョン <4.y+2> への更新を完了したことを確認します。

    Compute ページの MachineConfigPools タブで、Update status の値が Up to date になっていることを確認して、プールが更新されたことを確認できます。

    クラスターの Last completed version を表示することで、クラスターが更新を完了したことを確認できます。この情報は、Cluster Settings ページの Details タブにあります。

手順

1. Web コンソールの管理者パースペクティブを使用して、任意の Operator Lifecycle Manager (OLM) Operator を、目的の更新バージョンと互換性のあるバージョンに更新します。このアクションを実行する方法は、インストール済み Operator の更新を参照してください。

2. すべてのマシン設定プールが UPDATED のステータスを表示し、マシン設定プールが UPDATING のステータスを表示していないことを確認します。すべてのマシン設定プールのステータスを表示するには、以下のコマンドを実行します。

   $ oc get mcp

   出力例

   NAME     CONFIG                                         	UPDATED   UPDATING
   master   rendered-master-ecbb9582781c1091e1c9f19d50cf836c       True  	  False
   worker   rendered-worker-00a3f0c68ae94e747193156b491553d5       True  	  False

3. 現在のバージョンは <4.y> で、更新する予定のバージョンは <4.y+2> です。次のコマンドを実行して、eus-<4.y+2> チャネルに変更します。

   $ oc adm upgrade channel eus-<4.y+2>

   注記

   eus-<4.y+2> が利用可能なチャネルの 1 つでないことを示すエラーメッセージが表示された場合、これは、Red Hat が EUS バージョンの更新をまだロールアウトしていることを示しています。通常、このロールアウトプロセスには GA 日から 45 ~ 90 日かかります。

4. 以下のコマンドを実行して、マスタープール以外のすべてのワーカーマシンプールを一時停止します。

   $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'

   注記

   マスタープールを一時停止することはできません。

5. 次のコマンドを実行して、最新バージョンに更新します。

   $ oc adm upgrade --to-latest

   出力例

   Updating to latest version <4.y+1.z>

6. クラスターのバージョンを確認し、以下のコマンドを実行して更新が完了したことを確認します。

   $ oc adm upgrade

   出力例

   Cluster version is <4.y+1.z>
   ...

7. 次のコマンドを実行して、バージョン <4.y+2> に更新します。

   $ oc adm upgrade --to-latest

8. 次のコマンドを実行して、クラスターのバージョンを取得し、<4.y+2> の更新が完了していることを確認します。

   $ oc adm upgrade

   出力例

   Cluster version is <4.y+2.z>
   ...

9. ワーカーノードを <4.y+2> に更新するには、次のコマンドを実行して、以前に一時停止したすべてのマシン設定プールの一時停止を解除します。

   $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'

   重要

   プールの一時停止が解除されていない場合、クラスターは将来のマイナーバージョンへの更新が許可されず、証明書のローテーションなどの保守タスクが禁止されます。これにより、クラスターは将来の劣化のリスクにさらされます。

10. 次のコマンドを実行して、以前に一時停止したプールが更新され、バージョン <4.y+2> への更新が完了したことを確認します。

    $ oc get mcp

    出力例

    NAME 	   CONFIG                                            UPDATED     UPDATING
    master   rendered-master-52da4d2760807cb2b96a3402179a9a4c    True  	 False
    worker   rendered-worker-4756f60eccae96fb9dcb4c392c69d497    True 	 False

1. これまで　OLM でインストールされたすべての Operator が、最新チャネルの最新バージョンに更新されていることを確認します。Operator を更新することで、デフォルトの OperatorHub カタログが、クラスターの更新時に現行のマイナーバージョンから次のマイナーバージョンに切り替わる際、確実に有効な更新パスがあるようにします。Operator の更新方法については、関連情報の 「Operator 更新の準備」を参照してください。
2. 現在の Operator バージョンと更新後の Operator バージョン間のクラスターバージョン互換性を確認します。Red Hat OpenShift Container Platform Operator Update Information Checker を使用して、OLM Operator と互換性があるバージョンを確認できます。

ワークフローの例

1. ワーカーマシンプールを一時停止します。
2. OpenShift <4.y> → OpenShift <4.y+1> にアップグレードします。
3. ODF <4.y> → ODF <4.y+1> にアップグレードします。
4. OpenShift <4.y+1> → OpenShift <4.y+2> にアップグレードします。
5. ODF <4.y+2> にアップグレードします。
6. ワーカーマシンプールの一時停止を解除します。

手順

1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。
2. Administration → Cluster Settings に移動します。
3. Cluster Settings ページで、Configuration タブを選択します。
4. Configuration resource で CloudCredential を選択します。
5. CloudCredential details ページで、YAML タブを選択します。

6. YAML ブロックで、spec.credentialsMode の値を確認します。次の値が可能ですが、すべてのプラットフォームですべてがサポートされているわけではありません。

   • '': CCO はデフォルトモードで動作しています。この設定では、CCO は、インストール中に提供されたクレデンシャルに応じて、ミントモードまたはパススルーモードで動作します。
   • Mint: CCO はミントモードで動作しています。
   • Passthrough: CCO はパススルーモードで動作しています。
   • Manual: CCO は手動モードで動作します。
   重要

   spec.credentialsMode が ''、Mint、または Manual である AWS または GCP クラスターの特定の設定を特定するには、さらに調査する必要があります。

   AWS および GCP クラスターは、ルートシークレットが削除されたミントモードの使用をサポートします。クラスターが、mint モードを使用するように設定されている場合や、デフォルトで mint モードを使用するように設定されている場合、更新前に root シークレットがクラスターに存在するか確認する必要があります。

   手動モードを使用する AWS または GCP クラスターは、AWS Security Token Service (STS) または GCP Workload Identity を使用して、クラスターの外部からクラウド認証情報を作成および管理するように設定されている場合があります。クラスター Authentication オブジェクトを調べることで、クラスターがこの戦略を使用しているかどうかを判断できます。

7. mint モードのみを使用する AWS または GCP クラスター: クラスターがルートシークレットなしで動作しているかどうかを判断するには、Workloads → Secrets に移動し、クラウドプロバイダーのルートシークレットを探します。

   注記

   Project ドロップダウンが All Projects に設定されていることを確認します。

   プラットフォーム	シークレット名
   AWS	aws-creds
   GCP	gcp-credentials

   • これらの値のいずれかが表示される場合、クラスターはルートシークレットが存在するミントモードまたはパススルーモードを使用しています。
   • これらの値が表示されない場合、クラスターはルートシークレットが削除されたミントモードで CCO を使用しています。

8. 手動モードのみを使用する AWS または GCP クラスター: クラスターがクラスターの外部からクラウド認証情報を作成および管理するように設定されているかどうかを判断するには、クラスター Authentication オブジェクトの YAML 値を確認する必要があります。

   1. Administration → Cluster Settings に移動します。
   2. Cluster Settings ページで、Configuration タブを選択します。
   3. Configuration resource で Authentication を選択します。
   4. Authentication details ページで、YAML タブを選択します。

   5. YAML ブロックで、.spec.serviceAccountIssuer パラメーターの値を確認します。

      • クラウドプロバイダーに関連付けられている URL を含む値は、CCO が AWS STS または GCP Workload Identity で手動モードを使用して、クラスターの外部からクラウド認証情報を作成および管理していることを示します。これらのクラスターは、ccoctl ユーティリティーを使用して設定されます。
      • 空の値 ('') は、クラスターが手動モードで CCO を使用しているが、ccoctl ユーティリティーを使用して設定されていないことを示します。

手順

1. cluster-admin ロールを持つユーザーとしてクラスターの oc にログインします。

2. CCO が使用するように設定されているモードを確認するには、次のコマンドを入力します。

   $ oc get cloudcredentials cluster \
     -o=jsonpath={.spec.credentialsMode}

   すべてのプラットフォームですべてがサポートされているわけではありませんが、次の出力値が可能です。

   • '': CCO はデフォルトモードで動作しています。この設定では、CCO は、インストール中に提供されたクレデンシャルに応じて、ミントモードまたはパススルーモードで動作します。
   • Mint: CCO はミントモードで動作しています。
   • Passthrough: CCO はパススルーモードで動作しています。
   • Manual: CCO は手動モードで動作します。
   重要

   spec.credentialsMode が ''、Mint、または Manual である AWS または GCP クラスターの特定の設定を特定するには、さらに調査する必要があります。

   AWS および GCP クラスターは、ルートシークレットが削除されたミントモードの使用をサポートします。クラスターが、mint モードを使用するように設定されている場合や、デフォルトで mint モードを使用するように設定されている場合、更新前に root シークレットがクラスターに存在するか確認する必要があります。

   手動モードを使用する AWS または GCP クラスターは、AWS Security Token Service (STS) または GCP Workload Identity を使用して、クラスターの外部からクラウド認証情報を作成および管理するように設定されている場合があります。クラスター Authentication オブジェクトを調べることで、クラスターがこの戦略を使用しているかどうかを判断できます。

3. mint モードのみを使用する AWS または GCP クラスター: クラスターがルートシークレットなしで動作しているかどうかを判断するには、次のコマンドを実行します。

   $ oc get secret <secret_name> \
     -n=kube-system

   <secret_name> は、AWS の場合は aws-creds、GCP の場合は gcp-credentials です。

   ルートシークレットが存在する場合、このコマンドの出力はシークレットに関する情報を返します。エラーは、ルートシークレットがクラスターに存在しないことを示します。

4. 手動モードのみを使用する AWS または GCP クラスター: クラスターがクラスターの外部からクラウド認証情報を作成および管理するように設定されているかどうかを確認するには、次のコマンドを実行します。

   $ oc get authentication cluster \
     -o jsonpath \
     --template='{ .spec.serviceAccountIssuer }'

   このコマンドは、クラスター Authentication オブジェクトの .spec.serviceAccountIssuer パラメーターの値を表示します。

   • クラウドプロバイダーに関連付けられている URL の出力は、CCO が AWS STS または GCP Workload Identity で手動モードを使用して、クラスターの外部からクラウド認証情報を作成および管理していることを示しています。これらのクラスターは、ccoctl ユーティリティーを使用して設定されます。
   • 空の出力は、クラスターが手動モードで CCO を使用しているが、ccoctl ユーティリティーを使用して設定されていないことを示します。

手順

1. フックの設計後に、フック用に Ansible タスクを定義する YAML ファイルを作成します。このファイルは、以下に示すように一連のタスクで設定される必要があり、Playbook にすることはできません。

   ---
   # Trivial example forcing an operator to acknowledge the start of an upgrade
   # file=/home/user/openshift-ansible/hooks/pre_compute.yml
   
   - name: note the start of a compute machine update
     debug:
         msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"
   
   - name: require the user agree to start an upgrade
     pause:
         prompt: "Press Enter to start the compute machine update"

2. hosts Ansible インベントリーファイルを変更してフックファイルを指定します。フックファイルは、以下に示すように [all:vars] セクションのパラメーター値として指定されます。

   インベントリーファイルのフック定義の例

   [all:vars]
   openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
   openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml

   フックへのパスでの曖昧さを避けるために、それらの定義では相対パスの代わりに絶対パスを使用します。

手順

1. Red Hat OpenShift Container Platform Upgrade Graph visualizer および update planner を使用して、あるバージョンから別のバージョンへの更新を計画します。OpenShift Upgrade Graph はチャネルのグラフと、現行バージョンと意図されるクラスターのバージョン間に更新パスがあることを確認する方法を提供します。

2. 必要な環境変数を設定します。

   1. リリースバージョンをエクスポートします。

      $ export OCP_RELEASE=<release_version>

      <release_version> について、更新する OpenShift Container Platform のバージョンに対応するタグを指定します (例: 4.5.4)。

   2. ローカルレジストリー名とホストポートをエクスポートします。

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      <local_registry_host_name> については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port> については、コンテンツの送信に使用するポートを指定します。

   3. ローカルリポジトリー名をエクスポートします。

      $ LOCAL_REPOSITORY='<local_repository_name>'

      <local_repository_name> については、ocp4/openshift4 などのレジストリーに作成するリポジトリーの名前を指定します。

   4. OpenShift Update Service を使用している場合は、追加のローカルリポジトリー名をエクスポートして、リリースイメージを含めます。

      $ LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'

      <local_release_images_repository_name> については、ocp4/openshift4-release-images などのレジストリーに作成するリポジトリーの名前を指定します。

   5. ミラーリングするリポジトリーの名前をエクスポートします。

      $ PRODUCT_REPO='openshift-release-dev'

      実稼働環境のリリースの場合には、openshift-release-dev を指定する必要があります。

   6. パスをレジストリープルシークレットにエクスポートします。

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      <path_to_pull_secret> については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。

      注記

      クラスターが ImageContentSourcePolicy オブジェクトを使用してリポジトリーのミラーリングを設定する場合、ミラーリングされたレジストリーにグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。

   7. リリースミラーをエクスポートします。

      $ RELEASE_NAME="ocp-release"

      実稼働環境のリリースについては、ocp-release を指定する必要があります。

   8. サーバーのアーキテクチャーのタイプをエクスポートします (例: x86_64)。

      $ ARCHITECTURE=<server_architecture>

   9. ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。

      $ REMOVABLE_MEDIA_PATH=<path> 1

      1

      最初のスラッシュ (/) 文字を含む完全パスを指定します。

3. ミラーリングするイメージおよび設定マニフェストを確認します。

   $ 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

4. バージョンイメージをミラーレジストリーにミラーリングします。

   • ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。

     1. リムーバブルメディアをインターネットに接続しているシステムに接続します。

     2. イメージおよび設定マニフェストをリムーバブルメディア上のディレクトリーにミラーリングします。

        $ 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 も、リムーバブルメディアに保存します。

     3. メディアを切断された環境に移動し、イメージをローカルコンテナーレジストリーにアップロードします。

        $ 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 の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。

     4. oc コマンドラインインターフェイス (CLI) を使用して、アップグレードしているクラスターにログインします。

     5. ミラーリングされたリリースイメージ署名設定マップを接続されたクラスターに適用します。

        $ oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file> 1

        1

        <image_signature_file> について、ファイルのパスおよび名前を指定します (例: signature-sha256-81154f5c03294534.yaml)。

     6. 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}

   • ローカルコンテナーレジストリーとクラスターがミラーホストに接続されている場合は、次の操作を行います。

     1. 次のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュし、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 オプションが含まれる場合は、イメージ署名の検証用に設定マップを作成しません。

     2. 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}

手順

1. オプション: 既存のプルシークレットに新しいプルシークレットを追加するには、以下の手順を実行します。

   1. 以下のコマンドを入力してプルシークレットをダウンロードします。

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1

      1

      プルシークレットファイルへのパスを指定します。

   2. 以下のコマンドを実行して、新しいプルシークレットを追加します。

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3

      1

      新しいレジストリーを指定します。同じレジストリー内に複数のリポジトリーを含めることができます (例: --registry="<registry/my-namespace/my-repository>")。

      2

      新しいレジストリーの認証情報を指定します。

      3

      プルシークレットファイルへのパスを指定します。

      または、プルシークレットファイルを手動で更新することもできます。

2. 以下のコマンドを実行して、クラスターのグローバルプルシークレットを更新します。

   $ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1

   1

   新規プルシークレットファイルへのパスを指定します。

   この更新はすべてのノードにロールアウトされます。これには、クラスターのサイズに応じて多少時間がかかる場合があります。

   注記

   OpenShift Container Platform 4.7.4 の時点で、グローバルプルシークレットへの変更によってノードドレインまたは再起動がトリガーされなくなりました。

手順

1. 以下を含む Dockerfile (./Dockerfile など) を作成します。

   FROM registry.access.redhat.com/ubi8/ubi:8.1
   
   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"]

2. 上記の手順で作成した docker ファイルを使用して、グラフデータコンテナーイメージ (例: registry.example.com/openshift/graph-data:latest) を構築します。

   $ podman build -f ./Dockerfile -t registry.example.com/openshift/graph-data:latest

3. 前の手順で作成したグラフデータコンテナーイメージを、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 を実行します。

手順

1. 一時停止する利用可能なすべての MachineHealthCheck リソースをリスト表示するには、以下のコマンドを実行します。

   $ oc get machinehealthcheck -n openshift-machine-api

2. マシンヘルスチェックを一時停止するには、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-

手順

1. インターネットに接続されているデバイスで、以下のコマンドを実行します。

   $ 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

2. クラスターの更新時に使用する sha256 ダイジェストをコピーします。

手順

1. ミラーリングされたリポジトリーを設定します。以下のいずれかを実行します。

   • 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/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
     docker://example.io/example/ubi-minimal

     この例では、example.io いう名前のコンテナーイメージレジストリーと example という名前のイメージリポジトリーがあり、そこに registry.access.redhat.com から ubi8/ubi-minimal イメージをコピーします。レジストリーを作成した後、OpenShift Container Platform クラスターを設定して、ソースリポジトリーで作成される要求をミラーリングされたリポジトリーにリダイレクトできます。

2. OpenShift Container Platform クラスターにログインします。

3. ImageContentSourcePolicy ファイル (例: registryrepomirror.yaml) を作成し、ソースとミラーを固有のレジストリー、およびリポジトリーのペアとイメージのものに置き換えます。

   apiVersion: operator.openshift.io/v1alpha1
   kind: ImageContentSourcePolicy
   metadata:
     name: ubi8repo
   spec:
     repositoryDigestMirrors:
     - mirrors:
       - example.io/example/ubi-minimal 1
       - example.com/example/ubi-minimal 2
       source: registry.access.redhat.com/ubi8/ubi-minimal 3
     - mirrors:
       - mirror.example.com/redhat
       source: registry.redhat.io/openshift4 4
     - mirrors:
       - mirror.example.com
       source: registry.redhat.io 5
     - mirrors:
       - mirror.example.net/image
       source: registry.example.com/example/myimage 6
     - mirrors:
       - mirror.example.net
       source: registry.example.com/example 7
     - mirrors:
       - mirror.example.net/registry-example-com
       source: registry.example.com 8

   1

   イメージレジストリーおよびリポジトリーの名前を示します。

   2

   各ターゲットリポジトリーの複数のミラーリポジトリーを示します。1 つのミラーがダウンした場合、ターゲットリポジトリーは別のミラーを使用できます。

   3

   ミラーリングされているコンテンツが含まれるレジストリーおよびリポジトリーを示します。

   4

   レジストリー内の namespace を、その namespace の任意のイメージを使用するように設定できます。レジストリードメインをソースとして使用する場合、ImageContentSourcePolicy リソースはレジストリーからすべてのリポジトリーに適用されます。

   5

   レジストリー名を設定すると、ソースレジストリーからミラーレジストリーまでのすべてのリポジトリーに ImageContentSourcePolicy リソースが適用されます。

   6

   イメージ mirror.example.net/image@sha256:…​ をプルします。

   7

   ミラー mirror.example.net/myimage@sha256:…​ からソースレジストリー namespace のイメージ myimage をプルします。

   8

   ミラーレジストリー mirror.example.net/registry-example-com/example/myimage@sha256:…​ からイメージ registry.example.com/example/myimage をプルします。ImageContentSourcePolicy リソースは、ソースレジストリーからミラーレジストリー mirror.example.net/registry-example-com までのすべてのリポジトリーに適用されます。

4. 新しい ImageContentSourcePolicy オブジェクトを作成します。

   $ oc create -f registryrepomirror.yaml

   ImageContentSourcePolicy オブジェクトが作成されると、新しい設定が各ノードにデプロイされ、クラスターはソースリポジトリーへの要求のためにミラーリングされたリポジトリーの使用を開始します。

5. ミラーリングされた設定が適用されていることを確認するには、ノードのいずれかで以下を実行します。

   1. ノードのリストを表示します。

      $ oc get node

      出力例

      NAME                           STATUS                     ROLES    AGE  VERSION
      ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.24.0
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.24.0
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.24.0
      ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.24.0
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.24.0
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.24.0

      Imagecontentsourcepolicy リソースはノードを再起動しません。

   2. デバッグプロセスを開始し、ノードにアクセスします。

      $ 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`

   3. ルートディレクトリーを /host に変更します。

      sh-4.2# chroot /host

   4. /etc/containers/registries.conf ファイルをチェックして、変更が行われたことを確認します。

      sh-4.2# cat /etc/containers/registries.conf

      出力例

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      short-name-mode = ""
      
      [[registry]]
        prefix = ""
        location = "registry.access.redhat.com/ubi8/ubi-minimal"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "example.io/example/ubi-minimal"
      
        [[registry.mirror]]
          location = "example.com/example/ubi-minimal"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net/registry-example-com"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example/myimage"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net/image"
      
      [[registry]]
        prefix = ""
        location = "registry.redhat.io"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.com"
      
      [[registry]]
        prefix = ""
        location = "registry.redhat.io/openshift4"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.com/redhat"

   5. ソースからノードにイメージダイジェストをプルし、ミラーによって解決されているかどうかを確認します。ImageContentSourcePolicy オブジェクトはイメージダイジェストのみをサポートし、イメージタグはサポートしません。

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

手順

1. <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.11)。

   <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 ファイルを生成します。

2. 新しい ImageContentSourcePolicy リソースをクラスターに適用します。

   $ oc apply -f imageContentSourcePolicy.yaml

手順

1. クラスターのコントロールプレーンノードをリスト表示します。

   $ oc get nodes -l node-role.kubernetes.io/master

   出力例

   NAME                    STATUS   ROLES    AGE   VERSION
   control-plane-node-0    Ready    master   75m   v1.24.0
   control-plane-node-1    Ready    master   75m   v1.24.0
   control-plane-node-2    Ready    master   75m   v1.24.0

   コントロールプレーンノードの名前を書き留めておきます。

2. コントロールプレーンノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <control_plane_node>

3. コントロールプレーンノードに関連付けられた仮想マシンをシャットダウンします。仮想マシンを右クリックし、Power → Shut Down Guest OS を選択して、vSphere クライアントでこれを実行します。安全にシャットダウンされない場合があるため、Power Off を使用して仮想マシンをシャットダウンしないでください。
4. vSphere クライアントで VM を更新します。詳細については、VMware ドキュメントの 仮想マシンの互換性を手動でアップグレードするに 従ってください。
5. コントロールプレーンノードに関連付けられた仮想マシンの電源を入れます。仮想マシンを右クリックし、Power On を選択して、vSphere クライアントでこれを実行します。

6. ノードが Ready として報告されるまで待機します。

   $ oc wait --for=condition=Ready node/<control_plane_node>

7. コントロールプレーンノードを再度スケジュール対象としてマークします。

   $ oc adm uncordon <control_plane_node>

8. クラスター内のコントロールプレーンノードごとに、この手順を繰り返します。

手順

1. クラスターのコンピュートノードをリスト表示します。

   $ oc get nodes -l node-role.kubernetes.io/worker

   出力例

   NAME              STATUS   ROLES    AGE   VERSION
   compute-node-0    Ready    worker   30m   v1.24.0
   compute-node-1    Ready    worker   30m   v1.24.0
   compute-node-2    Ready    worker   30m   v1.24.0

   コンピュートノードの名前を書き留めておきます。

2. コンピュートノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <compute_node>

3. コンピュートノードから Pod を退避します。これにはいくつかの方法があります。たとえば、ノードですべてまたは選択した Pod を退避できます。

   $ oc adm drain <compute_node> [--pod-selector=<pod_selector>]

   ノードから Pod を退避させる方法は、ノードの Pod を退避する方法のセクションを参照してください。

4. コンピュートノードに関連付けられた仮想マシンをシャットダウンします。仮想マシンを右クリックし、Power → Shut Down Guest OS を選択して、vSphere クライアントでこれを実行します。安全にシャットダウンされない場合があるため、Power Off を使用して仮想マシンをシャットダウンしないでください。
5. vSphere クライアントで VM を更新します。詳細については、VMware ドキュメントの 仮想マシンの互換性を手動でアップグレードするに 従ってください。
6. コンピュートノードに関連付けられた仮想マシンの電源を入れます。仮想マシンを右クリックし、Power On を選択して、vSphere クライアントでこれを実行します。

7. ノードが Ready として報告されるまで待機します。

   $ oc wait --for=condition=Ready node/<compute_node>

8. コンピュートノードを再度スケジュール対象としてマークします。

   $ oc adm uncordon <compute_node>

9. クラスター内のコンピュートノードごとに、この手順を繰り返します。

手順

1. RHCOS テンプレートが vSphere テンプレートとして設定されている場合は、次のステップの前に、VMware ドキュメント のテンプレートを仮想マシンに変換するに 従ってください。

   注記

   テンプレートから変換したら、仮想マシンをパワーオンしないでください。

2. vSphere クライアントで VM を更新します。詳細については、VMware ドキュメントの 仮想マシンの互換性を手動でアップグレードするに 従ってください。
3. vSphere クライアントの VM を VM からテンプレートに変換します。詳細については、VMware ドキュメント の vSphere Client で仮想マシンをテンプレートに変換するに 従ってください。