The same cluster, every time.
Repeatable scripts stand up a multi-node MicroK8s cluster — a primary node, the lab addons, workers that join, and a kubeconfig. Lab clusters are built the same way every time — not a pile of one-off SSH.
The problem
A MicroK8s cluster assembled by hand is a memory. The primary was installed in a session. Addons were enabled when someone remembered them. A worker joined from a command still sitting in scrollback. The next rebuild is slower than the first, and the next cluster does not match.
The shape
The procedure has a fixed order. Bootstrap the primary. Enable the addon set the lab expects. Join each worker the same way. Write a kubeconfig an operator or GitOps can use. Machines change. The sequence does not.
Primary
Install MicroK8s and form the cluster. This is the node workers join.
Addons
Turn on the lab standard set, in the same order, on every build.
Join
Each additional node runs the same join. A new worker is a script run.
Delivery
Run the scripts in order. The primary comes up, addons match the lab standard, workers join, and a helper writes a kubeconfig for the cluster that just came up. A rebuild follows the same path as the first build.
Why this shape
Clusters get reinstalled. An addon enabled by hand never makes it onto the next build. A join command lives in a terminal history. Scripts make the shape explicit: a primary, a known addon set, workers that join, and a kubeconfig that is a result of the run. GitOps can assume the cluster already looks like this.
← Projects