A node is a machine in the cluster. A Pod is Kubernetes’ smallest deployable compute unit. A Deployment is a controller-level object commonly used to keep a desired set of interchangeable Pods running.
Swipe or scroll sideways to read the full diagram.
Deployment wants 3 replicas → Pods A/B/C → scheduler places Pods across Node 1 and Node 2.
The scheduler chooses placement for an unscheduled Pod. Controllers reconcile workload state, and kubelet manages the assigned Pod on its node. Machine capacity remains a separate concern.
Source: The Kubernetes Authors · CC-BY-4.0 · Reproduced unchanged.
Node: the resource pool
A node contributes central processing unit (CPU) capacity, memory, local storage, networking, and possibly GPUs or other devices.
The scheduler considers Pod resource requests and constraints when deciding which node can run it.
Pod: the scheduling and lifecycle unit
A Pod contains one or more tightly coupled containers that share a network namespace and can share volumes.
Most application Pods contain one main application container, but a Pod can also include init containers or sidecars where the lifecycle relationship makes sense.
Kubernetes schedules Pods, not arbitrary individual containers.
Deployment: desired replicated workload
A Deployment describes a desired Pod template and replica count.
If:
desired replicas = 4
but only three matching Pods exist, the control loop creates another.
If the Pod template changes, the Deployment coordinates replacement through ReplicaSets.
A Deployment continuously reconciles desired state versus actual state.
What happens when a Pod dies?
For a Deployment-managed stateless workload, a controller creates replacement work. The replacement Pod is a new Pod; Kubernetes does not resurrect the old one as an immortal object.
If the failure came from a dead node, the new Pod may be scheduled elsewhere if suitable capacity exists.
Controllers create work; the scheduler places it
The Deployment/controller decides that a Pod should exist.
The scheduler decides where an unscheduled Pod should run.
The kubelet on that node works with the container runtime to start and supervise the Pod’s containers.
That separation becomes important during autoscaling:
The workload autoscaler changes desired replicas; a controller creates the missing Pods and the scheduler tries to place them. If suitable capacity is unavailable, they stay Pending while node autoscaling can add machines.
Next: Services and networking.