kubernetes the hard way: what the 13 labs leave running on your machine

No scripts is the design, and lab 13 exists because of it

The repository description is two sentences: bootstrap Kubernetes the hard way, no scripts. That single constraint explains the shape of everything else. There is no installer, no Terraform, no shell wrapper to re-run, so each of the thirteen labs is a list of things you type, in order, and the state left behind by a lab is the input to the next one. It also means nothing here is idempotent. A command you mistype leaves a certificate, a config file or a running unit on a machine, and the guide cannot clean that up for you, which is exactly why `docs/13-cleanup.md` exists as the final lab rather than as an appendix. The trade is deliberate: you see every task a cluster bootstrap requires, at the cost of not being able to automate the repetition. A reader who wants a cluster on Friday is pointed elsewhere by the README itself, which says the guide is not for someone looking for a fully automated tool.

Four machines, one control plane node, two workers

The cluster you end up with is deliberately small and the shape matters more than the size. Every control plane component runs on a single node, and there are two worker nodes, which the README calls enough to learn the core concepts. One control plane node means there is no control plane redundancy in the exercise, so the failure domains that dominate production design are out of scope by construction. The hardware requirement is stated plainly: four ARM64 or AMD64 based virtual or physical machines connected to the same network, and the same network qualifier is doing real work because the later labs deal with pod network routes between nodes. Budget accordingly before you start. Provisioning the compute resources is its own lab, `docs/03-compute-resources.md`, so a bare set of four machines is the input and everything from addresses onward is what the tutorial teaches.

The labs are numbered markdown files, and the README is only a table of contents

Everything you learn is in `docs/`, in an order that builds the cluster from the network upward. The sequence runs prerequisites, setting up the jumpbox, provisioning compute resources, provisioning the CA and generating TLS certificates, generating Kubernetes configuration files for authentication, generating the data encryption config and key, bootstrapping the etcd cluster, bootstrapping the Kubernetes control plane, bootstrapping the worker nodes, configuring kubectl for remote access, provisioning pod network routes, a smoke test, and cleanup. Read that list as a dependency graph. The encryption key in lab six is what the etcd and control plane labs encrypt data with, and the CA from lab four is what every later certificate is signed by, so a skipped lab does not produce a smaller exercise, it produces a broken one. The jumpbox in lab two is the machine you issue commands from, which is also what tells you where you should be running kubectl from when you get to lab ten.

Component versions are pinned to lines that were current in 2025

The cluster details section pins four components to minor lines: kubernetes v1.32.x, containerd v2.1.x, cni v1.6.x and etcd v3.6.x. Those are the versions the commands in the labs were written against, and the last push to the `master` branch was on 2025-04-10, so the snapshot is frozen at that point. Two honest options, and no third. Follow the labs exactly and learn a control plane from the kubernetes 1.32 era, which is coherent and what most readers do, or update each lab yourself as components move and own every command you change. Substituting versions halfway is the worst of both, because the labs assume a specific combination of flags and file layouts and a mismatch shows up as an unexplained failure several labs later. If your goal is a cluster you can actually run, this tutorial is the wrong input, and the README's own warning says as much.

ca.conf, configs/, units/ and two download lists are what the labs leave on disk

The top level of the repository is a map of the artefacts a run produces, which makes it easy to see what you are meant to understand. `ca.conf` sits at the root because the certificate authority in lab four is the root of trust for everything that follows, so the configuration is shared and committed while the keys and certificates your run generates are not. `configs/` is where component configuration is assembled, and `units/` holds the systemd unit files that the control plane and worker labs install, which is the part people usually underestimate: a control plane is a set of long-running processes with restart policies, and the lab makes you write those files instead of accepting a package. Two more files are worth a look. `downloads-amd64.txt` and `downloads-arm64.txt` are per architecture lists of what the labs fetch, which is how one set of instructions works on both architectures the README allows. When you finish, treat `ca.conf` and everything under `configs/` and `units/` on your machines as production material, because they describe the trust and startup path of the cluster you just built.

The tutorial says its own results are not production ready

The README puts a warning above the lab list, and it is the most useful sentence in the file: the results of this tutorial should not be viewed as production ready, and may receive limited support from the community, with the note that this should not stop you from learning. Take both halves seriously. There is no issue SLA behind a cluster you assembled by hand from a pinned 2025 snapshot, and a reader who copies the resulting configuration into something real inherits single control plane node, a locally generated CA and whatever pod network defaults the labs used. The stated target audience is someone who wants to understand the fundamentals of Kubernetes and how the core components fit together, and the cluster details section says the shape is enough to learn the core concepts. That is the contract: comprehension, not a deployment. There are also no GitHub releases in this repository, so there is no versioned artifact to pin, only the commit you read.

The README names one licence and the repository metadata names another

There is a licensing inconsistency here that anyone republishing the work or building training material on it has to resolve. The repository is recorded as Apache-2.0, with a `LICENSE` file at the root, while the README's Copyright section states that the work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, and a `COPYRIGHT.md` file sits alongside. Those are different promises: one is permissive, the other carries a non-commercial condition and a share-alike requirement. This is not a licence opinion, just the observation that the two statements in the repository do not agree, so anyone using this beyond personal study has to read `COPYRIGHT.md` and `LICENSE` and decide which terms apply to the material they are copying. `CONTRIBUTING.md` is present as well, so the repository does have a written path for changes, even though the project has no release history to publish them in.

Editorial conclusion

Work through Kubernetes The Hard Way when you need to understand what the control plane components do and how they are wired to certificates and etcd, and you can give it four machines and a day. Do not adopt the cluster it produces, because the tutorial says the results are not production ready and community support is limited, and do not expect the commands to match a current install without editing every lab. Before you start, read COPYRIGHT.md and LICENSE, since the repository metadata and the README name different licences, and decide which component versions you are studying, because the labs pin kubernetes v1.32.x, containerd v2.1.x, cni v1.6.x and etcd v3.6.x while the last push was on 2025-04-10.

Frequently asked questions

Official sources

1. Official README
2. Project repository