Kubernetes Introduction

Kubernetes is a system that runs your containers across a group of machines and keeps them running. You tell it what you want, for example "three copies of my web app, version 2.1", and it starts them, watches them, replaces them when they crash and moves them when a machine fails.

In this lesson you will learn what problem Kubernetes solves, the idea of desired state that everything else is built on, and how to decide whether a project needs Kubernetes at all. This course assumes you already know containers and images. If you do not, start with the Docker tutorial first, because every Pod in Kubernetes runs ordinary container images.

The problem Kubernetes solves

Imagine Meera runs a small ticket-booking site for bus operators in Jaipur. She packs the app into a Docker image and runs it with Docker Compose on one server. That works well until festival season:

• Traffic jumps five times in one evening, and one server cannot handle it.
• The server's disk fails at 2 a.m. and the site is down until someone wakes up.
• Every deploy stops the old container and starts a new one, so users see errors for a few seconds.
• With three servers, someone has to decide which container runs where, and update that plan by hand whenever a server is added or removed.

Running many containers on many machines, and keeping them healthy, is called container orchestration. Kubernetes (often written K8s, because there are eight letters between the K and the s) is the most widely used orchestrator. The name comes from the Greek word for a ship's helmsman. Google open-sourced it in 2014, based on its experience with internal systems, and today it is maintained by a large open-source community under the Cloud Native Computing Foundation (CNCF).

Desired state: the one big idea

With Docker you give commands: "start this container", "stop that one". With Kubernetes you mostly give declarations: "this is what should exist". Kubernetes stores your declaration, compares it with what is really running, and acts to close the gap. This never-ending compare-and-fix cycle is called a reconciliation loop, and the programs that run it are called controllers.

Here is the idea in action on a small cluster. The first command declares a Deployment (a Kubernetes object that keeps a number of identical copies running) with three copies of an Nginx web server:

kubectl create deployment hello --image=nginx:1.30-alpine --replicas=3
kubectl get pods

deployment.apps/hello created
NAME                     READY   STATUS    RESTARTS   AGE
hello-p947wfgpc6-cl8jw   1/1     Running   0          38s
hello-p947wfgpc6-p42hh   1/1     Running   0          38s
hello-p947wfgpc6-q6gh7   1/1     Running   0          38s

Each line is a Pod, the smallest thing Kubernetes runs (one or more containers that live together). Now delete one Pod, as if it had crashed, and look again:

kubectl delete pod hello-p947wfgpc6-p42hh
kubectl get pods

pod "hello-p947wfgpc6-p42hh" deleted from default namespace
NAME                     READY   STATUS    RESTARTS   AGE
hello-p947wfgpc6-cl8jw   1/1     Running   0          71s
hello-p947wfgpc6-q6gh7   1/1     Running   0          71s
hello-p947wfgpc6-vntzl   1/1     Running   0          4s

You never asked for a new Pod. The Deployment's controller noticed that only two copies existed while three were wanted, and created hello-p947wfgpc6-vntzl within seconds. That is self-healing, and it comes directly from desired state.

What Kubernetes gives you

Kubernetes is also not a few things. It does not build your images (Docker or a CI pipeline does), it does not include databases or message queues (you run them on it or use a managed service), and it does not choose your logging and monitoring tools for you.

Everything is an object in YAML

In real projects you rarely type kubectl create. You write your desired state in YAML files called manifests, keep them in Git and apply them. This file describes the same Deployment as the command above:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: nginx
          image: nginx:1.30-alpine

You would apply it with kubectl apply -f hello.yaml. Every field is explained in YAML Manifests & kubectl apply and Deployments & ReplicaSets. For now, notice the shape: what kind of object, its name, and a spec that describes what you want.

Compose or Kubernetes?

Kubernetes is powerful, but it adds real work: more concepts, more YAML, and a cluster to upgrade and secure. A single VPS with Compose and good backups serves many small businesses perfectly well. Kubernetes starts to pay off when you need several machines for capacity or reliability, when many teams deploy many services, or when you need automatic scaling. Cloud providers also sell managed Kubernetes, where they run the control machines for you, which removes some of that work (see Managed Kubernetes).

Common mistakes

• Learning Kubernetes before containers. If images, ports and volumes are unclear, Kubernetes will feel like magic. Learn Docker first.
• Thinking "Kubernetes replaces Docker images". Kubernetes runs standard container images; you still build them with Docker or another builder.
• Fixing things by hand inside a running container. Kubernetes replaces Pods freely, so manual changes vanish. Change the image or the manifest instead.
• Choosing Kubernetes for a tiny app "because big companies use it". Match the tool to the problem.

Key points

• Kubernetes (K8s) orchestrates containers across many machines: scheduling, self-healing, scaling, updates and service discovery.
• You declare the desired state; controllers keep comparing it with reality and fix any difference.
• A Pod is the smallest unit Kubernetes runs; a Deployment keeps a set number of identical Pods alive.
• Desired state is written in YAML manifests that you keep in Git and apply with kubectl apply -f.
• Kubernetes adds complexity; Docker Compose on one server is often enough for small apps.

kubectl create deployment booking --image=ghcr.io/meera-jain/booking:2.1.0 --replicas=4

deployment.apps/booking created