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

6.4. OpenShift Update Service を使用しない非接続環境でのクラスターの更新

以下の手順を使用して、OpenShift Update Service にアクセスせずに非接続環境でクラスターを更新します。

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 に設定されている場合、保留中のマシン設定を適用するために、ノードの drain (Pod の退避) が実行され、退避プロセスがブロックされる可能性があります。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget フィールドはノードの drain (Pod の退避) の実行を防ぐことができます。
注記

Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。PodDisruptionBudget で minAvailable が 1 に設定されている場合、保留中のマシン設定を適用するために、ノードの drain (Pod の退避) が実行され、退避プロセスがブロックされる可能性があります。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget フィールドはノードの drain (Pod の退避) の実行を防ぐことができます。

6.4.2. MachineHealthCheck リソースの一時停止
リンクのコピー

更新プロセスで、クラスター内のノードが一時的に利用できなくなる可能性があります。ワーカーノードの場合、MachineHealthCheck リソースにより、このようなノードは正常ではないと識別され、それらが再起動される場合があります。このようなノードの再起動を回避するには、クラスターを更新する前にすべての MachineHealthCheck リソースを一時停止します。

注記

一部の MachineHealthCheck リソースは一時停止する必要がない場合があります。MachineHealthCheck リソースが回復不可能な条件に依存している場合は、その MHC を一時停止する必要はありません。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc get machinehealthcheck -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. マシンヘルスチェックを一時停止するには、cluster.x-k8s.io/paused="" アノテーションを MachineHealthCheck リソースに追加します。以下のコマンドを実行します。 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
    Copy to Clipboard Toggle word wrap

    アノテーション付きの 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
    Copy to Clipboard Toggle word wrap
    重要

    クラスターの更新後にマシンヘルスチェックを再開します。チェックを再開するには、以下のコマンドを実行して MachineHealthCheck リソースから pause アノテーションを削除します。 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-
    Copy to Clipboard Toggle word wrap

6.4.3. リリースイメージダイジェストの取得
リンクのコピー

--to-image オプションを指定して oc adm upgrade コマンドを使用することで非接続環境でクラスターを更新する場合、ターゲットリリースイメージに対応する sha256 ダイジェストを参照する必要があります。

手順

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

    $ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
    Copy to Clipboard Toggle word wrap

    {OCP_RELEASE_VERSION} では、更新する OpenShift Container Platform のバージョン (例: 4.10.16) を指定します。

    {ARCHITECTURE} では、クラスターアーキテクチャー (例: x86_64、aarch64、s390x、ppc64le) を指定します。

    出力例

    sha256:a8bfba3b6dddd1a2fbbead7dac65fe4fb8335089e4e7cae327f3bad334add31d
    Copy to Clipboard Toggle word wrap

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

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>
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <defined_registry>
    イメージのミラーリング先であるミラーレジストリーの名前を指定します。
    <defined_repository>
    ミラーレジストリーで使用するイメージリポジトリーの名前を指定します。
    <digest>
    ターゲットリリースイメージの sha256 ダイジェストを指定します (例: sha256:81154f5c03294534e1eaf0319bef7a601134f891689ccede5d705ef659aa8c92)。
    注記
    • ミラーレジストリーとリポジトリー名の定義を確認するには、「OpenShift Container Platform イメージのミラーリング」を参照してください。
    • ImageContentSourcePolicy または ImageDigestMirrorSet を使用した場合は、定義した名前の代わりに標準的なレジストリー名とリポジトリー名を使用できます。標準的なレジストリー名は quay.io、標準的なリポジトリー名は openshift-release-dev/ocp-release です。
    • ImageContentSourcePolicy、ImageDigestMirrorSet、または ImageTagMirrorSet オブジェクトを持つクラスターのグローバルプルシークレットのみを設定できます。プロジェクトにプルシークレットを追加することはできません。

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 CR は必ずソースレジストリーにフォールバックします。

      重要

      ImageContentSourcePolicy (ICSP) オブジェクトを使用してリポジトリーミラーリングを設定することは、非推奨の機能です。非推奨の機能は OpenShift Container Platform に引き続き含まれており、サポートが継続されます。これは今後のリリースで削除されるため、新しいデプロイメントには推奨されません。

      ImageContentSourcePolicy オブジェクトの作成に使用した既存の YAML ファイルがある場合は、oc adm migrate icsp コマンドを使用して、それらのファイルを ImageDigestMirrorSet YAML ファイルに変換できます。詳細については、イメージレジストリーリポジトリーミラーリング用の ImageContentSourcePolicy (ICSP)ファイルの変換を参照してください。

これらのカスタムリソースオブジェクトはそれぞれ、次の情報を識別します。

  • ミラーリングするコンテナーイメージリポジトリーのソース
  • コンテンツを提供する各ミラーリポジトリーの個別のエントリー

次のアクションと、それがノードの drain 動作にどのように影響するかに注意してください。

  • IDMS または ICSP CR オブジェクトを作成すると、MCO はノードの drain またはリブートを実行しません。
  • ITMS CR オブジェクトを作成すると、MCO はノードの drain とリブートを実行します。
  • ITMS、IDMS、または ICSP CR オブジェクトを削除すると、MCO はノードの drain とリブートを実行します。

  • ITMS、IDMS、または ICSP CR オブジェクトを変更すると、MCO はノードの drain とリブートを実行します。

    重要

    • MCO が以下の変更のいずれかを検出すると、ノードの drain (Pod の退避) の実行または再起動を行わずに更新を適用します。

      • マシン設定の spec.config.passwd.users.sshAuthorizedKeys パラメーターの SSH キーの変更。
      • openshift-config namespace でのグローバルプルシークレットまたはプルシークレットへの変更。
      • Kubernetes API Server Operator による /etc/kubernetes/kubelet-ca.crt 認証局 (CA) の自動ローテーション。

    • MCO は、/etc/containers/registries.conf ファイルへの変更 (ImageDigestMirrorSet、ImageTagMirrorSet、または ImageContentSourcePolicy オブジェクトの編集など) を検出すると、対応するノードの drain (Pod の退避) を実行し、変更を適用して、ノードをスケジューリング対象に戻します。次の変更ではノードの drain (Pod の退避) の実行は発生しません。

      • pull-from-mirror = "digest-only" パラメーターがミラーごとに設定されたレジストリーの追加。
      • pull-from-mirror = "digest-only" パラメーターがレジストリーに設定されたミラーの追加。
      • unqualified-search-registries へのアイテムの追加。

新規クラスターの場合、必要に応じて IDMS、ITMS、および ICSP CR オブジェクトを使用できます。ただし、IDMS と ITMS の使用を推奨します。

クラスターをアップグレードした場合、既存の ICSP オブジェクトは安定を維持し、IDMS オブジェクトと ICSP オブジェクトの両方がサポートされるようになります。ICSP オブジェクトを使用するワークロードは引き続き想定どおりに機能します。一方、IDMS CR で導入されたフォールバックポリシーを利用する場合は、oc adm migrate icsp コマンドを使用して、現在のワークロードを IDMS オブジェクトに移行できます。これは、後述の イメージレジストリーリポジトリーミラーリング用の ImageContentSourcePolicy (ICSP) ファイルの変換 セクションで説明しています。IDMS オブジェクトへの移行に、クラスターの再起動は必要ありません。

注記

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

6.4.5.1. イメージレジストリーのリポジトリーミラーリングの設定
リンクのコピー

インストール後のミラー設定カスタムリソース (CR) を作成して、ソースイメージレジストリーからミラーリングされたイメージレジストリーにイメージプル要求をリダイレクトできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

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

    • Red Hat Quay でミラーリングされたリポジトリーのセットアップRed Hat Quay を使用して、あるリポジトリーから別のリポジトリーにイメージをコピーでき、それらのリポジトリーを時間の経過とともに繰り返し同期することもできます。

    • skopeo などのツールを使用して、ソースリポジトリーからミラーリングされたリポジトリーにイメージを手動でコピーします。

      たとえば、{op-system-base-full システム} に skopeo RPM パッケージをインストールした後、以下の例に示すように skopeo コマンドを使用します。 

      $ skopeo copy --all \
docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \
docker://example.io/example/ubi-minimal
      Copy to Clipboard Toggle word wrap

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

  2. 次の例のいずれかを使用して、インストール後のミラー設定のカスタムリソース(CR)を作成します。

    • 必要に応じて ImageDigestMirrorSet または ImageTagMirrorSet CR を作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。 

      apiVersion: config.openshift.io/v1
kind: ImageDigestMirrorSet
metadata:
  name: ubi9repo
spec:
  imageDigestMirrors:
  - mirrors:
    - example.io/example/ubi-minimal
    - example.com/example2/ubi-minimal
    source: registry.access.redhat.com/ubi9/ubi-minimal
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.com/redhat
    source: registry.example.com/redhat
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.com
    source: registry.example.com
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.net/image
    source: registry.example.com/example/myimage
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.net
    source: registry.example.com/example
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.net/registry-example-com
    source: registry.example.com
    mirrorSourcePolicy: AllowContactingSource
      Copy to Clipboard Toggle word wrap

    • ImageContentSourcePolicy カスタムリソースを作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。 

      apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: mirror-ocp
spec:
  repositoryDigestMirrors:
  - mirrors:
    - mirror.registry.com:443/ocp/release
    source: quay.io/openshift-release-dev/ocp-release
  - mirrors:
    - mirror.registry.com:443/ocp/release
    source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
      Copy to Clipboard Toggle word wrap

      ここでは、以下のようになります。

      - mirror.registry.com:443/ocp/release
      ミラーイメージレジストリーおよびリポジトリーの名前を指定します。
      ソース：quay.io/openshift-release-dev/ocp-release
      ミラーリングされるコンテンツが含まれるオンラインレジストリーおよびリポジトリーを指定します。

  3. 次のコマンドを実行して、新しいオブジェクトを作成します。 

    $ oc create -f registryrepomirror.yaml
    Copy to Clipboard Toggle word wrap

    オブジェクトの作成後、Machine Config Operator (MCO) は ImageTagMirrorSet オブジェクトのみのノードの drain (Pod の退避) を実行します。MCO は、ImageDigestMirrorSet オブジェクトと ImageContentSourcePolicy オブジェクトのノードの drain (Pod の退避) を実行しません。

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

    1. ノードの一覧を表示します。 

      $ oc get node
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.30.3
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.30.3
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.30.3
ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.30.3
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.30.3
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.30.3
      Copy to Clipboard Toggle word wrap

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

      $ oc debug node/ip-10-0-147-35.ec2.internal
      Copy to Clipboard Toggle word wrap

      出力例

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`
      Copy to Clipboard Toggle word wrap

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

      sh-4.2# chroot /host
      Copy to Clipboard Toggle word wrap

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

      sh-4.2# cat /etc/containers/registries.conf
      Copy to Clipboard Toggle word wrap

      次の出力は、インストール後のミラー設定 CR が適用される registries.conf ファイルを示しています。

      出力例

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
short-name-mode = ""

[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi9/ubi-minimal"

  [[registry.mirror]]
    location = "example.io/example/ubi-minimal"
    pull-from-mirror = "digest-only"

  [[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.example.com"

  [[registry.mirror]]
    location = "mirror.example.com"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com/redhat"

  [[registry.mirror]]
    location = "mirror.example.com/redhat"
    pull-from-mirror = "digest-only"
[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi9/ubi-minimal"
  blocked = true

  [[registry.mirror]]
    location = "example.io/example/ubi-minimal-tag"
    pull-from-mirror = "tag-only"
      Copy to Clipboard Toggle word wrap

      [[registry]].location = "registry.access.redhat.com/ubi9/ubi-minimal":: プル仕様にリストされているリポジトリー。[[registry.mirror]].location = "example.io/example/ubi-minimal":: そのリポジトリーのミラーを示します。[[registry.mirror]].pull-from-mirror = "digest-only":: ミラーからイメージがダイジェスト参照イメージであることを示しています。[[registry]].blocked = true:: このリポジトリーに NeverContactSource パラメーターが設定されていることを示します。[[registry.mirror]].pull-from-mirror = "tag-only":: ミラーからのイメージプルがタグ参照イメージであることを示します。

    5. ソースからノードにイメージをプルし、ミラーによって解決されるかどうかを確認します。 

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...
      Copy to Clipboard Toggle word wrap

トラブルシューティング

リポジトリーのミラーリング手順が説明どおりに機能しない場合は、リポジトリーミラーリングの仕組みに関する以下の情報を使用して、問題のトラブルシューティングを行うことができます。

  • 最初に機能するミラーは、プルされるイメージを指定するために使用されます。
  • メインレジストリーは、他のミラーが機能していない場合にのみ使用されます。
  • システムコンテキストによって、Insecure フラグがフォールバックとして使用されます。
  • /etc/containers/registries.conf ファイルの形式が最近変更されました。現在のバージョンはバージョン 2 で、TOML 形式です。

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. 次のコマンドを使用して、1 つ以上の ImageContentSourcePolicy YAML ファイルを ImageDigestMirrorSet YAML ファイルに変換します。 

    $ oc adm migrate icsp <file_name>.yaml <file_name>.yaml <file_name>.yaml --dest-dir <path_to_the_directory>
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <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
    Copy to Clipboard Toggle word wrap

    出力例

    wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi8repo.5911620242173376087.yaml
wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi9repo.6456931852378115011.yaml
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して CR オブジェクトを作成します。 

    $ oc create -f <path_to_the_directory>/<file-name>.yaml
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <path_to_the_directory>
    --dest-dir フラグを使用した場合は、ディレクトリーへのパスを指定します。
    <file_name>
    ImageDigestMirrorSet YAML の名前を指定します。
  3. IDMS オブジェクトがロールアウトされた後、ICSP オブジェクトを削除します。

リポジトリーレベルまたはより幅広いレジストリーレベルでミラーリングされたイメージカタログのスコープを設定できます。幅広いスコープの ImageContentSourcePolicy リソースにより、リソースの変更に対応するためにノードが再起動する必要のある回数が減ります。

ImageContentSourcePolicy リソースのミラーイメージカタログの範囲を拡大するには、以下の手順を実行します。

前提条件

  • OpenShift Container Platform CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 非接続クラスターで使用するようにミラーリングされたイメージカタログを設定する。

手順

  1. <local_registry>、<pull_spec>、および <pull_secret_file> の値を指定して、次のコマンドを実行します。 

    $ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <local_registry>
    非接続クラスター (例: local.registry:5000) 用に設定したローカルレジストリーです。
    <pull_spec>
    非接続レジストリーで設定されるプル仕様です (例: redhat/redhat-operator-index:v4.17)。
    <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 ファイルを生成します。

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

    $ oc apply -f imageContentSourcePolicy.yaml
    Copy to Clipboard Toggle word wrap

検証

  • oc apply が ImageContentSourcePolicy に変更を正常に適用していることを確認します。 

    $ oc get ImageContentSourcePolicy -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    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"}]}}
...
    Copy to Clipboard Toggle word wrap

ImageContentSourcePolicy リソースを更新した後に、OpenShift Container Platform は新しい設定を各ノードにデプロイし、クラスターはソースリポジトリーへの要求のためにミラーリングされたリポジトリーの使用を開始します。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat