限定公開の 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

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

    このセクションに入力した場合、次の処理が行われます。

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

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

  2. ネットワークがプロキシ サーバーの背後にある場合は、proxy セクションに入力します。

Terraform

  1. 管理クラスタを作成するの [Terraform] タブの手順に沿って、管理クラスタ構成ファイルに入力します。

  2. 管理クラスタの構成ファイルに以下を追加します。

    private_registry_config {
  address = "ADDRESS"
  ca_cert = "CA_CERT"
}

    次のように置き換えます。

    • ADDRESS: 非公開レジストリを実行するマシンの IP アドレスまたは FQDN（完全修飾ドメイン名）。

    • CA_CERT: 非公開レジストリの CA 証明書の公開鍵。

  3. ネットワークがプロキシ サーバー経由である場合は、次を追加します。

    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 がこれらのアドレス、ホスト、ドメインのいずれかにリクエストを送信する場合、そのリクエストはプロキシ サーバーをバイパスして宛先に直接送信されます。

  4. 管理クラスタを作成するの [Terraform] タブの手順に沿って、Terraform 構成ファイルとプランを検証し、ブートストラップ クラスタを作成します。

  5. 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 します。