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

こんにちは！

インフラチームインターン生の國領です！今回インターンでは Kubernetes クラスタのバックアップについて，最新のツールの動向を探ると共に，より便利なツールの探索，検証を行いましたので，その成果をここで簡単に報告しようと思います．

なぜバックアップは重要か

Kubernetes は非常に便利なオーケストレーションツールで，現在ではコンテナを使ったプロダクション環境においてのデファクトに近い地位を築いているのではないかと思います．Wantedly でもほぼ全てのサービスが Kubernetes によって管理されており，その重要性は計り知れません．

しかし，いくら Kubernetes がよく出来ていても，

• オペレーションミスなどの人為的なミス
• バージョンアップグレード時など大きな変更が起きるときの障害

など，データを喪失する危険性は多くあります．deploymentの情報などは yaml として残しておくことが出来ますが，WantedlyではDATABASE_URLなどの秘匿するべき環境変数などをSecretで管理しているため，権限を持つ人にしか閲覧できないデータの扱いなどが難しく，単純にファイルとしておいておくことができないなどの課題もあります．

多くの顧客を抱えシステムをダウンさせることが許されない企業において，バックアップ/リストア手法の確立は非常に重要なタスクの一つと言えるかと思います．

Kubernetes のバックアップ手法

Kubernetes クラスタのバックアップ/リストア方法について，日本語ではあまり情報が無いというのが現状です．Kubernetes 公式のドキュメントにも etcd のバックアップを取る手法のみが公開されています．

ただし GKE のようなマネージドサービスにおいて master の etcd は隠蔽されていたりするためバックアップを取るのが難しかったり，etcd クラスタの復元のハードルが高いなどがあり，バックアップに関する良い事例はあまり見られませんでした．実際に Kubernetes のリポジトリでも議論はされていますが，あまり良い方法は出ていないようです．

Google検索だ！

とにかく最初はググりまくりました．英語ばかりで心がくじけそうになりましたが，そこは気合い（とGoogle 翻訳）で乗り切りました．

Heptio/ark

ググるとだいたい最初にヒットします．Kubernetes を作ったエンジニアたちが立ち上げた会社で，いくつかのプロダクトを既に作っています．

このツールの特徴としては，

• etcd ではなく Kubernetes API を使ってバックアップ/リストアを行う
• バックアップしたデータは AWS S3 などのオブジェクトストレージに保存
• Persistent Volume のバックアップにはクラウドプロバイダの API を利用

ということが上げられます．Kubernetes API から取れるものは全てバックアップ/リストアでき，実際に Microsoft と協力してディザスターリカバリーツールとして開発されているようです．

pieterlange/kube-backup

次に見かけたのはこれでした．リポジトリ以外からほとんど情報を得られず，海外の掲示板サイト等で名前を見る程度でした．Kubernetes の cronJob として実行し，Git リポジトリに同期して Kubernetes の Resource Definition のバックアップを取る？ようです．

また，Persistent Volume のバックアップは出来ないようです．

mhausenblas/reshifter

これは Red Hat OpenShift のブログにおいて紹介されていました．

このブログに大きく

TL;DR: If you’re using Kubernetes beyond dev/test, that is, in production, you need a strategy for restoring and upgrading clusters. ReShifter is a WIP aiming at supporting you with these operations.

と書かれており，まだWIPであることが明示されています．

このツールの大きな特徴としては Web UI を作ろうとしているところで，GUI でバックアップ/リカバリなどが行えるようになるのでは無いかと思います．ただし，GitHub の Releases を見ると2018/9/21段階ではまだ全て Pre-release になっており，まだまだ運用できる段階には至っていないように感じました．

で，何が良いの？

現時点では heptio/ark 一択なのではないかと思います．

理由はいくつかありますが，

• 開発が活発で比較的情報が多い
• Heptio と Microsoft が関わっており将来性も期待できる
• Kubernetes API を利用するため，その互換性が保たれる間はバックアップデータが有効
• • バックエンドが etcd 2 または 3 のどちらでもKubernetesがその差異を吸収してくれる
  • Kubernetes 1.13 では etcd 2 のサポートが切られることが v1.11 の Release Note で述べられている
• Persisten Volume のバックアップも取ることが出来る

などの面で他のツールに比べて優位性があると考えています．

柔軟なバックアップ/リストア

heptio/ark ではバックアップ/リストア時に

• Namespace
• Label selector
• Resource

などでバックアップ/リストアするオブジェクトを選択することができ，さらにある namespace から異なる namespace にリストアすることができる機能などもあり，かなり柔軟なタスクに対応することが出来ると思います．

Load Balancer

プロバイダ固有の機能であるロードバランサについても Kubernetes の Service の定義から自動で再生成することができるため，リストア時に再生成されます．

ただし，これはクラウドプロバイダによってユニークなUIDが振られており，毎回異なる名前のロードバランサが生成されるため，完全に同一とまではいかないのが残念なところです．これは将来，クラウドプロバイダの対応を期待しています．

Persistent Volume

これもクラウドプロバイダ特有の機能ですが，リストア時に Persistent Volume Claim との紐付けを行い，アタッチしてくれるため，リストアが可能です．

現状各プロバイダの API を利用してバックアップを行うようですが，オープンソースのバックアップツールである Restic を利用したプロバイダによらないバックアップを実現しようとしており，これが可能になれば異なるクラウドプロバイダ間の移行が大変容易になるのでは無いかと思います．

やってみた

heptio/ark のドキュメントにある Getting started に従い，Wantedlyの環境に合うようにいくつか変更を加えるだけで動作させることができました．

実際に立ち上げた Kubernetes クラスタに導入し，バックアップ/リストアを行いましたが，拍子抜けするほどしっかりと動作しました．

詳細は省きますが，

• 完全に新しいクラスタを立ち上げ別のクラスタのバックアップからリストア
• etcd 3 を利用しているクラスタに etcd 2 を利用していたクラスタのバックアップからリストア
• Kubernetes のバージョンを上げ，前のバージョンのバックアップからリストア

等を実施し，実際にリストアされることを確認しました．

これらの検証結果を活かし，Wantedly の開発環境にひとまず導入するところまで完了することが出来ました．namespaceが100を超えるような環境においてもバックアップが1分以内に完了し，リストアも同様にかなり高速に行うことが出来ました．

まとめ

現状 Kubernetes クラスタのバックアップ/リストアについてはデファクトスタンダードがなく，まだまだ発展途上の段階ではありますが，現状 heptio/ark は有力なツールであると言えると思います．まだバージョンは v0.9.0 ですが，現時点でもしっかりとバックアップ/リストアのツールとして動作するため，一度検証されてみてはいかがでしょうか．

インターンではメンターの方やインフラチームの方々に様々なアドバイスをいただきつつ，実際の業務に貢献することが出来ました．短い期間でしたが，エンジニアとして集中して一つのタスクに取り組むことは大変でもあり，しかし非常にワクワクする良い体験となりました．まだまだ課題は多いですが，より強固な信頼性の高いインフラに向け，色々とやっていきたいと思います．