Kubernetes (K8s) has become the dominant container orchestration platform, but it is also one of the most over-deployed tools in the industry. Many teams are running Kubernetes for workloads that would be better served by much simpler infrastructure. This article covers what Kubernetes actually does, when it genuinely helps, and when simpler alternatives are the better choice.
What Kubernetes Does
Kubernetes is a system for automating the deployment, scaling, and management of containerised applications. The core problem it solves: you have many containers (Docker containers) running your application, and you need to: place them on the right machines (scheduling); restart them if they crash (health checking and self-healing); route traffic to the right instances (service discovery and load balancing); scale up when traffic spikes and scale down during quiet periods (autoscaling); roll out new versions without downtime (rolling deployments); manage secrets and configuration (ConfigMaps and Secrets). Key abstractions: Pod: the smallest deployable unit — one or more containers that are always scheduled together and share a network namespace. Deployment: manages a set of replicated Pods, handling rolling updates and rollbacks. Service: a stable network endpoint that routes traffic to the appropriate Pods, even as Pods come and go. Ingress: exposes HTTP/HTTPS routes to outside the cluster; managed by an Ingress Controller (nginx, traefik, or cloud-specific). ConfigMap and Secret: configuration data and sensitive data (passwords, API keys) injected into Pods. PersistentVolume: storage that persists beyond the lifetime of a Pod. HorizontalPodAutoscaler (HPA): automatically scales the number of Pod replicas based on CPU usage, memory, or custom metrics. The control plane: the cluster is managed by a control plane (API server, etcd database, controller manager, scheduler) that continuously works to make the actual state of the cluster match the desired state you declare in YAML manifests. This declarative model — you declare what you want and Kubernetes figures out how to achieve it — is its core design.
When Kubernetes Genuinely Helps
Kubernetes adds significant value when: you are running many microservices (10+) that need to be deployed, scaled, and updated independently; you need zero-downtime deployments across multiple services simultaneously; you have variable traffic patterns that need autoscaling (e.g., batch jobs at night, traffic spikes during business hours); you need to run across multiple cloud providers or on-premises + cloud; you have a team large enough to justify operational overhead (a rough threshold: Kubernetes makes sense when you have at least 2–3 people who can manage it). The operational overhead: Kubernetes has significant operational complexity — version upgrades, node maintenance, network configuration, RBAC (role-based access control), storage configuration, monitoring setup, logging setup. A managed Kubernetes service (Amazon EKS, Google GKE, Azure AKS) removes some but not all of this overhead. When it probably does not help: a single application with a few containers; a startup with under 10 services; a team where everyone is already stretched thin; any situation where a junior developer needs to deploy a hotfix at 3am and the path through Kubernetes adds unnecessary risk. The alternatives: for most small-to-medium applications — a single Docker host with Compose, a managed container service (AWS ECS, Google Cloud Run, Fly.io), or even a conventional PaaS (Heroku, Render, Railway) is operationally simpler and often faster to develop against. Cloud Run in particular is worth considering: it scales to zero, has essentially no operational overhead, and handles most stateless workloads well.
