• Node: machine (physical/VM) that hosts Pods (formerly called minion)
  • Cluster: group of nodes; failed node → workloads continue on others
  • Control plane: monitors cluster, stores state, reschedules failed workloads
  • Worker node: runs Pods via kubelet + container runtime

Node lifecycle and scheduling

  • New Pod → Scheduler picks a node by filtering (taints, resources, affinity) then scoring.
  • Allocatable = Capacity minus reserved (system + kubelet). Scheduling uses requests against allocatable, not limits.
  • A node that stops heartbeating → Ready becomes NotReady; after the eviction timeout its Pods are rescheduled elsewhere (unless DaemonSet/local data ties them down).
  • cordon = mark unschedulable (existing Pods stay); drain = cordon + evict Pods for maintenance.

Node conditions

ConditionMeaning
ReadyNode healthy and accepting Pods
MemoryPressureLow available memory
DiskPressureLow disk capacity
PIDPressureToo many processes
NetworkUnavailableNode network not configured

kubectl 

kubectl get nodes
kubectl get nodes -o wide          # adds INTERNAL-IP, CONTAINER-RUNTIME
kubectl describe node <name>       # capacity, allocatable, taints, conditions
kubectl top node                   # CPU/memory (needs metrics-server)
kubectl cordon <name>              # mark unschedulable
kubectl drain <name> --ignore-daemonsets --delete-emptydir-data   # evict for maintenance
kubectl uncordon <name>            # re-enable scheduling

Useful describe node fields

FieldUse
Capacity / AllocatableTotal vs schedulable resources
TaintsWhy Pods won't schedule without tolerations
ConditionsReady, MemoryPressure, DiskPressure
Non-terminated PodsWhat's running on the node

Exam gotchas

  • Pod stuck Pending with "didn't match node's resources" → kubectl describe node allocatable vs Pod requests
  • For stable Pod networking, use Services: not node IPs or Pod IPs