Workloads & Scheduling
Workload objects
Deployments manage ReplicaSets and rolling updates; StatefulSets give stable names and per-Pod PVCs; DaemonSets run one Pod per eligible node; Jobs run to completion and CronJobs schedule them. Pods can have init containers (run sequentially before app containers) and sidecars (long-running helpers). Probes affect traffic and restarts: readiness removes a Pod from Service endpoints; liveness restarts; startup protects slow starts.
Scheduling controls
The scheduler filters nodes by requests, nodeSelector, node affinity, taints/tolerations, and topology constraints, then scores. Requests are reserved for scheduling; limits are enforced at runtime. QoS classes (Guaranteed, Burstable, BestEffort) follow from requests/limits. Taints repel Pods unless tolerated; NoExecute evicts non-tolerating Pods. Cordoning marks a node unschedulable; draining evicts workloads (respecting PodDisruptionBudgets unless forced).
Traps
Changing a Pod template triggers a rollout, but some fields are immutable. maxSurge/maxUnavailable control rollout speed. A Pod can be Pending because of insufficient requests, unsatisfied affinity, or an untolerated taint. A Running Pod can still fail readiness. Resource limits that are too low cause OOMKilled or throttling.
Worked example: to place a Pod only on SSD nodes that carry a dedicated taint, set nodeSelector: disk: ssd and add tolerations for dedicated=ssd:NoSchedule. Rule of thumb: requests schedule, limits enforce; check kubectl describe pod events first.