はじめに
Kubernetesクラスター内のデータは、他のセットアップと同様に、失われるリスクがあります。重大な問題を防ぐためには、データ復旧計画を用意しておくことが不可欠です。これを行うための簡単で効果的な方法は、バックアップを作成し、予期しないイベントが発生した場合にデータが安全であることを確認することです。バックアップは、一度だけ実行するか、スケジュールで実行することができます。スケジュールされたバックアップを行うことで、最新のバックアップが簡単に戻せるようになります。
Veleroは、Kubernetesクラスターのバックアップと復元操作を支援するために設計されたオープンソースのツールです。災害復旧ユースケースに最適であり、また、アップグレードなどのクラスターでのシステム操作を実行する前にアプリケーションの状態をスナップショットするのにも適しています。このトピックの詳細については、公式ページのVeleroの動作方法をご覧ください。
このチュートリアルでは、KubernetesクラスターにVeleroを展開し、バックアップを作成し、バックアップから復元する方法について学びます。クラスタ全体をバックアップするか、オプションでクラスタの名前空間またはラベルセレクターを選択してバックアップすることができます。
目次
- 前提条件
- ステップ1 – Helmを使用してVeleroをインストールする
- ステップ2 – ネームスペースのバックアップとリストアの例
- ステップ3 – クラスタ全体のバックアップとリストアの例
- ステップ4 – 定期バックアップ
- ステップ5 – バックアップの削除
前提条件
このチュートリアルを完了するには、以下が必要です：
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A DigitalOcean API token for Velero to use.
- A Git client, to clone the Starter Kit repository.
- Helm（Veleroリリースおよびアップグレードの管理に使用）。
- Doctl（DigitalOcean APIとの対話のため）。
- Kubectl（Kubernetesとの対話のため）。
- Veleroクライアント（Veleroバックアップを管理するため）。
ステップ1 – Helmを使用してVeleroをインストールする
このステップでは、必要なすべてのコンポーネントとともにVeleroを展開し、Kubernetesクラスタのリソース（PVも含む）のバックアップを実行できるようにします。バックアップデータは、事前条件セクションで作成したDO Spacesバケットに保存されます。
まず、Starter Kit Gitリポジトリをクローンし、ローカルコピーのディレクトリに移動します：
次に、Helmリポジトリを追加し、利用可能なチャートをリストします：
出力は次のようになります：
NAME CHART VERSION APP VERSION DESCRIPTION
vmware-tanzu/velero 2.29.7 1.8.1 A Helm chart for velero
興味のあるチャートはvmware-tanzu/veleroです。これにより、クラスタにVeleroがインストールされます。このチャートに関する詳細については、velero-chartページをご覧ください。
次に、選択したエディター（できればYAMLリントサポート付き）を使用して、Starter Kitリポジトリに提供されたVelero Helm値ファイルを開いて検査します。
次に、DO Spaces Veleroバケット（名前、リージョン、およびシークレットなど）に応じて、<>プレースホルダーを置き換えてください。必ず、あなたのDigitalOcean APIトークンも提供してください（DIGITALOCEAN_TOKENキー）。
最後に、helmを使用してVeleroをインストールします：
A specific version of the Velero Helm chart is used. In this case 2.29.7 is picked, which maps to the 1.8.1 version of the application (see the output from Step 2.). It’s a good practice in general to lock on a specific version. This helps to have predictable results and allows versioning control via Git.
–create-namespace \
今度は、次を実行してVeleroデプロイメントを確認してください：
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
velero velero 1 2022-06-09 08:38:24.868664 +0300 EEST deployed velero-2.29.7 1.8.1
出力は次のようになります（STATUS列にはdeployedが表示されます）：
次に、Veleroが起動していることを確認してください：
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 67s
出力は次のようになります（展開ポッドはReady状態でなければなりません）：
さらに詳しく見ることに興味がある場合は、Veleroのサーバーサイドコンポーネントを表示できます：
- Velero CLIのヘルプページを探索して、使用可能なコマンドとサブコマンドを確認してください。各コマンドのヘルプは、
--helpフラグを使用して取得できます： Veleroのすべての利用可能なコマンドをリストアップ：
Veleroのbackupコマンドオプションをリストアップ：
Veleroは、バックアップ、バックアップスケジュールなどのリソースを表すために複数のCRD（カスタムリソース定義）を使用します。チュートリアルの次のステップでそれぞれを見つけ、いくつかの基本的な例を紹介します。
この手順では、DOKS クラスターから特定の名前空間全体のワンタイムバックアップを実行し、その後すべてのリソースが再作成されることを確認してから、それを復元する方法を学びます。対象となる名前空間は ambassador です。
まず、バックアップを開始します：
次に、バックアップが作成されたことを確認します：
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 29d default <none>
出力は次のようになります：
その後、しばらくしてからそれを検査できます：
Name: ambassador-backup
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
...
- 出力は次のようになります：
Phase行を探します。それはCompletedと表示されるはずです。- エラーが報告されていないことも確認してください。
新しい Kubernetes バックアップオブジェクトが作成されます：
~ kubectl get backup/ambassador-backup -n velero -o yaml
apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/source-cluster-k8s-gitversion: v1.21.2
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "21"
...
最後に、DO Spaces バケットを見て、backups という新しいフォルダーが作成され、ambassador-backup の作成されたアセットが含まれていることを確認します：
まず、ambassador名前空間を意図的に削除して、災害をシミュレートします:
次に、名前空間が削除されたことを確認します（名前空間のリストにambassadorが表示されないはずです）:
最後に、echoおよびquoteバックエンドサービスのエンドポイントがDOWNであることを確認します。スターターキットチュートリアルで使用されるバックエンドアプリケーションに関する情報は、アンバサダーエッジスタックバックエンドサービスの作成を参照してください。これをテストするには、curlを使用できます（または、ウェブブラウザを使用することもできます）:
ambassador-backupを復元します:
重要: ambassador ネームスペースを削除すると、ambassador サービスに関連するロードバランサーリソースも削除されます。したがって、ambassador サービスを復元すると、DigitalOcean によってロードバランサーが再作成されます。問題は、ロードバランサーの新しい IP アドレスが取得されるため、クラスター上のドメインにトラフィックを取得するために A レコード を調整する必要があることです。
ambassador-backup の復元コマンド出力から Phase 行を確認してください。それは Completed と表示されるはずです（また、警告セクションに注意してください – 何かが間違っている場合にそれが通知されます）:
次に、ambassador ネームスペースのすべてのリソースが復元されたことを確認してください。 ambassador ポッド、services、および deployments を探してください。
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-9qnz6 1/1 Running 0 18h
pod/ambassador-5bdc64f9f6-twgxb 1/1 Running 0 18h
pod/ambassador-agent-bcdd8ccc8-8pcwg 1/1 Running 0 18h
pod/ambassador-redis-64b7c668b9-jzxb5 1/1 Running 0 18h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.74.214 159.89.215.200 80:32091/TCP,443:31423/TCP 18h
service/ambassador-admin ClusterIP 10.245.204.189 <none> 8877/TCP,8005/TCP 18h
service/ambassador-redis ClusterIP 10.245.180.25 <none> 6379/TCP 18h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 18h
deployment.apps/ambassador-agent 1/1 1 1 18h
deployment.apps/ambassador-redis 1/1 1 1 18h
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 18h
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 18h
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 18h
出力は次のようになります:
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
出力は次のようになります:
STATE は Ready で、HOSTNAME 列は完全修飾ホスト名を指すはずです。
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
出力は次のようになります（echo-backendがecho.starter-kit.onlineホストおよび/echo/ソースプレフィックスにマップされていることに注意してください。同様にquote-backendもです）：
最後に、ロードバランサーとDigitalOceanドメイン設定を再構成した後、echoおよびquoteバックエンドサービスのエンドポイントがUPであることを確認してください。Ambassador Edge Stackバックエンドサービスの作成を参照してください。
次のステップでは、意図的にDOKSクラスターを削除して災害をシミュレートします。
このステップでは、災害復旧シナリオをシミュレートします。クラスタ全体のDOKSが削除され、それから以前のバックアップから復元されます。
まず、DOKSクラスタ全体のバックアップを作成します：
次に、バックアップが作成されたことを確認し、エラーが報告されていないことを確認します。次のコマンドは利用可能なすべてのバックアップをリストします：
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
all-cluster-backup Completed 0 0 2021-08-25 19:43:03 +0300 EEST 29d default <none>
出力は次のようになります：
最後に、バックアップの状態とログを調査します（エラーが報告されていないことを確認します）：
重要: doctlコマンドに--dangerousフラグを指定せずにDOKSクラスターを破壊し、それを復元すると、同じロードバランサーが同じIPで再作成されます。これは、DigitalOcean DNSのAレコードを更新する必要がないことを意味します。
ただし、--dangerousフラグをdoctlコマンドに適用すると、既存のロードバランサーが破壊され、Veleroがイングレスコントローラーを復元すると新しい外部IPを持つ新しいロードバランサーが作成されます。そのため、DigitalOcean DNSのAレコードを適切に更新してください。
まず、DOKSクラスター全体を削除します（<>プレースホルダーを適切に置き換えてください）。
関連するロードバランサーを破壊せずにKubernetesクラスターを削除するには、次のコマンドを実行します：
または、関連するロードバランサーとともにKubernetesクラスターを削除する場合:
次に、 DigitalOcean Kubernetesをセットアップで説明されているようにクラスタを再作成します。 新しいDOKSクラスタのノード数が、元のものと同じかそれ以上であることを確認することが重要です。
次に、前提条件セクションとステップ1 – Helmを使用してVelero CLIおよびサーバをインストールするに従って、Velero CLIおよびサーバをインストールします。 同じHelm Chartバージョンを使用することが重要です。
最後に、次のコマンドを実行してすべてを復元します:
まず、all-cluster-backupリストア記述コマンドのPhase行をチェックします。 （<>プレースホルダーを適切に置き換えてください）。 Completedと表示される必要があります。
次に、以下を実行してすべてのクラスタリソースを確認します:
これで、バックエンドアプリケーションもHTTPリクエストに応答するはずです。 スターターキットチュートリアルで使用されているバックエンドアプリケーションに関する情報は、 Ambassador Edge Stack Backend Servicesの作成を参照してください。
次のステップでは、DOKSクラスターのアプリケーションの定期的（または自動）バックアップの実行方法を学びます。
スケジュールに基づいてバックアップを自動的に取ることは、非常に便利な機能です。これにより、何か問題が発生した場合にシステムを以前の動作状態に戻すことができます。
定期バックアップを作成するのは非常に簡単なプロセスです。以下に、1分のインターバルの例を示します（kube-system名前空間が選択されました）。
まず、スケジュールを作成します：
schedule="*/1 * * * *"
Linux cronジョブ形式もサポートされています：
次に、スケジュールが作成されたことを確認します：
NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR
kube-system-minute-backup Enabled 2021-08-26 12:37:44 +0300 EEST @every 1m 720h0m0s 32s ago <none>
出力は次のようになります：
その後、1分ほど経過した後にすべてのバックアップを検査します：
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
kube-system-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:20 +0300 EEST 29d default <none>
kube-system-minute-backup-20210826093744 Completed 0 0 2021-08-26 12:37:44 +0300 EEST 29d default <none>
出力は次のようになります：
まず、バックアップの1つからPhase行を確認します（<>プレースホルダーを適切に置き換えてください）。それはCompletedと表示されるはずです。
1分前のバックアップを復元するには、このチュートリアルの前の手順で学んだ方法と同じ手順に従ってください。これは、これまでに蓄積された経験を活用して、練習およびテストする良い方法です。
次のステップでは、時間の経過とともに作成した特定のバックアップを手動または自動で削除する方法を学びます。
古いバックアップが必要ない場合は、KubernetesクラスターおよびVelero DO Spacesバケットのリソースを解放できます。
まず、例として1分前のバックアップを選択し、次のコマンドを発行します（<>プレースホルダーを適切に置き換えてください）:
今、velero backup getコマンドの出力から消えているかを確認してください。DO Spacesバケットからも削除されているはずです。
次に、selectorを使用して複数のバックアップを一度に削除します。velero backup deleteサブコマンドには、--selectorというフラグが用意されています。これにより、Kubernetesラベルに基づいて一度に複数のバックアップを削除できます。
まず、利用可能なバックアップをリストアップします。
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 23d default <none>
backend-minute-backup-20210826094116 Completed 0 0 2021-08-26 12:41:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826094016 Completed 0 0 2021-08-26 12:40:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093816 Completed 0 0 2021-08-26 12:38:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093716 Completed 0 0 2021-08-26 12:37:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093616 Completed 0 0 2021-08-26 12:36:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093509 Completed 0 0 2021-08-26 12:35:09 +0300 EEST 24d default <none>
出力は次のようになります：
次に、backend-minute-backup-*アセットをすべて削除したいとします。リストからバックアップを選択し、Labelsを調査します。
Name: backend-minute-backup-20210826094116
Namespace: velero
Labels: velero.io/schedule-name=backend-minute-backup
velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: backend
Excluded: <none>
...
出力は次のようになります（velero.io/schedule-nameラベルの値に注意してください）：
次に、velero.io/schedule-nameラベルの値がbackend-minute-backupに一致するすべてのバックアップを削除できます：
最後に、すべてのbackend-minute-backup-*アセットがvelero backup getコマンドの出力から消えているか、DO Spacesバケットからも消えているかを確認してください。
- バックアップを作成する際には、
--ttlフラグを使用してTTL（Time To Live）を指定できます。Veleroは既存のバックアップリソースが期限切れであることを検出すると、以下を削除します： - バックアップリソース
- クラウドオブジェクト
storageからのバックアップファイル - すべての
PersistentVolumeのスナップショット
すべての関連するRestores
TTLフラグを使用すると、時間、分、秒で指定された値を使用してバックアップの保持期間を指定できます。指定されていない場合、デフォルトのTTL値である30日が適用されます。
まず、TTL値を3分に設定してambassadorバックアップを作成します：
次に、ambassadorバックアップを調査します：
Name: ambassador-backup-3min-ttl
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
Resources:
Included: *
Excluded: <none>
Cluster-scoped: auto
Label selector: <none>
Storage Location: default
Velero-Native Snapshot PVs: auto
TTL: 3m0s
...
A new folder should be created in the DO Spaces Velero bucket as well, named ambassador-backup-3min-ttl.
出力は次のようになります（Namespaces -> Includedセクションに注目してください – ambassadorが表示され、TTLフィールドが3ms0に設定されているはずです）：
最後に、約3分後にバックアップと関連するリソースが自動的に削除されます。バックアップオブジェクトが破棄されたことを確認するには、velero backup describe ambassador-backup-3min-ttlを使用できます。これにより、バックアップがもはや存在しないことを示すエラーが発生します。DO Spaces Veleroバケットからの対応するambassador-backup-3min-ttlフォルダも削除されます。