Linux カスタムマシンイメージ

この手順では、AWS、Azure、または vSphere でクラスタを作成するときに使用する Linux カスタムマシンイメージをビルドする方法について説明します。次のセクションに分かれています。Tanzu Kubernetes Grid のクラスタタイプの詳細については、「Workload クラスタタイプ」を参照してください。

「Linux イメージの前提条件」には、カスタムの Linux イメージを正常にビルドして使用するために必要な情報が一覧表示されています。
「Linux イメージのビルド」では、Kubernetes Image Builder と Docker を使用してイメージをカスタマイズおよびビルドする方法について説明します。
「Linux イメージ用の TKr の作成」では、Linux イメージを Tanzu Kubernetes リリース (TKr) に変換する方法について説明します。このリリースでは、イメージを将来の Kubernetes バージョンのデフォルトにし、それを使用および管理するためのより多くのオプションを提供します。
「管理クラスタに Linux イメージを使用する」では、カスタムイメージをテンプレートとして使用する管理クラスタを展開する方法について説明します。
「ワークロードクラスタに Linux イメージを使用する」では、カスタムイメージをテンプレートとして使用するワークロードクラスタを展開する方法について説明します。

手順で説明したように、一部の手順は、クラスベースクラスタとプランベース（レガシー）クラスタのどちらのイメージをビルドしているかによって異なります。

Linux イメージの前提条件

Linux カスタムマシンイメージをビルドするには、以下が必要です。

ターゲットインフラストラクチャ、AWS、Azure、または vSphere 上のアカウント。
以下がインストールされた macOS または Linux ワークステーション：
- Docker デスクトップ
- AWS の場合：aws コマンドラインインターフェイス (CLI)
- Azure の場合：az CLI
- vSphere の場合：RHEL 8 イメージをビルドするには、macOS ではなく Linux ワークステーションが必要です。

（クラスベース、vSphere）OS イメージバージョンの取得

vSphere でクラスベースのクラスタに使用するイメージをビルドする前に、カスタムイメージに使用する Kubernetes バージョンのデフォルトの Ubuntu OVA に関連付けられている OS イメージバージョンを取得する必要があります。この OS イメージバージョンは、以下の「Linux イメージのビルド」の手順でカスタムイメージに割り当てます。

OS イメージバージョンを取得するには、使用事例に応じて次のいずれかを実行します。

現在の Tanzu Kubernetes Grid バージョンのデフォルトの Kubernetes バージョンを使用して作成された実行中の管理クラスタがある場合は、クラスタから OS イメージバージョンを取得できます。
1. kubectl コンテキストを管理クラスタに設定します。
2. 使用可能な TKr のリストから、カスタムイメージに使用する Kubernetes バージョンの Tanzu Kubernetes リリース (TKr) を選択します。たとえば、v1.26.5---vmware.2-tkg.1です。使用可能な TKr を一覧表示するには、次のコマンドを実行します。
```
kubectl get tkr
```
3. TKr を開き、osImages プロパティを見つけます。このプロパティは、TKr に関連付けられている OSImage オブジェクトの名前を指定します。
4. デフォルトの Ubuntu OVA の OSImage オブジェクトを見つけて開きます。OSImage オブジェクトの名前は、TKr の osImages のいずれかの名前と一致します。
```
kubectl get osimages
```
5. デフォルトの Ubuntu OVA の OSImage オブジェクトで、spec.image.ref の下にある version プロパティの値を見つけて記録します。たとえば、v1.26.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075eです。
現在の Tanzu Kubernetes Grid バージョンのデフォルトの Kubernetes バージョンを使用して作成された実行中の管理クラスタがない場合は、ローカルまたは vSphere で、デフォルトの Ubuntu OVA から OS イメージバージョンを直接取得できます。
- OS イメージバージョンをローカルで取得するには、次の手順を実行します。
  1. Customer Connect からターゲット Kubernetes バージョンのデフォルトの Ubuntu OVA をダウンロードします。
    1. Tanzu Kubernetes Grid のダウンロードページに移動し、VMware Customer Connect 認証情報を使用してログインして、[ダウンロードに移動 (Go to Downloads)] をクリックします。
    2. OVA をダウンロードします。たとえば、Ubuntu 2004 Kubernetes v1.26.5 OVA などです。
  2. 選択した抽出ツールを使用してダウンロードした OVA を展開します。
  3. 解凍したディレクトリで、.ofv ファイルを見つけます。
  4. .ofv ファイルで、OVA の VERSION プロパティを検索し、その値を記録します。たとえば、v1.26.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075eです。プロパティは次のようになります。
```
<Property ovf:key="VERSION" ovf:type="string" ovf:userConfigurable="false" ovf:value="v1.26.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"/>
```
- ターゲット Kubernetes バージョンのデフォルトの Ubuntu OVA を vSphere にすでにアップロードしている場合は、vSphere ユーザーインターフェイスで OVA 仮想マシンのプロパティを調べることや、govc CLI を使用して OS イメージバージョンを取得することもできます。この方法を使用するには、OVA 仮想マシンをテンプレートに変換する前に OS イメージバージョンを取得します。
  - vSphere ユーザーインターフェイスから OS イメージバージョンを取得するには、次の手順を実行します。
    1. OVA 仮想マシンを見つけて、OVA 仮想マシンのサマリページで [構成 (Configure)] タブを開きます。
    2. [設定 (Settings)] > [vApp Options (vApp オプション)] に移動します。
    3. [プロパティ (Properties)] テーブルで、VERSION キーを見つけて、その[デフォルト値 (Default Value)] を記録します。たとえば、v1.26.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075eです。
  - govc CLI を使用して OS イメージバージョンを取得するには、govc vm.info コマンドを実行します。例：
```
govc vm.info -json /dc0/vm/ubuntu-2004-kube-v1.26.5+vmware.1-tkg.1 | jq
```
    出力で、"Id": "VERSION" を検索し、"DefaultValue" プロパティの値を記録します。例：
```
{
"Key": 10,
"ClassId": "",
"InstanceId": "",
"Id": "VERSION",
"Category": "Cluster API Provider (CAPI)",
"Label": "VERSION",
"Type": "string",
"TypeReference": "",
"UserConfigurable": false,
"DefaultValue": "v1.26.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e",
"Value": "",
"Description": ""
}
```

Linux イメージのビルド

インフラストラクチャの認証を設定します。
- vSphere：認証情報 JSON ファイルを作成し、その値を入力します。
```
{
"cluster": "",
"convert_to_template": "false",
"create_snapshot": "true",
"datacenter": "",
"datastore": "",
"folder": "",
"insecure_connection": "false",
"linked_clone": "true",
"network": "",
"password": "",
"resource_pool": "",
"template": "",
"username": "",
"vcenter_server": ""
}
```
- AWS：aws CLI にログインします。プロンプトが表示されたら、リージョンを認証して指定します。
```
aws configure
```
- Azure：az CLI にログインします。次に、構成 JSON ファイル azure-sig.json を作成し、Azure 固有の情報を入力します。このようなファイルの例は、こちらで確認できます。
projects.registry.vmware.com から Linux リソースバンドルコンテナをダウンロードします。
1. ワークステーションが VMware イメージレジストリ projects.registry.vmware.com にアクセスできることを確認します。
2. Image Builder が Linux OVA をビルドするために必要な Kubernetes Linux バイナリを含むコンテナをダウンロードして実行します。
```
docker pull projects.registry.vmware.com/tkg/linux-resource-bundle:v1.26.5_vmware.1-tkg.1

docker run -d -p 3000:3000 projects.registry.vmware.com/tkg/linux-resource-bundle:v1.26.5_vmware.1-tkg.1
```
Image Builder 構成ディレクトリをダウンロードします。
1. ビルド元の Image Builder 構成バージョンを決定します。
  - VMware {code} Sample Exchange で TKG Image Builder を検索し、使用可能なバージョンを一覧表示します。
  - 各 Image Builder のバージョンは、互換性のある Kubernetes および Tanzu Kubernetes Grid のバージョンに対応しています。たとえば、TKG-Image-Builder-for-Kubernetes-v1.26.5-on-TKG-v2.3.0-master.zip は Tanzu Kubernetes Grid v2.3.0 の Kubernetes v1.26.5 イメージをビルドします。
  - Tanzu Kubernetes Grid を初めてインストールするときには管理クラスタを作成する必要があります。この場合、Tanzu Kubernetes Grid バージョンのデフォルトの Kubernetes バージョンを選択します。たとえば、Tanzu Kubernetes Grid v2.3.0 では、デフォルトの Kubernetes バージョンは v1.26.5 です。ワークロードクラスタの場合は、v1.26.5 に加えて、Kubernetes v1.25.10 または v1.24.14 をビルドすることもできます。
  次の手順では、Tanzu Kubernetes Grid v2.3.0 の Kubernetes v1.26.5 イメージをビルドする方法について説明します。
2. 構成コードの zip ファイルをダウンロードし、その内容を展開します。
3. cd で TKG-Image-Builder- ディレクトリに移動し、tkg.json ファイルが現在のディレクトリに配置されるようにします。
vSphere vSphereの場合は、Image Builder ディレクトリに metadata.json ファイルを作成します。このファイルは、バージョン文字列を後の手順でカスタム TKr に一覧表示するバージョン文字列と一致するように設定します。
- クラスベース：上記の「OS イメージバージョンの取得」手順で取得した値を使用します。例：
```
{
"VERSION": "v1.26.5+vmware.1-tkg.1-765d418b72c247c2310384e640ee075e"
}
```
- プランベース：image-builder は、作成した OVA に対して、VMware が公開した OVA と同一のバージョン文字列（v1.26.5+vmware.1-tkg.1 など）を付与します。カスタムイメージの場合、VMware では、-tkg.1 を組織にとって意味のある文字列に置き換えることをお勧めします。例：
```
{
"VERSION": "v1.26.5+vmware.1-myorg.0"
}
```
tkg.json ファイルを編集して、<IP> と <PORT> の設定および containerd_url と kubernetes_http_source のカスタマイズを入力します。ここで：
- IP は、Docker コンテナを実行しているマシンの IP アドレスに対応します。
- PORT は、Docker ホストの未使用ポートをコンテナのポート 3000 に関連付けます（3001:3000 など）。コンテナは、ポート 3000 を介してアーティファクトを公開します。
次のオプションを含める場合は、tkg.json ファイルの編集を続行します。
- Photon：Photon-3 OVA をビルドする場合は、tkg.json で "extra_rpms" を編集して、サポートされている追加のカスタムパッケージを反映します。
```
"extra_rpms": "sysstat nfs-utils ethtool apparmor-parser"
```
- STIG および CIS セキュリティ強化：カスタム Ubuntu イメージをデフォルトレベル以上に強化するには、次の手順を実行します。
  1. 次の変数の一部またはすべてに対する ansible_user_vars を true に設定する行を追加します。これらのデフォルトは false です。
  2. STIG：
    - install_aide - AIDE（高度な侵入検知環境）を有効にする
    - install_sshd_login_banner - DoD ログインバナーをインストールする
    - remove_existing_ca_certs - DoD PKI インフラストラクチャを保持する
    - install_audispd_plugins - イベントマルチプレクサ (audispd) プラグインをインストールする
  3. CIS：
    - install_aide - AIDE（高度な侵入検知環境）を有効にする
    - install_clamav - ClamAV AntiVirus を有効にする
    - install_systemd_timesyncd - chrony ではなく timesyncd を使用する
    - install_protect_kernel_defaults - カーネル保護のデフォルトアップストリームを設定する
  4. STIG の場合は /home/imagebuilder/stig_ubuntu_2004、CIS の場合は /home/imagebuilder/cis_ubuntu_2004 を追加して、custom_role_names 設定を変更します。
  たとえば、追加の CIS セキュリティ強化の場合：
```
  "ansible_user_vars": "install_aide=true install_clamav=true install_systemd_timesyncd=true install_protect_kernel_defaults=true",
  "custom_role_names": "/home/imagebuilder/tkg /home/imagebuilder/cis_ubuntu_2004",
```
  注
  カスタム Photon イメージは、ansible_user_vars を介した追加のセキュリティ強化ではサポートされません。
- FIPS：FIPS 対応イメージをビルドするには、次の設定を削除します（存在する場合）。
```
"ansible_user_vars": "install_fips=no"
```
- インターネット制限：HTTP プロキシサーバ経由でインターネットにアクセスする、インターネットが制限された環境のイメージをビルドするには、次の情報を追加します。
```
"http_proxy": "http://proxy.acme.com:80",
"https_proxy": "http://proxy.acme.com:80",
"no_proxy": "localhost, 127.0.0.1, acme.com, 10.0.0.0/8"
```
- GPU 対応クラスタ：GPU 対応クラスタのイメージをビルドするには、次の情報を追加します。
```
"vmx_version": "17"
```
tkg.json にカスタマイズを追加したり、別のファイル customizations.json に配置したりできます。
次のパラメータ文字列を収集して、次の手順で docker コマンドに接続します。これらの多くは、イメージのビルドに使用されるコンテナの /home/imagebuilder ディレクトリに、現在の作業ディレクトリをコピーする docker run -v パラメータを指定します。
- AUTHENTICATION：ローカル CLI ディレクトリをコピーします。使用可能
  - vSphere：/PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
  - AWS：~/.aws:/home/imagebuilder/.aws
  - Azure：~/.azure:/home/imagebuilder/.azure
- SOURCES：リポジトリの tkg.json ファイルをコピーします。これにより、バージョン管理された OS、Kubernetes、コンテナネットワークインターフェイス (CNI) イメージのダウンロードソースが一覧表示されます。
  - /PATH/TO/tkg.json:/home/imagebuilder/tkg.json を使用します
- ROLES：Image Builder で必要な Ansible ロールを含むリポジトリの tkg ディレクトリ。
  - `/PATH/TO/tkg:/home/imagebuilder/tkg を使用します
- TESTS：イメージのターゲットインフラストラクチャ、OS、および Kubernetes バージョン用に設計された goss テストディレクトリをコピーします。
  - リポジトリの goss ディレクトリにあるファイルのファイル名を使用します。
  - 例：amazon-ubuntu-1.26.5+vmware.1-goss-spec.yaml
- CUSTOMIZATIONS：カスタマイズファイルを JSON 形式でコピーします。
  - Image Builder ドキュメントの「カスタマイズ」を参照してください。
  - 変更を加える前に、ベストプラクティスと推奨事項について VMware Customer Reliability Engineering (CRE) にお問い合わせください。
- PACKER_VAR_FILES：Packer の変数を含む上記の JSON ファイルのスペース区切りリスト。
- (Azure) AZURE-CREDS：Image Builder ドキュメントに記載されている Azure 認証情報ファイルのパス。
- COMMAND：カスタムイメージ OS に基づいて、次のいずれかのコマンドを使用します。vSphere および Azure イメージの場合、コマンドは build-node-ova- および build-azure-sig- で始まります。
  - build-ami-ubuntu-2004：Ubuntu v20.04
  - build-ami-ubuntu-1804：Ubuntu v18.04
  - build-ami-amazon-2：Amazon Linux 2
  - build-node-ova-vsphere-ubuntu-2004：GPU 対応クラスタ

上記の文字列を使用して、VMware レジストリ projects.registry.vmware.com からプルされた Docker コンテナで Image Builder を実行します。

vSphere 用のイメージをビルドしていない場合は、metadata.json を省略し、Azure 用のイメージをビルドしていない場合は、env-file を省略します。

export ROLES="... the value for roles you created above"
export SOURCES="... ..." 
docker run -it --rm \
    -v $AUTHENTICATION \
    -v $SOURCES \
    -v $ROLES \
    -v /PATH/TO/goss/TESTS.yaml:/home/imagebuilder/goss/goss.yaml \
    -v /PATH/TO/metadata.json:/home/imagebuilder/metadata.json \
    -v /PATH/TO/CUSTOMIZATIONS.json:/home/imagebuilder/CUSTOMIZATIONS.json \
    --env PACKER_VAR_FILES="tkg.json CUSTOMIZATIONS.json" \
    --env-file AZURE-CREDS \
    --env IB_OVFTOOL=1 \
    projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
    COMMAND

注
このコマンドは完了までに数分かかる場合があります。

例

vSphere：.ova ファイルはワークステーションのローカルファイルシステムに保存されます。これらの OVA を保存するフォルダは、コンテナ内の /home/imagebuilder/output にマウントする必要があります。次に、コンテナイメージを使用して OVA を作成します。

docker run -it --rm \
  -v /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json \
  -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
  -v $(pwd)/tkg:/home/imagebuilder/tkg \
  -v $(pwd)/goss/vsphere-ubuntu-1.26.5+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

GPU 対応クラスタ：コマンドを実行して OVA を作成するときに、上記の手順で作成した customizations.json ファイルを含めます。

docker run -it --rm \
  -v /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json \
  -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
  -v $(pwd)/tkg:/home/imagebuilder/tkg \
  -v $(pwd)/goss/vsphere-ubuntu-1.26.5+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v $(pwd)/customizations.json:/home/imagebuilder/customizations.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json customizations.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

RHEL：RHEL OVA をビルドするには、macOS ではなく Linux マシンを使用する必要があります。これは、macOS の Docker が --network host オプションをサポートしていないためです。
また、上記の docker run コマンドに次のコマンドを追加して、Red Hat にライセンスされた OS を登録し、アップデートにサインアップする必要があります。

  -v $(pwd)/isos/rhel-8.4-x86_64-dvd.iso:/rhel-8.4-x86_64-dvd.iso \
  --network host \
  --env RHSM_USER=USER --env RHSM_PASS=PASS

ここで、

RHSM_USER と RHSM_PASS は、Red Hat Subscription Manager アカウントのユーザー名とパスワードです。
上記の例の $(pwd)/isos/rhel-8.4-x86-64-dvd.iso にあるローカル RHEL ISO パスを追加ボリュームとしてマッピングします。

AWS：tkg.json を含むディレクトリから実行して、Ubuntu v20.04 と Kubernetes v1.26.5 を使用して AWS で実行するカスタムイメージを作成します。

docker run -it --rm \
    -v ~/.aws:/home/imagebuilder/.aws \
    -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
    -v $(pwd)/tkg:/home/imagebuilder/tkg \
    -v $(pwd)/goss/amazon-ubuntu-1.26.5+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
    -v /PATH/TO/CUSTOMIZATIONS.json /home/imagebuilder/aws.json \
    --env PACKER_VAR_FILES="tkg.json aws.json" \
    --env IB_OVFTOOL=1 \
    projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
    build-ami-ubuntu-2004

クラウドプロバイダにイメージをアップロードします。
- vSphere の手順については、「vSphere への管理クラスタの展開の準備」の「基本イメージテンプレートの vSphere へのインポート」を参照してください。
- ターゲットの Kubernetes バージョンのデフォルトの Ubuntu OVA を vSphere にアップロードした場合は、カスタム OVA をアップロードする前にデフォルトの OVA を削除します。

Linux イメージ用の TKr の作成

Linux イメージを将来の Kubernetes バージョンのデフォルトにするには、それに基づいて TKr を作成します。それ以外の場合は、「ワークロードクラスタに Linux イメージを使用する」に進みます。

次の図は、vSphere でカスタム Linux イメージの TKr を作成する方法の概要を示しています。

TKr の作成

TKr を作成するには：

~/.config/tanzu/tkg/bom/ ディレクトリから、カスタムイメージの Kubernetes バージョンに対応する TKr BoM を開きます。たとえば、Kubernetes v1.26.5 の場合は、tkr-bom-v1.26.5+vmware.1-tkg.1.yaml といったファイル名になります。

ディレクトリに必要な TKr BoM ファイルがない場合は、「デフォルト以外の Kubernetes バージョンを使用してクラスタを展開する」の説明に従って、目的の Kubernetes バージョンのクラスタを展開して、このファイルを取り込むことができます。
1. BoM ファイルで、インフラストラクチャのイメージ定義ブロックを見つけます。vSphere の場合は ova、AWS の場合は ami、Azure の場合は azure です。各イメージ定義ブロックには、osinfo.name、osinfo.version、および osinfo.arch が含まれます。
  - osinfo.name は OS 名です。たとえば、ubuntu などです。サポートされている OS のリストを表示するには、「ターゲットのオペレーティングシステム」を参照してください。
  - osinfo.version は OS バージョンです。たとえば、20.04 などです。サポートされているバージョンのリストを表示するには、「ターゲットのオペレーティングシステム」を参照してください。
  - osinfo.arch は OS アーキテクチャです。サポートされる値は amd64 です。
2. 新しい OS イメージへの参照を追加するには、ターゲットインフラストラクチャに応じて、ova、ami、または azure の下にイメージ定義ブロックを追加します。イメージ定義ブロックには、前述のように、osinfo.name、osinfo.version、および osinfo.arch が含まれている必要があります。さらに、イメージ定義ブロックを追加する場合は、次のようにします。
  - vSphere：
    - name: は、OS バージョンを含む OVA の一意の名前です（my-ova-ubuntu-2004 など）。
    - version: には、OVA を作成したときに metadata.json で割り当てられた一意の VERSION を使用します（v1.26.5+vmware.1-myorg.0 など）。
    注
    version は、metadata.json 内の同じ VERSION と完全に一致する必要があります。
  - AWS：カスタムイメージを使用する予定のリージョンごとに、既存の id 値形式に従います。ただし、末尾には一意の 16 進数の文字列を使用します（ami-693a5e2348b25e428 など）。
  BoM ファイルでリージョンの下にイメージが定義されている場合は、カスタムイメージ定義ブロックがそのリージョンの最初にリストされている必要があります。各リージョン内で、クラスタの作成プロセスによって、リストされた最初の適切なイメージが選択されます。
3. release.version 値で、サフィックスを追加してカスタムバージョンを設定します。プリフィックスを追加してバージョンをカスタマイズしないでください。たとえば、v1.26.5+vmware.1-tkg.1 を v1.26.5+vmware.1-tkg.1-mycustomtkr に変更します。
4. 前の手順で release.version に指定したのと同じカスタムサフィックスを使用して BoM ファイルを保存します。
  
  ファイル名にプラス記号 (+) が含まれている場合は、+ を 3 つのダッシュ (---) に置き換えます。
  
  たとえば、BOM ファイルを tkr-bom-v1.26.5---vmware.2-tkg.1-mycustomtkr.yaml として保存します。
ファイルのコンテンツをバイナリ文字列に base64 エンコードします。次に例を示します。
```
cat tkr-bom-v1.26.5---vmware.2-tkg.1-mycustomtkr.yaml | base64 -w 0
```
ConfigMap YAML ファイルを作成します。たとえば、configmap-v1.26.5---vmware.2-tkg.1-mycustomtkr.yaml という名前を付けて、次のような値を指定します。
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: CUSTOM-TKG-BOM
 labels:
   tanzuKubernetesRelease: CUSTOM-TKR
binaryData:
 bomContent: "BOM-BINARY-CONTENT"
```
ここで、
- CUSTOM-TKG-BOM は ConfigMap の名前です。BOM ファイルで指定した TKr release.version 値を含め、+ 記号を 3 つのダッシュ (—) で置き換える必要があります。たとえば、v1.26.5---vmware.2-tkg.1-mycustomtkr を設定します。
- CUSTOM-TKR は TKr の名前で、CUSTOM-TKG-BOM に指定した値と一致する必要があります。たとえば、v1.26.5---vmware.2-tkg.1-mycustomtkrです。
- BOM-BINARY-CONTENT は、前の手順で生成したカスタマイズされた BoM ファイルの base64 エンコードされたコンテンツです。
例：
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: v1.26.5---vmware.2-tkg.1-mycustomtkr
 labels:
   tanzuKubernetesRelease: v1.26.5---vmware.2-tkg.1-mycustomtkr
binaryData:
 bomContent: "YXBpVmVyc2lvbjogcnVuLnRhbnp1...."
```
ConfigMap ファイルを保存し、kubectl コンテキストを TKr を追加する管理クラスタに設定し、次のようにファイルをクラスタに適用します。
```
kubectl -n tkr-system apply -f configmap-v1.26.5---vmware.2-tkg.1-mycustomtkr.yaml
```
TKr コントローラは、TanzuKubernetesRelease を作成して、新しい ConfigMap オブジェクトを調整します。デフォルトの調整時間は 600 秒です。この遅延を回避するには、TKr コントローラポッドを削除します。これにより、ポッドがすぐにリストアされ、調整されます。
1. tkr-system 名前空間内のポッドを一覧表示します。
```
kubectl get pod -n tkr-system
```
2. TKr コントローラポッドの名前を取得します。たとえば、tkr-controller-manager-f7bbb4bd4-d5lfd のようになります。
3. ポッドを削除します。
```
kubectl delete pod -n tkr-system TKG-CONTROLLER
```
  ここで、TKG-CONTROLLER は TKr コントローラポッドの名前です。
カスタム TKr が追加されたことを確認するには、tanzu kubernetes-release get または kubectl get tkr を実行するか、上記で設定した CUSTOM-TKR 値を出力で探します。

カスタム TKr が kubectl および tanzu CLI によって一覧表示されたら、それを使用して以下の説明に従って管理クラスタまたはワークロードクラスタを作成できます。

管理クラスタに Linux イメージを使用する

ノードの基本 OS としてカスタムイメージを使用する管理クラスタを作成するには、次の手順を実行します。

インストーラインターフェイスを実行するときに、「基本 OS イメージを選択する」の説明に従って、[OS イメージ (OS Image)] ペインでカスタムイメージを選択します。

詳細については、「基本 OS イメージの選択を生成する方法」を参照してください。

ワークロードクラスタに Linux イメージを使用する

Linux イメージからワークロードクラスタを作成する手順は、上記の「Linux イメージ用の TKr の作成」で TKr を作成したかどうかによって異なります。

TKr を作成した場合は、tanzu kubernetes-release get によってリストされた TKr 名を tanzu cluster create の --tkr オプションに渡します。
TKr を作成しなかった場合は、次の手順を実行します。
1. 「構成ファイルとオブジェクト仕様」の手順に従って、管理クラスタ構成ファイルをコピーして新しい名前で保存します。
2. 新しい構成ファイルで、以下を追加または変更します。
```
VSPHERE_TEMPLATE: LINUX-IMAGE
```
  ここで、LINUX-IMAGE は、「Linux イメージのビルド」で作成した Linux イメージの名前です。
  
  CLUSTER_NAME とその設定が存在する場合は削除します。
3. 「ワークロードクラスタの作成」の説明に従って、ワークロードクラスタを展開します。

Linux カスタム マシン イメージ