Kubernetes is the system that runs containers at scale, and it has become the default answer for orchestrating workloads across many machines. It is also one of the most over-adopted technologies in software, dragged into projects that would run happily on a single managed container. This guide explains what Kubernetes actually does, the handful of objects you really need to understand, and the honest question of whether your project needs it at all.
What changed in 2026
- Managed Kubernetes is the norm. Almost no one stands up their own control plane anymore. Amazon EKS, Google GKE, and Azure AKS handle the hard parts, and that is the recommended path for most teams.
- Platform layers smoothed the edges. Internal developer platforms and tools built on top of Kubernetes hide raw YAML from application developers, so teams interact with a simpler interface.
- Cost awareness rose. Idle nodes and over-provisioned clusters became a visible line item, pushing teams toward autoscaling and right-sizing rather than running large always-on clusters.
- Serverless container options matured. For many workloads, running a container on a managed platform without a cluster is now a credible alternative, narrowing the cases where full Kubernetes earns its complexity.
What Kubernetes actually does
At its core, Kubernetes takes a description of the state you want and works to keep reality matching it. You declare "run three copies of this container, expose it on this port, restart it if it crashes," and the control plane makes it so. The pieces you will touch most:
- Pod — the smallest unit, usually one container plus its shared resources.
- Deployment — manages a set of identical Pods, handles rolling updates and rollbacks, and keeps the desired count running.
- Service — a stable network address and load balancer for a set of Pods, since Pods come and go.
- Ingress — routes external HTTP traffic to Services, handling hostnames and paths.
- ConfigMap and Secret — inject configuration and credentials without baking them into the image.
You can go a long way with just those. The rest of the ecosystem (operators, custom resources, service meshes) is powerful but optional, and adopting it before you feel the pain is a classic mistake. If you have not yet packaged your app into containers, start with containers using Docker before worrying about orchestration.
Managed versus self-hosted
| Factor |
Managed (EKS/GKE/AKS) |
Self-hosted |
| Control plane ops |
Provider handles it |
You patch and run it |
| Upgrades |
Mostly automated |
Manual, error-prone |
| Cost |
Cluster fee plus nodes |
Nodes plus your time |
| Flexibility |
High, within provider limits |
Total |
| Right for |
Almost everyone |
Strict compliance, on-prem, scale specialists |
For the overwhelming majority of teams, managed wins. The control plane is undifferentiated heavy lifting; pay someone to run it.
Do you actually need it?
- One small app, modest traffic? A single container on a managed platform or a small VM is simpler and cheaper. Skip Kubernetes.
- A handful of services? Container orchestration helps, but consider whether a managed serverless-container option covers you before committing to a cluster.
- Many services, real scale, multiple teams? This is Kubernetes' home turf. Declarative deploys, self-healing, and autoscaling pay off here.
- Compliance or hybrid-cloud requirements? Kubernetes provides a consistent layer across environments, which can justify the complexity.
The deciding question is not "is Kubernetes good" but "do I have enough services and scale that orchestration saves more time than it costs." Adopt it when you feel the pain, not before.
Common mistakes
- Adopting it for a single app. The operational overhead dwarfs the benefit at that size.
- Hand-writing raw YAML for everything. Use Helm or a higher-level tool to template and version your manifests.
- Self-hosting the control plane casually. Unless you have a strong reason, let a managed service run it.
- Ignoring cost. Clusters left over-provisioned burn money quietly. Enable autoscaling and review node usage.
FAQ
What does Kubernetes do in simple terms?
It keeps your containers running the way you declared. You say how many copies, how they network, and what to do on failure, and Kubernetes schedules, scales, and restarts them across a cluster automatically.
Do I need Kubernetes for a small project?
Usually not. A single container on a managed platform is simpler and cheaper. Reach for Kubernetes when you have many services and real scale that orchestration genuinely simplifies.
Should I use managed or self-hosted Kubernetes?
Managed for almost everyone. EKS, GKE, and AKS run the control plane for you, which is the hard, undifferentiated part. Self-host only for strict compliance, on-prem, or specialist needs.
Is Kubernetes the same as Docker?
No. Docker builds and runs individual containers; Kubernetes orchestrates many containers across machines. They complement each other rather than compete.
Where to go next
Learn containers with Docker first, compare serverless versus containers for your workload, and decide between microservices and a monolith.