What Kubernetes Is

Kubernetes is an open-source platform that runs and manages containerized applications across a group of machines. You hand it your containers and a description of how you want them to run, and it places them, keeps them alive, and connects them. The group of machines is called a cluster, and Kubernetes lets you treat it almost like one large computer.

The single idea that makes the rest of the system click is this: you do not tell Kubernetes what steps to take. You declare the end state you want, and a control loop works continuously to make reality match it. Self-healing, repeatable deployments, and recovery are not bolt-on features — they fall out of that one mechanism.

From Servers to Orchestration

A small team runs one app on a few servers, starts it by hand, and restarts it when it breaks. That works. Then the app grows: one service becomes ten, each needs several copies for capacity and failure tolerance, and a few servers become fifty. Now the manual habits hurt. Which machine has room for this copy? A container died at 3 a.m. — who restarts it? A server failed — who moves its work, and how fast?

Containers solved packaging. A tool like Docker lets you build an image once and run it the same way on a laptop, in test, and in production. But packaging one app is not the same as running thousands of containers across many machines without losing sleep. That missing piece is orchestration: deciding where containers run, restarting them when they fail, moving them when a machine dies, and helping them find each other.

Several orchestrators appeared in the 2010s. Kubernetes is the one that won. It came out of Google, which had run containers internally for years with a system called Borg, was open-sourced in 2014, and is now governed by the vendor-neutral Cloud Native Computing Foundation. You do not need that history to use it — only to know that the design reflects real experience running containers at very large scale.

What It Is, and What It Is Not

Two descriptions are both true: Kubernetes is a container orchestrator that runs your containers on a cluster and keeps them running, and it is an API plus a set of controllers that hold your applications in the state you asked for. Most confusion comes from expecting more than that.

• It is not a Platform as a Service like the early Heroku. It does not build your source code, choose your language, or guess how your app should run. You bring a built image and a description of how to run it.
• It is not a fix for application design. A poorly designed app does not become well-behaved just because it runs on Kubernetes.
• It does not scale your app for free. It can add and remove copies, but only the way you configure it to (Topic 27).
• It is not tied to one cloud. The same Kubernetes runs on your laptop, in your data center, and on every major cloud.

The Mental Model: Declarative Desired State

There are two ways to tell a computer to do something. The imperative way is step by step: start this container, now start another, the first died so restart it. You own every step, forever. Kubernetes works the declarative way: you describe the end state and let it work out how to get there. Instead of "start a container, then another, then watch them," you say "I want three copies of this app running, always." Keeping that true is Kubernetes' job, not yours.

You write desired state as an object — usually YAML — with a few stable parts: apiVersion and kind name the type, metadata names the object, and spec holds what you want. A Deployment with replicas: 3 is the whole instruction. You never tell Kubernetes to "start a copy" or "restart that one." You tell it the number you want, and the system does the rest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3            # desired state: always keep 3 running
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-app:1.0

Read only the middle line for now. replicas: 3 is the desired state; the rest names the object and describes the Pods it should create. The Deployment gets its own topic later — here it is just the smallest taste of what "declare what you want" looks like on disk.

The Reconcile Loop

The engine behind this is the reconciliation loop, and it is simpler than it sounds. You write down the desired state. Kubernetes constantly compares that desired state to the actual state in the cluster. When they differ, a piece of software called a controller takes action to close the gap. The loop never stops — it runs again and again, forever.

Walk one example. You asked for three copies. Three are running, so actual matches desired and nothing happens. Then one crashes; actual drops to two. The controller notices the gap and starts a new copy. Actual is back to three. Nobody paged anyone, nobody typed a command. This is why self-healing and recovery are not extra features bolted on — they are what a system that always compares "what I have" to "what I asked for" does by design.

A First Look at the Cluster

A cluster is two kinds of machines. The control plane is the brain: it decides what runs where and holds the desired state. The worker nodes are the muscle: they actually run your containers. The practical takeaway is that you almost never touch the nodes directly. You talk to the control plane's API, describe what you want, and it makes the nodes carry it out. That single front door is why Kubernetes feels consistent no matter where it runs.

Running the control plane yourself is real work, and the big clouds will do it for you. Amazon EKS, Google GKE, and Azure AKS all run a managed control plane so you worry mostly about your nodes and your apps. Cluster architecture is the subject of Topic 03, and the managed offerings get their own chapter.