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 の機能状態」を参照してください。

ワークロードクラスタに対する Pinniped 認証は、管理クラスタが再作成された後は機能しません。

Velero の設定

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

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

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

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

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

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

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

Velero CLI のインストール

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

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

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 バイナリへのパスを入力します。

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

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.4.2 プラグインの「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.9.5 サーバをスタンドアローン管理クラスタにインストールし、インストールを確認します。

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

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

--provider $PROVIDER：たとえば、aws
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.3_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.1.0_vmware.1
```
注
複数のオプションをカンマで区切って追加できます。例：
```
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.3_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.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 のドキュメントの「バックアップのスケジュール設定」を参照してください。

リストアの完了

スタンドアローン管理クラスタおよび管理するワークロードクラスタオブジェクトをリストアするには、次の手順を実行します。

「構成ファイルからの管理クラスタの展開」の説明に従って、ここで構成ファイル mgmt-cluster-config.yaml から管理クラスタを再作成します。

注
管理クラスタが展開された後に適用される構成の変更は、構成ファイルまたは環境変数に反映する必要があります。そうしないと、変更はリストアされません。

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

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

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

tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.22.17---vmware.2-tkg.2  v1.22.17+vmware.2-tkg.2  True        True
v1.23.16---vmware.1-tkg.1  v1.23.16+vmware.1-tkg.1  True        True
v1.24.10---vmware.1-tkg.1   v1.24.10+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.24.10+vmware.1   <none>  prod  v1.24.10---vmware.1-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.24.10+vmware.1  <none>  prod  v1.24.10---vmware.1-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.24.10+vmware.1 <none>  v1.24.10---vmware.1-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 を取得し、それを 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.24.10+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.24.10+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.24.10+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.24.10+vmware.1  <none>  v1.24.10---vmware.1-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 またはその他のインフラストラクチャにログインし、仮想マシンを手動で削除します。

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

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