AKSのバックアップツール「Verelo」をインストールから解説

バックアップもリストアも非常に早い

惣道哲也氏：実際にバックアップするときどんなイメージでやるのかもコマンドで簡単に紹介したいんですが、バックアップスケジュールを組むことが多いと思うので、ここでは一例として「velero schedule create」というコマンドを紹介します。

おおまかに言うと、2つ指定するんですけど、どこの対象をバックアップしますかというのをまず指定します。これは、このnamespaceとか、クラスタ全体とか、あとはさっき言ったようにラベルでとか、こういったことを、範囲を指定するオプションがまずあります。

それから、その他挙動を指定するオプションで、スケジュールもそうですし、保持期間ですね。いわゆるTTL。デフォルトだと720時間なんですけど、どれぐらい持っておくか、あとはtrue/falseでスナップショットを取る・取らないも指定できます。

こんな感じでやってあげると、この例ですと、5分おきに勝手に自動でバックアップが取られるという動きになります。ワンショットで取るときは、一番下に「velero backup create」というコマンドがあるので、これで1回だけ取ることも可能です。

取れると自動でバックアップが走って、Veleroコマンドで確認するとSTATUS Completedみたいな感じになります。

いざ、やらかしちゃったときにリストアをするんですけど、あまり難しくなくて、バックアップのIDがついているので、どこの時点のバックアップを取りたいかということを指定してあげて、restoreコマンドを投げてあげると、そのとおりに戻りますというだけの、シンプルな動きになっています。

あとでデモでも見てもらうんですけれども、バックアップもリストアも非常に早いので、安心して使えるなという感じです。

全体構成イメージ

デモの動画を見てもらおうかと思うんですけれども、構成イメージがわかりにくいので、その前に簡単に図にまとめてみました。

左側の黄色い枠のところはいわゆるVeleroが常駐で立ち上がっているもので、Podがずっと上がっています。これがいわゆるサーバだと思ってください。さっきのVeleroコマンドはクライアントでリクエストを投げて、このVeleroサーバが受け取って、いろんな処理をしてくれるという流れになっています。

右側はなんでもいいんですけど、ユーザーアプリケーションだと思ってもらって、今日のデモではGitHubにあるAKSのサンプルのvotingアプリ、これをバーって展開するとこんな感じになります。

ちょっと無駄に3レイヤーになっていて、フロントエンドのPodが3つあって、Analyticsという真ん中のやつは「何分の何」みたいなことを計算するだけのやつ。右側はMySQLになっていて、ストレージのMySQLのやつはPVCとPV、これがMySQLのいわゆるvar/lib/mysql領域になっていて、ここ、実体はAzureのManaged Disksになっています。

Azureでどういう動きをするかというと、さっき先に作っておいたBLOBコンテナ、ここにドカドカ放り込まれます。実際にブラウザから見ると、コンテナにバックアップのファイルが放り込まれるのが確認できます。これをVelero用語でBackupStorageLocationと言います。

スナップショットはVolumeSnapshotLocationという言い方をするんですけれども、Azureの場合にはManaged Disksがスナップショットを取れるので、VeleroはそこのAPIを投げていて、スナップショット取るよってなったらここに、リソースグループ内にスナップショットが1個2個3個と増えていきます。

Veleroインストール手順のデモ

では、実際に動画をお見せします。まだ時間は大丈夫そうですね。たぶん5〜10分ぐらいの動画になると思います。音はないです。大丈夫です。音ないけど、始まらないな。あっ、始まった。

（デモ開始）

これCloud Shellから叩いてるんですけど、こういう構成で、さっきスライドでお見せしたのと一緒です。

これはちょっとやっている雰囲気だけお見せしようと思ってて、VeleroのCLIをまずダウンロードして、PATHを通してVeleroコマンドを使えるようにしているというものですね。全部細かく追ってもらわなくてもいいんですけど、なんとなく雰囲気でこうだなみたいな。PATHを通して、そうするとVeleroコマンドが使えます、みたいな感じですね。

Veleroをインストールするんですけれども、さっきのコマンドで一発でドーンと入れるのですが、必要なファイル、クレデンシャルファイルとかも作っておく必要があるので、こんな感じで作ります。

実際のSecretとかが見えると嫌なので、sedコマンドでアスタリスクでマスクしたんですけど、こういうファイルを用意していただいて、実際にこんなinstallコマンドを叩きます。さっきスライドで紹介したのとまったく一緒です。

投げると、いわゆるオペレーターなのでCustom Resource Definitionがずらずらっと流れて。これですね。

あと、さっきの常駐Podとかできるので、PodとかDeploymentとかができるみたいな、こんな感じです。こういうシンプルな、PodがRunningになって、インストールが終わります。

ちょっと早送りしますが、実際にアプリケーションもここで今インストールしていて、さっき紹介したGitHubからcloneしてきて、ここはあまり本質と関係ないので早送り気味でいきますけど、必要なyamlをゴリゴリと全部kubectl applyで投げていきます。

実際にはこれはIstioとかを体験してもらうサンプルになっていて、IngressGatewayとかを通るんですけど、必要以上に複雑になると嫌なのでちょっとそこだけ端折っていて。

フロントPodにアクセスするときにはServiceリソースを追加で作って、AzureのLoad Balancerを使って、type: LoadBalancerのServiceを使ってアクセスできるようにしています。このyamlを追加しています。これを追加で入れてあげると、実際にアプリケーションにブラウザからアクセスできるようになります。

全体像としては、5つPodが立ち上がっているんですけど、まだContainerCreatingとか、ロードバランサーがまだ配備中なのでEXTERNAL-IPがpendingとかになったりしています。

あと、PVCとPVというのもつけてしてあげると、ごめんなさい、ちょっと下のほうが若干見づらいかもしれないですけれども、これですね、PV、あとPVCがBoundされて配備されています。

実際にリソースグループの中身を見ていくと、ここにあるようにAzure Load Balancerができたり、ディスクって一番下にあるんですけど、これがいわゆるManaged Disksで、さっきの1GのPVを配備されているのを確認できます。

これはロードバランサーですね。ここにパブリックIPがついてアクセスできるようになると、実際にブラウザからさっきのアプリケーションにアクセスできます。

これももうちょっと……もうEXTERNAL-IPは配備されていて、もうちょっとだけ早送りすると、最後のMySQLがなかなか遅いので……これで今Runningになったので配備完了して。

こういうボタンを押して……AKSのサンプルアプリ、こういうのいくつかありますよね。Cat何票、Dogが何票みたいな。今、3・3入れて合計6という状態。この状態で1回バックアップを取ろうかなと思っていて、1回ここで止めます。

バックアップスケジュールの定義と確認

「velero schedule create」コマンドを叩いて、この状態を1回バックアップを取ろうと思います。こうですね。

さっきのスライドと同じなんですけれども、votingというnamespace、これがアプリケーションのnamespaceで、スナップショットも取りますよということで、5分おきにスケジュールして、これで今スケジュールが定義されたので、実際にgetコマンドとかでいつでも確認できます。

これはスケジュールなので、実際バックアップが取れているかどうかというのは、velero backup getというコマンドで叩くと確認できます。

これ投入した瞬間は、最初のバックアップを取りにいくので、InProgressになっています。今、時刻的に、これ過去の日付ですけど、7時37分になっていて、1回これで37分で取って、あとは40分・45分・50分と取り続けることになります。

今Completedになったのでバックアップは全部これで取れました。これで安心していつでも何があっても復旧できるという状況ですね。

実際に障害を発生させるというか、やってみたいので、その前にこのカウンターをもうちょっと進めます。ポチポチ押して……もうちょっと早めますね……いくつか押した状態で、ここでもとの時間に戻そうかなと思っています。

実際にバックアップを指定してrestoreを投入する

今こういうリソースが配備されている状態で、1回これを全消しします。delete ns/voting。votingというのがアプリケーションなので、これでアプリケーションは今全消ししました。ちょっと時間かかるので、少し早送りさせてもらってですね。3分ぐらい確かかかるんですけど。これで今消えちゃいましたと。

アプリケーション、ブラウザは残っているんですけど、押しても、もちろんアプリケーションがもういないので、反応しないという状態になっています。この状態から最初に取ったバックアップで無事に戻せますかというのが、今日やりたい、デモでお見せしたい内容になるんですけれども。

取っているバックアップ、実は5分おきに取っているので2個目も取れてるんですけど、1個の37分のやつ、これを指定してあげてrestore createと打ってあげて、コマンドを投げるだけです。コピペして投げると、restoreが今投入されました。

これで、オブジェクトストレージ、BLOBに入っているリソース使って、もう1回全部applyしているようなかたちになります。あと、スナップショットを取ってたので、スナップショット戻しも行なわれていますよと。

さっきのバックアップと同じように、STATUSを見てもらって、InProgressからCompletedに変わった。これで全部リソースが投入終わったということですね。全部復旧したかどうかはまた別の話で、実際get allすると、いくつかのPodはContainerCreatingだったりとか、さっきと同じように、ロードバランサーがまだpendingだったりするわけですけれども、これはさっきと同じようにもうちょっとだけ待つと戻ります。

ちょっと時間も巻いてきたので早送りして。よいしょ。はい、今戻りましたね。

戻ったので、アクセスします。今3/6と3/6になっていて、バックアップ取った時点に戻っているのがわかると思います。ここからまた普通にワークロードを再開させられるという感じですね。すごく、中の実装を見せずに透過的に、抽象的にバックアップとリストアができたのがわかったかと思います。

必要な範囲で定期的にバックアップを自動でとれば安心できる

こういった感じで、必要な範囲に絞って定期的にバックアップを自動で取るみたいなことをやっておけば、安心してKubernetesも使ってもらえるんじゃないのかなと思います。

もし試される方は、注意してもらいたいのは、スケジュールって入れるとずっと取り続けるので、どんどんスナップショットが増えていくので、スケジュールは1回消さないと、5分おきのやつは永久に5分ずつ取っちゃうので、そこだけ気をつけてください。

最後に実際にBLOBの中も見てもらおうかなと思っていて。Azure PortalからBLOBのコンテナですね。「Velero」という名前のコンテナを作ったので、この中を見るんですけれども、バックアップ、これで5分おきに取ったものが全部フォルダ名ごとに入っていて、jsonだったりgzファイルみたいなものがまとめて一式入ってます。これが5分おきにどんどん積み重なっていきます。

（デモ終わり）

デモのほうは以上でして、スライドに戻ります。

Veleroはコンテナをうまく引っ越してくれる、ストラドルキャリアのようなもの

ユースケースとしてはいくつかあると思うんですけど、これは普通のバックアップのユースケースと同じだと思うのですが、障害・オペミス対策ということで、Spotifyさんみたいなことがあっても、バックアップ取っておけばいいですよね。

あとは、リージョンをまたいでバックアップを取っておけば、DRになります。意外と多いなと思うのは、クラスタ間でワークロードを引っ越したいみたいなことがあると思うんですけれども、そういったのにも使えるんですね。あとは、これはあまり意味ないんですけど、心の平安のために、aks upgradeコマンドを打つ前にバックアップを取っておくとすごくいいかなと。

ちなみに、Veleroはコンテナをうまく引っ越してくれるので……これストラドルキャリアというんですけど、みなさん知っていますか？　港で船からコンテナを積んで移動するやつなんですけど、Veleroってどんなもんですかって聞かれたら「ストラドルキャリアみたいなものです」と言えばみんなわかるかなと思うので、説明に使ってください。