Cloud Parts

Container orchestration

Software that keeps your containers running, wherever there’s room.

7 technologies on this page ↓
Live model
What you’re watchingThe Service spreads requests across three pods. When node-2 disappears, traffic skips it and the control plane starts a replacement, because the desired count is still 3.

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.

Think of it as

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

  • One or two services: a managed container runner like Cloud Run or Fargate is far less to operate
  • Teams without time to learn, upgrade and secure the cluster itself
  • Learning or testing on one machine: a local cluster from kind or minikube is enough

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.

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

Article· August 2025lambda to eks pod migrationAWS re:Post community questionA short Q&A on what replaces Lambda’s built-in triggers, SQS polling and scaling when functions move to EKS pods. The useful answer points to KEDA (with Karpenter) for scaling pods on queue depth; the longer answer is an unreviewed AI-generated checklist from AWS’s own assistant, so treat it as a starting list, not guidance.
Article· January 2025How to create Kubernetes Jobs from AWS LambdaCloudfleetA tutorial for a Lambda function (a Bash custom runtime that downloads 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.
Article· November 2024Kubernetes for databases: weighing the pros and consKate Obiidykhata, Percona, on the CNCF blog (first published on The New Stack)A short, high-level overview of why companies move databases onto Kubernetes (one platform across clouds and data centres, self-service, scaling, built-in failover) and the three ways to get there: a cloud DBaaS, a private DBaaS product, or an internal platform built from operators and monitoring. There is no technical depth or data. It is a CNCF member post by a Percona employee and ends by recommending Percona Everest, so read it as a vendor’s framing of the choice.
Article· August 2023Using Kubernetes with AWS Lambda: Scaling Up Your Serverless ApplicationsRohit Ghumare, LumigoA vendor blog post whose concrete part is a walkthrough of creating a Lambda function from an EKS cluster with the AWS Controllers for Kubernetes (ACK) Lambda controller, closely following AWS’s own 2022 tutorial. The benefits section is vague and blurs what Kubernetes and Lambda each do, and the post ends with a pitch for Lumigo’s observability product.
Article· March 2023The Great Lambda Migration to Kubernetes Jobs: a Journey in Three PartsLiav Yona, InfoQA first-person account of how Firefly moved event-driven work off Lambda (after hitting the 15-minute timeout), briefly onto ECS, and finally onto Kubernetes Jobs on EKS, with practical notes on reusing container images, swapping an IAM trust policy for EKS OIDC, moving environment variables into ConfigMaps and a blue/green cutover. It is one company’s story with few numbers, and the author’s employer sells infrastructure-as-code tooling, which colours the emphasis on IaC.
Article· August 2022Deploying AWS Lambda functions using AWS Controllers for Kubernetes (ACK)Rajdeep Saha, AWS Compute BlogAWS’s step-by-step tutorial for managing Lambda functions as Kubernetes custom resources: install the ACK Lambda controller in EKS, give it IAM permissions through IRSA, then 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.
Article· May 2021Spice up Your Kubernetes Environment with AWS LambdaLiav Yona, MediumShows how a Lambda function triggered by SQS or SNS can forward events to an internal (ClusterIP) service in EKS through the Kubernetes API server’s service proxy, using IAM-to-RBAC mapping instead of exposing an endpoint, with code on GitHub. A clever pattern, but written for 2021-era EKS: it maps the IAM role through the aws-auth ConfigMap, and it routes application traffic through the cluster’s control plane.
Article· February 2021Alternative to AWS lambda serverless concept in Kubernetes?Stack Overflow question by ajsgA team running everything on Kubernetes asks how to get Lambda-style, per-request scaling for loading AI models from S3. The 2021 answers name Knative, KFServing (now KServe) and Kubeless (since archived), which makes it a quick snapshot of the options rather than an up-to-date guide.
ArticleKubernetes in a microVMsmol machines docsThe vendor’s own guide to two ways of combining Kubernetes with microVMs: a containerd shim and 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.
ArticleUsing Lambda with KubernetesAWS Lambda Developer GuideAWS’s short docs page on managing Lambda functions through the Kubernetes API, with either AWS Controllers for Kubernetes (ACK) or Crossplane, and the use cases for each (reusing RBAC and IAM roles for service accounts, GitOps, tag policies). It covers provisioning only: the functions still run on Lambda, not in your cluster.
All resources →

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

  1. 2009

    Mesos first presented by UC Berkeley researchers

  2. 2010

    Twitter begins testing Mesos

  3. 2014

    Google open-sources Kubernetes; Docker starts Swarm

  4. 2015

    Kubernetes 1.0, HashiCorp Nomad and the Borg paper all appear

  5. 2017

    Microsoft (AKS) and AWS (EKS) announce managed Kubernetes

  6. 2025

    Apache Mesos retired and moved to the Apache Attic

Sources21

Improve this page on GitHub