Nodes & Pods
A Node is a machine that lends its resources to the cluster; a Pod is something placed on it for a while. A Node does not decide what it runs — a controller creates the workload, the scheduler picks the seat, and the Node's kubelet takes it and starts it. That is why Pods do not travel between Nodes: what looks like a move is a Pod being deleted here and a new one created there.
01Nodes & Pods
Concept at a GlanceA Node is one machine lending resources to the cluster. Physical or virtual makes no difference; what Kubernetes looks at is the software running on it.
There are three pieces. The kubelet takes a Pod spec and starts it, a container runtime actually runs the containers, and kube-proxy turns Service addresses into rules on this Node.
Pods are placed on top. A Node does not decide what it runs — how many is the controller's call, and which Node is the scheduler's.
Many Pods to a Node, but one Node to a Pod. The containers inside a Pod are never split either; they run together on the same machine.
What a Node offers is not its full capacity. The scheduler reads the allocatable amount left after the system's share, and the count is bounded too — 110 Pods per Node is the working ceiling.
Workloads are not the only thing on a Node. Pieces that must exist once per Node, like kube-proxy or the network plugin, are filled in by a DaemonSet.
Pods do not travel between Nodes. There is simply no command that moves a running Pod to another machine.
Node 2 stops answering. The node controller sets Ready to Unknown and applies a taint, and with the defaults its Pods become eviction candidates after about five minutes.
The missing share is created anew on a Node that is still alive. What came back is not the same Pod, though — the name changing to web-4 is the proof, and the IP changes with it.
So whatever needs an address must call the Service, not the Pod. A Pod's name and IP are values that can change at any moment.
There is a cost. Nobody can tell whether the Pods on an unreachable Node actually died, so two Pods doing the same work may exist for a while.
02 Understand It Simply
For EveryoneA node is one machine where pods actually run, offering pods what is left after the system's own reservation. When a node stops, the pods on it are not moved — they are created afresh on another node.
Every Node carries three pieces Kubernetes requires: the kubelet takes a Pod spec and starts its containers, a container runtime actually runs them, and kube-proxy turns Service addresses into rules on that Node.
What a Node offers the cluster is not its full capacity but its allocatable amount — capacity minus what system daemons keep — and the count is bounded too, with 110 Pods per Node taken as the ceiling.
All containers of one Pod always run together on one machine.
When a Node stops answering, the node controller sets Ready to Unknown and applies a NoExecute taint, so with the defaults its Pods become eviction candidates after about five minutes.
At that moment the API server has lost contact with the kubelet and cannot tell whether those Pods actually died — so two Pods doing the same work may exist briefly, which is precisely why workloads that cannot tolerate duplication, such as StatefulSets, are handled carefully here.
Kubernetes repairs workloads, not machines.
- –Understanding why a Pod's name and IP change when it comes back
- –tracing the recovery path and delay after a node failure
- –sizing capacity with allocatable and the per-node Pod ceiling
- –and telling node-resident system Pods (DaemonSets) apart from workloads
03 Frequently Asked Questions
FAQWhat is Nodes & Pods?+
A Node is a machine that lends its resources to the cluster; a Pod is something placed on it for a while. A Node does not decide what it runs — a controller creates the workload, the scheduler picks the seat, and the Node's kubelet takes it and starts it. That is why Pods do not travel between Nodes: what looks like a move is a Pod being deleted here and a new one created there.
Where is Nodes & Pods used?+
Understanding why a Pod's name and IP change when it comes back, tracing the recovery path and delay after a node failure, sizing capacity with allocatable and the per-node Pod ceiling, and telling node-resident system Pods (DaemonSets) apart from workloads.
What's a simple analogy for Nodes & Pods?+
A node is one machine where pods actually run, offering pods what is left after the system's own reservation. When a node stops, the pods on it are not moved — they are created afresh on another node.