Kubernetes explained: how container orchestration works

Kubernetes, also known as K8s, is an open-source container orchestration system for automating software deployment, scaling, and management. It assembles one or more computers — virtual machines or bare metal — into a cluster that runs workloads inside containers, and it keeps those workloads running at the state you declare, no matter which machine they land on. Kubernetes was originally designed by Google and is now maintained by a worldwide community of contributors, with the trademark held by the Cloud Native Computing Foundation (CNCF).

Where the name comes from

The name Kubernetes comes from the Ancient Greek term kubernḗtēs, meaning "helmsman" or "pilot" — the same word that gave us cybernetics and, through Latin, governor. The abbreviation "K8s" is a numeronym: the letter K, followed by 8 letters, followed by s.

What a cluster is

A Kubernetes cluster is a group of computers that work together as a single system. Any of them can be a virtual machine or a bare-metal server. The cluster runs workloads in containers and works with various container runtimes, such as containerd and CRI-O. Because containers already bundle the application and its dependencies, Kubernetes can move them between machines without rebuilding anything.

The software consists of a control plane and the nodes on which the actual applications run. It includes tools like kubeadm (to set up a cluster) and kubectl (to interact with its REST-based API).

The control plane

The control plane manages the workload and directs communication across the system. It is split into several components, each its own process, which can run on a single node or on multiple nodes for high-availability clusters.

A concrete example ties them together: an operator declares that three instances of a particular pod must be running, and etcd stores that fact. If the Deployment controller finds that only two instances are running, it schedules the creation of the missing instance.

Worker nodes

A node — also called a worker — is a machine where containers are deployed. Every node must run a container runtime plus the components that connect it to the control plane:

• kubelet is responsible for the running state of each node: it starts, stops, and maintains the application containers that the control plane asks it to run. It reports node status to the API server every few seconds via heartbeat messages.
• Container runtime manages the lifecycle of containers — launching them, reconciling them, and killing them. Kubelet talks to the runtime through the Container Runtime Interface (CRI). Originally kubelet was tightly coupled to Docker; the "dockershim" shim bridged them until it was deprecated in 2020 and removed entirely in Kubernetes v1.24 (May 2022). As of 2026, widely used CRI-compliant runtimes include containerd and CRI-O.
• kube-proxy is a network proxy and load balancer running on each node. It supports the service abstraction and routes traffic to the right container based on the IP address and port of the incoming request.

Pods: the smallest unit of work

The basic deployable unit in Kubernetes is the pod, which consists of one or more containers co-located on the same node. Each pod gets a unique IP address inside the cluster, so applications can use ports without the risk of conflict, and the containers inside one pod share a context and can reference each other. In the most common use case, each pod holds a single container — but the pod, not the container, is what Kubernetes schedules and manages.

Workloads: managing pods at a higher level

Kubernetes offers several workload abstractions layered on top of pods, so you declare the shape of your application instead of managing individual pods by hand:

• ReplicaSet keeps a stable set of replica pods running at any given time — it guarantees the availability of a specified number of identical pods. The older ReplicationController did the same job; it was deprecated in favor of the ReplicaSet's set-based label selectors.
• Deployment is a higher-level management mechanism for ReplicaSets: it decides whether an update is rolled out or rolled back, and when you scale a Deployment up or down, the underlying ReplicaSet declaration changes with it.
• StatefulSet enforces uniqueness and ordering among pod instances, which is what stateful applications need. Databases running in high-availability mode have a primary and secondary instances, and Apache Kafka distributes data among brokers — in both cases instances are not interchangeable, so ordering and identity matter.
• DaemonSet ensures that a pod runs on every single node in the cluster, scaling up as nodes are added. This suits workloads tied to the host machine, such as log collection, ingress controllers, and storage services.

Services: stable addresses for changing pods

Pods are ephemeral — they come and go as the cluster scales or heals. A Service fixes this by grouping the pods of one tier (for example, all backend pods) behind a label selector and giving the group a stable IP address and DNS name. Kubernetes discovers services in two ways — through environment variables or through Kubernetes DNS — and load balances traffic in a round-robin fashion among the pods that match the selector. A Service can be exposed inside the cluster only, or outside it, for clients to reach the front-end pods.

Namespaces, storage, and configuration

Kubernetes keeps its resources organized with a few supporting concepts:

• Namespaces divide cluster resources into distinct, non-intersecting collections — useful when many users share a cluster across teams or projects, or to separate development, test, and production environments.
• Volumes provide persistent storage. A container's filesystem is ephemeral and wiped out on restart, but a Volume survives and can even be shared as disk space by the containers inside one pod.
• ConfigMaps and Secrets let you change configuration without rebuilding the application. Both can be exposed as environment variables or mounted into the container's filesystem as volumes — mounted ConfigMaps reload automatically without restarting. Secrets are meant for sensitive data such as passwords, SSH keys, and registry credentials, although by default they are not encrypted at rest.

Labels and selectors: how Kubernetes finds things

Labels are key-value pairs attached to any API object — pods, nodes, services. Label selectors are queries against those labels that resolve to the matching objects. A Service, for example, selects the pods that receive its traffic: pods labeled tier=backend AND release_track=canary can be addressed as a group in one operation. Because traffic routing depends only on labels, switching the labels or the selector changes which pods get traffic — the mechanism behind blue-green deployments and A/B testing.

Declarative API, custom resources, and operators

Everything in Kubernetes is a record of intent. Object definitions carry spec (the desired state, written by the user or a higher-level controller) and status (the current state, actively updated by the controller that manages the object). That declarative model is what lets controllers keep converging the cluster toward what you declared.

The API itself is extensible. Custom resources are objects that are not part of the standard installation, registered dynamically through Custom Resource Definitions (CRDs). Pair a custom resource with a custom controller — a reconciliation loop of your own — and you have an Operator: automation that captures how a human operator would run and care for a specific service, from taking backups to handling upgrades. Notable CNCF projects that follow the operator pattern include Argo, Open Policy Agent, and Istio.

API security

The API server is the single point of access to a cluster, so it is locked down: it serves HTTPS with TLS certificate authority verification. Requests are authenticated with X.509 client certificates, bearer tokens, or service account tokens for programmatic access, usually supplied through a kubeconfig file. Authorization runs through pluggable modes — Node, Attribute-Based Access Control (ABAC), Role-Based Access Control (RBAC), and a webhook mode that delegates authorization decisions to an external service.

How Kubernetes came to be

Kubernetes was announced by Google on June 6, 2014, created by Joe Beda, Brendan Burns, and Craig McLuckie. Its design was inspired by Google's internal Borg cluster manager, and the internal codename was "Project 7" after the Star Trek ex-Borg character Seven of Nine — the logo's seven-spoked ship's wheel comes from that. Unlike Borg, which was written in C++, Kubernetes is written in Go. The first tagged release, v0.2, came in September 2014, and version 1.0 was released in July 2015. Google then worked with the Linux Foundation to form the Cloud Native Computing Foundation and offered Kubernetes as its seed technology.

Adoption accelerated quickly. In 2017 the principal competitors rallied around Kubernetes and announced native support: VMware in August, Mesosphere in September, Docker Inc. and Microsoft Azure in October, and Amazon Web Services with its Elastic Kubernetes Service (EKS) in November. On March 6, 2018, Kubernetes reached ninth place among GitHub projects by number of commits, and second place in authors and issues after the Linux kernel, as the first CNCF project to graduate.

Kubernetes follows a version support policy of N-3 since version 1.19 — the three most recent minor versions receive security updates and bug fixes, for roughly one year of full support plus a maintenance period.

Kubernetes vs Docker

Kubernetes and Docker answer different questions. Docker (via the Docker Engine) builds, ships, and runs containers on a single machine; Kubernetes schedules and manages containers across a cluster of machines. The two are complementary: Docker produces the images and the containers, Kubernetes runs them at scale, heals them when a node fails, and load balances traffic between them. Historically Kubernetes even used Docker directly as a runtime through the dockershim, until the container runtime interface matured and the shim was removed in v1.24.

Distributions

Because Kubernetes is open source under the Apache License 2.0, it ships in many forms. Open-source distributions include k3s (a lightweight build for edge and small clusters), k0s, Amazon EKS-D, SUSE Rancher's RKE, and OKD (the community distribution behind Red Hat OpenShift). Commercial distributions add enterprise support, such as Red Hat OpenShift, SUSE Rancher Prime, Nutanix, and Mirantis Kubernetes Engine. Every major cloud vendor also offers a managed version — Amazon EKS, Google GKE, Microsoft AKS, plus offerings from Alibaba Cloud, IBM, Oracle, DigitalOcean, and Huawei — where the cloud provider operates the control plane for you.

FAQ

What does Kubernetes do?

Kubernetes automates the deployment, scaling, and management of containerized applications. It groups machines into a cluster, schedules containers onto them, keeps them running at the state you declare, and load balances traffic between them.

Is Kubernetes a container runtime?

No. Kubernetes is an orchestration system: it schedules and manages containers, but the containers themselves are run by a container runtime such as containerd or CRI-O, which Kubernetes talks to through the Container Runtime Interface.

What is the difference between Kubernetes and Docker?

Docker builds and runs containers on one machine. Kubernetes manages containers across a cluster of machines — scheduling, scaling, healing, and networking them. In practice, Docker builds the images and Kubernetes runs them at scale.

Is Kubernetes free?

Yes. Kubernetes is open source under the Apache License 2.0. Managed offerings from cloud vendors (EKS, GKE, AKS) are paid services, but the platform itself is free to run on your own infrastructure.