Kubernetes is an open-source system that runs containers across a cluster of machines, keeping the number and placement of running copies matched to a declared desired state, and restarting, rescheduling and scaling them without a person intervening.
Our take. Kubernetes solves coordination problems that appear at a scale most teams have never reached, and adopting it earlier than that scale buys complexity with nothing to spend it on. One container on one machine first; a managed platform second; the cluster when you can name the problem it solves. Teams that start with the cluster spend their first year operating it instead of shipping.
You tell the system what you want running: three copies of this container image, reachable at this name, with this much memory each. It compares that declaration with what exists, starts what is missing, stops what is extra, and keeps doing so. A machine fails and the copies on it are rescheduled elsewhere; a copy crashes and is restarted; load rises and, if you asked, more copies are added. Everything is a declaration reconciled against reality by a controller that never stops looking, and that loop is the whole design. The rest of the system, and there is a great deal of rest, is objects that declare other things and controllers that reconcile them.
Pod: one or more containers scheduled together on one machine; the smallest unit the system runs.
Deployment: the declaration of how many copies of a pod should exist and how to roll a new version out without downtime.
Service: a stable name and address in front of a changing set of pods, so callers never need to know where the copies are.
Ingress: the rules that route outside traffic to services, usually terminating TLS on the way.
ConfigMap and Secret: configuration and credentials injected into pods, so the image stays generic.
Namespace: a partition of the cluster for separating teams or environments.
Stage
Run it as
Why not the next stage yet
One application, small team
A container on a virtual machine, or a platform that runs containers for you
Nothing here needs coordinating
Several services, one team
A managed container service from the cloud provider
You get scaling and restarts without operating a control plane
Many services, several teams, real traffic
A managed Kubernetes cluster from the provider
You now have the scheduling, networking and isolation problems it solves
Regulated, multi-region, hundreds of services
Kubernetes, possibly self-managed, with a platform team
The cluster is the product the platform team ships to everyone else
The system came out of a decade of internal cluster management at one very large company and was designed for its problems: thousands of machines, many teams, constant failure. Those problems are real and most organisations do not have them, which is why the managed offerings from every cloud provider exist and why the Certified Kubernetes Administrator exam is performed on live clusters rather than answered from memory; the skill is operating the thing under failure, and it cannot be recognised. The containers concept underneath it is the one to learn first, and the DevOps shelf puts the cluster last in its order for the reason this page gives.
In practice
A four-person startup with one web application adopts a Kubernetes cluster on day one because a senior hire has used it before. Six months later the team has written more configuration than application code, an upgrade of the cluster has consumed a fortnight, and a networking policy nobody fully understands has caused two outages. The application still has one service and modest traffic. They move it to the cloud provider's managed container service, delete four thousand lines of configuration, and ship features again. Two years later, with a dozen services and a team of thirty, they adopt a managed cluster, and this time they can name the problems it solves: placement, isolation between teams, and rolling out forty services without a person watching each.
A container packages one program and its dependencies to run identically anywhere. Kubernetes decides where many containers run and keeps them running. You need containers to use Kubernetes; you do not need Kubernetes to use containers.
Serverless runs your code on demand without any cluster you can see, billed per invocation. Kubernetes gives you a cluster to run long-lived containers on. Serverless removes the operations; Kubernetes gives you control over them and the work that comes with it.
Cloud hosting is renting compute from a provider; Kubernetes is one way to organise what runs on it. Every major provider offers a managed Kubernetes service, and every one also offers simpler ways to run containers that most teams should try first.
Key takeaways
→Declare the desired state; controllers reconcile reality to it, forever.
→Pods, deployments, services, ingress, config: the six objects cover most real use.
→Adopt it when you can name the coordination problem it solves; a managed platform is the step before.
Certifications that test this
Vendor exams whose syllabus covers this concept — facts, cost and a preparation path on each page.
A rotating selection from the course directory, drawn from the subcategories where this concept is taught rather than picked for it. Details, price and the provider link are on the course page.
Welcome to Generative AI for All course.In today's rapidly evolving business landscape, technologies changes, requires…
Udemy
FAQ
Do I need Kubernetes to run containers in production?
No. Every cloud provider runs containers for you without a cluster you manage, and for one application or a handful of services that is the right answer. Kubernetes earns its cost when there are many services, several teams, and a real need to schedule and isolate them.
Managed or self-hosted Kubernetes?
Managed, for almost everyone. The cloud providers run the control plane, handle upgrades and integrate with their networking and identity. Self-hosting makes sense for regulated environments or scale where the platform is a product with a team behind it.
Which certification covers it?
The Certified Kubernetes Administrator, which is performed on live clusters against a clock and is respected precisely because of that. A developer-facing sibling and a security specialisation exist. All assume comfort with containers, Linux and the command line first.
Sources
The primary text this definition rests on. Read it before you trust ours.
