What is Kubernetes? Container orchestration explained
Kubernetes is an open-source system for automating the deployment, scaling and management of containerised applications across a cluster of machines. Containers made software portable and quick to start; Kubernetes answers the question that arrives immediately afterwards — how do you run hundreds of them, across a fleet of servers, keeping them healthy, connected and correctly sized, without an army of operators doing it by hand? Its answer is to let you declare the state you want and then continuously work to make reality match, restarting what fails and rebalancing what drifts. Originally developed at Google and now maintained as an open-source project, it has become the industry’s standard orchestrator, offered as a managed service by every major cloud — EKS on AWS, AKS on Azure. This article explains the problem it solves, its core concepts in plain English, and where it fits in certification study.
The problem: containers multiply faster than humans can manage them
A single container is trivial to run. A production system is not a single container: a modern application decomposes into many services, each running several identical container copies for capacity and resilience, spread across many machines so that no single failure takes everything down. Now count the chores: deciding which machine each container runs on, restarting the ones that crash, replacing the ones lost when a machine dies, scaling copies up and down with demand, letting containers find and talk to each other as they move, and rolling out new versions without downtime.
Done by hand, that operational load grows with every service you add, and it never sleeps. Container orchestration exists to absorb it — and Kubernetes is the orchestrator the industry converged on. Our containers-versus-virtual-machines explainer covers why containers won the packaging story; Kubernetes is what happened when running them at scale became the next problem.
The core concepts, in plain English
Kubernetes has a reputation for complexity, but its foundation is a handful of ideas:
- Cluster — the whole system: a set of machines pooled together that Kubernetes treats as one large computer to place work on.
- Nodes — the individual machines (usually virtual machines) in that pool, each running the software that lets Kubernetes place and supervise containers on it.
- Pods — the smallest unit Kubernetes runs: one or more tightly coupled containers deployed together. When Kubernetes scales or restarts your application, pods are what it creates and destroys.
- Control plane — the cluster’s brain: it stores the desired state, decides which node each pod should run on, and continuously compares what is running with what should be.
- Services — stable network addresses in front of ever-changing pods, so other parts of the system can reach “the checkout service” without caring which pods currently exist or where they are.
- Declarative configuration — you describe the end state in configuration files (“three copies of this container, this version, reachable here”) rather than issuing step-by-step commands; the cluster works out how to get there.
Desired state and self-healing: the big idea
The concept that makes Kubernetes more than a scheduler is the reconciliation loop. You declare a desired state — say, three replicas of a service — and the control plane never stops comparing that declaration against reality. A pod crashes: the count is now two, which does not match three, so a replacement is started. A whole node dies: its pods are recreated on surviving nodes. Someone scales the deployment to five: two more appear. Nobody is paged to fix the drift; the system corrects itself, continuously, in the direction you declared.
This is why Kubernetes deployments are described rather than performed. A rolling update is just a new desired state — same service, newer container image — which the control plane achieves by replacing pods gradually, keeping the service available throughout. The same loop that heals failures also delivers releases, and that unification of “keep it running” and “change it safely” under one mechanism is the heart of the system’s appeal.
Why it became the standard — and the honest caveat
Kubernetes won orchestration for reasons beyond its features. It is open source and vendor-neutral, so it runs on any cloud or on your own hardware — which made it the natural common ground as companies grew wary of being locked into any one provider. Every major cloud embraced it rather than fighting it, a vast ecosystem of tooling grew around it, and its concepts became shared vocabulary: a team that knows Kubernetes can move between employers and clouds and find the same system waiting.
The honest caveat is that its power has a price. Kubernetes is genuinely complex — its concepts take time to learn, and operating it well takes more — and it is frequently adopted by teams whose needs never justified it. A small application that would thrive on a simpler container service or a serverless platform gains nothing from a cluster except operational burden. The mature engineering position is that Kubernetes is the right tool for organisations running many services at real scale, not a rite of passage for every project — and recognising when a simpler option fits better is exactly the judgement good architecture, and good exam answers, reward.
Managed Kubernetes: EKS and AKS
Running Kubernetes itself — operating the control plane, keeping it available, upgrading it safely — is expert work that has little to do with your actual application. The cloud providers’ answer is managed Kubernetes: Amazon Elastic Kubernetes Service (EKS) on AWS and Azure Kubernetes Service (AKS) on Azure. With these, the provider runs the control plane for you; you get a standard, conformant Kubernetes cluster and concentrate on the workloads you deploy to it, with the platform handling much of the undifferentiated heavy lifting around upgrades, availability and integration with the cloud’s networking, identity and monitoring.
Managed does not mean effortless — you still design the cluster, configure the workloads and own everything you deploy — but it removes the hardest operational layer. It is also worth knowing each cloud’s simpler alternatives, because exams like the contrast: AWS offers ECS as its own, less complex orchestrator, and both clouds offer container platforms that trade Kubernetes’ flexibility for far less to manage. Choosing managed Kubernetes is choosing the industry standard and its portability, at the cost of more moving parts than the simplest options.
Where Kubernetes appears in certification study
On the cloud certification tracks, Kubernetes appears as one option in the compute landscape rather than a subject examined in internal depth. The AWS Solutions Architect Associate expects you to know what EKS is and when to choose it over ECS, Fargate or plain EC2 in a scenario; the Developer Associate approaches the same services from the build-and-deploy side. On Azure, AZ-104 includes AKS among the compute services an administrator should recognise and reason about. What these exams reward is placement judgement: matching an orchestrator to a workload, not writing cluster configuration.
If your goal is deep Kubernetes expertise, dedicated certifications exist for that — our comparison of Kubernetes and AWS certifications weighs those paths against the cloud track. For cloud exams, the level in this article is close to the level required: know what Kubernetes does, what pods, nodes and the control plane are, what EKS and AKS manage for you, and when something simpler is the better answer. The service-selection detail lives in the compute lessons in our revision sections.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.