Skip to content

One binary, four components, no manifests you wrote

Artifact — a serving k0s control plane on a fresh guest, plus a process tree and a table mapping each component you hand-started in module 3.1 to where it now lives and what supervises it.

Rests on — the hand-started apiserver and the whole of module 3.0. The contrast only lands because you did those first, which is why the phase orders them this way.

Topology — k0s-light, provisioned fresh. The pair cluster was destroyed at the end of module 3.5; provision per the strand. A baselined guest has no container runtime on it and step 1 does not need one: k0s ships its own.

Do

  1. Install and start it. Time yourself from first command to serving cluster, and compare against the time module 3.0 took:
curl -sSLf https://get.k0s.sh | sudo sh
sudo k0s install controller --single
sudo k0s start
sudo k0s status
sudo k0s kubectl get nodes
  1. Before reading any k0s documentation, look at the process tree and work out the architecture from it:
ps -ef --forest | sed -n '/k0s/,$p'
sudo ls -l /var/lib/k0s/bin/
sudo ss -ltnp | grep -E '2379|2380|6443|10257|10259'

The bin directory is the answer to the question the phase's ecosystem note poses: are the components gone, or hidden?

  1. Build the mapping table. For each of kube-apiserver, kube-controller-manager, kube-scheduler, etcd:
Component Separate process? Parent Config you would have written Where k0s put that config

Find the last column by looking, not by guessing: sudo find /var/lib/k0s -name '*.yaml' -o -name '*.conf' | head -40, and sudo k0s config create to see the full default with everything it did not make you decide.

  1. Ask what happened to the certificates. You signed every one of them by hand in module 3.0 and exercise 17:
sudo ls -l /var/lib/k0s/pki/
sudo openssl x509 -in /var/lib/k0s/pki/apiserver.crt -noout -subject -ext subjectAltName -dates

Compare the SAN list against the one you had to reason out by hand. Note what it included that you would have forgotten.

  1. Find the supervision. In the k0s source — clone it on the guest or read it on forge — locate the supervisor type that starts these as child processes and answer: what does it do when a child exits, and does it have a backoff? Cite file:line.

  2. Run a workload, to confirm this is a real cluster and not a demo:

sudo k0s kubectl create deploy web --image=nginx --replicas=2
sudo k0s kubectl get pods -o wide

Observe — the process tree above all. Then:

sudo k0s kubectl get pods -n kube-system
sudo journalctl -u k0scontroller -n 50

Expect — kube-system contains coredns, kube-proxy and a CNI, and no control-plane pods at all. There is no /etc/kubernetes/manifests. The components you have spent a month starting by hand are child processes of one supervisor, visible in ps and invisible to the API. A learner who arrived at k0s first would conclude the control plane is a single program; you can say it is four programs with the seams pre-configured, and you can point at /var/lib/k0s/bin to prove it.

The SAN comparison in step 4 usually produces one entry you would have missed. Write down which.

Footprint note — 2.0GB of the 9.5GB ceiling, the cheapest topology in the phase, and it is the only thing running: pair is gone and forge is idle. If forge is still at the 2560MB module 3.1 raised it to, that is fine here and nothing needs changing — but note that the phase's peak was module 3.3, not this.

Teardown — delete the Deployment. The topology stays — killing the process needs exactly this cluster.