“It works on my machine.”

Whoever works with software has heard this phrase. Containers solved part of the problem: the application carries its libraries, runtime, and configuration. But a container alone doesn't answer questions like:

• Who guarantees the application stays up if the process dies?
• How to distribute 20 containers among 6 servers without a spreadsheet?
• How to update a version without bringing everything down?
• How to give a stable name to a service whose IPs change all the time?

Kubernetes is the answer to these questions. It is an orchestrator: you declare the desired state and it tries to keep reality aligned with that state.

Course Seal: concepts valid for Kubernetes 1.35. The lab commands are tested on Ubuntu 24.04.

Container is not a VM

A VM virtualizes the hardware: each VM has its own kernel, drivers, boot. A container shares the host kernel and isolates processes with namespaces and cgroups.

	VM	Container
Weight	GBs	MBs
Boot	seconds/minutes	milliseconds
Kernel	own	shares the host's
Isolation	strong (virtual hardware)	good (process)
Density	dozens per host	hundreds per host

This explains why containers are fast and why a small image matters. It also explains why 'container is not absolute security': isolation is at the process level, not hardware.

What Kubernetes actually does

Kubernetes doesn't 'run containers' in the sense of executing the binary. What runs them is the container runtime (containerd, CRI-O, Docker via shim). Kubernetes decides where, how many, and how they run.

The model is declarative:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal
spec:
  replicas: 3
  selector:
    matchLabels:
      app: portal
  template:
    metadata:
      labels:
        app: portal
    spec:
      containers:
        - name: portal
          image: nginx:1.27
          ports:
            - containerPort: 80

You say 'I want 3 replicas'. Kubernetes compares with reality. If there are 2, it creates 1. If there are 4, it removes 1. This cycle is called reconciliation.

The condominium

Think of the cluster as a condominium:

• API Server is the front desk: every request goes through it.
• etcd is the registry book: stores the state of the condominium.
• Scheduler is the superintendent: decides in which apartment (node) each resident (pod) will stay.
• Controller Manager is the administration: enforces what is outside the regulations.
• kubelet is the janitor of each tower: ensures that the residents of its node are there.
• container runtime is the company that effectively delivers the change.
• CNI is the plumbing system between apartments.
• kube-proxy is the central for forwarding visitors.

Each piece has a simple role. Complexity appears when many pieces need to agree.

Control plane and workers

Component	Where it runs	Function
kube-apiserver	control plane	single point of entry and validation
etcd	control plane	key-value database for state
kube-scheduler	control plane	chooses the node for the pod
kube-controller-manager	control plane	reconciles controllers
kubelet	worker	executes and monitors pods on the node
container runtime	worker	pulls image and runs container
kube-proxy	worker	network rules for Services
CNI	worker	pod networking

In a lab cluster, control plane and workers can be on the same machine. In production, you separate them. In this course, we will separate from the start — including to understand what breaks when a node goes down.

Pod: the smallest unit

A pod is one or more containers that share network and volumes. In practice, 90% of pods have one container. The pod is ephemeral: it is born, dies, and is recreated with another IP.

That's why you almost never create pods directly. You create Deployments, which create ReplicaSets, which create pods. The Deployment ensures the number of replicas and the rollout history.

Deployment -> ReplicaSet -> Pod(s)

What Kubernetes doesn't solve

• Doesn't write your application.
• Doesn't replace observability: without metrics and logs, you are blind.
• Doesn't replace backup: persistence without tested restore is faith.
• Doesn't prevent human error: wrong YAML remains wrong YAML.
• Is not high-availability magic: if the database is single-node, the cluster won't save it.

Chapter Lab

In this chapter we won't set up the cluster yet. We'll just prepare the client and understand the terrain.

1. Install kubectl

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client

2. Install kind (optional, for a disposable cluster)

curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind
kind create cluster --name curso
kubectl get nodes

If you don't want kind now, that's fine: in chapter 02 we set up the real cluster with kubeadm.

3. Explore the API

kubectl api-resources | head -30
kubectl explain pod.spec.containers | head -30

kubectl explain is the documentation that lives in the cluster. Use and abuse it.

4. Create and observe a pod

kubectl run ola --image=nginx:1.27 --port=80
kubectl get pods -o wide
kubectl describe pod ola | tail -20
kubectl logs ola
kubectl delete pod ola

Notice: the pod got an IP, was scheduled on a node, and when deleted, it disappeared. If you had created a Deployment, it would come back.

Common errors at this stage

Symptom	Likely cause
The connection to the server was refused	wrong kubeconfig or cluster turned off
error: You must be logged in	missing context/kubeconfig
ImagePullBackOff	nonexistent image, private registry or no credential
CrashLoopBackOff	container starts and dies; see kubectl logs --previous
Pod Pending	no resources, nodeSelector/taint, or unbound PVC
YAML “doesn't apply”	indentation, unknown field, or kubectl apply on the wrong file

Checklist

• [ ] I know the difference between VM and container.
• [ ] I understood desired state and reconciliation.
• [ ] I know the role of API server, etcd, scheduler, controller, kubelet, CNI, and kube-proxy.
• [ ] I understood that pod is ephemeral and Deployment is the right level.
• [ ] I installed kubectl and ran kubectl version --client.
• [ ] I created and removed a pod.

Glossary

• Cluster: set of nodes managed by a control plane.
• Node: machine (physical or VM) that runs pods.
• Pod: smallest unit of execution.
• Deployment: controller that ensures replicas and rollout.
• ReplicaSet: ensures a number of pods of a version.
• CNI: pod network plugin.
• etcd: cluster state database.
• kubeconfig: cluster access file.

Next

In chapter 02 we will move from theory and set up the lab: 6 VMs, network, containerd, and the first kubeadm init.

Next: Course Kubernetes 02 — Setting Up the Lab: 6 VMs and a Cluster That Fits in Your Pocket