TrilioVaultを使用して、Kubernetesクラスタのバックアップと復元方法

“Kubernetesクラスターのバックアップと復元方法- TrilioVault for Kubernetesを使用する方法”

筆者は、Write for Donationsプログラムの一環として寄付先としてDiversity in Tech Fundを選びました。

はじめに

Kubernetes用のTrilioVault(TVK)は、アプリケーションのメタデータとデータをクラウドネイティブな方法で保護し、オンデマンドでバックアップを独立したストレージリポジトリに保存するソリューションです。

Trilioを利用することにはいくつかの利点があります。Trilioを使えば、クラスターのフルバックアップやインクリメンタルバックアップを取得し、データ損失の場合にはそれらを復元することができます。また、一つのクラスターから別のクラスターに移行することや、バックアップや復元操作の前後にプレフックやポストフックを実行することも可能です。バックアップのスケジュール設定や保持ポリシーの定義も行えます。最後に、ウェブ管理コンソールを使用して、バックアップと復元操作の状態を詳細に確認することもできます(その他多くの機能もあります)。

この記事では、TVKを使用してローカルのKubernetesクラスターデプロイメントまたはSilicon Cloud Kubernetesサービスを保護する方法についての手順を提供します。これには、クラスターにデプロイされている状態を持つまたは持たないアプリケーションも含まれます。このチュートリアルでは、KubernetesクラスターにTVKをデプロイし、クラスターバックアップを作成し、そのバックアップから復元する方法を説明します。

もしマネージドKubernetesホスティングサービスを探しているなら、成長に向けて作られた簡単なマネージドKubernetesサービスをぜひチェックしてください。

前提条件

このチュートリアルを完了するためには、以下が必要です:

  • A Silicon Cloud account. If you do not have one, sign up for a new account.
  • A Silicon Cloud Kubernetes cluster with multiple namespaces. You can create a cluster by following our documentation on How To Create Clusters.
  • Doctl for Silicon Cloud API interaction. To get started, see our guide on How To Install and Configure doctl.
  • Kubectl for Kubernetes interaction. For installation and set up, see the Kubernetes product documentation for Install Tools.
  • A Silicon Cloud Spaces bucket or any S3-compatible object storage bucket with its access keys. To use a Silicon Cloud Spaces bucket, follow our guides on How to Create Spaces and How to Manage Administrative Access with access keys. Save the access and secret keys in a safe place for later use. You can also use NFS export to store the backup.
  • Helm for managing TrilioVault Operator releases and upgrades. For installation, see Step 1 of our tutorial, How To Install Software on Kubernetes Clusters with the Helm 3 Package Manager.
  • A TrilioVault license saved as a yaml file. This tutorial uses Cluster-scoped installation, which you may need to select when fetching the license. For Silicon Cloud users, the TVK installation is free for five years. If you are not using a Silicon Cloud Kubernetes cluster, you will need to enroll on the Trilio website to request a TVK license. There are free trials and a free basic version available.

ステップ1 — Kubernetesクラスタの設定

このステップでは、TrilioVaultが正しく機能するために、Kubernetesクラスタの構成を確認します。

TrilioVaultが正常に動作し、PersistentVolumeClaim(PVC)をバックアップするためには、KubernetesクラスターがContainer Storage Interface(CSI)をサポートするように設定されている必要があります。デフォルトでは、Silicon CloudのManaged Kubernetes Serviceには、CSIドライバが既にインストールおよび設定されています。以下のコマンドを使用して確認できます。

  1. kubectl get storageclass

 

以下のように日本語で自然なパラフレーズを提供いたします(ただし、1つのオプションのみ):
出力はこのように見えるはずです。

Output

NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE do-block-storage (default) dobs.csi.digitalocean.com Delete Immediate true 1d

ご覧の通り、プロビジョナーはdobs.csi.digitalocean.comです。

TrilioVaultのインストールには、volumeSnapshotカスタムリソース定義(CRD)も必要です。以下のコマンドを使用して、これが正常にインストールされているかを確認できます。

  1. kubectl get crd | grep volumesnapshot

 

もしも volumeSnapshot がすでにインストールされている場合、出力は次のようになります。

Output

volumesnapshotclasses.snapshot.storage.k8s.io2022-03-02T07:24:23Z volumesnapshotcontents.snapshot.storage.k8s.io2022-03-02T07:24:23Z volumesnapshots.snapshot.storage.k8s.io2022-03-02T07:24:23Z |

もしもVolumeSnapshotがまだインストールされていない場合は、VolumeSnapshot CRDsのインストールに関するドキュメントを参照してください。

最後に、v1 APIバージョンをサポートしているかCRDが確認できるようにしてください。以下のコマンドを実行することで確認できます。

  1. kubectl get crd volumesnapshots.snapshot.storage.k8s.io -o yaml

 

CRDのYAML出力の最後には、v1の値を含むstoredVersionsリストが表示されるはずです。

Output

… – 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:v1

もしインストールされていない場合は、「VolumeSnapshot CRDsのインストールに関するドキュメント」を参照してください。

次のステップで行うTrilioVaultのインストールに先立ち、このステップではKubernetesの設定が準備されていることを確認します。

ステップ2 — Kubernetes用の TrilioVault をインストールする

この手順では、ローカルのKubernetesクラスターにTrilioVaultを展開し、Helmを使用してTVKのインストールを管理します。バックアップデータは、前提条件として作成したS3互換のバケットに保存されます。

以下は日本語での一つのオプションです:

「TrilioVaultアプリケーションは、Kubernetesクラスターの配布方法に応じて複数の方法でインストールすることができます。このチュートリアルでは、triliovault-operatorチャートを介してHelmを使用してTrilioVaultをインストールします。」

このチュートリアルでは、「tvk」アプリケーションのCluster-scopedインストールタイプを使用します。このタイプのインストールでは、TVKはすべてのネームスペースをまたいでアプリケーションを保護できます。(一方、Namespace-scopedインストールでは、そのネームスペースに展開されたアプリケーションのみを保護できます。)

TrilioVault for Kubernetesをインストールするには、前提条件としてライセンスが必要です。TVKのライセンスを取得する際には、クラスタースコープのインストールを選択する必要があるかもしれません。

Helmを使用して、TrilioVaultをインストールします。

TrilioVaultをHelmでインストールするには、まずTrilioVault Helmリポジトリを追加し、以下のコマンドを使用して利用可能なチャートをリストします。

  1. helm repo add triliovault-operator http://charts.k8strilio.net/trilio-stable/k8s-triliovault-operator
  2. helm repo update triliovault-operator
  3. helm search repo triliovault-operator

 

出力は以下のように似ています。

Output

NAME CHART VERSION APP VERSION DESCRIPTION triliovault-operator/k8s-triliovault-operator 2.10.3 2.10.3 K8s-TrilioVault-Operator is an operator designe…

最後に、helmを使用してKubernetesにTrilioVaultをインストールしてください。

  1. helm install triliovault-operator triliovault-operator/k8s-triliovault-operator \
  2. –namespace tvk \
  3. –set installTVK.ingressConfig.host=“demo-tutorial.tvk-doks.com” \
  4. –create-namespace

 

このコマンドは、TrilioVault Helm valuesファイルで提供されるデフォルトのパラメータを使用して、triliovault-operatorとTriloVault Manager(TVM)カスタムリソースをインストールします。

  • TVK Operator: TVK has a Helm-based Operator, which is managed by a CRD called TrilioVault Manager. The TVK Operator takes care of the lifecycle of the application and auto-recovery in case one of the application components goes down.
  • TVK Manager: The TVK application contains several CRDs and their controllers. It has its own webhook server that manages the validation and mutation of its CRD instances. Controllers reconcile the events generated by the operations done on the Custom Resources.

このチュートリアルでは、TrilioVault Helm値ファイル(triliovault-values.yaml)のデフォルト値を使用します。以下のものを含みます。

  • installTVK.applicationScope: The scope for the TVK installation can be Cluster or Namespaced. This parameter protects applications either across the ‘Cluster’ or ‘Namespace’, and the TVK license is also generated based on the installation scope. This tutorial uses Cluster-scoped installation.
  • installTVK.ingressConfig.host: The domain name for the TVK UI hostname, which is demo-tutorial.tvk-doks.com. Users will access the TVK Management Console through this domain name.
  • installTVK.ComponentConfiguration.ingressController.service.type: The service type to access the TVK UI, such as NodePort or LoadBalancer.

Note

注意:利用可能なすべてのオプションを確認するには、TrilioVault Helm valuesファイルを調査してください。詳細については、TVKドキュメンテーションの設定オプションをご確認ください。

テレビケイディーの展開を確認するために、以下のコマンドを実行してください。

  1. helm ls -n tvk

 

このコマンドは、追加したHelmリポジトリを一覧表示します。

Output

NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION triliovault-manager-tvk tvk 1 2022-08-18 08:19:50.409742366 +0000 UTC deployed k8s-triliovault-2.10.3 2.10.3 triliovault-operator tvk 1 2022-08-18 08:15:51.618651231 +0000 UTC deployed k8s-triliovault-operator-2.10.3 2.10.3

STATUS 列は、デプロイ済みを表示する必要があります。

次に、TrilioVaultが起動していることを確認してください。以下のコマンドを実行して、tvkのインストール状態を表示します。

  1. kubectl get deployments -n tvk

 

このコマンドは、tvkネームスペース内のデプロイメントを表示します。

出力は次のように見えるでしょう。

Output

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カラムには、ready/desiredのパターンに従って利用可能な展開数が表示されます。全ての展開ポッドはREADYの状態であり、これはtvkが正常にインストールされたことを意味します。次に、TrilioVaultのライセンスタイプと有効性を確認します。

トリリオボールトアプリケーションのライセンスを確認しています。

前提条件の一環として、クラスター範囲のインストールタイプにTrilioVaultのライセンスを要求し、それをyamlファイルとして保存しました。このセクションでは、TrilioVaultのライセンスを適用し、そのステータスを確認し、フィールドを検査します。

前提として、Trilioのウェブサイトから無料のライセンスをダウンロードし、yamlファイルとして保存しました。今、以下のコマンドを使用してそれを適用してください。

  1. kubectl apply -f your_license_filename.yaml -n tvk

 

次に、クラスタにライセンスがインストールされ、アクティブな状態になっているかどうかを確認してください。

  1. kubectl get license -n tvk

 

出力は以下のように見えます。

Output

NAME STATUS MESSAGE CURRENT NODE COUNT GRACE PERIOD END TIME EDITION CAPACITY EXPIRATION TIME MAX NODES your_license Active Cluster License Activated successfully. 1 Basic 100 2023-04-25T00:00:00Z 1

「ステータス」を確認してください。それは「アクティブ」であるべきです。また、「エディション」の列にライセンスタイプを、そして「有効期限」の列にライセンスの期限を確認することもできます。

ライセンスは、ライセンスオブジェクトと呼ばれる特殊なCRDを介して管理されています。前の出力で示されているように、下記のコマンドを実行して、ハイライト部分をライセンス名で置き換えて検査することができます。

  1. kubectl describe license your_license -n tvk

 

出力は次のように見えますように思われる。

Output

Name: your_license Namespace: tvk Labels: <none> Annotations: generation: 4 triliovault.trilio.io/creator: trilio.user@trilio.io triliovault.trilio.io/instance-id: 1350188a-9289-49ba-9086-553e8cd7cabe triliovault.trilio.io/updater: [{“username”:”system:serviceaccount:tvk:k8s-triliovault”,”lastUpdatedTimestamp”:”2022-04-21T09:50:40.530365762Z”},{“username”:”0c9f7f19-c4… API Version: triliovault.trilio.io/v1 Kind: License Metadata: Creation Timestamp: 2022-04-06T08:07:16Z … Status: Condition: Message: Cluster License Activated successfully. Status: Active Timestamp: 2022-04-06T08:07:17Z Current CPU Count: 6 Max CP Us: 6 Message: Cluster License Activated successfully. Properties: Active: true Capacity: 100 Company: TRILIO-KUBERNETES-LICENSE-GEN-BASIC Creation Timestamp: 2022-04-21T00:00:00Z Edition: Basic Expiration Timestamp: 2027-04-25T00:00:00Z Kube UID: 1350188a-9289-49ba-9086-553e8cd7cabe License ID: TVAULT-7f70e73e-c158-11ec-990f-0cc47a9fd48e Maintenance Expiry Timestamp: 2027-04-25T00:00:00Z Number Of Users: -1 Purchase Timestamp: 2022-04-21T00:00:00Z Scope: Cluster

メッセージと容量フィールド、そしてエディションを確認してください。

上記の出力には、有効期限タイムスタンプフィールドでライセンスの期限が示されます。また、スコープ(この場合はクラスタベース)も示します。詳細は、TrilioVault for Kubernetesのライセンスドキュメントページで確認できます。

このステップでは、TVKのライセンスを申請し、その状態を確認しました。次に、TVKのウェブコンソールを使用して、ターゲットやバックアップ、復元などを管理する手順を探索します。

ステップ3- TVK管理コンソールへのアクセス

このステップでは、TVK管理コンソールにアクセスします。ここでは、GUIを使用してターゲットを作成したり、バックアップや復元などの操作を管理したりすることができます。kubectlやCRDsを使用してCLIから操作を管理することもできますが、TVK管理コンソールはクリック操作による一般的なタスクの簡素化や、TVKクラスタオブジェクトの視覚化と検査がより優れています。

以前の「Helmを使用してTrilioVaultをインストールする」セクションで、Web管理コンソールに必要なコンポーネントをインストールして設定しました。コンソールにアクセスし、提供される機能を探索するために、Kubernetesクラスタのkubeconfigファイルをエクスポートし、TVKのイングレスコントローラーサービスにポートフォワードします。

最初に、Kubernetesクラスターのためにkubeconfigファイルをエクスポートしてください。この手順は、Webコンソールがあなたを認証するために必要です。

デジタルオーシャンのKubernetesサービスを利用している場合、kubeconfigファイルをエクスポートするために以下の手順に従うことができます。

利用可能なクラスタの一覧を表示してください。

  1. doctl k8s cluster list

 

クラスタの設定をYAML形式で保存し、ハイライトされた値をクラスタの名前で置き換えてください。

  1. doctl kubernetes cluster kubeconfig show YOUR_CLUSTER_NAME_ > config_YOUR_CLUSTER_NAME_.yaml

 

Note

注意:クラスタが1つしかない場合、以下のコマンドを使用できます:
DOKS_CLUSTER_NAME=”$(doctl k8s cluster list –no-header –format Name)”
doctl kubernetes cluster kubeconfig show $DOKS_CLUSTER_NAME > config_${DOKS_CLUSTER_NAME}.yaml

生成されたkubeconfigファイルには、クラスタにアクセスするために使用されるトークンやユーザーの詳細など、機密データが含まれているため、必ず安全な場所に保管してください。ファイルを非公開の場所に保存し、パスワード管理アプリケーションや暗号化形式を使用することも検討してください。

認証のためのkubeconfigファイルを取得したので、ポートフォワードを設定して管理コンソールにアクセスします。

最初に、tvkネームスペースのingress-nginx-controllerサービスを特定してください。tvkネームスペースのサービスをリストするために、以下のコマンドを実行することでこれを行うことができます。

  1. kubectl get svc -n tvk

 

出力は次のように見える。

出力は以下のような外観をしている。

出力の外観は次のようになっています。

出力は以下のように似ています。

Output

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

k8s-triliovault-ingress-nginx-controllerの行を検索し、PORT(s)の列でポート80でのリスニングを確認してください。

TrilioVault Ingressサービスは、NodePortまたはLoadBalancerで構成することができます。これは、TYPE列で確認できます。NodePortに設定されている場合、ドメインがアクセス可能であることを確認する必要があります。TVK管理コンソールへのアクセスにNodePortを使用している場合、TrilioVault Ingressサービスは、TVKコンソールへのアクセスに使用されるドメイン名を解決しない限り、外部ネットワークに直接接続することができません。この問題を解決するために、etc/hostsファイルにIPアドレスとドメイン名のエントリを追加し、ドメイン名をIPに解決します。

これを行うには、編集用に/etc/hostsファイルを開き、このエントリを追加してください。

/etc/hosts
ホストファイル
127.0.0.1 demo-tutorial.tvk-doks.com

demo-tutorial.tvk-doks.comはTrilioVaultイングレスコントローラーサービスのドメイン名です。このドメインを使用して、TVK管理コンソールにアクセスします。

ファイルを保存して閉じる。

次に、TVKイングレスコントローラーサービスのポートフォワードを作成してください。

  1. kubectl port-forward svc/k8s-triliovault-ingress-nginx-controller 8080:80 -n tvk &

 

次のように日本語で言い換えます:
「http://demo-tutorial.tvk-doks.com:8080」にアクセスすることで、ウェブブラウザからコンソールにアクセスできます。kubeconfigファイルが要求された場合は、このセクションで作成したものを選択してください。」

Note

注意:TVKは、kubeconfigファイルを使用して認証用トークンを生成します。kubeconfigファイル内に格納されているユーザーの詳細は保存されません。

この手順では、TVK管理コンソールへのアクセスを設定します。コンソールの利用可能な機能についての詳細は、TVK Web管理コンソールの公式ドキュメンテーションをご覧ください。

次のステップでは、TrilioVaultのストレージバックエンドであるターゲットを定義します。

ステップ4 — バックアップを保存するためのTrilioVaultターゲットの作成

TrilioVaultは、バックアップを保存する場所であるターゲットを知る必要があります。サポートされているターゲットの種類は次のとおりです:S3およびNFS。このチュートリアルでは、S3ストレージタイプを使用します。詳細は、TVKドキュメンテーションのバックアップターゲットセクションで利用できます。

S3ストレージにアクセスするためには、各ターゲットがバケットの認証情報を知る必要があります。これらの認証情報はシークレットに格納されています。このステップでは、バックアップ用のTrilioVaultターゲットと、バケットの認証情報を格納するためのシークレットを作成します。

最初に、目的のS3バケットの認証情報が含まれたKubernetesシークレットを作成します。nanoまたはお気に入りのテキストエディタを使用して、”trilio-s3-target-secret”というファイルを作成し、以下のコードを追加します。Silicon Cloud Spacesのアクセスキーとシークレットキーの部分を自分のものに置き換えることを確認してください。

トリリオのS3ターゲットシークレット.yaml
apiVersion: v1
kind: Secret
metadata:
  name: trilio-s3-target-secret
  namespace: tvk
type: Opaque
stringData:
  accessKey: your_bucket_access_key
  secretKey: your_bucket_secret_key

秘密の名前はtrilio-s3-target-secretです。これは、次に作成するターゲットマニフェストのspec.objectStoreCredentials.credentialSecretフィールドで参照されます。このシークレットは、TrilioVaultがインストールされている同じネームスペース(デフォルトはtvk)または任意の他のネームスペースに配置することができます。(使用するネームスペースが正しく参照されることを確認してください。)

ファイルを保存して閉じる。

このマニフェストを適用してシークレットを作成するために、以下のコマンドを実行してください。

  1. kubectl apply -f trilio-s3-target-secret.yaml -n tvk

 

Note

注:または、次のコマンドを実行して、プレースホルダの値をDigitaOceanバケットのアクセスキーとシークレットキーに置き換え、シークレットを作成することもできます。

kubectl create secret generic trilio-s3-target-secret \
–namespace=tvk \
–from-literal=accessKey=”あなたのバケットのアクセスキー” \
–from-literal=secretKey=”あなたのバケットのシークレットキー”

あなたの出力はこのようになります。

Output

secret/trilio-s3-target-secret created

次に、ターゲット用のマニフェストを作成します。trilio-s3-target.yamlという新しいファイルを作成し、以下のコードブロックを追加してください。bucketName、region、およびurlのハイライトされた値を、Silicon Cloudバケットに関する情報で置き換えてください。これらの情報は、バケットのコントロールパネルで見つけることができます。

トリリオ-S3ターゲット.yaml
apiVersion: triliovault.trilio.io/v1
kind: Target
metadata:
  name: trilio-s3-target
  namespace: tvk
spec:
  type: ObjectStore
  vendor: Other
  enableBrowsing: true
  objectStoreCredentials:
    bucketName: your_bucket_name
    region: your_bucket_region           # e.g.: nyc1 or us-east-1
    url: https://nyc1.digitaloceanspaces.com      # update the region to match your bucket
    credentialSecret:
      name: trilio-s3-target-secret
      namespace: tvk
  thresholdCapacity: 10Gi

上記の構成について説明いたします。

  • spec.type: Type of target for backup storage (S3 is ObjectStore).
  • spec.vendor: Third-party storage vendor hosting the target (for Silicon Cloud Spaces, you’ll need to use Other).
  • spec.enableBrowsing: Enable browsing for the target.
  • spec.objectStoreCredentials: Defines required credentials (via credentialSecret) to access the S3 storage, as well as other parameters such as bucket region and name.
  • spec.thresholdCapacity: Maximum threshold capacity to store backup data.

以下の点に注意してください。credentialSecretの名前が、さきほど作成したシークレットと一致していることを確認してください。

保存してマニフェストファイルを閉じる。

今、kubectlを使用してターゲットオブジェクトを作成してください。

  1. kubectl apply -f trilio-s3-target.yaml -n tvk

 

あなたの出力はこのようになります。

Output

target.triliovault.trilio.io/trilio-s3-target created

TrilioVaultは、S3バケット(可用性、権限など)を検証するための「trilio-s3-target-validator」というワーカージョブを生成します。ジョブが成功裏に完了すると、バケットは正常または利用可能と見なされ、その後「trilio-s3-target-validator」ジョブリソースは削除されます。

早急に作成した対象リソースの状態を確認するため、以下のコマンドを実行し、対象の名前を渡してください。

  1. kubectl get target trilio-s3-target -n tvk

 

出力はこれに似たような形になります。

Output

NAME TYPE THRESHOLD CAPACITY VENDOR STATUS BROWSING ENABLED trilio-s3-target ObjectStore 10Gi Other Available true

STATUS列の値が利用可能であり、それは対象が健全な状態であることを意味しています。

テレビケーブル管理コンソールを使用して、対象の状態を検証することもできます。ログイン後、[バックアップとリカバリー]を選択し、[ターゲット]をクリックして表示してください。

Screencapture showing the list of targets

もし状態が”利用可能”と表示されている場合、S3のターゲットオブジェクトの設定が正常に完了しています。

ただし、設定に問題がある場合、ステータスは「利用できない」を示します。このような場合、S3ターゲットバリデータジョブは実行されたままであり、ログを調査して可能な問題を見つけることができます。ターゲットオブジェクトが正常にならない場合は、ログを調べるためにtrilio-s3-target-validator Podからログを確認できます。

ログを確認するためには、まずターゲットの検証者を見つけることから始めます。

  1. kubectl get pods -n tvk | grep trilio-s3-target-validator

 

出力はこのように見えますが、ユニークな識別子が付いたものになります。

Output

trilio-s3-target-validator-tio99a-6lz4q 1/1 Running 0 104s

前の出力結果からターゲットバリデータを使用し、次のコマンドを使ってデータログを取得してください。

  1. kubectl logs pod/trilio-s3-target-validator-tio99a-6lz4q -n tvk

 

出力は次のようになります(例として例外に注目してください):

Output

… 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. …

追加のデバッグ支援や、ターゲットの作成中に問題が発生した場合は、ドキュメントのトラブルシューティングセクションを確認するか、サポートに連絡してください。

このステップでは、TrilioVaultのターゲットを設定し、バケットの認証情報を提供するためのシークレットを作成しました。次に、バックアップとリストアの操作を行い、災害復旧シナリオをカバーします。

ステップ5 – Kubernetesクラスタのバックアップとリストア

このステップでは、Kubernetesクラスタのバックアップを実行します。その後、名前空間を削除し、バックアップを使用してすべての重要なアプリケーションをそれらの名前空間に復元します。クラスタの復元作業はターゲットからの場所を経由して行います。クラスタの移行を実行する場合も同様の手順が適用されます。

ここでの主なアイデアは、重要な名前空間(essential applications and configurationsを保持する)を含めることによって、完全なクラスタバックアップを実行することです。これは完全なクラスタバックアップやリストアではなく、むしろマルチネームスペースのバックアップとリストアの操作です。実際には、これが必要なのは、Kubernetesではすべてが名前空間で管理されているためです。

Kubernetesクラスターバックアップを作成する。

このセクションでは、Kubernetesクラスターからすべての重要な名前空間を対象としてClusterBackupPlan CRDを使用してマルチネームスペースのバックアップを作成します。

クラスタバックアップの操作を開始するには、ClusterBackupPlanを作成します。このプランには、バックアップスケジュール、バックアップ対象、およびバックアップするリソースが定義されています。リソースは、Helmリリース、オペレータ、または単なるKubernetes APIリソースの形で定義することができます。

テキストエディタを使用して、k8s-cluster-backup-plan.yamlという名前のClusterBackupPlanマニフェストファイルを作成してください。次に、複数の名前空間を対象とする典型的なマニフェストのコードブロックを以下に追加してください。

k8sクラスタのバックアップ計画.yaml
apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: k8s-cluster-backup-plan
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupComponents:
    - namespace: wordpress
    - namespace: mysqldb
    - namespace: etcd

バックアップコンポーネントにリストされている名前空間がクラスタ上に存在するか確認してください。

特別な設定の永続化が必要な場合を除き、通常はkube-system(または他のKubernetesクラスタ関連の名前空間)はbackupComponentsに含まれていないことに気づくかもしれません。

ファイルを保存して閉じる。

今、kubectlを使用してClusterBackupPlanリソースを作成してください。

  1. kubectl apply -f k8s-cluster-backup-plan.yaml

 

あなたの出力は、このようになります。

Output

clusterbackupplan.triliovault.trilio.io/k8s-cluster-backup-plan created

今、kubectlを使用してClusterBackupPlanのステータスを確認してください。

  1. kubectl get clusterbackupplan k8s-cluster-backup-plan -n tvk

 

出力はこれに似たようなものになります。

Output

NAME TARGET … STATUS k8s-cluster-backup-plan trilio-s3-target … Available

「STATUS」列の値を確認してください。値は「Available」に設定されている必要があります。

TVK Management Consoleを使用して、ClusterBackupPlanのステータスを確認することもできます。ログイン後、バックアップ&リカバリーを選択し、バックアップ計画を表示します。

Screencapture showing the status of the Cluster Backup Plan

この時点では、ClusterBackupPlanを作成しました。次に、実際のClusterBackupPlanを指す設定であるClusterBackupを作成します。ClusterBackupPlanは常に同じままであり、複数のバックアップを複数のClusterBackupマニフェストファイルにリフレッシュすることで作成できます。

今、k8s-cluster-backup.yamlというClusterBackupのマニフェストファイルを作成してください。以下のコードブロックを追加してください。

k8sクラスターバックアップ.yaml
apiVersion: triliovault.trilio.io/v1
kind: ClusterBackup
metadata:
  name: k8s-cluster-backup
  namespace: tvk
spec:
  type: Full
  clusterBackupPlan:
    name: k8s-cluster-backup-plan
    namespace: tvk

ファイルを保存して閉じてください。

最後に、kubectlを使用してClusterBackupリソースを作成します。

  1. kubectl apply -f k8s-cluster-backup.yaml

 

クラスターバックアップのマニフェストを適用することで、バックアッププロセスがトリガーされます。

あなたの出力は以下のようになります。

Output

clusterbackup.triliovault.trilio.io/k8s-cluster-backup created

今、kubectlを使用して、ClusterBackupの状態を調べてください。

  1. kubectl get clusterbackup k8s-cluster-backup -n tvk

 

出力は次のように見えます。

Output

NAME BACKUPPLAN BACKUP TYPE STATUS … PERCENTAGE COMPLETE k8s-cluster-backup k8s-cluster-backup-plan Full Available100

STATUS列の値をチェックしてください。値は「利用可能」に設定されている必要があります。また、PERCENTAGE COMPLETEは100に設定されている必要があります。

TVKの管理コンソールを使用して、クラスタバックアップの状態も確認できます。メインのダッシュボードから、左のペインでモニタリングを選択し、次にTrilioVaultモニタリングを選択します。

Screencapture showing the status of the Cluster Backup

全クラスタのバックアップが完了するまで、関連するネームスペースやリソース、およびPVCに含まれるデータの量によって時間がかかる場合があります。上記のような出力があれば、バックアップ計画に含まれる重要なアプリケーションのネームスペースが正常にバックアップされました。

メインダッシュボード上で、Webコンソールのメインダッシュボードを開き、複数の名前空間バックアップを調査することもできます。メインダッシュボードから、バックアップ&リカバリーを選択し、次に名前空間を選択します。右上にある切り替えボタンを使用して、リスト表示とハニカム構造を切り替えることができます。

Screencapture showing the honeycomb view of the namespaces

ハニカムビューでは、バックアップに含まれていたすべての重要な名前空間が強調表示されます。

このセクションでは、クラスタのバックアップを作成しました。次のセクションでは、名前空間を削除してから、バックアップからそれらを復元します。

名前空間を削除する。

後でバックアップから復元できるように、クラスタバックアップを作成したら、名前空間を削除します。名前空間を削除するには、必要に応じて、以下のコマンドを実行してください。該当する名前空間を置き換えてください。

  1. kubectl delete ns wordpress
  2. kubectl delete ns mysqldb
  3. kubectl delete ns etcd

 

あなたの出力結果は次のようになります:

Output

namespace “wordpress” deleted namespace “mysqldb” deleted namespace “etcd” deleted

あなたの名前空間が削除されたので、バックアップを復元します。

管理コンソールを使用してバックアップを復元する。

このセクションでは、TVKのウェブコンソールを使用してバックアップからすべての重要なアプリケーションを復元します。復元プロセスでは、バックアップが保存されている対象の妥当性が確認されます。TVKは、データムーバーポッドとメタムーバーポッドを使用して対象リポジトリに接続し、バックアップファイルを取得します。TVKは、バックアップストレージから取得したKubernetesアプリケーションを作成します。

リストア操作を開始するには、まずターゲットのマニフェストを再作成する必要があります。既存の名前空間が削除されたため、それらの名前空間で作成されたターゲットのカスタムリソースも削除されています。つまり、クラスター上にターゲットのカスタムリソースは存在しません。

「バックアップデータが保存されている同じS3バケットにTVKターゲットを作成し、TrilioVaultターゲットの設定に従って構成してください。また、ターゲットのブラウジングが有効になっていることを確認してください。」

それから、バックアップ&リカバリに移動し、その後、ターゲットのネームスペースをすべて選択しました。

Screencapture showing the TVK target list

利用可能なバックアップを一覧表示するには、右側のアクションボタンをクリックし、ドロップダウンメニューから「ブラウザ起動」オプションを選択してください。

Screencapture showing the Actions button drop-down menu

これが機能するためには、ターゲットのenableBrowsingフラグがtrueに設定されている必要があります。

「ブラウザ起動」を選択すると、ターゲットブラウザが表示されます。

Screencapture showing the TVK target browser

今、バックアッププランのリストからk8s-cluster-backup-planアイテムをクリックしてください。サブウィンドウが右側に表示され、バックアップの状態を含む情報が表示されます。

右のサブウィンドウからk8s-cluster-backupアイテムをクリックして展開してください。

Screencapture showing the TVK Cluster Backup item

復元プロセスを開始するには、復元ボタンをクリックしてください。

次に、リストアプロセスのいくつかのオプションが表示されるポップアップウィンドウが表示されます。リストアプロセスの異なるオプションを理解するには、TrilioVaultのドキュメンテーションのリストアフラグセクションに各フラグの詳細が記載されています。

Screencapture showing the restore operation options

「復元カスタムリソースの作成のための復元名を入力してください。名前を提供したら、バックアップの重要な名前空間をデータを復元したい名前空間にマッピングできます。この場合、設定パネルの 名前空間の設定 を選択し、必要な名前空間を選択してください。」

Screencapture showing namespace configuration options

復元プロセスが開始されると、進捗状況を監視することができます。以下のような進捗ウィンドウが表示されます。

Screencapture showing the cluster restore progress pane

しばらく経った後、進捗が完了したら、マルチネームスペースの復元操作が成功裏に完了しました。

このセクションでは、マネジメントコンソールを使用してバックアップを復元しました。次のセクションでは、復元操作が成功したことを確認します。

DOKSクラスターのアプリケーションの状態を確認します。

このセクションでは、リストア操作が成功したことを確認し、リストア後にアプリケーションにアクセスできることを確認します。まず、以下のコマンドを実行して、リストア対象のアプリケーションに関連するすべてのオブジェクトを名前空間から取得してください。

  1. kubectl get all –namespace wordpress
  2. kubectl get all –namespace mysqldb
  3. kubectl get all –namespace etcd

 

各アプリケーションごとに、出力は以下のようになります。

Output

NAME READY STATUS RESTARTS AGE pod/wordpress-5dcf55f8fc-72h9q 1/1 Running 1 2m21s pod/wordpress-mariadb-0 1/1 Running 1 2m20s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/wordpress LoadBalancer 10.120.1.38 34.71.102.21 80:32402/TCP,443:31522/TCP 2m21s service/wordpress-mariadb ClusterIP 10.120.7.213 <none> 3306/TCP 2m21s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/wordpress 1/1 1 1 2m21s NAME DESIRED CURRENT READY AGE replicaset.apps/wordpress-5dcf55f8fc 1 1 1 2m21s NAME READY AGE statefulset.apps/wordpress-mariadb 1/1 2m21s

出力の詳細によると、WordPressアプリケーションのデプロイメントのコンテナの1/1がREADYの状態であることが示されています。また、WordPressアプリケーションのポッドとWordPress MariaDBポッドのコンテナも1/1がRUNNINGの状態であることが確認されています。これらの状態から、アプリケーションが正常に復元されたことが確認されます。

次のステップでは、DOKSクラスターアプリケーションの定期的な(または自動的な)バックアップの実行方法を学びます。

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

予定に基づいて自動的にバックアップを作成することは非常に便利な機能です。何か問題が発生した場合に、時間を巻き戻してシステムを以前の動作状態に復元することができます。TrilioVaultはデフォルトで、毎日、週次、および月次の3つの予定ポリシーを作成します。

テレビキャストのコンソールでは、バックアップ&リカバリーの下のデフォルトのポリシーを表示できます。その後、スケジューリングポリシーを選択します。

Screencapture showing the default scheduled policies in the TVK management console

スケジューリングポリシーは、BackupPlanまたはClusterBackupPlan CRDのいずれかに使用することができます。

スケジュールバックアップを毎5分実行するためのマニフェストファイル、scheduled-backup-every-5min.yamlを作成し、以下のコードを追加してください。このコードは、典型的なカスタムスケジュールポリシーのCRDです。

5分ごとにスケジュールされたバックアップ。
apiVersion: triliovault.trilio.io/v1
kind: Policy
apiVersion: triliovault.trilio.io/v1
metadata:
  name: scheduled-backup-every-5min
  namespace: tvk
spec:
  type: Schedule
  scheduleConfig:
    schedule:
      - "*/5 * * * *" # trigger every 5 minutes

このマニフェストでは、tvk名前空間の下にscheduled-backup-every-5minという予定されたバックアップポリシーを作成します。BackupPlanオブジェクトに基づいて、5分ごとに予定されたバックアップをトリガーするために使用されます。

マニフェストを作成した後、それを使用してスケジュールポリシーを作成することができます。

  1. kubectl apply -f scheduled-backup-every-5min.yaml

 

出力結果は次のようになります。

Output

policy.triliovault.trilio.io/scheduled-backup-every-5min created

スケジューリングポリシーを適用するためには、それを ClusterBackupPlan CRD に追加します。Step 5 で作成した ClusterBackupPlan CRD を開き、以下のハイライトされた行を追加してください。

K8sクラスタのバックアップ計画
apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: k8s-cluster-backup-plan
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    schedulePolicy:
      fullBackupPolicy:
        name: scheduled-backup-every-5min
        namespace: tvk
  backupComponents:
    - namespace: wordpress
    - namespace: mysqldb
    - namespace: etcd

ClusterBackupPlan CRDは、spec.backupConfig.schedulePolicyフィールドを介して以前に定義されたPolicy CRDを参照しています。フルバックアップまたは増分バックアップのために個別のポリシーを作成することができるため、spec内でfullBackupPolicyまたはincrementalBackupPolicyが指定できます。

ファイルを保存して閉じてください。

この段階では、バックアップをスケジュールし、ClusterBackupPlanにスケジューリングポリシーを追加しました。次のステップでは、バックアップの保持ポリシーの設定方法について学びます。

ステップ7- バックアップ保有ポリシーの作成

このステップでは、バックアップの保持ポリシーを作成します。このポリシーは、バックアップの取得頻度を決定します。保持ポリシーは重要です。なぜなら、ストレージは有限であり、あまりに多くのオブジェクトが保持されると、コストがかかる可能性があるからです。

バックアップを保持する数と、コンプライアンス要件に応じて削除するバックアップの頻度を定義するための保持ポリシーがあります。保持ポリシーCRDは、日数、週数、月数、年数、最新などを指定するYAML仕様を提供します。

テレビ神奈川(TVK)にはデフォルトの保持ポリシーもあります。これはTVKコンソールのバックアップ&リカバリー、次に保持ポリシーの下で確認することができます。

Screencapture showing the default retention policy in the TVK management console

Retention policies can be applied to either BackupPlan or ClusterBackupPlan CRDs. Please create a new file named sample-retention-policy.yaml and include the following content:

サンプルの保持ポリシー.yaml
apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: sample-retention-policy
spec:
  type: Retention
  retentionConfig:
    latest: 2
    weekly: 1
    dayOfWeek: Wednesday
    monthly: 1
    dateOfMonth: 15
    monthOfYear: March
    yearly: 1

これはリテンションタイプの典型的なポリシーマニフェストです。上記の設定についての説明を以下に記載します。

  • spec.type: Defines the policy type: Retention or Schedule.
  • spec.retentionConfig: Describes the retention configuration, such as the interval to use for backup retention and how many to retain.
  • spec.retentionConfig.latest: Maximum number of latest backups to be retained.
  • spec.retentionConfig.weekly: Maximum number of backups to be retained in a week.
  • spec.retentionConfig.dayOfWeek: Day of the week to maintain weekly backups.
  • spec.retentionConfig.monthly: Maximum number of backups to be retained in a month.
  • spec.retentionConfig.dateOfMonth: Date of the month to maintain monthly backups.
  • spec.retentionConfig.monthOfYear: Month of the backup to retain for yearly backups.
  • spec.retentionConfig.yearly: Maximum number of backups to be retained in a year.

上記に設定された保持ポリシーでは、バックアップポリシーは週単位で毎週水曜日に1つのバックアップを保持し、月単位で毎月15日に1つのバックアップを保持し、年単位で毎年3月に1つのバックアップを保持します。全体としては、最新の2つのバックアップが利用可能です。

Retention policy resourceの作成の基本フローは、スケジュールされたバックアップと同じです。リテンションポリシーを参照するためにBackupPlanまたはClusterBackupPlan CRDが定義されている必要があり、その後、プロセスをトリガーするためにBackupまたはClusterBackupオブジェクトが必要です。

保存ポリシーを適用するために、ClusterBackupPlan CRDを開き、以下のように更新してください。

k8sクラスタのバックアップ計画
apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: k8s-cluster-backup-plan
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    retentionPolicy:
      fullBackupPolicy:
        name: sample-retention-policy
        namespace: tvk
  backupComponents:
    - namespace: wordpress
    - namespace: mysqldb
    - namespace: etcd

マニフェストでは、retentionPolicyフィールドを使用して対象のポリシーを参照します。予定されたバックアップを実行し、保持戦略も処理できるよう、両方の種類のポリシーが設定されたバックアッププランを作成することができます。

このステップでは、バックアップの保持ポリシーを設定します。

結論

このチュートリアルでは、TrilioVault for Kubernetesをインストールして、クラスターのバックアップとリストアに使用しました。また、バックアップのスケジュール設定と保持ポリシーの構成も行いました。

トリリオバルトのKubernetes向けのクラスターバックアップにおいて、基本的なタスクを達成しましたので、次はトリリオバルトの製品ドキュメントから以下のコンテンツを利用して他のトピックや素材を探索できるようになりました。

  • TVK Custom Resource Definition API Documentation.
  • How to Integrate Pre/Post Hooks for Backup Operations, with examples given for various databases.
  • Multi-Cluster Management
  • Helm Releases Backup, which shows examples of Helm releases backup strategies.
  • Immutable Backups, which restrict backups on the target storage to be overwritten.
  • Backups Encryption, which explains how to encrypt and protect sensitive data on the target (storage).
  • Restore Transforms
  • Disaster Recovery Plan

Kubernetesに関する詳細は、Silicon Cloud Kubernetes(DOKS)の製品ドキュメントと追加のチュートリアルをご覧ください。

コメントを残す 0

Your email address will not be published. Required fields are marked *