What Is Kubernetes? Explained, With Kubernetes vs. Docker

Kubernetes is an open-source system for automating the deployment, scaling, and management of containerized applications — in plain terms, software that takes a pile of containers spread across many machines and keeps them running the way you told it to, restarting what crashes and rebalancing load as traffic changes. It does not replace Docker; it picks up where Docker leaves off, taking the containers Docker builds and runs on one machine and operating fleets of them across a cluster of machines instead.

What is Kubernetes, in simple words?

Strip away the jargon and Kubernetes is a manager for containers. A container packages an application with everything it needs to run — code, runtime, libraries, settings — so it behaves the same on a laptop, a test server, or in the cloud, a concept Docker describes as "a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another." That's great for one container on one machine. The problem starts once an application needs dozens or hundreds of containers spread across many servers: something has to decide which server runs which container, notice when one dies and start a replacement, route traffic to healthy copies, and add more copies when demand spikes.

That "something" is Kubernetes. According to its own documentation, Kubernetes is "a portable, extensible, open source platform for managing containerized workloads and services that facilitate both declarative configuration and automation." The "declarative" part matters: instead of scripting a step-by-step sequence of commands, you describe the end state you want — "run three copies of this web server, always" — and Kubernetes continuously works to make reality match that description, no matter what breaks along the way.

What is Kubernetes used for?

Kubernetes is used to run containerized applications reliably at scale, across a cluster of machines rather than a single server. Per the official docs, it provides a set of capabilities that most teams would otherwise have to build themselves, including:

• Service discovery and load balancing — exposing a group of containers through a single DNS name or IP address and spreading traffic across them.
• Storage orchestration — automatically mounting the storage system of your choice, whether local disk or cloud storage.
• Automated rollouts and rollbacks — changing an application's running state at a controlled rate, and rolling back automatically if something goes wrong.
• Automatic bin packing — fitting containers onto nodes based on the CPU and memory each one needs, to use hardware efficiently.
• Self-healing — restarting containers that fail, replacing them, killing ones that fail a health check, and hiding them from traffic until they're actually ready.
• Secret and configuration management — storing and managing sensitive data like passwords and API keys without baking them into container images.

In short: anywhere an organization runs many containers across many machines — a web app behind a load balancer, a fleet of background workers, a mix of microservices that scale independently — Kubernetes is the layer that keeps it all running and adjusts it automatically as conditions change.

How Kubernetes works: clusters, nodes, and the control plane

A running Kubernetes deployment is called a cluster. Per the official architecture documentation, a cluster consists of two broad parts: a control plane that manages the overall state of the cluster, and one or more worker nodes that actually run the containerized applications.

The control plane is made up of several components working together:

• kube-apiserver — "the core component server that exposes the Kubernetes HTTP API," the front door every other piece talks to.
• etcd — a "consistent and highly-available key value store" that holds all of the cluster's data: what should be running, what is running, and the configuration behind it.
• kube-scheduler — watches for newly created Pods that haven't been assigned to a node yet, and picks a suitable node for each one.
• kube-controller-manager — runs the controllers that implement Kubernetes' behavior, each one a control loop that "watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state."
• cloud-controller-manager — an optional component that integrates the cluster with the APIs of an underlying cloud provider.

Each worker node, meanwhile, runs its own set of components: the kubelet, which ensures that a node's assigned Pods and their containers are actually running; kube-proxy, which maintains the network rules that let traffic reach the right containers; and a container runtime, the software actually responsible for running containers on that machine.

Kubernetes explicitly avoids calling this "orchestration" in the traditional sense. As the documentation puts it, classic orchestration means executing a fixed workflow — "first do A, then B, then C" — but Kubernetes instead "comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state." It shouldn't matter how the cluster gets from A to C, only that it ends up there — and stays there even as servers fail or traffic shifts.

What is a Kubernetes Pod?

A Pod is the smallest deployable unit in Kubernetes — you never deploy a bare container directly; you deploy it inside a Pod. The official docs define a Pod as "a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers." Containers in the same Pod are always scheduled onto the same node together, share the same network address and port space, and can share storage volumes — Kubernetes treats a Pod as a kind of logical host for whatever is running inside it.

Most Pods hold exactly one container; multi-container Pods are reserved for tightly coupled helper processes that genuinely need to share resources with a primary container. Pods are also deliberately disposable: the documentation calls them "relatively ephemeral" and notes that losing a Pod isn't the same as losing an application, since higher-level objects like Deployments or StatefulSets create new Pods automatically to replace ones that disappear.

What is a Kubernetes cluster?

A cluster is the full set of machines — physical or virtual — plus the control plane that manages them, working together as a single system. Rather than thinking in terms of "server 1" and "server 2," engineers describe desired state in terms of the whole cluster: "run five copies of this Pod somewhere in the cluster," and Kubernetes decides exactly which nodes those copies land on, moving them if a node fails. Clusters can run on-premises, in a public cloud, or across a mix of both, which is a large part of why Kubernetes became the common language for running containers regardless of where the underlying hardware actually sits.

What is a Kubernetes Operator?

An Operator is a way of extending Kubernetes to handle tasks that are specific to one application and go beyond what Kubernetes understands out of the box. The official docs describe it as "a software extension to Kubernetes that uses custom resources to manage applications and their components," acting as a controller for a custom resource the way the built-in controllers manage Pods and Deployments. The idea is to capture the knowledge of a human operator — someone who knows how to install, back up, upgrade, and recover a specific piece of software — and encode it so Kubernetes can perform those tasks automatically. A database Operator, for example, might know how to provision storage for a new database instance, take and restore backups, and apply schema changes during an upgrade, all triggered by a simple kubectl command against a custom resource rather than a manual runbook.

What is Kubernetes vs. Docker? The difference, explained

This is the single most common point of confusion for anyone new to containers, and the short version is that Docker and Kubernetes aren't competitors — they operate at different layers and are usually used together.

Docker is a platform for building, packaging, and running individual containers. A developer uses it to turn an application into a container image, test that image locally, and run containers from it — the Docker homepage describes its job as using containers to "Build, Share and Run your applications." Docker's focus is the container itself and the single machine it runs on; it has no native concept of coordinating containers across a fleet of servers.

Kubernetes operates one layer up. It doesn't build container images at all — it takes images that a tool like Docker already produced, and decides where to run the resulting containers across a cluster of many machines, restarts them when they fail, scales the count of running copies up or down, and routes network traffic to whichever copies are healthy. In most real deployments, the two sit side by side in the same pipeline: a container image is built with Docker (or a similar tool), pushed to a registry, and then Kubernetes schedules and runs it at scale — which is also why Kubernetes clusters still rely on a container runtime under the hood to actually start and stop containers on each node.

Readers who want the container-building side of this story in more depth can see Pandromeda's companion explainer on what Docker is and how containers work, which covers images, Dockerfiles, and the Docker Engine in detail.

Self-healing and automatic scaling, explained

Two of Kubernetes' most-cited capabilities are self-healing and horizontal scaling, and both follow directly from the control-loop model described above. For self-healing, the documentation is explicit: "Kubernetes restarts containers that fail, replaces containers, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve." None of that requires a human to notice the failure first — the control plane's controllers are constantly comparing actual state to desired state and correcting any drift on their own.

Horizontal scaling works the same way: an operator can raise or lower the number of running replicas through a command, a dashboard, or an automated rule tied to CPU usage or another metric, and the scheduler figures out where the new replicas should run. Because this is declarative rather than scripted, scaling up after a traffic spike and scaling back down afterward both happen through the same mechanism — updating the desired replica count and letting Kubernetes reconcile it.

Who maintains Kubernetes?

Kubernetes began as an internal Google project, drawing on lessons from Google's own internal cluster manager, before the company open-sourced it in 2014. Google subsequently worked with the Linux Foundation to establish the Cloud Native Computing Foundation (CNCF) and donated Kubernetes as the new foundation's seed project. CNCF describes itself as a community that "enable[s] open source projects including Kubernetes, Prometheus, Envoy, and many others," operating as part of the nonprofit Linux Foundation. Today Kubernetes is developed by a large, independent community of contributors from many companies rather than by Google alone, and it's released under the Apache License 2.0.

The name itself comes from the Greek word for "helmsman" or "pilot" — fitting for software whose job is steering a fleet of containers — and "K8s," the common abbreviation, is a numeronym formed by the letter K, the eight letters it elides, and the letter s.

Running Kubernetes without running it yourself: GKE, EKS, and AKS

Operating the control plane described above — the API server, etcd, the scheduler, the controllers — is real infrastructure work, so most organizations today use a managed Kubernetes service rather than running every component by hand. The three major clouds each offer one. Google Kubernetes Engine (GKE) is Google Cloud's managed Kubernetes offering, available in a Standard mode where customers configure their own nodes and an Autopilot mode where Google also manages node provisioning. Amazon Elastic Kubernetes Service (EKS) is positioned by AWS to help teams "build, run, and scale production-ready Kubernetes applications easily across any environment," including hybrid options that extend to on-premises hardware and edge locations. Microsoft offers the equivalent service, Azure Kubernetes Service (AKS), through Azure. In each case, the cloud provider takes over running and patching the control plane while customers still use the same standard Kubernetes APIs and the same kubectl command-line tool they'd use on a self-managed cluster — which is also the point: workloads defined for Kubernetes are meant to be portable between a laptop, a data center, and any of these managed services without being rewritten.

That portability is also why Kubernetes shows up well beyond the cloud. Developers frequently run a lightweight local cluster for testing, including on Windows machines using WSL2 to host the Linux-based tooling that Kubernetes and its container runtimes expect — a setup covered in Pandromeda's guide to WSL2 on Windows 11.

What's next: where to go from here

For a beginner, the practical path usually starts with Docker: build and run a single container locally, understand what an image actually contains, and get comfortable with the idea of packaging an application once and running it anywhere. From there, Kubernetes concepts — Pods, Deployments, Services, and eventually Operators for anything application-specific — start to make sense as answers to a very concrete question: what happens once "one container on one machine" needs to become "many containers across many machines, reliably, without anyone babysitting them." Most teams never hand-roll a cluster from scratch; they reach for a managed service like GKE, EKS, or AKS and focus on the application itself. The underlying model, however — declare the desired state and let a set of control loops continuously reconcile reality against it — is the same wherever Kubernetes runs, which is precisely why it has become the common baseline for running containerized software at scale.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage