Container orchestration
Software that keeps your containers running, wherever there’s room.
7 technologies on this page ↓How it works
An orchestrator runs containers across a fleet of machines. You declare the desired state (three copies of api:1.4.2, 512 MB each) and a control loop keeps making reality match it. It places containers on machines with free capacity, restarts crashed ones, replaces them when a machine dies, rolls out new versions gradually and gives each group a stable address.
An air-traffic controller for containers. You file the flight plan; it picks the runway, and it reroutes when one closes.
Reach for it when
- Dozens of services that need scheduling, discovery and rolling deploys
- Self-healing: failed containers come back without a human
- One consistent platform across clouds or on-prem
Think twice when
A real example
An API runs as a Kubernetes Deployment with 3 replicas. At 2 a.m. a node fails. The scheduler sees only 2 pods running, starts a replacement on a healthy node, and nobody gets paged.
Technologies
Specific products, and what each does differently.
KubeVirtOpen sourceAdds virtual machines to Kubernetes as ordinary resources, so VMs and containers share one cluster, one API and one set of tools.Mainly Virtual machines
VeleroOpen sourceBacks up a Kubernetes cluster’s objects and persistent volumes to object storage, and restores them into the same cluster or a new one.Mainly Backup & restore
CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.Mainly Relational databases
Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.Mainly Relational databases
PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.Mainly Relational databases| Commercial product | HashiCorp, an IBM company | Business Source License 1.1 since Nomad 1.7 (source-available, not OSI open source); MPL 2.0 up to 1.6.x | 2026-10-05 | |
| Open source | Cloud Native Computing Foundation | Apache 2.0 | 2026-10-05 | |
KubeVirt | Open source | Cloud Native Computing Foundation | Apache 2.0 | 2026-10-06 |
Velero | Open source | Cloud Native Computing Foundation | Apache 2.0 | 2026-10-06 |
CloudNativePG | Open source | CloudNativePG community (started at 2ndQuadrant and EDB) | Apache 2.0 | 2026-10-06 |
Percona Operators | Open source | Percona | Apache 2.0 (operators). The databases they deploy keep their own licences: Percona Server for MongoDB is source-available under the SSPL | 2026-10-06 |
PGO (Crunchy Postgres for Kubernetes) | Open source | Crunchy Data (joining Snowflake, announced June 2025) | Apache 2.0 for the operator code. Crunchy’s prebuilt images are under the Crunchy Data Developer Program terms: free for development, but free in production only for individuals and organisations with fewer than 50 employees | 2026-10-06 |
What each provider calls it
- AWS
- EKS, ECS; Red Hat OpenShift Service on AWS (ROSA)
- Google Cloud
- GKE
- Azure
- AKS; Azure Red Hat OpenShift (ARO)
- Open source & others
- Kubernetes and Nomad. Kubernetes distributions: K3s, RKE2, MicroK8s, Talos Linux, OKD, and Red Hat OpenShift (commercial); Rancher manages many clusters; kubeadm bootstraps your own; kind and minikube run a cluster on a laptop
See it in a real stack
Architectures that use container orchestration
In code · yaml
apiVersion: apps/v1
kind: Deployment
metadata: { name: api }
spec:
replicas: 3 # desired state
selector: { matchLabels: { app: api } }
template:
metadata: { labels: { app: api } }
spec:
containers:
- name: api
image: registry.example.com/api:1.4.2
resources: { requests: { cpu: 250m, memory: 512Mi } }Worth exploring
kubectl on start) that runs kubectl commands against a cluster, used here to launch a Kubernetes Job in response to an event. It is written for Cloudfleet’s own managed Kubernetes and its CLI, so the authentication steps need changing for other clusters, and passing raw kubectl arguments in an event is fine for a demo but too permissive for production.kubectl apply a Function manifest that points at code in S3. It explains why you might (one GitOps and RBAC model for pods and functions) but, being AWS’s own post, not the drawbacks.aws-auth ConfigMap, and it routes application traffic through the cluster’s control plane.RuntimeClass that start each pod as its own VM (marked experimental, with its known blockers listed), or a whole k3s cluster, through k3d, inside one VM. Useful for the concrete details, such as per-pod overhead, the /dev/kmsg device the kubelet needs and why Docker’s storage must sit on ext4, but written to sell smolvm.Often confused with
Where it came from2009–2025
The model for container orchestration was Google’s internal cluster manager, Borg. Instead of assigning services to particular machines, engineers described jobs and Borg decided where they ran, restarted them when they failed and packed different workloads onto shared machines to keep utilisation high. Its 2015 paper describes it running “hundreds of thousands of jobs” across clusters “each with up to tens of thousands of machines”, and summarises a decade of lessons.
Outside Google, the same idea emerged in research. Mesos, started at UC Berkeley by Benjamin Hindman, Andy Konwinski, Matei Zaharia and Ion Stoica and first presented in 2009, let several frameworks share one cluster; by 2010 Twitter was testing it. When Docker made the container image the standard unit of deployment in 2013, many companies wanted a Borg of their own. Google released Kubernetes in 2014, built on Borg’s lessons; Docker started Swarm the same year, and HashiCorp’s Nomad followed in 2015.
Kubernetes became the common choice: Microsoft and AWS announced managed Kubernetes services in 2017, and Apache retired Mesos to its Attic in 2025. Many teams now use it through managed Kubernetes or serverless container services that hide the cluster entirely.
Why it’s built this way
- Declare the goal, not the steps
- You state how many copies should run and the orchestrator keeps working toward it. Because controllers react to the current state rather than individual events, crashes and lost messages are corrected on the next pass instead of needing a script for every failure.
- Pack mixed workloads onto shared machines
- Machines dedicated to one service often sit largely idle. Borg got its utilisation from placing many jobs per machine, over-committing resources and isolating performance, and Kubernetes schedules by CPU and memory requests for the same reason.
- Give moving workloads a stable address
- If any container can be rescheduled anywhere, clients can’t track machines. Kubernetes separated naming, discovery and load balancing from the apps themselves, so a Service keeps one address while its Pods come and go.
Timeline
- 2009
Mesos first presented by UC Berkeley researchers
- 2010
Twitter begins testing Mesos
- 2014
Google open-sources Kubernetes; Docker starts Swarm
- 2015
Kubernetes 1.0, HashiCorp Nomad and the Borg paper all appear
- 2017
Microsoft (AKS) and AWS (EKS) announce managed Kubernetes
- 2025
Apache Mesos retired and moved to the Apache Attic
- Verma et al.: Large-scale cluster management at Google with Borg (EuroSys 2015)
- Burns et al.: Borg, Omega, and Kubernetes (ACM Queue, 2016)
- Hindman et al.: A Common Substrate for Cluster Computing (HotCloud 2009)
- Hindman et al.: Mesos, a platform for fine-grained resource sharing (Berkeley tech report, 2010)
- Kubernetes Blog: 10 years of Kubernetes (Jun 2024)
- Docker Swarm (classic) repository on GitHub, created 2014
- HashiCorp Nomad v0.1.0 release on GitHub (Sep 2015)
- Azure Blog: Introducing AKS, managed Kubernetes (Oct 2017)
- AWS News Blog: Amazon Elastic Container Service for Kubernetes (Nov 2017)
- Apache Attic: Mesos
- Kubernetes design and architecture
Sources21
- Kubernetes docs: Overview
- Kubernetes docs: Deployments (rolling updates, replacing failed Pods)
- Kubernetes docs: Service (stable address for a set of Pods)
- Amazon EKS docs: What is Amazon EKS?
- Amazon ECS docs: What is Amazon ECS?
- GKE docs: GKE overview
- Azure docs: What is AKS?
- HashiCorp Nomad docs
- K3s docs
- Cloud Run docs: What is Cloud Run
- Amazon EKS docs: AWS Fargate (no nodes to provision or scale)
- ROSA User Guide: What is Red Hat OpenShift Service on AWS?
- Red Hat press release: Azure Red Hat OpenShift (May 2019)
- RKE2 docs
- MicroK8s docs
- Talos docs: What is Talos Linux?
- OKD website
- Rancher Manager docs: Overview
- Kubernetes docs: kubeadm
- kind: Quick start
- minikube docs: Get started