お試しk3sクラスタをAWS EC2上で運用しています。暫く使わないので、AWS Backupを使ってバックアップ・レストア(復元)を試しました。
AWS Backupは大変便利で、EC2をバックアップするとついでにアタッチされたEBSボリューム一緒にバックアップしてくれます。ですが、私が試しに使ってみると、問題になる点がいくつかありました。
- 復元したEC2インスタンスには元のプライベートIPアドレスが割り振られず、違うアドレスになってしまう。
- 復元したEC2インスタンスにSSHでログインしようとすると、「SSHのホスト鍵が変わっている」と盛大に叱られてしまう。
- k3sで使う証明書を作り直す必要がある。
元のプライベートアドレスを保持してEC2インスタンスを復元する
バックアップした時と同じプライベートIPアドレスにしてあげないと、k3sクラスタが復元後にまともに動作しなくなります。しかし何も考えずにAWSコンソール上で復元すると勝手に違うアドレスに割り振ってしまいます。
元のプライベートIPアドレスを保持して復元する方法は、以下に書いてあります。
ですが、以下のQiita記事の方が分かりやすいでしょう。
二点だけ。
メタデータ取得する時、--output jsonを指定してあげないと、json形式でメタデータを取れなかったのですが、私だけでしょうか。
もうひとつ取得したメタデータを編集し、不要な部分を削るのですが、私の場合上記記事の内容にプラスして
\"SecondaryPrivateIpAddressCount\":0
も削除する必要がありました。これを残していると復元が失敗し、「SecondaryPrivateIpAddressCountの内容は正の数を入れる必要があります。」と叱られました（AWS Backupの復元ジョブを確認すると分かります)。
ホスト鍵が変わってしまう場合の対策
EC2インスタンスの復元に成功したのですが、SSHで使うホスト鍵は変わってしまうようです(メカニズムは分かりませんw)そこで、以下のQiita記事に基づいて処置をしました。
こちらは簡単に、
$ ssh-keygen -R example.com
を行って解決しました。
k3s証明書の作り直し
k3sの証明書の作り直しも必要でした。参考記事は手前味噌ですが、
これを見ながら処置しました。「キャッシュされた証明書の削除」は多分不要かな、と思ってやりませんでしたが。
まとめ
その他、k3s自体を新しく入れなおしたら、ローカル側(Windows10)のkubectlが古いと文句を言われたり色々あったのですが、これはまた別の話だと思います。
AWS Backupは便利だな、と思う反面、ipアドレスまで簡単に元通りになる訳ではない、とか、証明書類の作り直しなどが必要だったり、面倒な点はいくつかありました。
とは言え、私の場合勉強用・実験用なので使わないがあります。その間、EBSボリュームなどをそのままにしておくのは料金がもったいない。使わない時はインスタンスごと全て削除してしまい、必要な時に復元する運用としたいです。
これで大幅に料金が節約できる、、、、、、はず！？