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

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

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

概要

デフォルトでは、クラスタの作成またはアップグレード時に、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 を使用するには、gkectl コマンドラインツールまたは Terraform を使用します。

`gkectl`

クラスタを作成する前に、privateRegistry セクションを管理クラスタ構成ファイルに追加します。

このセクションに入力した場合、次の処理が行われます。
- クラスタの作成またはアップグレード前に gkectl prepare コマンドを実行すると、管理クラスタ構成ファイルの bundlePath フィールドで指定された tar ファイルからイメージが抽出され、イメージが非公開レジストリサーバーに push されます。
- クラスタの作成またはアップグレード時に、システムイメージが非公開レジストリサーバーから pull されます。
ネットワークがプロキシサーバーの背後にある場合は、proxy セクションに入力します。

Terraform

管理クラスタを作成するの [Terraform] タブの手順に沿って、管理クラスタ構成ファイルに入力します。
管理クラスタの構成ファイルに以下を追加します。
```
private_registry_config {
  address = "ADDRESS"
  ca_cert = "CA_CERT"
}
```
次のように置き換えます。
- ADDRESS: 非公開レジストリを実行するマシンの IP アドレスまたは FQDN（完全修飾ドメイン名）。
- CA_CERT: 非公開レジストリの CA 証明書の公開鍵。
ネットワークがプロキシサーバー経由である場合は、次を追加します。
```
proxy {
  url: "PROXY_SERVER_ADDRESS"
  no_proxy: "BYPASS_LIST"
}
```
次のように置き換えます。
- PROXY_SERVER_ADDRESS: プロキシサーバーの HTTP アドレス。スキームのデフォルトポートと同じ場合でも、ポート番号を含めます。
- BYPASS_LIST: プロキシサーバーを経由しない IP アドレス、IP アドレス範囲、ホスト名、ドメイン名のカンマ区切りのリスト。
例:
```
url: "http://my-proxy.example.local:80"
no_proxy: "192.0.2.0/24,my-host.example.local,198.51.100.0"
```
Google Distributed Cloud がこれらのアドレス、ホスト、ドメインのいずれかにリクエストを送信する場合、そのリクエストはプロキシサーバーをバイパスして宛先に直接送信されます。
管理クラスタを作成するの [Terraform] タブの手順に沿って、Terraform 構成ファイルとプランを検証し、ブートストラップクラスタを作成します。
gkectl register bootstrap コマンドを実行すると、gkectl から非公開レジストリのユーザー名とパスワードを入力するよう求められます。

クラスタの作成時に、システムイメージが非公開レジストリサーバーから 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 されます。

通常のクラスタと高度なクラスタの違い

高度なクラスタには、標準クラスタと比較していくつかの重要な違いがあります。

非公開レジストリを使用する場合、イメージは非公開レジストリのホスト名ではなく、gcr.io から pull されるように見えます。これは、実際には非公開レジストリサーバーからイメージが pull されている場合でも、想定される動作です。
イメージの pull では、クラスタ内の private-registry-creds シークレットの認証情報ではなく、非公開レジストリに接続する各マシンの /etc/containerd/config.toml ファイルの認証情報が使用されます。
すべての gcr.io イメージについて、クラスタはまず限定公開レジストリからの pull を試みます。イメージが非公開レジストリにない場合、システムはインターネット経由で gcr.io からイメージを pull します。このフォールバックを停止するには、noProxy を設定するか、ファイアウォールルールを使用して gcr.io トラフィックをブロックします。

イメージが正しいソースから pull されていることを確認するには、イメージがレジストリサーバーから 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 します。

限定公開の Container Registry を構成する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要