To understand any tool, first understand the pain that made someone invent it.

The old world: one app, one server

Years ago, a company that wanted to run a website bought a physical computer, called a server, installed the operating system, installed the application, and switched it on. If the website became popular, they bought a bigger server. If the server broke at three in the morning, a person woke up and fixed it by hand.

This worked for small sites, but it was wasteful and fragile. Most servers sat mostly idle, like a huge restaurant kitchen open all night for two customers. And if one application needed a different version of a shared tool than another application, they fought each other on the same machine.

Virtual machines helped, but were heavy

The next idea was the virtual machine, or VM. A VM is a pretend computer running inside a real one, complete with its own operating system. Now each application could have its own private space. The flats now had private kitchens.

The catch was weight. Every VM carries a whole operating system, which takes gigabytes of storage and minutes to start. Running fifty of them wastes a great deal of memory just on repeated operating systems.

Containers made things light, and created a new problem

Containers arrived as a lighter answer. A container packs an application together with everything it needs to run, such as its libraries and settings, but shares the operating system core of the machine it sits on. Containers start in seconds and use far less memory than VMs.

Containers solved the shared-kitchen problem, but they created a management problem. A modern application is often split into dozens of small services, each in its own container, and each service may need several copies. Suddenly a team is juggling hundreds or thousands of containers spread across many machines. Who decides which machine each container lands on? Who restarts the ones that die? Who connects them so they can talk to each other? Doing this by hand is impossible.

Kubernetes is an open-source system that automates the running of containerized applications across a group of machines.

Let us unpack that sentence one piece at a time. Open-source means the code is public and free, and anyone can use it or help improve it. Automates means humans describe what they want and the system does the repetitive work. Containerized applications are programs packed into containers. A group of machines means it does not care whether you have three computers or three thousand; it treats them as one big pool of computing power.

The name comes from a Greek word meaning helmsman, the person who steers a ship. People often write it as K8s, where the 8 stands for the eight letters between the K and the s. Its logo is a ship’s wheel for the same reason.

What Kubernetes actually does for you

Kubernetes is a child of one of the largest computing operations on Earth.

Google runs services such as Search, Gmail and YouTube for billions of people. For many years, it ran them on an internal system called Borg, which managed enormous numbers of containers across its data centers. Borg taught Google engineers hard lessons about running software at scale, and those lessons became the foundation of Kubernetes.

You cannot understand the conductor without knowing the instruments.

A container image is like a sealed meal kit. Inside are your application, the exact libraries it needs and its settings. When you start the kit, you get a running container. Start the same image on your laptop, a colleague’s laptop or a giant cloud server, and it behaves the same way. That sameness is the big win: the classic complaint “it works on my machine” mostly disappears.

Where the images live

Images are stored in a registry, which works like a library of meal kits. Kubernetes pulls the image it needs from a registry whenever a machine has to start a container. Public registries hold popular open images, while companies usually keep private ones for their own applications.

Who actually runs the container?

Kubernetes itself does not start containers directly. It hands that job to a container runtime, a small program on every machine, such as containerd or CRI-O. Think of Kubernetes as the manager who gives instructions and the runtime as the worker who does the physical task.

Eight words unlock almost everything else. Learn these and the rest becomes easy.

The pod, explained slowly

Beginners often ask why Kubernetes does not just manage containers directly. The reason is that some programs need a helper sitting right beside them. A web server might need a tiny helper that collects its logs. Placing both in one pod means they always land on the same machine, share the same network address and can share files. Most pods hold just one container, but the option to group is useful.

Pods are also disposable. Kubernetes treats them like paper cups, not fine china. When a pod dies, it is not repaired; a fresh one is created to replace it. Each new pod gets a new address, and that is exactly why services exist, as we will see later.

Every Kubernetes cluster has two halves: a control plane that thinks and worker nodes that work.

flowchart TB
  subgraph CP[Control Plane - the brain]
    API[API Server]
    ETCD[(etcd - memory)]
    SCH[Scheduler]
    CM[Controller Manager]
  end
  subgraph N1[Worker Node 1]
    K1[kubelet]
    P1[kube-proxy]
    R1[Container Runtime]
    POD1[Pods]
  end
  subgraph N2[Worker Node 2]
    K2[kubelet]
    P2[kube-proxy]
    R2[Container Runtime]
    POD2[Pods]
  end
  USER[You and your tools] --> API
  API  ETCD
  SCH --> API
  CM --> API
  API --> K1
  API --> K2
  K1 --> R1 --> POD1
  K2 --> R2 --> POD2
        

In the diagram, everything at the top is the control plane. Everything below is a worker node. Notice that every arrow passes through the API server. Nobody talks to anybody directly; the API server is the single front door for the whole cluster.

The control plane components

The worker node components

This single idea explains almost everything Kubernetes does.

Most older tools work like a recipe: do step one, then step two, then step three. Kubernetes works differently. You do not give it steps. You describe the end result you want, called the desired state. For example: “I want three copies of my web application running, using this image.”

Kubernetes then compares your wish with what is really happening, called the actual state. If the two match, it does nothing. If they differ, it takes action to close the gap. It repeats this comparison again and again, forever. This repeating comparison is called a control loop or reconciliation loop.

flowchart LR
  A[You declare desired state] --> B[State stored in etcd]
  B --> C[Controller compares desired vs actual]
  C -->|Match| D[Do nothing]
  C -->|Gap found| E[Take action to fix]
  E --> F[Actual state changes]
  F --> C
  D --> C
        

Why this design is so powerful

Because the loop never stops, Kubernetes recovers from surprises on its own. If a node loses power and three pods disappear, the loop notices that only two of the five wanted copies remain, and immediately creates replacements elsewhere. Nobody needs to write special rules for that particular disaster. The same simple idea handles thousands of different failures.

It also makes your work easier to review and repeat. Since you describe the result, not the steps, you can keep those descriptions in a version-controlled folder, review changes like any other work, and rebuild an entire environment from them. This habit is often called declarative management.

Let us follow a request from your keyboard all the way to a running container.

sequenceDiagram
  participant U as You
  participant A as API Server
  participant E as etcd
  participant S as Scheduler
  participant K as kubelet on Node
  participant R as Container Runtime
  U->>A: Submit desired state (3 copies)
  A->>E: Save the request
  A-->>U: Accepted
  S->>A: Any pods without a node?
  A-->>S: Yes, three pods
  S->>A: Assign each pod to the best node
  K->>A: Any pods assigned to me?
  A-->>K: Yes, start these pods
  K->>R: Pull image and start containers
  R-->>K: Containers running
  K->>A: Report status healthy
        

Notice the teamwork. No single component does everything. Each does one small job, watches the API server for work in its area, and updates the shared record when finished. This loose cooperation is why the system is so resilient and so easy to extend.

Different kinds of programs need different kinds of supervision.

You rarely create bare pods yourself. Instead, you pick a workload object that manages pods for you. Each type matches a particular style of program.

Since pods are disposable and their addresses keep changing, Kubernetes needs a stable way to connect them.

The basic networking promises

Kubernetes makes a few simple promises about networking. Every pod gets its own unique address inside the cluster. Any pod can talk to any other pod without complicated translation. And nodes can talk to pods too. The actual plumbing is provided by a network plugin, chosen when the cluster is built, such as Calico or Cilium.

The problem of moving addresses

Suppose your website needs to call your payment service. The payment service has three pods, and each pod has an address. But pods die and get replaced with new addresses all the time. If your website memorised those addresses, it would break constantly.

Services: the stable front door

A Service solves this by giving the group of pods one steady name and one steady address. The service watches for pods carrying a matching label, keeps a live list of the healthy ones and spreads traffic across them. Callers only ever remember the service name, and the changing crowd behind it stays hidden.

flowchart LR
  W[Website pod] -->|calls payments| SVC[Service: payments]
  SVC --> PA[Payment pod A]
  SVC --> PB[Payment pod B]
  SVC --> PC[Payment pod C]
        

The four service flavours

Ingress and the Gateway API: smart doors for web traffic

If you create one load balancer per service, costs pile up quickly. An Ingress is a smarter option: one entrance that reads the web address and path of each request and routes it to the right service. For example, requests for the shop page go to the shop service and requests for the blog page go to the blog service. A newer standard, called the Gateway API, offers a more flexible and role-friendly way of doing the same job.

Cluster DNS

Kubernetes also runs its own internal phone book, called cluster DNS. Every service gets a readable name automatically, so your website can simply ask for “payments” instead of hunting for an address. Names work across namespaces too, by adding the namespace to the name.

Applications need settings, secrets and sometimes permanent disks. Kubernetes keeps all three separate from the container.

ConfigMaps: settings outside the box

A good container image should be the same in every environment. But your test system and your live system need different settings, such as different database addresses. A ConfigMap holds those settings separately and delivers them to pods when they start. Change the setting, not the image.

Secrets: passwords and keys

A Secret is similar but meant for sensitive items such as passwords, tokens and certificates. Kubernetes can limit which pods and which people can read them. One important warning: by default, secrets are only encoded, not truly encrypted, inside etcd. Real protection needs encryption at rest, tight access rules and often an external secret manager.

Volumes and persistent storage

Since pods are disposable, anything written inside them vanishes when they are replaced. For data that must last, such as a customer database, Kubernetes offers persistent storage built from three pieces.

The two abilities that make people fall in love with Kubernetes.

Self-healing at three levels

Kubernetes protects your application at several layers at once. Each layer catches a different kind of trouble.

The three probes

Scaling: three different dials

Rolling updates and rollbacks

Releasing a new version normally risks downtime. Kubernetes uses a rolling update: it starts a few pods of the new version, waits until they are ready, then retires a few old ones, and repeats. At every moment, enough healthy pods are serving users. If the new version misbehaves, one command returns to the previous version, because Kubernetes remembers the earlier definition.

flowchart LR
  A[Old version: 3 pods] --> B[Start 1 new pod]
  B --> C[New pod ready]
  C --> D[Retire 1 old pod]
  D --> E{All replaced?}
  E -->|No| B
  E -->|Yes| F[New version: 3 pods]
        

A cluster has limited memory and processing power, and Kubernetes needs to share it sensibly.

Every container can declare two numbers. A request is the amount it needs to run properly, and the scheduler uses it to pick a node with enough room. A limit is the maximum it may ever use. A container that tries to exceed its memory limit is stopped, while one that exceeds its processor limit is slowed down.

Quality of service classes

Based on how requests and limits are set, Kubernetes sorts pods into three priority classes. When a node runs short of memory, it evicts the least protected pods first.

Namespaces, quotas and fairness

When many teams share a cluster, one careless team could eat all the resources. Administrators can attach a resource quota to a namespace, which sets a ceiling on the total memory, processing power or number of objects that namespace may use. Limit ranges provide sensible default sizes for containers that forget to declare their own.

A cluster runs valuable applications, so protecting it is part of the job from day one.

The principle of least privilege

The golden rule is to give every person and program only the access it truly needs and nothing more. A web application that only reads product data should never carry permission to delete cluster objects. If that application is ever compromised, the damage stays small.

You cannot fix what you cannot see. Observability is how you watch a cluster’s health.

Because pods appear and disappear constantly, looking at a single machine no longer tells the story. Kubernetes teams rely on three kinds of signals, often called the three pillars of observability.

What to watch first

Alerts should point to problems that hurt users, not to every tiny twitch. An alert that fires all day teaches people to ignore alerts. Good teams alert on symptoms, such as rising errors, and use dashboards to investigate causes.

Kubernetes is powerful, but it is not free of cost. An honest look at both sides helps you decide wisely.

When Kubernetes is a good fit

It shines when you run many services, need frequent releases, must handle changing traffic, or want the same platform across teams and clouds. It is also valuable when reliability is critical and manual operation would be too risky.

When to think twice

If you have a single small website with steady traffic, a simple managed hosting service is often cheaper and quicker. Adopting Kubernetes too early is like buying a cargo ship to deliver a single parcel across town.

Habits that experienced teams follow, and traps they learned to avoid.

Helpful patterns

Traps to avoid

Simple habits that prevent most early pain.

Theory becomes clearer when you see who uses it and why.

Well-known organisations such as Spotify, Airbnb, Pinterest and The New York Times have publicly shared stories about running large parts of their systems on Kubernetes. Kubernetes has also been tested at remarkable scale: the project documents support for clusters of up to five thousand nodes and well over a hundred thousand pods, which is far beyond what most companies will ever need.

Managed Kubernetes on major clouds

You do not need a data center to begin. A laptop is enough.

No. Docker is a tool for building and running individual containers. Kubernetes manages many containers across many machines. They work together: Docker-style images are what Kubernetes runs, though today Kubernetes typically uses runtimes such as containerd.

Neither. It is a management layer that sits on top of machines, whether real or virtual, and treats them as one pool. It is often described as a platform for building platforms.

Usually not. Simple hosting or a container service that hides the cluster is often better for one small application. Consider Kubernetes as your number of services, teams and traffic swings grow.

Pods that are already running usually keep running, because the kubelet on each node continues managing them. However, no new changes, scheduling or self-healing can happen until the control plane returns. That is why production clusters run several control plane copies for high availability.

Yes, using StatefulSets, persistent volumes and often specialised operators. It takes careful planning around backups and storage, and many teams choose a managed database service instead to reduce risk.

A container is a single packaged program. A pod is a small wrapper around one or more containers that share a network address and storage, and is the smallest unit Kubernetes schedules.

Namespaces divide a cluster into virtual sections, so different teams, projects or environments can live side by side with their own names, permissions and resource limits.

Helm is a package manager for Kubernetes. It bundles the many descriptions an application needs into a single reusable package called a chart, so you can install and upgrade whole applications with a single instruction.

Not entirely. Several defaults favour convenience, such as open pod-to-pod communication and only-encoded secrets. A production cluster needs deliberate hardening, including access rules, network policies, encryption and regular updates.

The project publishes new minor versions a few times a year, and each version is supported for a limited period. Teams need a habit of regular upgrades, so they never fall too far behind and lose security fixes.

It describes applications designed to run in dynamic environments such as clouds, using containers, small independent services, automation and rapid change. Kubernetes is the most famous foundation for this style.

Kubernetes exists because containers, while wonderful for packaging software, create a new challenge: managing thousands of them reliably. Born from Google’s experience with Borg and now guided by a neutral foundation, Kubernetes solves this by letting you describe the result you want and then working relentlessly to make reality match. A control plane acts as the brain, worker nodes supply the muscle, and small controllers run endless loops that repair anything that drifts.

Around that heart sits a rich toolbox: pods and deployments to run applications, services and ingress to connect them, ConfigMaps, secrets and volumes to feed them, autoscalers to stretch them, probes to heal them and security layers to protect them. It is not the right answer for every project, but for organisations with many services and changing demand, it has become the standard foundation.

Start small, practise on a local cluster, learn the vocabulary, and let the thermostat idea guide you. Once the big picture clicks, every new feature becomes a variation on a theme you already know.