紹介
このチュートリアルでは、TrilioVault for Kubernetes（またはTVK）をDOKSクラスターにデプロイし、バックアップを作成し、バックアップから復元する方法を学びます。クラスタ全体をバックアップするか、オプションでネームスペースまたはラベルベースのバックアップを選択できます。
Trilioを使用する利点：
- クラスタの完全（または増分）バックアップを取得し、データ損失の場合に復元します。
- 別のクラスタに移行します。
- Helmリリースのバックアップがサポートされています。
- バックアップと復元操作の前後にフックを実行します。
- バックアップ/復元操作の詳細な状態を確認できるWeb管理コンソール。
- バックアップの保持ポリシーを定義します。
- 専用のTrilioVault Operatorを介してアプリケーションライフサイクル（TVK自体）を管理できます。
- Velero統合。
- オペレータベースのアプリケーションをバックアップおよび復元できます。
詳細については、公式のTVK CRDsドキュメントを参照してください。
目次
- 前提条件
- ステップ1 – Kubernetes用のTrilioVaultのインストール
- ステップ2 – バックアップを保存するTrilioVaultターゲットの作成
- ステップ3 – TVK Web管理コンソールの操作方法
- ステップ4 – 名前空間ごとのバックアップとリストアの例
- ステップ5 – クラスタ全体のバックアップとリストアの例
- ステップ6 – 定期バックアップ
- ステップ7 – バックアップの保持ポリシー
- 結論
前提条件
このチュートリアルを完了するには、次のものが必要です：
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A Git client to clone the Starter Kit repository.
- Helm、TrilioVault Operatorのリリースとアップグレードの管理に使用します。
- Doctl、DigitalOcean APIとのやり取りに使用します。
- Kubectl、Kubernetesとのやり取りに使用します。
TrilioVaultが正しく機能し、PVCをバックアップするためには、DOKSをContainer Storage Interface（またはCSI）をサポートするように構成する必要があります。デフォルトでは、ドライバがすでにインストールされ、構成されています。次のコマンドを使用して確認できます：
出力は次のスニペットのようになります。プロビジョナーが dobs.csi.digitalocean.com であることに注意してください。
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
do-block-storage (default) dobs.csi.digitalocean.com Delete Immediate true 10d
TrilioVaultのインストールには、成功したインストールのためにvolumeSnapshotカスタムリソース定義（CRD）も必要です。次のコマンドを使用して確認できます：
出力は次のスニペットのようになります。 VolumeSnapshot CRDがインストールされていない場合は、VolumeSnapshot CRDsのインストールを参照してください。
volumesnapshotclasses.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io 2022-02-01T06:01:15Z
また、CRDがv1beta1およびv1の両方のAPIバージョンをサポートしていることを確認してください。次のコマンドを実行してAPIバージョンを確認できます：
CRD YAMLの最後に、storedVersionsリストが表示され、v1beta1とv1の両方の値が含まれているはずです（インストールされていない場合は、VolumeSnapshot CRDsのインストールを参照してください）：
...
- lastTransitionTime: "2022-01-20T07:58:06Z"
message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
reason: ApprovedAnnotation
status: "True"
type: KubernetesAPIApprovalPolicyConformant
storedVersions:
- v1beta1
- v1
ステップ1 – Kubernetes用TrilioVaultのインストール
このステップでは、TrilioVaultをDOKSに展開し、Helmを使用してTVKインストールを管理する方法を学びます。バックアップデータは、前の前提条件セクションで作成されたDO Spacesバケットに保存されます。
TrilioVaultアプリケーションはいくつかの方法でインストールできます:
- TrilioVault Operatorを介して。
TrilioVaultオペレーターにインストール、ポスト構成ステップ、および将来のTrilioアプリケーションコンポーネントのアップグレードの処理方法を伝えるTrilioVaultManagerCRDを定義します。 - Helmによって完全に管理されるtriliovault-operatorチャートを介して（このチュートリアルで説明されています）。
Helmを使用してTrilioVaultをインストールする
Starter Kitチュートリアルでは、TVKアプリケーションのクラスターインストールタイプが使用されます（applicationScope Helm値が「Cluster」に設定されています）。このチュートリアルのすべての例は、このタイプのインストールに正しく機能するように依存しています。
まず、Starter Kit Gitリポジトリをクローンし、ディレクトリをローカルコピーに変更します：
次に、TrilioVault Helmリポジトリを追加し、利用可能なチャートをリストします：
出力は次のようになります：
NAME CHART VERSION APP VERSION DESCRIPTION
triliovault-operator/k8s-triliovault-operator 2.9.2 2.9.2 K8s-TrilioVault-Operator is an operator designe...
興味のあるチャートは、triliovault-operator/k8s-triliovault-operator です。これにより、クラスターに TrilioVault と TrilioVault-Manager がインストールされます。 helm show values triliovault-operator/k8s-triliovault-operator を実行して、利用可能なすべてのオプションをファイルにエクスポートして表示できます。
次に、選択したエディターで Starter キットリポジトリに提供された TrilioVault Helm バリュー ファイルを開いて検査します（可能ならば、YAML lint サポートがあるエディターを使用してください）。
最後に、Helm を使用して Kubernetes 用の TrilioVault をインストールします：
–create-namespace \
上記のコマンドは、triliovault-values.yaml で提供されたパラメーターを使用して、TrilioVault Operator と TriloVault Manager（TVM）カスタム リソースの両方をインストールします。TVK のバージョンは、05-setup-backup-restore/assets/manifests/triliovault-values.yaml ファイルの tag フィールドで管理されるため、helm コマンドは常に最新バージョンの TVK を使用します。
values.yamlで以下のフィールドを更新できます：installTVK.applicationScope：インストールされる TVK のスコープを指定します。たとえば、ClusterまたはNamespacedinstallTVK.ingressConfig.host：TVK UI のホスト名を指定します。たとえば、tvk-doks.com
installTVK.ComponentConfiguration.ingressController.service.type：TVK UI にアクセスするためのサービス タイプを指定します。たとえば、NodePort または LoadBalancer
今、TVK デプロイメントを確認してください：
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
triliovault-manager-tvk tvk 1 2022-06-08 08:30:08.490304959 +0000 UTC deployed k8s-triliovault-2.9.2 2.9.2
triliovault-operator tvk 1 2022-06-08 11:32:55.755395 +0300 EEST deployed k8s-triliovault-operator-2.9.2 2.9.2
出力は次のスニペットに似ています（STATUS列はdeployedを表示する必要があります）：
次に、TrilioVaultが正常に動作していることを確認します：
NAME READY UP-TO-DATE AVAILABLE AGE
k8s-triliovault-admission-webhook 1/1 1 1 83s
k8s-triliovault-control-plane 1/1 1 1 83s
k8s-triliovault-exporter 1/1 1 1 83s
k8s-triliovault-ingress-nginx-controller 1/1 1 1 83s
k8s-triliovault-web 1/1 1 1 83s
k8s-triliovault-web-backend 1/1 1 1 83s
triliovault-operator-k8s-triliovault-operator 1/1 1 1 4m22s
出力は次のスニペットに似ています。すべての展開ポッドはReady状態である必要があります。
このような出力が表示された場合、TVKを正常にインストールしました。次に、ライセンスの種類と有効性を確認する方法、および更新する方法を学びます。
- デフォルトでは、Helmを使用してTVKをインストールすると、自動的に無料トライアルライセンスはインストールされません。常にTrilioのウェブサイトにアクセスして、クラスタに適した新しいライセンスを生成できます（たとえば、クラスタ容量が10ノードを超えない場合はTrilioVaultを無期限で実行できる基本ライセンスタイプを選択できます）。無料トライアルライセンスを使用すると、無制限のクラスタノードで1か月間TVKを実行できます。
- TrilioVaultは、DigitalOceanユーザー向けに最大100,000ノードまでのKubernetesクラスタで無料です。DO顧客専用の特別なライセンスを作成するために、次の手順に従うことができます。
スターターキットの例は、適切に機能するためにクラスタライセンスタイプに依存しています。
以下のコマンドを実行して、クラスター用の新しいライセンスを作成します（これはライセンスCRDを介して管理されます）：
上記のコマンドは、Trilioライセンスサーバーからライセンスを取得し、DOKSクラスターにインストールするために、job.batch/tvk-license-digitaloceanというジョブを作成します。ジョブが完了すると、60秒後に削除されます。
Trilioのウェブサイトから無料のライセンスをダウンロードする場合は、次のコマンドを使用して適用してください：
クラスターにライセンスがインストールされていてActive状態にあるかどうかを確認するには、次のコマンドを実行してください。
NAME STATUS MESSAGE CURRENT NODE COUNT GRACE PERIOD END TIME EDITION CAPACITY EXPIRATION TIME MAX NODES
test-license-1 Active Cluster License Activated successfully. 1 FreeTrial 100000 2023-02-25T00:00:00Z 1
出力は次のようになります。 STATUSに注目してください。これはActiveである必要があります。また、EDITION列とEXPIRATION TIMEのライセンスタイプにも注目してください。
ライセンスはLicenseオブジェクトという特別なCRDを介して管理されます。次のコマンドを実行して確認できます：
出力は次のようになります。 MessageとCapacityフィールド、およびEditionに注意してください。
上記の出力には、有効期限タイムスタンプ フィールドでライセンスの有効期限も表示されます。この場合、スコープ（クラスタベース）も含まれます。クラスタ全体のライセンスタイプまたは名前空間ベースのライセンスを選択できます。
ライセンスを更新するには、Trilioのウェブサイトから新しいライセンスをリクエストする必要があります。これは、古いライセンスを置き換えるためにライセンスページに移動して行います。フォームの入力を完了すると、クラスタに適用できるライセンスYAMLマニフェストを受け取るはずです。次のコマンドは、TVKがデフォルトのtvk名前空間にインストールされていることを前提としています（必要に応じて<>プレースホルダを置換してください）：
# `tvk` 名前空間から特定のライセンスに関する情報を取得します
次のステップでは、バックアップを保存するためのTrilioVaultのストレージバックエンドであるターゲットを定義する方法について説明します。
ステップ2 – バックアップを保存するためのTrilioVaultターゲットの作成
A typical Target definition looks like:
TrilioVaultはまずバックアップを保存する場所を知る必要があります。TrilioVaultは、target用語を使用してストレージバックエンドを参照し、Targetという特別なCRDを介して管理されます。次のターゲットタイプがサポートされています：S3およびNFS。DigitalOceanおよびStarter Kitの目的では、安価でスケーラブルなS3ストレージタイプを利用することが合理的です。強化された保護レベルを享受するために、複数のターゲットタイプ（S3およびNFSの両方）を作成して、データを複数の場所に安全に保管し、バックアップの冗長性を実現できます。
- この構成では、
spec.type: バックアップストレージのターゲットのタイプ（S3はオブジェクトストアです）。spec.vendor: ターゲットをホストするサードパーティーのストレージベンダー（DigitalOcean Spacesの場合は、AWSの代わりにOtherを使用する必要があります）。spec.enableBrowsing: ターゲットのブラウジングを有効にします。spec.objectStoreCredentials:S3ストレージへのアクセスに必要な資格情報（credentialSecretを介して）およびバケットのリージョンと名前などのその他のパラメータを定義します。
spec.thresholdCapacity: バックアップデータを保存するための最大閾値容量。
# 値は base64 エンコードされている必要があります
シークレットの名前が trilio-s3-target であり、これは以前に説明した Target CRD の spec.objectStoreCredentials.credentialSecret フィールドによって参照されます。この secret は、TrilioVault がインストールされた同じ namespace (デフォルトは tvk) または選択した別の namespace に存在する場合があります。ただし、namespace への参照が正しく行われていることを確認してください。一方で、セキュリティ上の理由から、TrilioVault のシークレットを格納する namespace を RBAC で保護することを確認してください。
TrilioVault のターゲットを作成する手順：
まず、ローカルマシンにクローンされた Starter Kit Git リポジトリのディレクトリを変更してください：
次に、ターゲットの S3 バケットの認証情報を含む Kubernetes シークレットを作成します（<> プレースホルダを適切に置き換えてください）：
–from-literal=accessKey=“<YOUR_DO_SPACES_ACCESS_KEY_HERE>” \
–from-literal=secretKey=“<YOUR_DO_SPACES_SECRET_KEY_HERE>”
次に、選択したエディター（可能であればYAML lintサポートを備えたもの）を使用して、スターターキットリポジトリで提供されるターゲットマニフェストファイルを開き、検査します。
次に、<> のプレースホルダーを、DO Spaces Trilioバケット用に適切に置き換えてください。たとえば、bucketName、region、url、credentialSecretなどです。
最後に、マニフェストファイルを保存し、kubectl を使用してターゲットオブジェクトを作成します：
NAME TYPE THRESHOLD CAPACITY VENDOR STATUS BROWSING ENABLED
trilio-s3-target ObjectStore 10Gi Other Available
次に、TrilioVaultは、S3バケットの検証（可用性、権限など）を担当するtrilio-s3-target-validatorという名前のワーカージョブを生成します。ジョブが正常に完了すると、バケットは健全または利用可能と見なされ、trilio-s3-target-validatorジョブリソースはその後削除されます。何か問題が発生した場合、S3ターゲットバリデータージョブは動作し続け、ログを検査して可能な問題を見つけることができます。
次に、以前に作成したターゲットリソースが健全かどうかを確認してください：
# 出力は次のようになります：
...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
mount_s3_datastore(metadata_list, base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
wait_until_mount(base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...
#trilio-s3-target-validator-tio99a-6lz4q 1/1 Running 0 104s
# そして、ログデータを取得します
次に、次の例外が発生します：
その後、バックアップとリストア操作を容易に管理するのに役立つTVKウェブコンソールを見つけます。
ステップ3 – TVK Web管理コンソールの理解
バックアップとリストア操作は、完全にkubectlとCRDを介してCLIから管理できますが、TVKはGUIを介して同じ操作を実行するためのWeb管理コンソールを提供します。管理コンソールは、ポイントアンドクリック操作を介して一般的なタスクを簡素化し、TVKクラスタオブジェクトのより良い可視化と検査を提供し、災害復旧計画（DRP）を作成するのに役立ちます。
ステップ1 – Kubernetes用TrilioVaultのインストールでカバーされたHelmベースのインストールは、ウェブ管理コンソールの必要なコンポーネントのインストールをすでに処理しました。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
k8s-triliovault-admission-webhook ClusterIP 10.245.202.17 <none> 443/TCP 13m
k8s-triliovault-ingress-nginx-controller NodePort 10.245.192.140 <none> 80:32448/TCP,443:32588/TCP 13m
k8s-triliovault-ingress-nginx-controller-admission ClusterIP 10.3.20.89 <none> 443/TCP 13m
k8s-triliovault-web ClusterIP 10.245.214.13 <none> 80/TCP 13m
k8s-triliovault-web-backend ClusterIP 10.245.10.221 <none> 80/TCP 13m
triliovault-operator-k8s-triliovault-operator-webhook-service ClusterIP 10.245.186.59 <none> 443/TCP 16m
コンソールにアクセスし、提供されている機能を探索するには、TVKのイングレスコントローラーサービスをポートフォワードする必要があります。
出力は以下のようになります。 k8s-triliovault-ingress-nginx-controllerの行を検索し、PORT(S)列でポート80でリッスンしていることに注意してください。
127.0.0.1 tvk-doks.com
TVKは、トラフィックを管理WebコンソールサービスにルーティングするためにNginx Ingress Controllerを使用しています。ルーティングはホストベースであり、ホスト名はスターターキットのHelm値ファイルで定義されているtvk-doks.comです：
# TVKイングレスnginxコントローラーを介してWebコンソールにアクセスする際に使用するホスト名
最後に、DOKSクラスターのkubeconfigファイルをエクスポートします。この手順は、Webコンソールが認証できるようにするために必要です。
# 利用可能なクラスターをリストアップします
# クラスター構成をYAML形式で保存します
1つのクラスターしかない場合は、次のコマンドを実行します：
これらの手順に従った後、Webブラウザで以下に移動してコンソールにアクセスできます：http://tvk-doks.com:8080。 kubeconfig ファイルが求められた場合は、前述のコマンドで作成したものを選択してください。
生成された kubeconfig ファイルを安全な場所に保管してください。それには機密情報が含まれています。
- TVK Webコンソールのユーザーインターフェースを探索する
- 左側の各セクションを探索してください：
- クラスター管理： これは、主要なTVKインスタンスを持つプライマリとその他のクラスターのリストを表示します。これらは、マルチクラスター管理機能を使用してプライマリOVHクラスターに追加されています。
- バックアップ＆リカバリー： これは、Discovered namespaces、Applications、Backup plans list、Targets、Hooks、Policiesなど、クラスタ全体の概要を一般的に示すメインダッシュボードです。
モニタリング： これには、TrilioVaultモニタリング と Veleroモニタリング の2つのオプションがあります。ユーザーがOVHクラスタにVeleroを設定している場合。
ディザスタリカバリー： ディザスタリカバリー操作を管理および実行することができます。
ディザスタリカバリー： ディザスタリカバリー操作を管理および実行することができます。
また、トップのドロップダウンメニューから Backup＆Recovery -> Targets -> <Namespace> tvk に移動して、以前に作成したS3ターゲットを表示することもできます。
さらに進んで、ターゲットを閲覧し、利用可能なバックアップをリストするには、右側の アクション ボタンをクリックし、ポップアップメニューから ブラウザを起動 オプションを選択します。これを実行するには、ターゲットに enableBrowsing フラグが true に設定されている必要があります。
詳細な情報や利用可能な機能については、TVK Web Management Console User Interface の公式ドキュメントを参照してください。
次に、特定のユースケースのバックアップとリストア操作の実行方法について学びます。
このステップでは、DOKSクラスターから特定のネームスペース（この場合はambassador）の一回限りのバックアップを作成し、その後にそれを復元する方法を学びます。すべてのリソースが再作成されることを確認します。 TVKには、名前空間よりも高いレベルでバックアップを実行できる機能があります。
- アンバサダーHelmリリースのバックアップを作成する
- 名前空間（またはHelmリリース）単位で単一のアプリケーションのバックアップを実行するには、バックアッププランに続いてバックアップCRDが必要です。バックアッププランは、バックアッププロセスの「何」、「どこ」、「へ」、および「方法」を定義しますが、実際のバックアップを実行しません。バックアップCRDは、バックアッププラン仕様に従って実際のバックアッププロセスをトリガーします。
- この構成では、
A typical Backup CRD looks like below:
spec.backupConfig.target.name: TVKにバックアップを保存するためのターゲット名を指示します。
spec.backupConfig.target.namespace: TVKにターゲットが作成された名前空間を指示します。spec.backupComponents：バックアップするリソースのリストを定義します。
この構成では、
spec.type：バックアップタイプを指定します。
spec.backupPlan：このバックアップに使用するBackupPlanを指定します。
Ambassador Helmリリースのワンタイムバックアップを開始する手順：
まず、クラスターにAmbassador Edge Stackがデプロイされていることを確認します。これは、Ambassador Ingressチュートリアルの手順に従って行います。
次に、ローカルマシンにクローンされたStarter Kit Gitリポジトリが存在するディレクトリに移動します。
その後、お好みのエディターを使用して、Starter Kitリポジトリで提供されているAmbassador BackupPlanおよびBackupマニフェストファイルを開き、検査します（可能であればYAML lintサポートがあるエディターを使用してください）。
NAME TARGET ... STATUS
ambassador-helm-release-backup-plan trilio-s3-target ... Available
最後に、kubectlを使用してBackupPlanおよびBackupリソースを作成します。
次に、kubectlを使用してBackupPlanのステータスを検査します（ambassador Helmリリースを対象とします）：
NAME BACKUPPLAN BACKUP TYPE STATUS ...
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full InProgress ...
出力は次のようになります。 STATUS列の値に注目してください。これはAvailableに設定されている必要があります。
次に、kubectlを使用してBackupオブジェクトのステータスを確認します：
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full Available ... 100
出力は次のようになります。 STATUS列の値に注目してください。これはInProgressに設定されている必要があります。また、BACKUP TYPEがFullに設定されていることにも注意してください。
すべての大使のヘルムリリースコンポーネントがS3ターゲットにアップロードされた後、これらの結果を取得する必要があります:
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04 311 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04 302 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04 305 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04 330 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...
# 出力は次のように見えます（`STATUS`が`Available`に変更され、`PERCENTAGE`が`100`になることに注意してください）
このように出力が見える場合、大使のambassadorヘルムリリースのバックアップが正常に完了しました。TrilioVaultがKubernetesメタデータをどのように保存するかを確認するために、TrilioVault S3バケットのコンテンツをリストアップできます。たとえば、s3cmdを使用できます：
ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx 1/1 Running 0 4m32s
出力は次のようになります。リストにはKubernetesオブジェクトを表すJSONマニフェストとUIDが含まれていることに注意してください。
バックアップが利用可能にならない場合は、metamoverポッドからログを調査して問題を見つけることができます：
...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...
出力は次のように見えます:
さて、ログデータを取得します:
出力は次のようになります。
最後に、Webコンソールでもバックアップが利用可能であることを確認できます。これは、リソース管理 -> 大使 -> バックアッププランに移動して確認できます。`Available`の状態であり、大使のHelmリリースがコンポーネントの詳細サブビューでバックアップされていることに注意してください。
今、ambassador Helm リリースを意図的に削除して、災害をシミュレートしてください。
次に、名前空間リソースが削除されたことを確認します（リストは空になるはずです）：
- 最後に、
echoおよびquoteバックエンドサービスのエンドポイントがDOWNであることを確認してください。Starter Kit チュートリアルで使用されているバックエンドアプリケーションに関するAmbassador Edge Stack Backend Servicesを作成するに関して参照してください。テストにはcurlを使用できます（またはウェブブラウザを使用できます）： - Ambassador Helm リリースのバックアップを復元する
- 重要
同じ名前空間を復元する場合は、元のアプリケーションコンポーネントが削除されていることを確認してください。特に、アプリケーションの PVC が削除されていることを確認してください。
別のクラスターに復元する場合（移行シナリオ）は、TrilioVault for Kubernetesがリモートのネームスペース/クラスターでも実行されていることを確認してください。新しいクラスターに復元する場合（バックアップ CR が存在しない場合）、source.typeをlocationに設定する必要があります。復元に関する詳細は、カスタムリソース定義の復元セクションを参照して、場所での復元の例をご覧ください。
-
ambassadorネームスペースを削除すると、ambassadorサービスに関連するロードバランサーリソースも削除されます。そのため、ambassadorサービスを復元すると、DigitalOceanによってLBが再作成されます。問題は、LBの新しいIPアドレスが取得されるため、クラスター上のドメインにトラフィックを取得するためにAレコードを調整する必要があることです。 - 特定のバックアップを復元するには、
RestoreCRDを作成する必要があります。典型的な復元 CRD は次のようになります： - この構成では、
spec.source.type: 復元元のバックアップタイプを指定します。
spec.source.backup: 復元元のバックアップオブジェクトへの参照を含みます。
spec.skipIfAlreadyExists: 復元されるネームスペースにリソースがすでに存在する場合に復元をスキップするかどうかを指定します。
Restoreは、アプリケーションの最後に成功したバックアップを復元することができます。これは、Backup CRDで保護された単一の名前空間またはHelmリリースを復元するために使用されます。 Backup CRDは、その名前ambassador-helm-release-full-backupで識別されます。
まず、Starter Kit GitリポジトリからRestore CRDの例を検査します：
NAME STATUS DATA SIZE START TIME END TIME PERCENTAGE COMPLETED DURATION
ambassador-helm-release-restore Completed 0 2021-11-25T15:06:52Z 2021-11-25T15:07:35Z 100 43.524191306s
次に、kubectlを使用してRestoreリソースを作成します：
最後に、Restoreオブジェクトのステータスを検査します：
出力は次のように似ています。 STATUS列がCompletedに設定されており、PERCENTAGE COMPLETEDが100に設定されていることに注意してください。
このように出力が見える場合、ambassador Helmリリースの復元プロセスが正常に完了しています。
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-42wzr 1/1 Running 0 9m58s
pod/ambassador-5bdc64f9f6-nrkzd 1/1 Running 0 9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv 1/1 Running 0 9m58s
pod/ambassador-redis-64b7c668b9-69drs 1/1 Running 0 9m58s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.173.90 157.245.23.93 80:30304/TCP,443:30577/TCP 9m59s
service/ambassador-admin ClusterIP 10.245.217.211 <none> 8877/TCP,8005/TCP 9m59s
service/ambassador-redis ClusterIP 10.245.77.142 <none> 6379/TCP 9m59s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 9m59s
deployment.apps/ambassador-agent 1/1 1 1 9m59s
deployment.apps/ambassador-redis 1/1 1 1 9m59s
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 9m59s
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 9m59s
ambassador名前空間リソースがすべて正常に配置され、実行されていることを確認します：
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
出力は次のように似ています：
ambassadorホストを取得します：
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
出力は次のように似ています。 STATEはReadyになっており、HOSTNAME列が完全修飾ホスト名を指している必要があります。
ambassadorマッピングを取得します：
出力は次のようになります。 echo-backend にマップされる echo.starter-kit.online ホストと /echo/ ソースプレフィックスに注意してください。同様に quote-backend にも適用されます。
今度は、DigitalOcean ロードバランサーリソースが再作成され、新しい外部 IP が割り当てられたため、DNS A レコード を更新する必要があります。
最後に、バックエンドアプリケーションが HTTP リクエストに応答するかどうかを確認してください。Starter Kit チュートリアルで使用されるバックエンドアプリケーションに関する詳細については、Creating the Ambassador Edge Stack Backend Services を参照してください。
次のステップは、クラスタ全体のバックアップと復元に関するものです。
A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:
このステップでは、災害復旧シナリオをシミュレートします。DOKS クラスタ全体が削除され、次に重要なアプリケーションが以前のバックアップから復元されます。
ここでの主なアイデアは、重要なアプリケーションと設定を保持するすべての重要な名前空間を含めて、DOKSクラスタのバックアップを実行することです。
kube-system（またはその他のDOKSクラスタ関連の名前空間）がリストに含まれていないことに注意してください。通常、それらは必要ありませんが、そのレベルでいくつかの設定を永続化する必要がある特別なケースがある場合を除きます。
まず、ローカルマシンにクローンされたStarter Kit Gitリポジトリのディレクトリを変更します：
次に、お好みのエディタ（できればYAML lintサポート付き）を使用して、Starter Kitリポジトリで提供されているClusterBackupPlanとClusterBackupのマニフェストファイルを開いて検査します。
NAME TARGET ... STATUS
starter-kit-cluster-backup-plan trilio-s3-target ... Available
最後に、kubectlを使用してClusterBackupPlanとClusterBackupリソースを作成します：
次に、kubectlを使用してClusterBackupPlanのステータスを検査します：
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE COMPLETE
starter-kit-cluster-backup starter-kit-cluster-backup-plan Full Available ... 100
以下のように出力が似ていることに注意してください。 STATUS列の値がAvailableに設定されているはずです。
次に、kubectlを使用してClusterBackupのステータスを確認します：
以下のように出力が似ていることに注意してください。 STATUS列の値がAvailableに設定されているはずです。また、PERCENTAGE COMPLETEが100に設定されていることにも注意してください。
出力が上記のように見える場合、すべての重要なアプリケーション名前空間が正常にバックアップされました。
プロセスに関与する名前空間と関連するリソースの数に応じて、完全なクラスタバックアップが完了するまでには時間がかかる場合があります。
メインダッシュボードのウェブコンソールを開き、マルチネームスペースバックアップを調査します（バックアップされたすべての重要なネームスペースが緑色で強調表示されており、ハニカム構造になっています）：
覚えておくべき重要なポイントは、DOKSクラスターを破棄してから復元するたびに、TVKがイングレスコントローラーを復元する際に新しい外部IPを持つ新しいロードバランサーも作成されることです。したがって、DigitalOcean DNSのAレコードを適切に更新してください。
今、DOKSクラスター全体を削除します（<>プレースホルダーを適切に置き換えてください）：
次に、DigitalOcean Kubernetesのセットアップで説明されているように、クラスターを再作成します。
復元操作を実行するには、Step 1 – TrilioVault for Kubernetesのインストールに記載されているように、TVKアプリケーションをインストールする必要があります。 同じHelm Chartバージョンを使用することが重要です。
インストールが成功したら、バックアップデータがある同じ S3 バケットを指すように、ステップ 2 – バックアップを格納する TrilioVault ターゲットの作成 に記載されているように、TVK ターゲットを設定してください。また、ターゲットブラウジング が有効になっていることを確認してください。
次に、TrilioVault アプリケーションのライセンスセクションに記載されているように、新しいライセンスを確認してアクティブ化してください。
Web コンソールのユーザーインターフェースにアクセスするには、TVK Web マネージメントコンソールへのアクセスの取得セクションを参照してください。
次に、リソース管理 -> TVK 名前空間 -> ターゲット（Starter Kit の場合、TVK 名前空間はtvkです）に移動します。
さらに進んで、ターゲットを参照し、アクションボタンをクリックして利用可能なバックアップのリストを表示します。その後、ポップアップメニューからブラウザを起動オプションを選択します。これを実行するには、ターゲットに enableBrowsing フラグが true に設定されている必要があります。
次に、リストからstarter-kit-cluster-backup-planアイテムをクリックし、右側のサブウィンドウからstarter-kit-cluster-backupアイテムをクリックして展開します。
リストアプロセスを開始するには、リストアボタンをクリックします。
まず、すべてのクラスター Kubernetes リソースを確認してください。
次に、DNS の A レコードが更新され、新しいロードバランサーの外部 IP を指すようにしてください。
最後に、バックエンドアプリケーションは HTTP リクエストに応答する必要があります。Starter Kit チュートリアルで使用されるバックエンドアプリケーションに関する詳細は、Ambassador Edge Stack バックエンドサービスの作成を参照してください。
次のステップでは、DOKS クラスターアプリケーションの定期的（または自動）バックアップの実行方法について説明します。
スケジュールに基づいて自動的にバックアップを取ることは非常に便利な機能です。何か問題が発生した場合、以前の動作状態にシステムを巻き戻すことができます。このセクションでは、5分間隔で自動バックアップを行う例を提供します（kube-system 名前空間が選択されました）。
まず、ScheduleタイプのPolicy CRDを作成する必要があります。このCRDは、Linux cronと同じ形式のcron形式でバックアップスケジュールを定義します。スケジュールポリシーは、BackupPlanまたはClusterBackupPlan CRDのどちらかに使用できます。典型的なスケジュールポリシーCRDは以下のようになります（5分のスケジュールを定義）：
# 5分ごとにトリガー
次に、以下のようにClusterBackupPlan CRDにスケジューリングポリシーを適用できます：
これは基本的なClusterBackupPlan CRDであり、spec.backupConfig.schedulePolicyフィールドを介して前述のPolicy CRDを参照しています。spec内にfullBackupPolicyまたはincrementalBackupPolicyを指定することができます。
今、Starter Kitチュートリアルで提供されているサンプルマニフェストを使用して、スケジュールPolicyを作成してください。
NAME POLICY DEFAULT
scheduled-backup-every-5min Schedule false
Starter Kit Gitリポジトリがローカルマシンにクローンされたディレクトリに移動してください。
最後に、kube-system名前空間のスケジュールされたバックアップのリソースを作成します：
# まずkube-system名前空間のバックアッププランを作成します
NAME TARGET ... FULL BACKUP POLICY STATUS
kube-system-ns-backup-plan-5min-schedule trilio-s3-target ... scheduled-backup-every-5min Available
# kube-system名前空間のスケジュールされたバックアップを作成してトリガーします
kube-systemの予定されたバックアップ計画の状態を確認します：
NAME BACKUPPLAN BACKUP TYPE STATUS ...
kube-system-ns-full-backup-scheduled kube-system-ns-backup-plan-5min-schedule Full Available ...
出力は次のようになります。以前に作成されたscheduled-backup-every-5minポリシー リソースに設定されたFULL BACKUP POLICYの値に注意してください。また、STATUSはAvailableである必要があります。
kube-systemの予定されたバックアップの状態を確認します：
出力は次のようになります。以前に作成されたバックアップ プラン リソースに設定されたBACKUPPLANの値に注意してください。また、STATUSはAvailableである必要があります。
今、クラスタ バックアップ リソースをクエリして、START TIME列（kubectl get clusterbackup -n tvk）を調べることで、定期的な間隔（5分）でバックアップが実行されていることを確認できます。以下の画像で強調されているように、それは5分の差を反映するはずです：
次のステップでは、バックアップの保持ポリシーの設定方法を学びます。
保持ポリシーを使用すると、コンプライアンス要件に従ってバックアップを保持する数と削除するタイミングを定義できます。保持ポリシー CRD は、日数、週数、月数、年数、最新などの形式で保持するバックアップの数を
- 保持ポリシーの使用
- 保持ポリシーは、
BackupPlanまたはClusterBackupPlanCRDに使用できます。Retentionタイプの典型的なPolicyマニフェストは次のようになります： - 上記の保持ポリシーは次のように変換されます：
- 毎週、水曜日に1つのバックアップを保持します。
毎月、15日に1つのバックアップを保持します。
A typical ClusterBackupPlan example configuration that has a retention set looks like:
毎年、3月ごとに1つのバックアップを保持します。
全体として、最新のバックアップが2つ利用可能である必要があります。
保持ポリシーのリソースを作成する基本的な手順は、スケジュールされたバックアップと同じです。 保持ポリシーを参照するためには、BackupPlanまたはClusterBackupPlanCRDを定義し、次にプロセスをトリガーするBackupまたはClusterBackupオブジェクトが必要です。
使用されるretentionPolicyフィールドが、問題のポリシーを参照していることに注意してください。 もちろん、スケジュールされたバックアップを実行し、保持戦略を処理するための両方のタイプのポリシーが設定されているバックアッププランを持っていることができます。
クリーンアップポリシーの使用
使われなくなったすべてのオブジェクトをガベージコレクトする方法が必要です。そのために、Cleanup Policy CRDを導入する必要があります：
上記のクリーンアップポリシーは、TVKインストールの名前空間に定義する必要があります。その後、specフィールド内で指定された値に基づいて、30分ごとに実行され、失敗したバックアップを削除するためのクロンジョブが自動的に作成されます。
結論
- このチュートリアルでは、一度限りのバックアップと定期的なバックアップの実行方法、およびすべてを復元する方法について学びました。
- このチュートリアルで説明されている基本的なタスクと操作は、TrilioVault for Kubernetesの機能を基本的に紹介し、理解するためのものです。
- さらに学ぶ