k0sを立ててetcdを復旧する

このラボは本物のk0s上で動きます

VMの中にk0sが1台実際に起動していて、コントロールプレーンのデータストアはetcdです。そのため、バックアップと復旧を実際に試せます。

認定資格向けコースの他のラボで使うkwokは偽のコントロールプレーンなので、k0s backupもetcdctlも意味がありません。

起動するまでに3分ほどかかります。

目標

k0sクラスターの構成を確認し、バックアップ → 変更 → 復旧を一巡させて、復旧が実際に何を元に戻すのかを目で確かめます。そして、k3sとの違いを整理します。

なぜ重要なのか

バックアップは、復旧を試したことがあって初めてバックアップです。取得しただけで復旧を試していないバックアップは、「あると信じているもの」であって、バックアップではありません。実際に使えないバックアップは珍しくなく、その事実はいつも最悪のタイミングで明らかになります。

そして、復旧が何を元に戻すのかを正確に知っておくことが重要です。etcdの復旧は「クラスターをその時点へ戻すこと」です。バックアップ以降に作ったものはすべて消えます。これを知らないと、復旧後に「昨日作ったものがないのはなぜか」という2つ目の事故が起きます。

このラボでは、それをわざと起こしてみます。バックアップを取り、そのあとで何かを作り、復旧してから、それが消えたことを確認します。

ステップ

k0s statusとノードの状態を保存してください(保存先: /root/k0s/status.txt)。
データストアがetcdであることをk0s etcd member-listで確認して保存し(保存先: /root/k0s/etcd.txt)、--singleモードだった場合になぜこれが失敗するのかも書いてください。
このクラスターのServiceのCIDR範囲を確認して保存し(保存先: /root/k0s/cidr.txt)、なぜデフォルトのCIDR範囲を使わなかったのかを書いてください。
canaryという名前のConfigMap(v=before)を作成してからk0s backupでバックアップを取り、記録してください(記録先: /root/k0s/backup.txt)。
バックアップの後にConfigMapをもう1つ作成し、その名前をafter_backup=<이름>の形で書いてください(プレースホルダーは名前です。書き込み先: /root/k0s/disaster.txt)。復旧するとこれがどうなるかの予想もあわせて書きます。
k0s restoreで復旧し、結果を保存してください(保存先: /root/k0s/restore.txt)。canaryは残り、ステップ5で作ったものは消えている必要があります。
k3sとk0sの違いを整理してください(書き込み先: /root/k0s/compare.md)。データストア、CNI、デフォルトのコンポーネントを含める必要があります。
store=etcd、service_cidr_dns=、restore_verified=の3行と説明を書いてください(書き込み先: /root/k0s/report.md)。

参考

k0sは独立したkubectlをインストールしません。k0s kubectlとして使うか、この環境のようにk0sバイナリにkubectlのシンボリックリンクを作成します。
バックアップはk0s backup --save-path /rootです。復旧はk0sを停止した後にk0s restore <파일>を実行し(プレースホルダーはファイル名です)、そのあと再び起動します。
復旧手順の順序が重要です。k0s stop → 既存のetcdデータを空にする → k0s restore <파일> → k0s startの順です。
途中のステップを抜かすと、復旧コマンドは成功するのにデータはそのままです。etcdはデータディレクトリがすでにあるとそれを使い、スナップショットを無視するからです。エラーも警告も出ないため、復旧したと思い込んでしまうことが最も危険です。
よくあるミス1: k0s install controller --singleで構築してetcdのラボをやろうとすることです。そのモードはデータストアがkine(sqlite)なので、k0s etcdコマンドはすべて拒否されます。
よくあるミス2: 復旧後、kubectlが応答するまで待たずにすぐ確認することです。コントロールプレーンが再び立ち上がるまでの時間が必要です。

何が起動しているかを確認する

k0s statusとノードの状態を保存してください(保存先: /root/k0s/status.txt)。

k0s statusは、役割とワークロードの有無を教えてくれます。Workloads: trueは、このコントローラーがワーカーの役割も兼ねているという意味です。

データストアは何かを確認する

データストアがetcdであることをk0s etcd member-listで確認して保存し(保存先: /root/k0s/etcd.txt)、--singleモードだった場合になぜこれが失敗するのかも書いてください。

k0s etcd member-listが成功すればetcdです。kine(sqlite)の場合は'wrong storage type'で拒否されます。

なぜデフォルトのCIDR範囲を使わなかったのか

このクラスターのServiceのCIDR範囲を確認して保存し(保存先: /root/k0s/cidr.txt)、なぜデフォルトのCIDR範囲を使わなかったのかを書いてください。

このVMはKubernetesクラスターの中で動いています。ホストが渡したDNSサーバーのアドレスと重なると何が起きるかを考えてみてください。

バックアップを取る

canaryという名前のConfigMap(v=before)を作成してからk0s backupでバックアップを取り、記録してください(記録先: /root/k0s/backup.txt)。

復旧を検証するには、「バックアップ時点で何があったか」を示す目印が必要です。ConfigMapが1つあれば十分です。

バックアップの後に何かを作る

バックアップの後にConfigMapをもう1つ作成し、その名前をafter_backup=<이름>の形で書いてください(プレースホルダーは名前です。書き込み先: /root/k0s/disaster.txt)。復旧するとこれがどうなるかの予想もあわせて書きます。

復旧は、クラスターをバックアップ時点へ戻します。その後に作ったものがどうなるかを予想して書いてください。

復旧が何を元に戻すのかを確認する

k0s restoreで復旧し、結果を保存してください(保存先: /root/k0s/restore.txt)。canaryは残り、ステップ5で作ったものは消えている必要があります。

k0s stop → k0s restore <파일> → k0s startの順です(プレースホルダーはファイル名です)。停止せずに復旧すると、動いているetcdと衝突します。

k3sとの違いを整理する

k3sとk0sの違いを整理してください(書き込み先: /root/k0s/compare.md)。データストア、CNI、デフォルトのコンポーネントを含める必要があります。

データストア、CNI、デフォルトで入ってくるコンポーネントを軸に比較してください。どちらが優れているかではなく、どんな状況で何が合うのかが要点です。

何を学んだかをまとめる

store=etcd、service_cidr_dns=、restore_verified=の3行と説明を書いてください(書き込み先: /root/k0s/report.md)。

store=、service_cidr_dns=、restore_verified=の3行とあわせて、バックアップをなぜ復旧して確かめる必要があるのかを書いてください。