You now know what Kubernetes does, how it is built inside and what every term in the vocabulary means. All of that was necessary theory, but Kubernetes is not learned by reading: it is learned by breaking things in a cluster of your own. This lesson has two parts. First, an honest overview of the real options for getting hold of a cluster —local, self-managed or managed in the cloud— with criteria for choosing in a professional project. And then, the step-by-step practical guide to building the practice cluster you will use throughout the twelve modules of the course, where we will deploy the Rutas Norte platform. By the end you will have a working environment, you will know how to stop it, resume it and destroy it without fear, and you will know the causes of the most common start-up failures.

1. The three routes to getting a cluster
2. The course practice cluster: requirements
3. Installing minikube and the driver
4. Starting the cluster with enough resources
5. Addons required for the course
6. Verifying the cluster
7. Lifecycle: stop, resume, destroy
8. The kind alternative and a multi-node cluster
9. Troubleshooting common start-up failures

Practical criteria for deciding:

• Are you learning or developing? Local. No argument: it is free, quick to recreate and it exposes nothing.
• Do you have a platform team with 24×7 on-call? If the answer is no, avoid self-managing production. Maintaining etcd, rotating certificates and upgrading three times a year is not a small job.
• Are there data sovereignty constraints or special hardware? Self-managed, with kubeadm or a commercial distribution.
• Ordinary production for an ordinary company? Managed. Rutas Norte will end up here: the control plane is the provider's problem and the team concentrates on the platform.

Each route has its own lesson later on: Minikube and Local Environments with kind, Kubeadm and Managed Kubernetes: EKS, AKS and GKE. Here we only build what we need to have a working environment.

We choose minikube as the main option because, through its addons, it ships two things we will need a lot: an Ingress Controller (module 4) and a dynamic storage provisioner (module 5). Installing those by hand in other tools is extra work that teaches nothing at this point. We also give the equivalent recipe with kind, which is lighter and makes multi-node clusters easy.

Rutas Norte will end up with six components deployed at once plus the observability add-ons, so it is worth not skimping on resources.

You also need kubectl, whose installation and use are covered in detail in the next lesson, The Kubernetes CLI: kubectl. If you do not have it yet, minikube can run it for you with minikube kubectl -- <command>, although the normal thing is to install it separately.

minikube creates the cluster inside something: a container or a virtual machine. That "something" is the driver.

We will use docker. Check that you have it and that your user can use it without sudo:

If the second command fails with permission denied, add your user to the docker group and log in again:

Linux (x86_64):

macOS (with Homebrew):

Windows (with winget, in PowerShell):

Verify the installation:

This is the command that defines your working environment for the whole course:

What each option does, and why:

Expected output (abridged):

Two important details in that output:

• The last line says that minikube has modified your kubeconfig and has created and activated a context called rutas-norte. That is what makes kubectl talk to this cluster.
• Two addons have already been enabled by default: default-storageclass and storage-provisioner. They are the ones that will let us ask for persistent volumes in module 5 without any real infrastructure.

If your machine has fewer resources, start with --cpus=2 --memory=4096 and bear it in mind: in module 7 you will have to switch components off to make room.

Addons are pre-packaged components that minikube installs into the cluster. Enable these three right away:

Check that the Ingress controller has started before moving on:

The two pods in Completed are not an error: they are installation Jobs that have already finished their work (remember from the previous lesson that a Job finishes, it does not stay running). The one that matters is the third, in Running and 1/1.

Three checks that are always worth doing after creating a cluster.

1. The node is ready:

What matters: STATUS: Ready (the kubelet is reporting and the network plugin works) and ROLES: control-plane (in minikube the same node acts as control plane and as worker, something that would never happen in production).

2. The system components are healthy:

Recognise this list: these are exactly the components from the lesson Kubernetes Architecture, now really running on your machine. Note that in minikube the control plane runs as pods inside the cluster itself (static pods managed by the kubelet), and that coredns appears, the internal DNS server we will study in module 4.

3. The API responds and you know which cluster you are talking to:

If the three checks pass, you have a working cluster.

A local cluster consumes resources even when you are not using it. These are the four commands you need:

Method tip: not being afraid of minikube delete is precisely the goal. If all your manifests are versioned in the repository's k8s/ directory —as we will do from lesson 01-07 onwards— recreating the cluster and reapplying them should take you five minutes. If deleting it scares you, that is a sign there is important state that is not in Git.

You will also find these useful:

kind (Kubernetes IN Docker) creates each node as a Docker container. It is lighter than minikube and its great advantage is how easy it makes building a multi-node cluster, something that will come in handy when we study scheduling and affinity (module 6). Its downside: it ships no addons, so Ingress and storage take extra steps.

Installing it on Linux:

A configuration file with one control node and two workers, also prepared for Ingress:

An explanation of the parts that matter:

• nodes: each entry is a Docker container that will act as a node. Here we will have three.
• extraPortMappings: without this, the cluster's port 80 would not be reachable from your browser. It is the equivalent of minikube tunnel.
• labels on the workers: node labels we will use to practise affinity and anti-affinity in module 6, simulating two availability zones.

Creating and verifying:

Installing the Ingress Controller (kind does not ship it) and deleting the cluster when it is no longer needed:

What to choose: if in doubt, minikube. Use kind when you need several nodes or when you build Kubernetes inside a continuous integration pipeline, where its creation speed is decisive.

General-purpose diagnostic commands when something goes wrong at start-up:

The third one is especially valuable and we will use it a lot: events are the cluster's diary and they almost always contain a plain-text explanation of why something did not work.

• Starting with the defaults (2 CPUs, 2 GiB). It works for the first modules and falls short as soon as you add observability. Sizing it properly from the start beats recreating the cluster halfway through the course.
• Not using --profile. If you work with several local clusters, the default profile becomes a source of confusion: you end up applying manifests to the wrong cluster. Naming the profile rutas-norte always makes it clear where you are.
• Changing the Kubernetes version between sessions. If one day you start with 1.30 and another without pinning a version, behaviours and APIs change. Pin the version in the command and write it down in the repository.
• Confusing "the cluster started" with "the cluster is ready". minikube start returns before the addons are operational. Always check with kubectl get pods -A that nothing is in Pending or ContainerCreating.
• Expecting a Service of type LoadBalancer to get an external IP. There is no cloud-controller-manager locally (we saw this in 01-02): it stays at <pending>. It is solved with minikube tunnel, and we will cover it in module 4.
• Leaving the cluster running permanently. It eats CPU and battery. minikube stop at the end of the session keeps absolutely everything.
• Tip: save your cluster creation command in the repository itself (for example, in k8s/local-environment/README or a create-cluster.sh script). It is as much a part of the project's documentation as the manifests are.

Build the practice cluster with the rutas-norte profile, 4 CPUs, 8 GiB and Kubernetes 1.30, enable the ingress and metrics-server addons, and answer:

1. How many nodes does it have and what role do they have?
2. How many pods are there in the kube-system namespace and which of them match the control plane components you studied in lesson 01-02?
3. What is the node's IP?
4. Which kubectl context is active?

Create the project's development namespace, stop the cluster, resume it and check whether the namespace still exists:

Explain why the result is what it is, mentioning where that object is stored. Then state which command would make that namespace disappear along with everything else.

Use kind to create a cluster called rutas-norte-multi with one control node and two workers labelled zone: north and zone: south. Check that the three nodes are Ready and list only the nodes in the north zone. Explain in two lines why this cluster will be useful to you in module 6 and why we do not use it as the course's main environment.

Solution 1

1. A single node, with the control-plane role. In minikube that same node also runs user workloads, which is not done in production: the control plane is reserved through taints.
2. Around eight pods. They match the architecture: etcd, kube-apiserver, kube-scheduler, kube-controller-manager (control plane), kube-proxy (node), plus coredns (internal DNS), storage-provisioner and metrics-server. cloud-controller-manager does not appear because there is no cloud provider.
3. minikube ip --profile=rutas-norte → typically 192.168.49.2.
4. kubectl config current-context → rutas-norte.

Solution 2

The namespace still exists after stop and start. The reason is that stop destroys nothing: it shuts down the node's container or VM while keeping its disk, and on that disk lives etcd, which is where the Namespace object resides. On resuming, the apiserver reads from that same etcd again and all the declared state reappears.

The command that would destroy everything is minikube delete --profile=rutas-norte, which removes the node and its disk, etcd included. That is why manifests must live in Git: recreating the cluster is then a formality.

Solution 3

It will be useful in module 6 because affinity, anti-affinity, taints and topology spread can only really be practised with several nodes: on a single-node cluster the scheduler has no decision to make. We do not use it as the main environment because kind includes no addons: you would have to install the Ingress Controller and a storage provisioner by hand, work that at this point in the course distracts from the goal.

You now have a Kubernetes cluster running on your machine, with the rutas-norte profile, version 1.30 pinned, enough resources for the whole course and the Ingress, metrics and dynamic storage addons enabled. You have also seen the full landscape of options —local, self-managed with kubeadm, managed in the cloud— and the criteria for choosing one or another in a real project, plus a multi-node alternative with kind for when we get to scheduling. And, above all, you know how to stop it, resume it and destroy it without fear, because the operational truth of this course is that the cluster is replaceable and the manifests are not.

You have the environment, but you have barely used the tool you are going to talk to it with. In the next lesson, The Kubernetes CLI: kubectl, we will master kubectl thoroughly: the kubeconfig file and contexts, the verbs you will use every day, the output formats, selection by labels and the productivity tricks that make the difference between fighting the cluster and working with ease.