vSphere での管理およびワークロードクラスタインフラストラクチャのバックアップおよびリストア（テクニカルプレビュー）

このトピックでは、vSphere 上のスタンドアローン管理クラスタを使用して、Tanzu Kubernetes Grid (TKG) のクラスタインフラストラクチャをバックアップおよびリストアする方法について説明します。以下の方法があります。

Velero を使用して、スタンドアローン管理クラスタ上のワークロードクラスタオブジェクトをバックアップおよびリストアする
構成ファイルからスタンドアローン管理クラスタを再作成する

注

VMware では、Velero を使用した TKG スタンドアローン管理クラスタのバックアップはサポートされていません。

スタンドアローン管理クラスタが展開された後に再構成された場合、ここで説明するように再作成しても、すべてのリソースがリカバリされない場合があります。

スタンドアローン管理クラスタを使用して、Tanzu Kubernetes Grid (TKG) ワークロードクラスタでホストされているワークロードと動的ストレージボリュームをバックアップおよびリストアするには、「クラスタワークロードのバックアップとリストア」を参照してください。

スーパーバイザークラスタ、およびそれらのクラスタが作成したワークロードクラスタを含む vSphere with Tanzu クラスタをバックアップおよびリストアするには、VMware vSphere 8.0 のドキュメントの「vSphere with Tanzu のバックアップとリストア」を参照してください。

注意

この機能は、サポートされていない「テクニカルプレビュー」状態です。「TKG の機能状態」を参照してください。

Velero の設定

オープンソースコミュニティ標準ツールである Velero を使用して、TKG スタンドアローン管理クラスタのインフラストラクチャとワークロードをバックアップおよびリストアできます。

Velero は、バックアップを保存するためにさまざまなストレージプロバイダをサポートしています。Velero は、次の機能もサポートします。

バックアップおよびリストアイベントの前後にカスタムプロセスを実行するための、バックアップおよびリストアの事前フックと事後フック。
バックアップ/リストアに適していないワークロードまたはクラスタ状態の側面の除外。

Tanzu Kubernetes Grid サブスクリプションには、Tanzu Kubernetes Grid ダウンロードページから入手可能な、テスト済みの互換性のある Velero ディストリビューションのサポートが含まれています。

TKG クラスタをバックアップおよびリストアするには、以下が必要です。

ローカルワークステーションで実行されている Velero CLI v1.10.3。「Velero CLI のインストール」を参照してください。
バックアップを保存する場所を持つストレージプロバイダ。「ストレージプロバイダの設定」を参照してください。
バックアップするクラスタで実行されている Velero サーバ：
- ワークロードクラスタの Velero は、次に説明するようにワークロードと動的ストレージをバックアップします。
- スタンドアローン管理クラスタの Velero は、「管理およびワークロードクラスタインフラストラクチャのバックアップおよびリストア」の説明に従ってワークロードクラスタオブジェクトをバックアップします。

上記の前提条件を満たしたら、Velero を使用してクラスタ間でワークロードを移行することもできます。手順については、Velero ドキュメントの「Cluster Migration」および「Resource Filtering」を参照してください。

Velero CLI のインストール

注意
以前のバージョンの TKG で配布されている Velero CLI v1.9.x またはそれ以前をすでにインストールしている場合は、v1.10.3 にアップグレードする必要があります。古いバージョンの Velero は、v1.10 およびそれ以降で使用される CRD では動作しません。詳細については、以下の「Velero のアップグレード」を参照してください。

Velero CLI v1.10.3 をインストールするには、次の手順を実行します。

Tanzu Kubernetes Grid のダウンロードページに移動し、VMware Customer Connect の認証情報を使用してログインします。
Product Downloads で Go to Downloads をクリックします。
Velero エントリまでスクロールし、ワークステーション OS 用の Velero CLI .gz ファイルをダウンロードします。ファイル名は、velero-linux-、velero-mac-、または velero-windows64- で始まります。
gunzip コマンドまたは任意の抽出ツールを使用してバイナリを解凍します。
```
gzip -d <RELEASE-TARBALL-NAME>.gz
```
プラットフォームの CLI バイナリの名前を velero に変更し、実行可能であることを確認して、PATH に追加します。
macOS および Linux
1. バイナリを /usr/local/bin フォルダに移動し、名前を velero に変更します。
2. ファイルを実行可能にします。
```
chmod +x /usr/local/bin/velero
```
Windows
1. 新しい Program Files\velero フォルダを作成し、そこにバイナリをコピーします。
2. バイナリの名前を velero.exe に変更します。
3. velero フォルダを右クリックして [プロパティ] > [セキュリティ] を選択し、ユーザーアカウントに [フルコントロール] 権限があることを確認します。
4. Windows 検索を使用して、env を検索します。
5. [システム環境変数の編集] を選択し、[環境変数] ボタンをクリックします。
6. [システム環境変数] の下にある Path 行を選択し、[編集] をクリックします。
7. [新規 (New)] をクリックして新しい行を追加し、velero バイナリへのパスを入力します。

Velero のアップグレード

Velero v1.10.3 は、v1.9.x とは異なる CRD を使用します。さらに、Velero v1.10 では、アップローダとして Restic を使用した Kopia が採用され、コンポーネントとコマンドの命名や Velero の機能が変更されました。v1.9.x と v1.10 の間の互換性を破る変更の詳細については、「Velero v1.10 変更ログの互換性を破る変更」を参照してください。以前のバージョンの TKG を使用して Velero v1.9.x をインストールした場合は、Velero をアップグレードする必要があります。

「Velero CLI のインストール」の手順に従って、Velero v1.10.3 をインストールします。
Velero v1.10 バイナリを使用して CRD 定義を更新します。
```
velero install --crds-only --dry-run -o yaml | kubectl apply -f -
```

Velero v1.10 で発生したコンポーネント名の変更に合わせて、Velero の展開およびデーモンセットの構成を更新します。

次のコマンドでは、uploader_type は restic または kopia のいずれかになります。

kubectl get deploy -n velero -ojson \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \
| sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \
| sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \
| sed "s#restic-timeout#fs-backup-timeout#g" \
| kubectl apply -f -

（オプション）restic デーモンセットを使用している場合は、対応するコンポーネントの名前を変更します。

echo $(kubectl get ds -n velero restic -ojson) \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \
| sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \
| kubectl apply -f -
kubectl delete ds -n velero restic --force --grace-period 0

詳細については、Velero ドキュメントの「Velero 1.10 へのアップグレード」を参照してください。

ストレージプロバイダの設定

Tanzu Kubernetes Grid ワークロードクラスタのコンテンツをバックアップするには、次のもののストレージ場所が必要です。

クラスタ内の Kubernetes メタデータ用のクラスタオブジェクトストレージバックアップ
クラスタで使用されるデータのボリュームスナップショット

Velero ドキュメントの「Backup Storage Locations and Volume Snapshot Locations」を参照してください。Velero は、次のいずれかのストレージプロバイダをサポートしています。

オンラインクラウドストレージプロバイダ。
プロキシまたはエアギャップ環境用の、MinIO などのオンプレミスオブジェクトストレージサービス。

VMware では、一意のストレージバケットを各クラスタ専用にすることをお勧めしています。

MinIO を設定するには：

MinIO 認証情報とストレージの場所を使用して minio コンテナイメージを実行します。次に例を示します。

$ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7

認証情報をローカルファイルに保存して、velero install の --secret-file オプションに渡します。次に例を示します。
```
[default]
aws_access_key_id=minio
aws_secret_access_key=minio123
```

vSphere のストレージ

vSphere では、クラスタオブジェクトストレージのバックアップとボリュームスナップショットが同じストレージの場所に保存されます。この場所は、Amazon Web Services (AWS) の S3 互換の外部ストレージ、または MinIO などの S3 プロバイダである必要があります。

vSphere で Velero のストレージを設定するには、v1.5.1 プラグインの「Velero Plugin for vSphere in Vanilla Kubernetes Cluster」を参照してください。

AWS のストレージ

AWS で Velero のストレージを設定するには、Velero Plugins for AWS リポジトリに記載されている手順に従います。

プラグインごとに必要に応じて S3 ストレージを設定します。オブジェクトストアプラグインはクラスタオブジェクトのバックアップを格納および取得し、ボリュームスナップショットツールはデータボリュームを保存および取得します。

Azure のストレージ

Azure で Velero のストレージを設定するには、Velero Plugins for Azure リポジトリに記載されている手順に従います。

管理クラスタへの Velero サーバの展開

ワークロードクラスタオブジェクトをバックアップするには、Velero v1.10.3 サーバをスタンドアローン管理クラスタにインストールし、インストールを確認します。

Velero インストールオプション

Velero をインストールするには、次のオプションを指定して velero install を実行します。

--provider $PROVIDER：たとえば、aws
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1
--bucket $BUCKET：S3 バケットの名前。
--backup-location-config region=$REGION：バケットが含まれる AWS リージョン。
--snapshot-location-config region=$REGION：バケットが含まれる AWS リージョン。
（オプション）--kubeconfig Velero サーバを現在のデフォルト以外のクラスタにインストールします。
（オプション）--secret-file ./VELERO-CREDS Velero に S3 バケットへのアクセス権を付与する 1 つの方法は、このオプションに次のようなローカル VELERO-CREDS ファイルを渡すことです。
```
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
```
その他のオプションについては、「Install and start Velero」を参照してください。

velero install コマンドを実行すると、velero という名前の名前空間をクラスタに作成し、velero という名前の展開をそこに配置します。

次の設定が必要です。

管理クラスタプラグイン：次のプラグインが必要です。このオプションは、クラスタを一時停止し、バックアップするクラスタに関連するリソースを収集します。
```
--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.0_vmware.1
```
注
複数のオプションをカンマで区切って追加できます。例：
```
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.0_vmware.1
```
スナップショットの場所なし：クラスタインフラストラクチャをバックアップする場合は、--snapshot-location-config を設定しません

Velero のインストールの検証

velero install コマンドが完了したら、Velero が正常にインストールされたことを検証します。

Velero ポッドのステータスが Running であることを検証します。

kubectl -n velero get pod
NAME                      READY   STATUS    RESTARTS   AGE
velero-78fdbcd446-v5cqr   1/1     Running   0          3h41m

バックアップの場所が Available フェーズであることを検証します。

velero backup-location get
NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
default   aws        mgmt            Available   2022-11-11 05:55:55 +0000 UTC   ReadWrite     true

ワークロードクラスタオブジェクトのバックアップ

スタンドアローン管理クラスタによって管理されているすべてのワークロードクラスタオブジェクトをバックアップするには、以下を実行します。

velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait

注

--exclude-namespaces tkg-system は管理クラスタ自体を除外します。

--include-resources cluster.cluster.x-k8s.io はワークロードクラスタオブジェクトを含めます。

VMware では、スケールアップやスケールダウンなど、構造上の変更を行った直後にワークロードクラスタをバックアップすることをお勧めします。これにより、リストアプロセスの失敗を引き起こす可能性のあるバックアップオブジェクトと物理インフラストラクチャ間の不一致が回避されます。

バックアップのスケジュール設定

最新のバックアップ後にクラスタオブジェクトが変更されると、リストア後のシステムの状態が想定した最新の状態と一致しません。この問題は「ドリフト」と呼ばれます。一般的なタイプのドリフトを検出して回復する方法については、以下の「ドリフトの処理」セクションを参照してください。

ドリフトを最小限に抑えるために、VMware では Velero を使用して頻繁で定期的なバックアップをスケジュール設定することをお勧めします。たとえば、すべてのワークロードクラスタを毎日バックアップし、各バックアップを 14 日間保持するには、以下を実行します。

velero create schedule daily-bak --schedule="@every 24h"  --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s

Velero のスケジュール設定オプションの詳細については、Velero のドキュメントの「バックアップのスケジュール設定」を参照してください。

リストア後に `kubeconfig` ファイルを再生成する

Velero を使用してワークロードクラスタをリストアしたら、新しい kubeconfig ファイルを、それを使用するすべてのユーザーに配布する必要があります。

kubeconfig を再生成します。

tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

上記のコマンドの出力を、クラスタを使用するすべてのユーザーに配布して、古い kubeconfig ファイルを置き換えます。
- kubeconfig ファイルには ID または認証情報が含まれておらず、Pinniped のドキュメントの「Kubernetes クラスタへのフェデレーション認証に Pinniped を使用する方法」で説明されているように、安全に配布できます。

リストアの完了

スタンドアローン管理クラスタおよび管理するワークロードクラスタオブジェクトをリストアするには、構成ファイルから管理クラスタを再作成し、Velero を使用してワークロードクラスタをリストアし、新しい kubeconfig ファイルを、それを使用するユーザーに配布します。

ワークロードクラスタオブジェクトの最新のバックアップとその現在の実行状態との間でドリフトが疑われる場合は、「ドリフトディテクタの使用」の説明に従って、ドリフトディテクタツールを使用して修正レポートを生成します。
管理クラスタが最初に展開された後に行われた構成変更が、その構成ファイルまたは環境変数に反映されていることを確認します。反映されていない場合、最新の状態にリストアされません。
「構成ファイルからの管理クラスタの展開」の説明に従って、ここで構成ファイル mgmt-cluster-config.yaml から管理クラスタを再作成します。
- 「複数のアベイラビリティゾーンにまたがるクラスタの実行」の説明に従って、管理クラスタまたはそのワークロードクラスタを vSphere 上の複数のアベイラビリティゾーンに展開した場合、たとえば、--az-file vsphere-zones.yaml を tanzu mc create コマンドに含めることによって、VSphereFailureDomain および VSphereDeploymentZone オブジェクト定義を持つファイルも含めます。

管理クラスタが作成された直後は、TKR は 1 つだけである必要があります。

tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.26.8---vmware.2-tkg.1  v1.26.8+vmware.1-tkg.1  True        True

バックアップされたワークロードクラスタで使用されるすべての TKR が使用可能になるまで数分待機します。

tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.24.17---vmware.2-tkg.2  v1.24.17+vmware.2-tkg.2  True        True
v1.25.13---vmware.1-tkg.1  v1.25.13+vmware.1-tkg.1  True        True
v1.26.8---vmware.2-tkg.1   v1.26.8+vmware.1-tkg.1   True        True

上記の「クラスタへの Velero サーバの展開」の手順に従って、Velero を管理クラスタにインストールします。認証情報とバックアップ場所の構成設定の値がバックアップの作成時と同じであることを確認します。

Velero のインストール後、バックアップが同期され、使用するバックアップがコマンドによって一覧表示されるまで velero backup get を実行します。

velero backup get
NAME                 STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
my-backup            Completed   0        0          2022-12-07 17:10:42 +0000 UTC   24d       default            <none>

velero restore create を実行してワークロードクラスタリソースをリストアします。VMware では、最新のバックアップを使用することをお勧めします。

velero restore create my-restore --from-backup my-backup --wait

リストアが完了すると、クラスタのステータスは createdStalled になります。

tanzu cluster list
NAME                NAMESPACE  STATUS          CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    createdStalled  0/3           0/3      v1.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-tkg.1

クラスタオブジェクトにパッチを適用して、paused プロパティを false に設定します。これは、クラスタオブジェクトが新しい管理クラスタで paused 状態で再作成されるため、コントローラが調整を試みないようにするために必要です。
- リストア後にクラスタの一時停止を解除するには、以下を実行します。
```
kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
```
- 複数の名前空間内のすべてのクラスタの一時停止を解除するには、次のスクリプトを実行します。
```
#!/bin/bash

for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system");
do
      clusters=$(kubectl -n $ns get cluster -o name)
      if [[ -n $clusters ]];then
              kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}'
      fi
done
```

次のように、すべてのワークロードクラスタが running 状態であることを確認します。

tanzu cluster list
NAME                NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    running  3/3           3/3      v1.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-tkg.1

次のように、ワークロードクラスタごとに tanzu cluster get CLUSTER-NAME を実行して、すべてのコンポーネントが running 状態であることを確認します。

tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  3/3           3/3      v1.26.8+vmware.1 <none>  v1.26.8---vmware.2-tkg.1

Details:

NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
/tkg-vc-antrea                                                True                     4h14m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5  True                     4h36m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn      True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt                         True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp                         True                     4h23m
│ └─Machine/tkg-vc-antrea-ch5hn-x7nmm                         True                     4h32m
└─Workers
  ├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn                True                     4h23m
  │ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9       True                     4h24m
  ├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh                True                     4h24m
  │ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667       True                     4h28m
  └─MachineDeployment/tkg-vc-antrea-md-2-brm2m                True                     4h21m
    └─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn       True                     4h23m

すべてのワークロードクラスタが実行されたら、Tanzu CLI を使用してワークロードクラスタを管理できます。

管理クラスタを再作成する前にドリフトディテクタを実行した場合は、「ドリフトの修正」の説明に従って、ドリフトディテクタレポートにフラグが付いているオブジェクトを手動で修正または調査します。
管理クラスタとそのワークロードクラスタの新しい kubeconfig ファイルを再生成して配布します。
1. 管理クラスタの kubeconfig を再生成します。
```
tanzu management-cluster kubeconfig get
```
2. ワークロードクラスタごとに、その kubeconfig を再生成します。
```
tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
```
3. 上記のコマンドの出力を、クラスタを使用するすべてのユーザーに配布して、古い kubeconfig ファイルを置き換えます。
  - kubeconfig ファイルには ID または認証情報が含まれておらず、Pinniped のドキュメントの「Kubernetes クラスタへのフェデレーション認証に Pinniped を使用する方法」で説明されているように、安全に配布できます。

ドリフトの処理

最新のバックアップ後にクラスタオブジェクトが変更されるとドリフトが発生し、リストア後のシステムの状態が想定した最新の状態と一致しません。

ドリフトを最小限に抑えるため、VMware では頻繁で定期的なバックアップをスケジュール設定することをお勧めします。

ドリフトの検出と修正には、以下のセクションで説明するドリフトディテクタツールが役に立ちます。

ドリフトディテクタの使用

ドリフトディテクタは、次の機能を備えたコマンドラインツールです。

TKG バックアップの内容と TKG クラスタオブジェクトインフラストラクチャの現在の状態を比較する
潜在的な問題とドリフトを修正するための手順を一覧表示するレポートを生成する

重要
ドリフトディテクタはサポートされていない試験的な状態です。ドリフトは複雑で、ドリフトディテクタはドリフトのすべてのインスタンスを検出できない場合があります。これは参照としてのみ使用し、通常のバックアップの代わりに使用しないでください。

ドリフトディテクタをインストールして使用する方法については、VMware KB Web サイトの「Tanzu Kubernetes Grid 管理クラスタのドリフトディテクタ」を参照してください。プロセス全体は次のとおりです。

TKG をバックアップからリストアする前に、drift-detector コマンドを実行してレポートを生成します。
最新のバックアップから TKG をダウンロードしてリストアします。
ドリフトディテクタのレポートを参照して、「ドリフトの修正」のガイダンスに従って、リストアされた TKG の状態に対して修正アクションを実行します。

ドリフトの修正

ドリフトのケースは複雑な場合がありますが、ドリフトディテクタのレポートを作成した場合、または前回のバックアップ以降にクラスタオブジェクト状態でドリフトを検出した場合は、次のようにいくつかの一般的なパターンを修正できます。

古いワーカーノード：
- 余分な未使用ノード
- バックアップ後にワーカーノード数がスケールダウンされた場合に発生する可能性があります
- 多くの場合、軽減策は不要です。リストア後、マシンの健全性チェックは古いマシンオブジェクトを削除し、目的のマシン数を満たすために新しいノードが作成されます。

ゴーストワーカーノードインフラストラクチャ：

余分な、管理対象外のノードインフラストラクチャ
バックアップ後にワーカーノード数がスケールアップされた場合に発生する可能性があります

軽減策：

ワークロードクラスタの kubeconfig を取得し、それを kubectl コンテキストとして設定します。

次の kubectl コマンドと tanzu コマンドの出力を比較します。

# Get the actual worker nodes of the workload cluster
$ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node
NAME                                        STATUS   ROLES           AGE    VERSION
tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9   Ready    <none>          44m    v1.26.8+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.26.8+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.26.8+vmware.1

# Get the worker nodes managed by the TKG
$ tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  1/1           1/1      v1.26.8+vmware.1  <none>  v1.26.8---vmware.2-tkg.1-zshippable

  Details:

  NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
  /tkg-vc-antrea                                                True                     13m
  ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9  True                     13m
  ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx      True                     13m
  │ └─Machine/tkg-vc-antrea-wdsfx-2hkxp                         True                     13m
  └─Workers
    └─MachineDeployment/tkg-vc-antrea-md-0-p9vn5                True                     13m
      └─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt       True                     13m

tanzu cluster get からの Workers > Machine リストを持たない kubectl によってリストされた各ワーカーノードの場合：
1. ワーカーを想定される値にスケールアップします。次に例を示します。
```
tanzu cluster scale ${cluster_name} --worker-machine-count 2
```
2. クラスタの kubeconfig を使用してゴーストノードをドレインし、そのワークロードを TKG によって管理されるノードに移動します。
```
kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
```
3. クラスタからゴーストノードを削除します。
```
kubectl delete node ${node_name}
```
4. vSphere またはその他のインフラストラクチャにログインし、仮想マシンを手動で削除します。

制御プレーンの古いノードとゴーストインフラストラクチャ

制御プレーンの未使用ノードと余分なノードインフラストラクチャ
バックアップ後に制御プレーンノードが置き換えられた場合に発生する可能性があります