What does Kubernetes actually do for you that plain Docker doesn't?

#Docker answers "how do I run one container." Kubernetes answers "how do I run a fleet."

Docker (and the OCI runtime underneath it) solves a real problem: package an application with its dependencies and run it consistently anywhere. What it does not solve is what happens the moment you have more than one host and more than one instance of a service — and in production, you always do. That gap is exactly what Kubernetes? fills. It is not "Docker but better"; it's an orchestration layer that assumes containers already exist and adds the machinery to run hundreds of them, across many machines, without a human manually deciding where each one goes.

#What plain Docker leaves you to build yourself

If all you have is docker run on a handful of servers, you are personally responsible for: deciding which host has capacity for a new container, restarting a container that crashed or a whole service if a host dies, giving callers a stable address for a group of containers whose individual IPs change every time they restart, routing external traffic to the right service by hostname or path, rolling out a new version without downtime and rolling back if it's broken, and injecting configuration and secrets without baking them into the image. None of that is a Docker feature — it's infrastructure you'd have to script by hand, badly, forever.

#The core objects, and the job each one does

• Pod — the smallest deployable unit. Almost always one container, sometimes a tightly coupled pair (an app plus a sidecar), sharing one network namespace and one IP. Pods are disposable and expected to die; you almost never create one directly.
• Deployment — a declarative statement of desired state: "I want 3 replicas of this Pod template, running this image." A Deployment manages a ReplicaSet, which is the thing that actually keeps the replica count correct, and the Deployment layer on top adds rolling updates and rollback history.
• Service — a stable virtual IP and DNS name that load-balances across whichever Pods currently match a label selector. Pods are cattle with changing IPs; a Service is the one address that never changes, which is what lets one component find another without hardcoding anything.
• Ingress — Layer 7 routing into the cluster: host- and path-based rules, TLS termination, all funneling external HTTP(S) traffic down to the right Service. A Service alone gives you a stable internal address; an Ingress is what lets api.example.com/orders and api.example.com/users reach two different Services through one external load balancer.

#The idea underneath all of it: the reconciliation loop

Every one of those objects is managed the same way, and it's the single most important concept in Kubernetes: you declare what you want (spec), and a controller continuously drives the actual state toward it (status). This is a level-triggered control loop, not an event handler — it doesn't just react once to "a Pod died," it continuously asks "does actual match desired right now?" forever, which is what makes it self-healing even against failures nobody wrote explicit code for.

No single component "deploys your app." The Deployment controller only decides how many Pods should exist; the scheduler only decides which node runs each one; the kubelet on that node only makes the container runtime actually start it and keeps reporting whether it's alive. Each one watches the API server, does its narrow job, and writes its result back — and because every step re-runs continuously, killing a node doesn't require a human to notice: the scheduler sees Pods with no healthy node and reschedules them, and the Deployment controller sees the replica count drop and asks for more.

#What you get that Docker alone never gave you

• Self-healing — a crashed container or a dead node triggers automatic rescheduling, no on-call page required for the common case.
• Service discovery and load balancing built into the platform, immune to Pods' ephemeral IPs.
• Declarative rolling updates and rollback — kubectl rollout undo reverts to the previous ReplicaSet in seconds.
• Horizontal autoscaling driven by CPU/memory or custom metrics.
• A uniform API for secrets, config, storage, and network policy, instead of one bespoke script per concern.

🧠 Check your understanding
0/3 · 0/3 answered
1. A Pod's IP address changes every time it restarts. What Kubernetes object exists specifically to give other components a stable address that survives that churn?
ServiceNamespaceDeploymentIngress
2. What does an Ingress add on top of what a Service already provides?
Layer 7 routing (host/path rules) and TLS termination for external traffic into one or more ServicesIt replaces the need for Pods entirelyA faster network protocol between PodsAutomatic horizontal scaling of Deployments
3. A node crashes, taking two Pods from a Deployment with it. What actually notices and fixes this, without a human intervening?
The reconciliation loop: the scheduler sees unscheduled/unhealthy Pods and the Deployment controller sees actual replicas below desired, and both act continuously until they match againNothing — Kubernetes requires manual rescheduling after a node failureThe Ingress controller reboots the affected nodeDocker automatically restarts the node