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

5.6. ミラーレジストリーで Windows コンテナーを使用する

Windows Machine Config Operator (WMCO) は、ImageDigestMirrorSet (IDMS) または ImageTagMirrorSet (ITMS) オブジェクトを使用してクラスターを設定し、ミラーレジストリーからイメージをプルすることにより、パブリックレジストリーではなくレジストリーミラーからイメージをプルできます。

ミラーレジストリーには次の利点があります。

  • パブリックレジストリーの停止を回避
  • ノードと Pod の作成を高速化
  • 組織のファイアウォールの背後からイメージを取得します

ミラーレジストリーは、切断されたネットワークまたはエアギャップネットワーク内の OpenShift Container Platform クラスターでも使用できます。切断されたネットワーク は、直接インターネットに接続できない制限されたネットワークです。クラスターはインターネットにアクセスできないため、外部のコンテナーイメージを参照することはできません。

ミラーレジストリーを使用するには、次の一般的な手順が必要です。

  • Red Hat Quay などのツールを使用して、ミラーレジストリーを作成します。
  • コンテナーイメージレジストリー認証情報ファイルを作成します。
  • オンラインイメージリポジトリーからミラーレジストリーにイメージをコピーします。

これらの手順の詳細は、「切断されたインストールのミラーリングについて」を参照してください。

ミラーレジストリーを作成してイメージをミラーリングした後、ImageDigestMirrorSet (IDMS) または ImageTagMirrorSet (ITMS) オブジェクトを使用して、各 Pod 仕様を更新せずにミラーレジストリーからイメージをプルするようにクラスターを設定できます。IDMS および ITMS オブジェクトは、ソースイメージレジストリーのリポジトリーからイメージをプルする要求をリダイレクトし、代わりにミラーリポジトリーによって解決されるようにします。

IDMS または ITMS オブジェクトに変更が加えられた場合、WMCO は Windows ノード上の適切な hosts.toml ファイルを新しい情報で自動的に更新します。ミラー設定が変更になると、WMCO は各 Windows ノードを順番に更新することに注意してください。そのため、これらの更新に必要な時間は、クラスター内の Windows ノードの数に応じて増加します。

WMCO によって設定される Windows ノードは、containerd コンテナーランタイムに依存しています。そのため、WMCO は containerd の設定ファイルをレジストリーの設定で最新の状態に維持します。新しいノードの場合、これらのファイルは作成時にインスタンスにコピーされます。既存のノードの場合、レジストリーコントローラーが、ミラーレジストリーをアクティブ化した後、SSH を使用して各ノードにアクセスし、生成された設定ファイルをコピーして、既存のファイルを置き換えます。

マシンセットまたは Bring-Your-Own-Host (BYOH) Windows ノードでミラーレジストリーを使用できます。

IDMS または ITMS オブジェクトを使用して Windows ノード上のコンテナーイメージをミラーリングする場合は、次の動作が Linux ノードとは異なる点に注意してください。

  • Windows ノードでのミラーリングは、レジストリーレベルで機能します。Linux ノードのように、イメージレベルでは機能しません。そのため、IDMS または ITMS オブジェクトを使用してミラーリングされる Windows イメージには、特定の命名要件があります。

    namespace の最後の部分とミラーイメージのイメージ名は、ミラーリングされるイメージと一致する必要があります。たとえば、mcr.microsoft.com/oss/kubernetes/pause:3.9 イメージをミラーリングする場合、ミラーは $mirrorRegistry/<organization>/oss/kubernetes/pause:3.9 形式である必要があります。$org は、任意の組織名または namespace にすることも、完全に除外することもできます。有効な値は、$mirrorRegistry/oss/kubernetes/pause:3.9、$mirrorRegistry/custom/oss/kubernetes/pause:3.9、$mirrorRegistry/x/y/z/oss/kubernetes/pause:3.9 などです。

  • Windows ノードは、ITMS オブジェクトを取得し、それを使用してレジストリー全体のミラーを設定します。次の例では、quay.io/remote-org/image を quay.io/my-org/image にミラーリングするように設定します。その結果、Windows ノードはそのミラーを quay.io/remote-org のすべてのイメージに使用するようになります。そのため、quay.io/remote-org/image:tag は期待どおり quay.io/my-org/image:tag イメージを使用しますが、quay.io/remote-org/different-image:tag を使用する別のコンテナーも quay.io/remote-org/different-image:tag ミラーを使用しようとします。これを考慮しないと、意図しない動作が発生する可能性があります。

    このため、コンテナーイメージを指定するには、ITMS オブジェクトではなく、IDMS オブジェクトによるダイジェストを使用してください。ダイジェストを使用すると、コンテナーが指定するイメージとプルされるイメージのダイジェストが同じになるため、間違ったコンテナーイメージが使用されるのを防止できます。

5.6.1. イメージレジストリーリポジトリーのミラーリングについて
リンクのコピー

コンテナーレジストリーリポジトリーのミラーリングを設定すると、次のタスクを実行できます。

  • ソースイメージのレジストリーのリポジトリーからイメージをプルする要求をリダイレクトするように OpenShift Container Platform クラスターを設定し、これをミラーリングされたイメージレジストリーのリポジトリーで解決できるようにします。
  • 各ターゲットリポジトリーに対して複数のミラーリングされたリポジトリーを特定し、1 つのミラーがダウンした場合に別のミラーを使用できるようにします。

OpenShift Container Platform のリポジトリーミラーリングには、以下の属性が含まれます。

  • イメージプルには、レジストリーのダウンタイムに対する回復性があります。
  • 非接続環境のクラスターは、quay.io などの重要な場所からイメージをプルし、企業のファイアウォールの背後にあるレジストリーに要求されたイメージを提供させることができる。
  • イメージのプル要求時にレジストリーへの接続が特定の順序で試行され、通常は永続レジストリーが最後に試行される。
  • 入力したミラー情報は、OpenShift Container Platform クラスター内のすべての Windows ノード上の適切な hosts.toml containerd 設定ファイルに追加されます。
  • ノードがソースリポジトリーからイメージの要求を行うと、要求されたコンテンツを見つけるまで、ミラーリングされた各リポジトリーに対する接続を順番に試行する。すべてのミラーで障害が発生した場合、クラスターはソースリポジトリーに対して試行する。成功すると、イメージはノードにプルされる。

リポジトリーミラーリングのセットアップは次の方法で実行できます。

  • OpenShift Container Platform のインストール時:

    OpenShift Container Platform に必要なコンテナーイメージをプルし、それらのイメージを会社のファイアウォールの背後に配置することで、非接続環境にあるデータセンターに OpenShift Container Platform をインストールできます。

  • OpenShift Container Platform の新規インストール後:

    OpenShift Container Platform のインストール中にミラーリングを設定しなかった場合は、以下のカスタムリソース (CR) オブジェクトのいずれかを使用して、インストール後に設定できます。

    • ImageDigestMirrorSet (IDMS)。このオブジェクトを使用すると、ダイジェスト仕様を使用して、ミラーリングされたレジストリーからイメージを取得できます。IDMS CR を使用すると、イメージのプルが失敗した場合に、ソースレジストリーからのプルの継続的な試行を許可または停止するフォールバックポリシーを設定できます。
    • ImageTagMirrorSet (ITMS)。このオブジェクトを使用すると、イメージタグを使用して、ミラーリングされたレジストリーからイメージをプルできます。ITMS CR を使用すると、イメージのプルが失敗した場合に、ソースレジストリーからのプルの継続的な試行を許可または停止するフォールバックポリシーを設定できます。

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

  • ミラーリングするコンテナーイメージリポジトリーのソース
  • ソースリポジトリーから要求されたコンテンツを提供する各ミラーリポジトリーの個別のエントリー。

以下のアクションと、ノードのドレイン動作への影響に注意してください。

  • IDMS または ICSP CR オブジェクトを作成する場合、MCO はノードをドレインまたは再起動しません。
  • ITMS CR オブジェクトを作成すると、MCO はノードをドレインして再起動します。
  • ITMS、IDMS、または ICSP CR オブジェクトを削除すると、MCO はノードをドレインして再起動します。

  • ITMS、IDMS、または ICSP CR オブジェクトを変更すると、MCO はノードをドレインして再起動します。

    重要

    • MCO が以下の変更のいずれかを検出すると、ノードのドレインまたは再起動を行わずに更新を適用します。

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

    • MCO は、ImageDigestMirrorSet、ImageTagMirrorSet、ImageContentSourcePolicy オブジェクトの編集など、/etc/containers/registries.conf ファイルへの変更を検出すると、対応するノードをドレインし、変更を適用し、ノードの遮断を解除します。次の変更ではノードのドレインは発生しません。

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

Windows Machine Config Operator (WMCO) は、IDMS および ITMS リソースへの変更を監視し、それらの変更を含む hosts.toml containerd 設定ファイルのセットをソースレジストリーごとに 1 つずつ生成します。次に、WMCO は既存の Windows ノードを更新して、新しいレジストリー設定を使用します。

注記

ミラー化されたレジストリーを使用して Windows ノードを追加する前に、IDMS および ITMS オブジェクトを作成する必要があります。

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

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

重要

ImageDigestMirrorSet および ImageTagMirrorSet オブジェクトを通じてミラーリングされた Windows イメージには、特定の命名要件があります。これは「ミラーレジストリーで Windows コンテナーを使用する」で説明されています。

前提条件

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

手順

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

    • Red Hat Quay でのレポジトリーのミラーリング で説明されているように、Red Hat Quay でミラーリングされたリポジトリーを設定します。Red Hat Quay を使用すると、あるリポジトリーから別のリポジトリーにイメージをコピーでき、これらのリポジトリーを一定期間繰り返し自動的に同期することもできます。

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

      たとえば、Red Hat Enterprise Linux (RHEL 7 または RHEL 8) システムに 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 という名前のイメージリポジトリーがあり、そこに registry.access.redhat.com から ubi9/ubi-minimal イメージをコピーします。ミラーリングされたレジストリーを作成した後、ソースリポジトリーに対する要求をミラーリングされたリポジトリーにリダイレクトするように OpenShift Container Platform クラスターを構成できます。

    重要

    mcr.microsoft.com/oss/kubernetes/pause:3.9 イメージをミラーリングする必要があります。たとえば、次の skopeo コマンドを使用してイメージをミラーリングできます。 

    $ skopeo copy \
docker://mcr.microsoft.com/oss/kubernetes/pause:3.9\
docker://example.io/oss/kubernetes/pause:3.9
    Copy to Clipboard Toggle word wrap
  2. OpenShift Container Platform クラスターにログインします。

  3. 必要に応じて 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/example2/ubi-minimal
    5 
    
    source: registry.access.redhat.com/ubi9/ubi-minimal
    6 
    
    mirrorSourcePolicy: AllowContactingSource
    7 
    
  - mirrors:
    - mirror.example.com
    source: registry.redhat.io
    mirrorSourcePolicy: NeverContactSource
  - mirrors:
    - docker.io
    source: docker-mirror.internal
    mirrorSourcePolicy: AllowContactingSource
    Copy to Clipboard Toggle word wrap
    1
    この CR で使用する API を示します。これは config.openshift.io/v1 である必要があります。
    2
    プルタイプに応じてオブジェクトの kind を示します。
    • ImageDigestMirrorSet: ダイジェスト参照イメージをプルします。
    • ImageTagMirrorSet: タグ参照イメージをプルします。
    3
    次のいずれかのイメージプルメソッドのタイプを示します。
    • imageDigestMirrors: ImageDigestMirrorSet CR に使用します。
    • imageTagMirrors: ImageTagMirrorSet CR に使用します。
    4
    ミラーリングされたイメージのレジストリーとリポジトリーの名前を示します。
    5
    オプション: 各ターゲットリポジトリーのセカンダリーミラーリポジトリーを示します。1 つのミラーがダウンした場合、ターゲットリポジトリーは別のミラーを使用できます。
    6
    イメージプル仕様で参照されるリポジトリーである、レジストリーおよびリポジトリーソースを示します。
    7
    オプション: イメージのプルが失敗した場合のフォールバックポリシーを示します。
    • AllowContactingSource: ソースリポジトリーからのイメージのプルの継続的な試行を許可します。これはデフォルトになります。
    • NeverContactSource: ソースリポジトリーからのイメージのプルの継続的な試行を防ぎます。

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

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

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

    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. WMCO が各 Windows インスタンスの各レジストリーに対して hosts.toml ファイルを生成したことを確認します。前述の IDMS オブジェクトの例の場合は、次のファイル構造に 3 つのファイルが存在するはずです。 

      $ tree $config_path
      Copy to Clipboard Toggle word wrap

      出力例

      C:/k/containerd/registries/
|── registry.access.redhat.com
|   └── hosts.toml
|── mirror.example.com
|   └── hosts.toml
└── docker.io
    └── hosts.toml:
      Copy to Clipboard Toggle word wrap

      次の出力は、前の例の IDMS オブジェクトが適用された hosts.toml containerd 設定ファイルを表しています。

      host.toml ファイルの例

      $ cat "$config_path"/registry.access.redhat.com/host.toml
server = "https://registry.access.redhat.com" # default fallback server since "AllowContactingSource" mirrorSourcePolicy is set

[host."https://example.io/example/ubi-minimal"]
 capabilities = ["pull"]

[host."https://example.com/example2/ubi-minimal"] # secondary mirror
 capabilities = ["pull"]


$ cat "$config_path"/registry.redhat.io/host.toml
# "server" omitted since "NeverContactSource" mirrorSourcePolicy is set

[host."https://mirror.example.com"]
 capabilities = ["pull"]


$ cat "$config_path"/docker.io/host.toml
server = "https://docker.io"

[host."https://docker-mirror.internal"]
 capabilities = ["pull", "resolve"] # resolve tags
      Copy to Clipboard Toggle word wrap

    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 フラグがフォールバックとして使用されます。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat