Stand Up k0s and Restore etcd

This lab runs on a real k0s

A single k0s machine is actually running inside the VM, and its control plane storage is etcd. That means you can really do backup and restore.

kwok, which runs the other labs in the certification track, is a fake control plane, so neither k0s backup nor etcdctl means anything there.

It takes about 3 minutes to come up the first time.

Goal

Check the configuration of the k0s cluster, then run through backup → change → restore once and see with your own eyes what a restore actually reverts. Then summarize the differences from k3s.

Why it matters

A backup is only a backup if you have restored from it at least once. A backup that you only took and never tested by restoring is "something you believe exists", not a backup. Backups that turn out to be unusable are not rare, and that fact always shows up at the worst possible moment.

It is also important to know exactly what a restore reverts. An etcd restore "rolls the cluster back to that point in time". Everything created after the backup is gone. If you don't know this, a second incident follows the restore: "why is what we created yesterday missing?"

This lab creates that situation on purpose. You take a backup, create something afterward, restore, and confirm that it is gone.

Steps

1. Save k0s status and the node status to /root/k0s/status.txt.
2. Confirm with k0s etcd member-list that the storage is etcd and save it to /root/k0s/etcd.txt, and also write why this would fail in --single mode.
3. Check the Service CIDR range of this cluster and save it to /root/k0s/cidr.txt, and write why the default range was not used.
4. Create a ConfigMap named canary (v=before), take a backup with k0s backup, and record it in /root/k0s/backup.txt.
5. After the backup, create one more ConfigMap and write its name to /root/k0s/disaster.txt as after_backup=<이름> (the placeholder is the ConfigMap name). Also write your prediction of what will happen to it when you restore.
6. Restore with k0s restore and save the result to /root/k0s/restore.txt. canary must still be alive and the one from step 5 must be gone.
7. Summarize the differences between k3s and k0s in /root/k0s/compare.md. It must cover storage, CNI, and default components.
8. In /root/k0s/report.md, write the three lines store=etcd, service_cidr_dns=, and restore_verified=, along with an explanation.

Notes

• k0s does not install a standalone kubectl. Use it as k0s kubectl, or, as in this environment, symlink kubectl to the k0s binary.
• The backup is k0s backup --save-path /root. The restore is k0s restore <파일> (the placeholder is the backup file) after stopping k0s, and then you start it again.
• The order of the restore procedure matters. It is k0s stop → empty the existing etcd data → k0s restore <파일> (the placeholder is the backup file) → k0s start.
• If you skip the middle step, the restore command succeeds but the data stays as it was. When the data directory already exists, etcd uses it and ignores the snapshot. No error and no warning appear, so believing you have restored is the most dangerous part.
• Common mistake 1: setting up with k0s install controller --single and then trying to do the etcd lab. In that mode the storage is kine (sqlite), so every k0s etcd command is rejected.
• Common mistake 2: checking right away after a restore without waiting for kubectl to respond. The control plane needs time to come back up.

What is running

Save k0s status and the node status to /root/k0s/status.txt.

k0s status tells you the role and whether workloads run. Workloads: true means this controller also acts as a worker.

What is the storage

Confirm with k0s etcd member-list that the storage is etcd and save it to /root/k0s/etcd.txt, and also write why this would fail in --single mode.

If k0s etcd member-list succeeds, it is etcd. If it is kine (sqlite), the command rejects it with 'wrong storage type'.

Why the default range was not used

Check the Service CIDR range of this cluster and save it to /root/k0s/cidr.txt, and write why the default range was not used.

This VM runs inside a Kubernetes cluster. Think about what happens if it overlaps with the DNS server address the host provided.

Take a backup

Create a ConfigMap named canary (v=before), take a backup with k0s backup, and record it in /root/k0s/backup.txt.

To verify a restore, you need a marker of 'what existed at backup time'. One ConfigMap is enough.

Create something after the backup

After the backup, create one more ConfigMap and write its name to /root/k0s/disaster.txt as after_backup=<이름> (the placeholder is the ConfigMap name). Also write your prediction of what will happen to it when you restore.

A restore rolls the cluster back to the backup point. Write down your prediction of what will happen to what you created afterward.

What the restore reverts

Restore with k0s restore and save the result to /root/k0s/restore.txt. canary must still be alive and the one from step 5 must be gone.

The order is k0s stop → k0s restore <파일> (the placeholder is the backup file) → k0s start. If you restore without stopping, it conflicts with the running etcd.

How it differs from k3s

Summarize the differences between k3s and k0s in /root/k0s/compare.md. It must cover storage, CNI, and default components.

Compare along the axes of storage, CNI, and the components that ship by default. The point is not which is better but what fits which situation.

What you learned

In /root/k0s/report.md, write the three lines store=etcd, service_cidr_dns=, and restore_verified=, along with an explanation.

Along with the three lines store=, service_cidr_dns=, and restore_verified=, write why you should restore from a backup at least once.