レジストリミラーを使用してクラスタを作成する

このページでは、gcr.io などの一般公開レジストリからではなく、レジストリミラーから pull されたイメージを使用してクラスタを作成する方法について説明します。

レジストリミラーは、一般公開レジストリのファイル構造をコピーまたはミラーリングする公開レジストリのローカルコピーです。たとえば、ローカルのレジストリミラーのパスが 172.18.0.20:5000 であるとします。containerd が gcr.io/kubernetes-e2e-test-images/nautilus:1.0 のようなイメージを pull するリクエストを受信すると、containerd は gcr.io ではなくパス: 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0のローカルレジストリからイメージを pull しようとします。イメージがこのローカルレジストリパスに存在しない場合は、イメージが一般公開レジストリ gcr.io から自動的に pull されます。

レジストリミラーを使用することには、次の利点があります。

一般公開レジストリの停止から保護します。
Pod の作成を高速化できます。
独自の脆弱性スキャンを実行できます。
レジストリへのコマンド発行頻度に関する一般公開レジストリによる制限を回避します。

始める前に

ネットワークに Container Registry サーバーが設定されている必要があります。
レジストリサーバーでプライベート TLS 証明書を実行する場合は、認証局（CA）ファイルが必要です。
レジストリサーバーで認証が必要な場合は、適切なログイン認証情報または Docker 構成ファイルが必要です。
レジストリミラーを使用するには、コンテナランタイムを containerd に設定する必要があります。

ベアメタル版 GKE に必要なすべてのイメージをダウンロードする

[ダウンロード] ページから、bmctl ツールとイメージパッケージの最新バージョンをダウンロードします。

コンテナイメージをレジストリサーバーにアップロードする

次のコマンドを実行して、イメージをイメージパッケージからレジストリサーバーにアップロードします。

[HTTPS_PROXY=http://PROXY_IP:PORT] ./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=REGISTRY_IP:PORT \
    [--cacert=CERT_PATH] \
    [--need-credential=false]

以下を置き換えます。

ワークステーションからレジストリサーバーにイメージをアップロードするためにプロキシが必要な場合は、PROXY_IP:PORT をプロキシの IP アドレスとポートに置き換えます。
VERSION は、ダウンロードページからダウンロードしたイメージパッケージのバージョンに置き換えます。
REGISTRY_IP:PORT は、プライベートレジストリサーバーの IP アドレスとポートに置き換えます。
レジストリサーバーがプライベート TLS 証明書を使用している場合は、CERT_PATH を CA 証明書ファイルのパスに置き換えます。

プロンプトが表示されたら、ユーザー名とパスワードを入力するか、Docker 構成ファイルを選択します。レジストリサーバーで認証情報が必要ない場合は、--need-credential=false を指定します。

bmctl push images コマンドについて詳しくは、以下を実行してください。

bmctl push images --help

独自の名前空間を使用する

レジストリサーバーでルート名前空間ではなく独自の名前空間を使用する必要がある場合は、限定公開レジストリの API エンドポイントを registryMirrors.endpoint に指定すると、containerd がこの名前空間から pull できるようになります。エンドポイントは通常、<REGISTRY_IP:PORT>/v2/<NAMESPACE> の形式になります。詳細については、非公開レジストリのユーザーガイドをご覧ください。

たとえば、172.18.0.20:5000/test-namespace/ へのアクセス権のみを付与されている場合は、次のコマンドを使用して、名前空間 test-namespace の下にあるすべての画像をアップロードできます。

./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=172.18.0.20:5000/test-namespace
    --username=<USERNAME>
    --password=<PASSWORD>
    --cacert <path/to/cert.crt>

次に、クラスタの構成ファイルに次のように追加して、containerd が名前空間から pull するように設定できます。

registryMirrors:
  - endpoint: https://172.18.0.20:5000/v2/test-namespace

レジストリミラーからクラスタを作成する

次のサンプルクラスタの構成ファイルでは、エンドポイントが https://172.18.0.20:5000 のローカルレジストリミラーからイメージを pull するように指定されています。以降のセクションでは、この構成ファイルの最初に表示されるフィールドの一部について説明します。

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://172.18.0.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

`hosts` フィールド

containerd は、クラスタ構成ファイルの hosts セクションを確認して、ローカルにミラーリングされているホストを特定します。構成ファイルの例では、hosts セクションにリストされている一般公開レジストリは somehost.io と otherhost.io です。これらの一般公開レジストリは hosts セクションに表示されるため、containerd は somehost.io または otherhost.io からのイメージの pull リクエストを検出すると、まず非公開レジストリミラーを確認します。

たとえば、containerd が somehost.io/kubernetes-e2e-test-images/nautilus:1.0 への pull コマンドを受信するとします。somehost.io はクラスタ構成ファイルの hosts セクションにホストの 1 つとしてリストされているため、containerd は kubernetes-e2e-test-images/nautilus:1.0 イメージのローカルレジストリミラーを検索します。somehost.io が hosts セクションにない場合、containerd は somehost.io のローカルミラーが存在することを認識しません。その場合、containerd はイメージのミラーを確認せず、somehost.io 一般公開レジストリからイメージを pull します。

デフォルトでは、ベアメタル版 GKE は自動的に gcr.io のイメージをミラーリングするため、hosts セクションにホストとして gcr.io を一覧表示する必要はありません。

`gcrKeyPath` フィールド

ベアメタル版 GKE で Container Registry（gcr.io）を自動的に使用して、ローカルレジストリにないイメージを pull する場合は、Container Registry サービスアカウントキーへのパスを指定する必要があります。ベアメタル版 GKE には、他の一般公開レジストリに鍵を提供するためのメカニズムはありません。

イメージがローカルレジストリにない場合に、イメージを gcr.io から pull する機能を使用する予定がない場合は、gcrKeyPath をクラスタ構成ファイルに追加する必要はありません。

`caCertPath` フィールド

レジストリでプライベートトランスポート層セキュリティ（TLS）証明書が必要な場合、このフィールドにはサーバーのルート CA 証明書ファイルへのパスが入ります。この証明書ファイルは、bmctl コマンドを実行するマシンの管理ワークステーション上にある必要があります。レジストリでプライベート TLS 証明書が不要な場合は、caCertPath フィールドを空白のままにできます。

`pullCredentialConfigPath` フィールド

レジストリサーバーで認証 Docker 構成ファイルが不要な場合は、pullCredentialConfigPath フィールドを空白のままにできます。これは、bmctl コマンドを実行しているマシン上の構成ファイルのパスです。

レジストリミラーからユーザークラスタを作成する

管理クラスタが行うように構成されている場合、ユーザークラスタはレジストリミラーからイメージを自動的に pull しません。ユーザークラスタがレジストリミラーから pull するように設定するには、レジストリミラーからクラスタを作成するの説明に沿って、個別に構成する必要があります。

レジストリミラーエンドポイント、証明書、pull 認証情報を更新する

レジストリミラーエンドポイント、証明書、または pull 認証情報を更新するには、次のように操作します。

クラスタ構成ファイルで、エンドポイント、CA 証明書ファイル、pull 認証情報構成ファイルのパスを更新します。
次のコマンドを実行して、変更を適用します。
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
以下を置き換えます。
- CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
- ADMIN_KUBECONFIG は、管理クラスタの構成ファイルのパスに置き換えます。

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

このセクションでは、containerd が一般公開レジストリではなくローカルレジストリミラーからイメージを pull しているかどうかを確認する 2 つの方法について説明します。

方法 #1: リポジトリのダイジェストを比較する

この方法では、リポジトリダイジェストを比較して、イメージがレジストリミラーから pull されたかどうかを判断します。

レジストリにはリポジトリダイジェストと呼ばれる一意の識別子があり、イメージにはコンテナイメージダイジェストと呼ばれる一意の識別子があります。同一の 2 つのイメージは、異なるレジストリから作成されたものであっても、同じコンテナイメージダイジェストを持ちます。ただし、イメージが別のレジストリから作成された場合は、異なるリポジトリダイジェストを持ちます。

SSH を使用してクラスタノードにログインします。
送信元を確認するイメージを選択します。
次のコマンドを実行して、使用するイメージを一般公開レジストリから pull します。
```
crictl pull PUBLIC_ENDPOINT
```
PUBLIC_ENDPOINT は、一般公開レジストリ内のイメージのパスに置き換えます。例: gcr.io/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0
次のコマンドを実行して、同じイメージをレジストリミラーから pull します。
```
crictl pull MIRROR_ENDPOINT
```
MIRROR_ENDPOINT は、レジストリミラー内のイメージのパスに置き換えます。例: 10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0
次のコマンドを実行して、前の手順で pull した 2 つのイメージのリポジトリダイジェストを表示します。
```
crictl inspecti PUBLIC_OR_MIRROR_ENDPOINT | grep -A 3 repoDigests
```
PUBLIC_OR_MIRROR_ENDPOINT は、イメージの一般公開エンドポイントまたはイメージのレジストリミラーエンドポイントに置き換えます。crictl inspecti コマンドでは、引き渡し先の引数のコンテナイメージダイジェストを参照するため、どちらでも問題ありません。一般公開レジストリのイメージはレジストリミラーのイメージと同一であるため、どちらも同じコンテナイメージダイジェストを持ちます。

コマンドの出力は次のようになります。
```
 "repoDigests": [
   "gcr.io/anthos-baremetal-release/kube-rbac-proxy@sha256:27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3",
   "10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy@sha256:27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3"
 ],
```
前のステップの出力で太字になっているリポジトリダイジェストを比較します。ダイジェストが同一の場合、クラスタ内のノードはレジストリミラーから pull しています。それ以外の場合は、クラスタノードが公開レジストリからイメージを pull しています。

方法 #2: `config.toml` ファイルを調べる

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

ノードにログインして、次のファイル（/etc/containerd/config.toml）の内容を調べます。
config.toml ファイルの plugins."io.containerd.grpc.v1.cri".registry.mirrors セクションを確認して、レジストリサーバーが endpoint フィールドにリストされているかどうかを確認します。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"]
...

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

レジストリ ミラーを使用してクラスタを作成する

始める前に

ベアメタル版 GKE に必要なすべてのイメージをダウンロードする

コンテナ イメージをレジストリ サーバーにアップロードする

独自の名前空間を使用する

レジストリ ミラーからクラスタを作成する

hosts フィールド

gcrKeyPath フィールド

caCertPath フィールド

pullCredentialConfigPath フィールド

レジストリ ミラーからユーザー クラスタを作成する

レジストリ ミラー エンドポイント、証明書、pull 認証情報を更新する

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