0 of 15 done
Start here

Orientation

You can already deploy to a Kubernetes cluster that someone else set up. This course is about the part underneath: how the cluster itself comes online, one component at a time, on machines you control. By the end you will have built a small working cluster by hand and you will keep it as your own starting point to change and grow.

Read this page once before lab 01. It gives you the single idea that makes every later step make sense.

How the course is organized

The course has three parts. Each part has a clear job.

  • Provision the ground (labs 01 to 03). Get four machines running, reachable, and named. You will run all four on your own Mac. Nothing about Kubernetes yet. You are preparing the ground you will build on.
  • Bring it online (labs 04 to 09). Create every piece of security identity first, then start the running parts in the right order. This is the core of the course.
  • Prove it works (labs 10 to 12). Get operator access, finish the pod network, and run a set of tests that confirm the cluster does what a cluster should do.

The one idea: a cluster brings itself online in order

A Kubernetes cluster is a set of programs that depend on each other. You cannot start them all at once, because some need others to already be running. The whole build follows from two rules about that order.

Identity comes before anything runs. Every component proves who it is with a certificate, and every connection between components is checked. So you create the certificate authority, all the certificates, the kubeconfig files, and the encryption key first, in labs 04 to 06. Nothing is started during those labs. You are making the trust material that the running parts will need the moment they start.

Runtimes start in dependency order. In labs 07 to 09 you start the running parts in the order their dependencies allow:

  • etcd first, because it stores all cluster state and everything else reads and writes it.
  • The control plane next, and within it the API server first, because the controller manager and the scheduler both talk to the API server.
  • The worker nodes last, because a worker needs to reach a running control plane to join.

The word for bringing a component online when it has no prior state to start from is bootstrap. You will see it in the lab titles for etcd, the control plane, and the workers. Each one has a small starting problem: it needs something to exist before it can exist. You solve that by supplying the starting condition from outside, which is exactly what the earlier identity labs prepared.

How each lab is written

Every lab has the same shape so you always know where you are:

  • Where you are. A short note on what this step is and why it happens now.
  • The steps. The commands to run and the output to expect. Run them in order.
  • Key terms. Plain definitions of any new words the lab introduces.
  • Reflect. One question to help you carry the idea to other systems.

A few labs include a short PHI lens note. PHI means protected health information, the kind of patient data a healthcare system handles. These notes point out where a choice in the cluster matters for keeping that data safe. They are optional context, not extra work.

What you need

  • A Mac with Apple Silicon (M1 or newer) and at least 16GB of RAM. The course was written on a 24GB machine.
  • Comfort with a terminal and SSH.
  • About a weekend of focused time.

When you are ready, start with the machine requirements.

Next: Prerequisites