Resources Kubernetes Kubernetes basics

Kubernetes basics · Lesson 1 of 12 · about 12 minutes

What Kubernetes solves

Before learning what a pod is, it helps to know what problem you're paying all this complexity to solve.

By the end you'll know

  • Why running containers on one server stops working as you grow
  • What "desired state" means, the single biggest idea in Kubernetes
  • The main parts inside Kubernetes, and what each one is for
  • When you don't need Kubernetes at all

New to containers? Start with Docker basics, which covers images and containers from scratch. This track assumes you've run a container before.

The problem

You've packaged your app in a container, and docker run on one server works. Then real life arrives: the app crashes at 3 AM, the server reboots for an update, traffic doubles, or you need to ship a new version without taking the site down. Do it for ten apps across five servers, and you're spending your days restarting things by hand.

What Kubernetes does

You stop giving step-by-step orders. Instead you describe what you want, and Kubernetes keeps making reality match it, all day, every day:

  • A container crashes: it's restarted.
  • A machine dies: its work moves to machines that still have room.
  • You ship a new version: copies are replaced a few at a time, so the site stays up.
Think of a thermostat. You don't switch the heater on and off yourself; you set 70 degrees and it keeps adjusting. That target is called the desired state.

The big picture

What Kubernetes doesYou declare what you want in a file: two copies of an app. Kubernetes sits in the middle and runs a loop: watch, compare, fix, and repeat, all day. On your machines, copy 1 is running, copy 2 has crashed, and Kubernetes has started a new copy 2 to replace it, without you doing anything.Youdeclare what you want,once, in a filereplicas: 2Kuberneteskeeps reality matching your fileWatchCompareFixrepeat, all dayYour machinesCopy 1runningCopy 2crashedNew copy 2started by KubernetesYou never restart anything yourself. You change the file, and Kubernetes makes it true.
Kubernetes sits between you and your machines. You say what you want once; it keeps checking and fixing, so a crashed copy is replaced without you. Lesson 2 opens up the box in the middle.

What's inside the box

You don't need to memorize these yet. Lesson 2 shows each one running on your own laptop. For now, just know what each part is for:

  • API server: the front door. Every request to the cluster, including yours, goes through it.
  • etcd (say "et-see-dee"): the cluster's memory. It stores your desired state.
  • Scheduler: decides which machine each new copy of your app runs on.
  • Controllers: the thermostats. They compare what you asked for with what's actually running, and fix the difference.
  • Kubelet: an agent on every machine that starts the containers it's told to run and reports back.

The first four together are called the control plane, the brain of the cluster. The machines that run your apps are called worker nodes.

What desired state looks like

You write it down in a file. This one says "keep two copies of the nginx web server running":

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 2          # how many copies to keep running
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: hello
          image: nginx:1.27

Don't worry about every line yet. Lesson 4 reads a file like this line by line.

In my real cluster

Self-healing is powerful, and it can hide problems. In October, my Prometheus monitoring kept running out of memory. Kubernetes did exactly its job and restarted it, 2,012 times in 9 days. Nothing was "down" for long enough to look broken, so nothing told me. Kubernetes keeps things running; it doesn't tell you why they keep failing. That's what monitoring is for.

When you don't need it

One small app with steady traffic runs perfectly well on a simple hosting service, and costs less. Kubernetes earns its keep when you have several services, need them to survive failures on their own, or want every change to go out the same repeatable way.

Check yourself

  1. What does desired state mean in Kubernetes?

  2. Your app's container crashes at 3 AM. What does Kubernetes do?

  3. In the thermostat comparison, what's the equivalent of setting the temperature to 70 degrees?

  4. My Prometheus restarted 2,012 times in 9 days and nothing looked broken. What's the lesson?

  5. Which part of Kubernetes is the front door that every request goes through?

  6. When might you not need Kubernetes at all?

Key terms

  • Cluster: a group of machines Kubernetes manages as one.
  • Node: one machine in the cluster.
  • Control plane: the parts that decide what runs where and keep checking it.
  • Pod: the smallest thing Kubernetes runs, one or more containers together. (Lesson 3.)
  • Desired state: what you've declared you want; Kubernetes works to keep it true.

Go deeper

From www.kwamib.dev/resources/kubernetes/what-kubernetes-solves