限定公開の Container Registry を構成する

このページでは、VMware 用 Google Distributed Cloud（ソフトウェアのみ）用に既存の Container Registry サーバーを構成する方法について説明します。

このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。 Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

概要

デフォルトでは、クラスタの作成またはアップグレード時に、Google Distributed Cloud はコンポーネント アクセス サービス アカウントを使用して gcr.io/gke-on-prem-release からシステム イメージを pull します。必要に応じて、独自の Container Registry サーバーを指定し、システム イメージが非公開レジストリ サーバーから pull されるようにすることもできます。

Google Distributed Cloud は、保護されていない Container Registry をサポートしていません。Container Registry サーバーを起動する際、証明書と鍵を提供する必要があります。証明書は、パブリック認証局（CA）によって署名されることも、自己署名されることもあります。

Container Registry サーバーを作成する

Container Registry サーバーの作成方法については、Docker ドキュメントの外部からアクセス可能なレジストリを実行するをご覧ください。

レジストリを構成する

非公開の Container Registry を使用するには、クラスタの作成前に管理クラスタ構成ファイルの privateRegistry セクションに入力します。このセクションに入力した場合、次の処理が行われます。

• クラスタの作成またはアップグレード前に gkectl prepare コマンドを実行すると、管理クラスタ構成ファイルの bundlePath フィールドで指定された tar ファイルからイメージが抽出され、イメージが非公開レジストリ サーバーに push されます。

• クラスタの作成またはアップグレード時に、システム イメージが非公開レジストリ サーバーから pull されます。

高度なクラスタとフルバンドルの制限事項

Google Distributed Cloud には、フルバンドルと標準バンドルの 2 つのバンドルがあります。管理ワークステーションのバンドルがどちらであるかを確認するには、管理クラスタ構成ファイルの bundlePath フィールドをチェックします。ファイル名の末尾が -full である場合、管理ワークステーションのバンドルはフルバンドルです。ファイル名の末尾が -full でない場合、管理ワークステーションのバンドルは標準バンドルです。

gkeadm コマンドを使用して管理ワークステーションを作成した場合、フルバンドルがインストールされた管理ワークステーション VM が作成され、管理クラスタ構成ファイルの bundlePath フィールドが構成されます。

高度なクラスタが有効になっている場合、非公開レジストリでフルバンドルを使用する際には、次のような制限があります。

• バージョン 1.31: 非公開レジストリでフルバンドルはサポートされていません。高度なクラスタで非公開レジストリを使用するには、以下の手順に沿って操作します。

  1. 標準サイズのバンドルを管理ワークステーションにダウンロードします。
  2. 管理クラスタ構成ファイルの bundlePath フィールドでファイル名を更新します。

• バージョン 1.32: フルバンドルの使用はサポートされていますが、gkectl prepare コマンドは tar ファイルではなく gcr.io/gke-on-prem-release からイメージを pull します。ただし、このコマンドによってイメージが非公開レジストリに push されます。これにより、クラスタの作成またはアップグレード時にシステム イメージが非公開レジストリから pull されます。

イメージがレジストリ サーバーから pull されていることを確認する

イメージがレジストリ サーバーから pull されていることを確認する方法は、高度なクラスタが有効になっているかどうかによって異なります。

• 高度なクラスタが有効になっていない場合は、次のコマンドを実行します。

  kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
      --all-namespaces -o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}"
  

  ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルのパスに置き換えます。

  このコマンドの出力には、クラスタ内のすべてのイメージが表示されます。すべての Google Distributed Cloud イメージが独自のリポジトリ サーバーから pull されていることを確認できます。

• 高度なクラスタが有効になっている場合は、次の操作を行います。

  containerd がローカル レジストリからイメージを pull しているかどうかを判断するには、次の手順で config.toml というファイルの内容を調べます。

  1. ノードにログインして、ファイル（/etc/containerd/config.toml）の内容を調べます。

  2. config.toml ファイルの plugins."io.containerd.grpc.v1.cri".registry.mirrors フィールドを確認して、レジストリ サーバーが endpoint フィールドにリストされているかどうかを確認します。

     以下は、config.toml ファイルの例からの抜粋です。

     version = 2
     root = "/var/lib/containerd"
     state = "/run/containerd"
     ...
     [plugins."io.containerd.grpc.v1.cri".registry]
     [plugins."io.containerd.grpc.v1.cri".registry.configs]
     [plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io"]
     [plugins."io.containerd.grpc.v1.cri".registry.configs."privateregistry2.io".tls]
     ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'
     [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
     [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
     endpoint = ["http://privateregistry.io", "http://privateregistry2.io"]
     ...
     

  3. レジストリ ミラーが endpoint フィールドに表示される場合、ノードは Artifact Registry ではなくレジストリ ミラーからイメージを pull します。