Kubernetes is software that runs and manages containerised applications across many machines automatically. You tell it the state you want — "keep five copies of this app running, restart any that crash, scale up under load" — and Kubernetes makes it happen. It's the industry standard for running containers at scale, and while it's genuinely complex, that complexity buys you reliability, scalability, and portability that are hard to get any other way.
If you work in a technology organisation, you've heard the word Kubernetes in meetings, job descriptions, and architecture debates — often without a clear explanation of what it actually is or why it's everywhere. This guide gives you that: what Kubernetes is, the problem it solves, how it works, its core pieces in plain English, when you genuinely need it (and when you don't), what it costs, and who on your team should learn it. No prior infrastructure knowledge assumed.
Start with the problem Kubernetes solves
Modern applications are built as containers — self-contained packages holding an app and everything it needs to run (see Docker vs Kubernetes for how containers are built). A container is easy to run on one machine. The trouble starts at scale.
Imagine you're running not one container but hundreds, across dozens of servers. Now the hard questions pile up: Which container runs on which server? What happens when one crashes at 3am? How do you push a new version without downtime? How do you handle a traffic spike? How do containers find and talk to each other across machines? Answering all of that by hand is impossible at scale.
Kubernetes automates every one of those decisions. It's an orchestrator — the system that decides where containers run, keeps the right number alive, replaces failures, routes traffic, and rolls out updates, continuously, without a human babysitting it. That's the entire reason it exists.
How Kubernetes works: declare the goal, not the steps
The core idea that makes Kubernetes powerful — and unfamiliar — is that it's declarative. You don't tell it how to do things step by step. You describe the desired state — "I want five copies of this app, always" — and Kubernetes constantly works to make reality match that description.
If a container crashes, actual state (four running) no longer matches desired state (five), so Kubernetes starts a new one. If a whole server dies, it reschedules that server's containers elsewhere. If you change the desired version, it rolls the change out gradually. This continuous "observe the gap, close the gap" loop is the engine underneath everything, and it's why Kubernetes is described as self-healing.
You tell Kubernetes what you want the world to look like. Its entire job is to keep making the world look like that — forever, without being asked twice.
Master the right skills for your goal
Not sure which path fits? Get a free 1:1 consultation with our team.
The core pieces, in plain English
Kubernetes has a reputation for jargon. Here are the pieces that actually matter, explained simply.
Cluster and nodes
A cluster is the whole system — a set of machines working together. Each machine is a node. Your containers run on the nodes; a control plane (the brain) decides what goes where.
Pods
A pod is the smallest unit Kubernetes runs — usually one container (sometimes a few that must live together), sharing networking and storage. You generally don't manage pods directly; you let higher-level objects manage them.
Deployments
A deployment is how you declare "run N copies of this app and keep them healthy." It manages pods for you — scaling them, replacing failures, and rolling out new versions gradually. This is the object teams work with most.
Services
Pods come and go, so their addresses change. A service gives a stable address to a set of pods and load-balances traffic across them, so other parts of the system can reliably reach "the app" without tracking individual pods.
Ingress and config
Ingress manages how outside traffic reaches your services (routing, HTTPS). ConfigMaps and Secrets hold configuration and sensitive values separately from the container image, so the same image runs in dev, staging, and production with different settings.
What Kubernetes gives you
- Self-healing — crashed containers and failed nodes are replaced automatically.
- Scaling — add or remove copies to match load, manually or automatically.
- Zero-downtime deploys — roll out new versions gradually and roll back if something breaks.
- Efficient resource use — pack containers onto machines intelligently instead of over-provisioning.
- Portability — the same Kubernetes setup runs on any cloud or on-premises, reducing lock-in.
When you genuinely need Kubernetes — and when you don't
Kubernetes is powerful, but it is not free of cost — the cost is complexity. The honest guidance:
You probably need it when: you run many containers across multiple machines; you need serious scaling and high availability; you deploy frequently; you want portability across environments; or you're building a platform other teams deploy onto.
You probably don't when: you run a single app on one server; your scale is modest and stable; or your team is small and would spend more time operating Kubernetes than building product. In those cases, simpler managed platforms (AWS ECS/Fargate, Google Cloud Run, Azure Container Apps) or Docker Compose deliver most of the benefit with a fraction of the overhead.
Adopting Kubernetes when your scale doesn't justify it is one of the most common and expensive mistakes in modern infrastructure. Match the tool to the need.
What Kubernetes costs
The Kubernetes software itself is open-source and free. Real costs come from two places: the infrastructure (the servers your cluster runs on) and, very commonly, a managed service. Running Kubernetes' control plane yourself is a serious operational job, so most enterprises use a managed offering — Amazon EKS, Google GKE, or Azure AKS — where the cloud provider operates the control plane and you pay for that plus your nodes. This trades a modest fee for eliminating a large chunk of operational burden, and it's the default choice for most teams.
Kubernetes in the enterprise stack
Kubernetes rarely stands alone. It sits at the centre of a broader cloud-native toolchain: CI/CD pipelines that build and deploy containers into it, monitoring and logging that watch what's running, infrastructure-as-code that provisions the clusters, and increasingly service meshes that manage traffic between services. Understanding Kubernetes is the anchor that makes the rest of the modern DevOps and platform-engineering picture cohere — which is why it's central to our enterprise DevOps training solutions and cloud training programmes.
Who should learn Kubernetes, and how deep
The depth needed varies sharply by role, which is why blanket "learn Kubernetes" advice wastes time. Platform and infrastructure engineers and SREs — the people who run it — need deep operational command. Developers who deploy onto it need working fluency in pods, deployments, services, and config, but not the internals of cluster operation. Technical leaders need enough to make sound architecture and buy-vs-build decisions. Matching the depth to the role is how teams build real capability without over-investing.
That role-based approach is exactly how our hands-on, instructor-led programmes teach it — from container fundamentals through production-grade cluster operation. Kubernetes and containers sit within our DevOps and SRE training, alongside the broader cloud skills in our AWS Cloud training programme.
- Kubernetes runs and manages containerised apps across many machines automatically — it's the standard container orchestrator.
- It's declarative: you describe the desired state and it continuously makes reality match, which is what makes it self-healing.
- Core pieces: clusters/nodes (the machines), pods (the unit), deployments (run N copies), services (stable addresses), ingress and config.
- You need it for many containers at scale with high-availability demands — not for a single small app, where it's costly overkill.
- The software is free; costs are infrastructure plus (usually) a managed service like EKS, GKE, or AKS. Learning depth should match the role.
Kubernetes glossary
- Container: a self-contained package of an app and its dependencies.
- Cluster: the whole set of machines Kubernetes manages together.
- Node: a single machine in the cluster.
- Pod: the smallest deployable unit — one or a few containers that run together.
- Deployment: declares and maintains N copies of an app; handles rollouts.
- Service: a stable address and load balancer for a set of pods.
- Ingress: manages external traffic routing into services.
- Control plane: the brain that decides scheduling and maintains desired state.
- Declarative: you specify the desired end state, not the steps to reach it.
- Managed Kubernetes: a cloud service (EKS/GKE/AKS) that operates the control plane for you.
Frequently asked questions
Is Kubernetes the same as Docker?
No — they solve different problems and work together. Docker packages an application into a container. Kubernetes orchestrates many containers across many machines: scheduling them, scaling them, restarting failed ones, and networking them. You use Docker to build the container and Kubernetes to run it at scale.
Do I need Kubernetes for a small application?
Usually not. Kubernetes shines when you run many containers across multiple servers with real demands for scaling and uptime. For a single app on one server, it is heavy overkill — simpler options (a managed platform, Docker Compose, or a single container host) are faster and cheaper. Adopt Kubernetes when the scale justifies the complexity.
Why is Kubernetes considered hard to learn?
Because it is a large system with many concepts — pods, services, deployments, ingress, config — and a declarative model that is unfamiliar at first. The learning curve is real, but structured, hands-on training compresses it dramatically compared with self-teaching from scattered documentation.
What is a pod in Kubernetes?
A pod is the smallest deployable unit — one or more tightly-coupled containers that share networking and storage and run together on the same node. You rarely manage pods directly; higher-level objects like deployments manage them for you.
Is Kubernetes free?
The core Kubernetes software is open-source and free. What costs money is the infrastructure it runs on and, commonly, a managed service (Amazon EKS, Google GKE, Azure AKS) that runs the control plane for you so you don't operate it yourself.
Who on a team needs to know Kubernetes?
Primarily platform and infrastructure engineers and SREs who run it, plus developers who deploy onto it and benefit from understanding pods, services, and config. The depth needed differs by role, which is why role-based training beats one-size-fits-all courses.
What are the main alternatives to Kubernetes?
For simpler needs: managed container platforms (AWS ECS/Fargate, Google Cloud Run, Azure Container Apps) that hide the orchestration, or Docker Compose for local and small deployments. Kubernetes wins when you need portable, fine-grained control at scale across environments.
Ready to build this capability in your team?
Browse our upcoming batches — live, instructor-led, delivered on Orbit.