深夜3時のNamespaceの悪夢
それは一瞬の出来事です。疲弊したエンジニアが、dev環境のつもりでkubectl delete namespace prodを実行してしまいます。わずか5秒で、本番環境のAPI、データベース、ConfigMapが消え去ります。CI/CDパイプラインでアプリケーションコードを再デプロイできても、データは復元できません。500GBの顧客アップロードデータや、レガシーデータベースの特定のステータスを失った場合、YAMLマニフェストだけでは救いようがありません。
GitOpsは強力ですが、状態（ステート）のバックアップ戦略ではありません。多くのチームは、インフラがコードで定義されているから保護されていると思い込んでいますが、そうではありません。Gitはクラスターが「どうあるべきか」を定義しますが、Persistent Volume（PV）内の実際のデータを保持しているわけではありません。クラウドリージョンがダウンしたり、ボリュームが破損したりした際、必要なのはデプロイメントだけでなく、データのリカバリ方法です。
なぜetcdのバックアップだけでは不十分なのか
Kubernetesは設計上、エフェメラル（一時的）で分散型です。単一のディスクのスナップショットをとる従来の仮想マシン（VM）とは異なり、K8sアプリは、異なるノードに分散されたService、Secret、PVCの断片的な集合体です。etcdのバックアップだけに頼るのはリスクが高く、非効率です。
特定のNamespaceを1つ復旧させるためだけに200MBのetcdスナップショットをリストアするのは、やりすぎです。それは「牛刀をもって鶏を割く」ようなものです。さらに重要なのは、etcdはメタデータのみを保存している点です。基盤となるEBSやAzure Diskが物理的に消失した場合、etcdには実際のデータの記録はありません。ここでVeleroがそのギャップを埋めてくれます。
Velero：クラスターリカバリの業界標準
Velero（旧Heptio Ark）は、正にこの問題のためのツールです。Kubernetes APIと直接通信してリソースをバックアップすると同時に、ストレージプロバイダー側でスナップショットをトリガーします。これにより、設定とデータがセットになった統合的なリカバリポイントが作成されます。
私は数百ものノードを管理するクラスターにVeleroを導入してきましたが、その安定性は素晴らしいものです。バックアップを実行すると、VeleroはYAML定義を取得し、クラウドプロバイダー（AWS、GCP、またはローカルのMinIOインスタンス）に対して、即座にボリュームのスナップショットを作成するよう指示を出します。
主要コンポーネント
- Velero Client: バックアップを管理するためのCLIツール。
- Velero Server: バックアップとリストアのプロセスをオーケストレーションする一連のPod。
- オブジェクトストレージ: メタデータやログを保存するバケット（S3など）。
- Volume Snapshotter: PVデータを処理するためにストレージバックエンド（EBS、Longhornなど）と連携するプラグイン。
実践：Veleroのセットアップ
今回のセットアップでは、S3互換のバックエンドを使用します。開始する前に、稼働中のクラスターに対してkubectlでアクセスできることを確認してください。
1. Velero CLIのインストール
最新のリリースをローカルマシンにダウンロードします。互換性を保つため、CLIのバージョンをサーバー側と一致させることが重要です。
# Linux v1.15.0の例
wget https://github.com/vmware-tanzu/velero/releases/download/v1.15.0/velero-v1.15.0-linux-amd64.tar.gz
tar -xvf velero-v1.15.0-linux-amd64.tar.gz
sudo mv velero-v1.15.0-linux-amd64/velero /usr/local/bin/2. ストレージ認証情報の設定
Veleroがオブジェクトストレージに書き込むための権限が必要です。アクセスキーを含んだcredentials-veleroファイルを作成します。
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY3. Velero Server의 데프로이
このコマンドでサーバーコンポーネントをクラスターにインストールします。この例ではMinIOを使用しますが、AWS S3の手順もほぼ同じです。
velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.9.0 \
--bucket k8s-backups \
--secret-file ./credentials-velero \
--use-volume-snapshots=true \
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.storage.svc.cluster.local:9000 \
--snapshot-location-config region=defaultvelero Namespace内のPodを監視して、インストールの状態を確認します：
kubectl get pods -n velero実践的なバックアップとリストア
ステートフルなデータベースを含むapp-productionという本番用Namespaceを保護してみましょう。
手動バックアップの実行
以下のコマンドを実行して、Namespace全体とそのボリュームの特定の時点でのスナップショットを作成します：
velero backup create prod-snapshot-01 --include-namespaces app-productionステータスを確認し、ボリュームのスナップショットが「Completed」になっていることを確認します：
velero backup describe prod-snapshot-01
velero backup get障害のシミュレーション
Namespaceを丸ごと削除します。標準的なCSIドライバーを使用している場合、Podと共にPVも消失する可能性が高いです。
kubectl delete namespace app-productionリストアのワークフロー
VeleroはS3のスナップショットから環境全体を再構築します。まずNamespaceをリストアし、次にクラウドプロバイダーを呼び出してPVを再作成し、最後に正しい依存関係の順序でリソースをデプロイします。
velero restore create --from-backup prod-snapshot-01ボリュームのサイズによりますが、2〜5分以内にアプリケーションはデータ損失ゼロでオンラインに復帰します。
高度な戦略：RPOとファイルレベルのバックアップ
手動バックアップは信頼性に欠けます。本番環境では、60分の目標復旧時点（RPO）を達成するために、常に1時間ごとのスケジュールを設定します。
velero schedule create daily-prod --schedule="0 * * * *" --include-namespaces app-production --ttl 720h0m0s--ttl（Time To Live）フラグは必須です。30日より古いバックアップを自動的に削除し、クラウドストレージのコストを抑制します。
Node Agent（Restic/Kopia）の使用
ストレージプロバイダーがスナップショットをサポートしていない場合はどうすればよいでしょうか？その場合はVelero Node Agentを使用できます。これはファイルシステムレベルでバックアップを行います。ハードウェアスナップショットよりは低速ですが、オンプレミスのベアメタルを含むあらゆるインフラで動作します。
インストール時に--use-node-agentを付けて有効化し、Podにボリュームを含めるためのアノテーションを追加します：
kubectl annotate pod <pod-name> backup.velero.io/backup-volumes=data-storage最終結論：信頼性はプロセスである
Kubernetesはアプリをスケールさせますが、ビジネスデータを自動的に保護してくれるわけではありません。「希望的観測」に基づいた戦略から、検証済みのリカバリプランへと移行することは、あらゆるDevOpsチームにとって大きな節目となります。Veleroを導入することで、データ消失の恐怖に絶えず怯えることなく、エンジニアがより迅速に動けるセーフティネットを構築できます。
まずは小さく始めましょう。重要なNamespaceを1つ選び、ローカルのMinIOバックエンドをセットアップして、完全なリストアを練習してください。kubectl deleteの後にデータが再出現するのを一度目にすれば、オンコールのシフト中もずっと安眠できるようになるはずです。信頼性とは、単に使用するソフトウェアのことではなく、実際にテストされたリカバリプロセス
