Module 1: Kubernetes Foundations

The Problem Kubernetes Solves

Containers made it easy to package an application with everything it needs. But packaging is only half the job. Once you have ten, fifty or five hundred containers spread across several servers, someone has to decide where each one runs, restart the ones that crash, add more copies when traffic grows and route requests to healthy copies only. Doing that by hand does not scale. Kubernetes exists to do that work for you, continuously and automatically.

Life before orchestration

Imagine you run the backend for a small Nairobi delivery app. You have an API, a worker that sends SMS confirmations and a database. At first you run each as a Docker container on one virtual machine. It works, until it does not:

• The machine reboots after a kernel update and nobody remembers the exact docker run flags to bring the API back.
• A Friday evening promotion triples traffic. You need more copies of the API, on more machines, behind a load balancer, and you need them in minutes.
• The SMS worker leaks memory and dies at 3 a.m. It stays dead until someone notices that customers are not receiving confirmations.
• Releasing a new version means stopping the old container and starting the new one, with a few seconds of errors for every user in between.

Each problem can be solved with scripts, cron jobs and monitoring, but every team ends up writing the same fragile glue. Kubernetes replaces that glue with one consistent system.

What Kubernetes actually does

Kubernetes (often written K8s) is an open-source container orchestration platform. It started at Google, drawing on lessons from Google's internal systems, and is now maintained under the Cloud Native Computing Foundation. Its core jobs are:

• Scheduling: choosing which server (node) each container should run on, based on available CPU, memory and rules you set.
• Self-healing: restarting failed containers, replacing them when a node dies and withholding traffic from containers that are not ready.
• Scaling: running more or fewer copies of an application, manually or automatically based on load.
• Service discovery and load balancing: giving a group of containers one stable name and address and spreading traffic across them.
• Rolling updates and rollbacks: replacing old versions with new ones gradually, and going back if something breaks.
• Configuration and secrets: injecting settings and credentials without rebuilding images.

The key idea: desired state

The most important concept in this whole course is declarative, desired-state management. You do not tell Kubernetes "start a container now". You describe what you want the world to look like, usually in a YAML file, and Kubernetes works constantly to make reality match that description.

Here is a small worked example. This file says "I want three copies of the delivery API running the image delivery-api:1.4":

apiVersion: apps/v1
kind: Deployment
metadata:
  name: delivery-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: delivery-api
  template:
    metadata:
      labels:
        app: delivery-api
    spec:
      containers:
      - name: api
        image: delivery-api:1.4
        ports:
        - containerPort: 8080

You submit it with kubectl apply -f deployment.yaml. Kubernetes records your desired state and its controllers start three copies. If one crashes, a controller notices that only two are running while three are desired, and starts a replacement. If a whole node fails, the copies on it are recreated elsewhere. You never wrote a restart script; the reconciliation loop is the restart script.

This loop (observe the current state, compare it with the desired state, act to close the gap) runs all the time for every kind of object in the cluster. Once you understand it, most Kubernetes behaviour stops being surprising.

When Kubernetes is the wrong tool

Kubernetes is powerful, but it has real costs: more concepts to learn, more components to monitor and, if you run it yourself, upgrades and security patches for the cluster itself. A single small website with one container is usually better served by a simple virtual machine, a platform-as-a-service or a serverless container product. Kubernetes pays off when you have several services, need high availability, deploy often or want one consistent platform across clouds and on-premises data centres.

Common mistakes to avoid

• Thinking imperatively. Starting things by hand and then wondering why Kubernetes "undoes" your changes. Change the YAML and re-apply it instead.
• Adopting Kubernetes for one tiny app. Match the tool to the problem.
• Assuming Kubernetes fixes a bad application. If your app stores data on its own disk or cannot run as several copies, orchestration will not save it. Design for multiple stateless replicas where you can.