Kubernetes: What It Does, and Whether You Need It

Quick Answer

Kubernetes runs containers across a cluster of machines, restarting failures, scaling replicas and routing traffic. You declare the desired state and it works continuously to match it. It is genuinely complex and unnecessary for small projects.

The problem it solves

Docker packages an application so it runs identically anywhere. That works well for one container on one machine.

Now suppose you have forty containers across a dozen machines. Questions appear immediately. Which machine has capacity for a new container? What happens when a container crashes at 3am? What happens when a machine dies? How do containers find each other when their addresses change constantly? How do you deploy a new version without downtime?

Answering those by hand does not scale. Kubernetes is an orchestrator — it makes those decisions continuously and automatically.

That is the honest framing: it exists to solve problems that appear at a certain scale. Below that scale it is a solution looking for one.

The declarative model

This is the idea worth taking away even if you never operate a cluster.

You do not tell Kubernetes to do things. You describe the state you want, and a control loop continuously compares actual state against desired state and acts to close the gap.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: web
          image: myapp:1.4.2
          ports:
            - containerPort: 8000

That says "there should be three of these". If one crashes, Kubernetes starts another. If a machine dies, its containers are rescheduled elsewhere. You never issue a restart command; the gap between desired and actual is closed automatically.

Changing the image version and reapplying triggers a rolling update — new containers start, health checks pass, old ones stop, with no downtime and automatic rollback if the new version fails its checks.

The objects you need to know

• Pod — the smallest unit, one or more containers sharing a network and storage. Usually one container. Pods are disposable and their addresses change.
• Deployment — manages a set of identical pods, handling replicas, rolling updates and rollbacks. This is what you normally write.
• Service — a stable address and name for a changing set of pods. Since pods come and go, nothing should ever target a pod directly.
• Ingress — routes external HTTP traffic to services, handling hostnames, paths and TLS.
• ConfigMap and Secret — configuration and credentials injected as environment variables or files, keeping them out of images.
• Namespace — logical separation within a cluster, commonly per environment or team.

The Service concept is the one beginners under-appreciate. It is the internal DNS and load balancing that makes a constantly-changing set of containers addressable at all.

The complexity is real

Being honest about this matters more than listing features.

Running Kubernetes properly means understanding networking across nodes, persistent storage for stateful workloads, resource requests and limits, health probes, role-based access control, secrets handling, monitoring and log aggregation, and how to debug a pod stuck in a crash loop.

Managed offerings — EKS, GKE, AKS — remove the burden of running the control plane, which is a genuine help. They do not remove the conceptual load of everything above.

The typical failure mode is a small team adopting Kubernetes for a three-service application and spending more time on the cluster than on the product. That time is real and it is rarely recovered.

A useful test: if you cannot name the specific problem Kubernetes is solving for you today, you do not need it yet.

What to use instead, and how to learn it anyway

For most projects: a PaaS, a managed container service, or a couple of virtual machines behind a load balancer. Docker Compose covers running several containers on one machine and is enough for a great deal.

Kubernetes earns its complexity when you have many services, several teams deploying independently, genuine scaling requirements, or a need to run the same platform across clouds.

That said, it is worth learning even if you do not need it, because it appears in job listings constantly. A practical path: install a local single-node cluster with kind or minikube, deploy a small application with a Deployment and a Service, expose it, scale it, and deliberately kill a pod to watch it recover.

That last step is the one that makes the declarative model click. Understanding the concepts and being able to read a manifest is what fresher-level roles actually expect — nobody asks a new graduate to operate a production cluster.

Frequently Asked Questions