既存のブートストラップクラスタを使用した管理クラスタの展開と削除

デフォルトでは、tanzu mc create を実行して管理クラスタを展開すると、Tanzu Kubernetes Grid はローカルブートストラップマシンに一時的な kind クラスタを作成します。次に、ローカルクラスタを使用して、ターゲットクラウドインフラストラクチャ（vSphere、Amazon Web Services (AWS)、または Azure）に最終的な管理クラスタをプロビジョニングし、管理クラスタが正常に展開された後に一時的なクラスタを削除します。tanzu mc delete を実行して管理クラスタを削除すると、一時的なローカルの kind クラスタを作成、使用、削除する同様のプロセスが呼び出されます。

場合によっては、管理クラスタを展開または削除した後も、ローカルクラスタを保持する必要があります。たとえば、クラスタ内のオブジェクトを調べたり、ログを確認したりする場合です。これを行うには、CLI オプション --use-existing-bootstrap-cluster または --use-existing-cleanup-cluster を使用して管理クラスタを展開または削除できます。

これらのオプションを使用すると、Tanzu Kubernetes Grid はローカルの kind クラスタの作成と削除をスキップし、代わりに、既存のローカルクラスタ、またはその目的のために新規作成するローカルクラスタを使用します。

注意
既存のブートストラップクラスタの使用は、経験豊富な Kubernetes ユーザー向けの高度なユースケースです。可能であれば、Tanzu Kubernetes Grid が提供するデフォルトの kind クラスタを使用して管理クラスタをブートストラップすることを強くお勧めします。

ローカルブートストラップクラスタの特定または作成

管理クラスタの作成または削除中にローカルの kind クラスタを保持するには、まずブートストラップマシン上で互換性のあるクラスタが実行している必要があります。そのためには、以下のサブセクションの説明に従ってクラスタを特定または作成します。

既存のクラスタの使用

既存のローカルクラスタを使用するには、次の両方の条件を満たしている必要があります。

クラスタが以前に管理クラスタのブートストラップまたは削除に使用されたことがない。
クラスタが kind v0.11 以降で作成された。
- これを確認するには、docker ps を実行し、リストされている kindest:node バージョンを kind リリースノートにリストされているバージョンと関連付けます。
- 背景：ブートストラップマシンが 2021 年 5 月の Linux セキュリティパッチの後にビルドされた Linux カーネル（Fedora を使用する Linux 5.11 や 5.12 など）を使用している場合は、ブートストラップクラスタを kind バージョン v0.11 以降で作成する必要があります。以前のバージョンの kind は、最近の Linux バージョンで読み取り専用にされたファイルを変更しようとして失敗します。セキュリティパッチは 4.9 以降のすべての LTS カーネルにバックポートされているため、たとえば Mac OS 上の Docker マシンや Windows Subsystem for Linux など、オペレーティングシステムのアップデートが出荷される際に管理クラスタの展開に失敗する可能性があります。

上記の条件の両方が現在のローカルクラスタに当てはまる場合は、そのローカルクラスタを使用して管理クラスタを作成または削除できます。それ以外の場合は、次のようにクラスタを置き換える必要があります。

クラスタを削除します。
kind ドキュメントの説明に従って、新しいバージョンの kind をダウンロードしてインストールします。
以下の「新しいクラスタの作成」セクションの説明に従って、kind クラスタを作成します。

新しいクラスタの作成

新しいローカルブートストラップクラスタを作成するには、ブートストラップマシンの接続に応じて次のいずれかを実行します。

完全なオンライン環境：

クラスタを作成します。
```
kind create cluster
```
インターネットが制限された環境：
1. 次のように、kind クラスタ構成ファイル kind.yml を作成します。
```
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: tkg-kind
nodes:
- role: control-plane
 # This option mounts the host docker registry folder into
 # the control-plane node, allowing containerd to access them.
 extraMounts:
   - containerPath: CONTAINER-CA-PATH
     hostPath: HOST-CA-PATH
containerdConfigPatches:
- |-
 [plugins."io.containerd.grpc.v1.cri".registry.configs."REGISTRY-FQDN".tls]
   ca_file = "/etc/containerd/REGISTRY-FQDN/CA.crt"
```
  ここで、
  - CONTAINER-CA-PATH は、kind コンテナの Harbor CA 証明書のパスです（例：/etc/containerd/REGISTRY-FQDN）
  - HOST-CA-PATH は、kind クラスタが作成されるブートストラップ仮想マシンの Harbor CA 証明書のパスです（例：/etc/docker/certs.d/REGISTRY-FQDN）
  - REGISTRY-FQDN は Harbor レジストリの名前です
  - CA.crt は Harbor レジストリの CA 証明書です
  デフォルトでは、crashd は tkg-kind という名前のクラスタを検索するため、kind クラスタに tkg-kind という名前を付けると、クラスタがブートストラップに失敗した場合にログを収集しやすくなります。
2. 上記の構成ファイルを使用して kind クラスタを作成します。
```
kind create cluster --config kind.yml
```