☸️ Introduction to Kubernetes

Why Orchestration?

A single container on your laptop is easy. Production is a different animal. Imagine your app is a hit: you now need ten copies of it spread over several servers, a way to send traffic evenly to all ten, automatic restarts when one dies, and a smooth way to ship a new version without downtime. Doing that by hand — SSHing into boxes, starting containers, editing load-balancer configs — is slow, error-prone, and impossible at 2 a.m.

Container orchestration is software that automates all of it. Think of it as an air-traffic controller for containers: you declare what you want in the sky, and it handles the takeoffs, landings, and re-routing.

What an orchestrator gives you

Kubernetes (abbreviated K8s — a "K", eight letters, then "s") is the most widely used orchestrator. It was born at Google, opened up in 2014, and is now stewarded by the Cloud Native Computing Foundation. This lesson is your conceptual map; you don't need to memorize every feature, just how the pieces click together.

💡 Is it overkill? For a tiny app on one server, yes — a single container or Docker Compose is simpler. Kubernetes earns its complexity when you have many services, real uptime requirements, and traffic that changes.

What Is Kubernetes?

Kubernetes is a platform that runs your containers across a group of machines and keeps them running the way you asked. You describe the desired state — "I want three copies of this web app, reachable on port 80" — and Kubernetes continuously works to make reality match that description.

The single most important idea is that Kubernetes is declarative. You don't write a script of steps ("start container, then start another…"). You hand it a description of the end goal, and it figures out the steps, over and over, forever.

Core capabilities in plain English

• Scaling: add or remove identical copies of a container on demand, manually or automatically.
• Self-healing: restart crashed containers, replace ones on dead machines, and stop routing traffic to unhealthy ones.
• Rolling updates & rollbacks: ship a new version gradually and undo it instantly if something breaks.
• Service discovery & load balancing: give a group of containers one stable name and one IP, and share traffic across them.
• Config & secret management: inject settings and passwords without rebuilding images.

Cluster Architecture

A Kubernetes cluster is a set of machines working as one. Every machine is a node, and nodes come in two roles. The control plane is the brain that makes decisions; the worker nodes are the muscle where your containers actually run.

The restaurant analogy helps: the control plane is the kitchen manager and order system — it decides what gets cooked and where. The worker nodes are the cooks at their stations, doing the actual cooking. You (through kubectl) are the customer placing an order; you never talk to the cooks directly.

Control plane components

• API Server: the front door. Every command and every component talks through it. When you run kubectl, you're calling this API.
• etcd: a reliable key-value store that holds the entire cluster state — the single source of truth for what should exist.
• Scheduler: watches for new pods that have no home yet and picks the best node to run each one, based on available CPU and memory.
• Controller Manager: runs the control loops that notice "reality drifted from desired state" and take corrective action.

Worker node components

• kubelet: the agent on each node. It takes instructions from the API server and makes sure the assigned containers are actually running and healthy.
• kube-proxy: handles the networking rules that let traffic reach the right pods.
• Container runtime: the software that actually runs containers — containerd is the common choice today (Docker Engine used one under the hood too).

Core Objects: Pods to Services

Kubernetes gives you a handful of building blocks. They nest: a Deployment manages a ReplicaSet, which manages Pods, which wrap your containers. A Service sits in front to provide a stable address. Let's build up from the smallest piece.

Pod — the smallest unit

A pod is the smallest thing Kubernetes runs. It usually holds a single container plus shared network and storage. Pods are ephemeral — they can be killed and replaced at any time, and each replacement gets a new IP. That's why you never rely on a pod's address directly.

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels:
    app: web          # labels are how other objects find this pod
spec:
  containers:
    - name: web
      image: nginx:1.27   # a real, current image tag
      ports:
        - containerPort: 80

You rarely create bare pods yourself, though — because if that pod dies, nothing brings it back. For that you use a Deployment.

Deployment — the object you actually use

A Deployment describes a desired state for a set of identical pods: which image, how many copies, and how to update them. It creates a ReplicaSet behind the scenes whose only job is to keep exactly that many pods alive. If a pod dies, the ReplicaSet makes a new one — that's self-healing in action.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3               # desired state: always keep 3 pods
  selector:
    matchLabels:
      app: web              # this Deployment owns pods labeled app=web
  template:                 # the pod blueprint to stamp out
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80

Service — a stable front door

Pods come and go, so their IPs are unreliable. A Service gives a group of pods (chosen by label) one stable DNS name and virtual IP, and load-balances traffic across them. Your other apps talk to the Service name, never to individual pods.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web              # send traffic to every pod labeled app=web
  ports:
    - port: 80            # the Service's port
      targetPort: 80      # the container's port
  type: ClusterIP         # reachable inside the cluster (the default)

Desired-State Reconciliation

Everything above rests on one loop. A controller constantly compares the desired state (what your YAML says) with the actual state (what's really running) and acts to close the gap. This is called reconciliation, and it's why Kubernetes feels alive.

Say you asked for 3 replicas and a pod crashes. Here's what unfolds — no human involved:

The same loop powers scaling (you change replicas: 3 to replicas: 5 and the controller creates two more) and rolling updates (you change the image and the Deployment swaps pods a few at a time, keeping the app up).

Working with kubectl

kubectl ("cube control") is the command-line tool that talks to the API server. The easiest way to get a cluster on your own machine is Minikube or kind (Kubernetes-in-Docker), or the one-click cluster built into Docker Desktop.

Spin up a local cluster

# Start a single-node local cluster with Minikube
minikube start

# Confirm kubectl can reach it
kubectl cluster-info
kubectl get nodes            # should list one Ready node

Deploy from a manifest

Save the Deployment and Service YAML from earlier into web.yaml (separated by a line with ---), then apply it:

# Create or update everything described in the file
kubectl apply -f web.yaml

# Watch it happen
kubectl get deployments      # see the Deployment and its replica count
kubectl get pods             # see the individual pods spin up
kubectl get services         # see the Service and its ClusterIP

The commands you'll use daily

# Inspect and debug
kubectl describe pod web-deployment-abc123   # full details and events
kubectl logs web-deployment-abc123           # a pod's stdout logs
kubectl exec -it web-deployment-abc123 -- sh # open a shell inside a pod

# Scale by editing desired state
kubectl scale deployment web-deployment --replicas=5

# Roll out a new image, then roll back if needed
kubectl set image deployment/web-deployment web=nginx:1.28
kubectl rollout status deployment/web-deployment
kubectl rollout undo deployment/web-deployment

# Clean up
kubectl delete -f web.yaml

$ kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
web-deployment-7d9f8c6b4-2xk9p    1/1     Running   0          20s
web-deployment-7d9f8c6b4-8mzq7    1/1     Running   0          20s
web-deployment-7d9f8c6b4-q4vlt    1/1     Running   0          20s

💡 apply, not create: Prefer kubectl apply -f over kubectl create -f. apply is idempotent — run it again after editing the file and Kubernetes computes just the difference, which is the whole declarative point.

Practice & Quiz

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 4
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/acme/api:2.1
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Best Practices & Pitfalls

✅ Do

• Manage apps with Deployments, not bare pods, so self-healing works
• Keep manifests in version control and deploy with kubectl apply -f
• Pin real image tags (e.g. nginx:1.27), never latest, so rollouts are predictable
• Use labels consistently — they're the glue between Deployments, Services, and pods
• Start local with Minikube or kind before touching a cloud cluster

❌ Don't

• Don't SSH into nodes to start containers by hand — you bypass the whole system
• Don't hard-code pod IP addresses; they change every restart
• Don't reach for Kubernetes on a one-container hobby app — Compose is simpler
• Don't forget that type: ClusterIP is internal only; you need NodePort or LoadBalancer for outside traffic

Summary

📚 Additional Resources

• Kubernetes — Overview and core concepts
• Kubernetes Basics — interactive tutorial
• kubectl reference documentation
• Minikube — get started locally

🚀 What's Next?

Kubernetes is the industry standard, but it isn't the only orchestrator — and it can be a lot to run. Next we look at Docker Swarm, Docker's simpler, built-in orchestration mode, and weigh when its lighter approach is the better fit.