Workloads and Scheduling
This chapter explains the controllers that run and manage Pods, how rolling updates and rollbacks work, and how the scheduler decides where Pods run using requests, taints, tolerations, and affinity. These are the day-to-day tools for deploying and operating applications.
Choosing the right workload controller
Deployments manage stateless, scalable replicas with rolling updates. StatefulSets provide stable identities and ordered rollout for stateful apps. DaemonSets run one Pod per node, which is ideal for agents like log collectors, and automatically extend to new nodes. Jobs and CronJobs run Pods to completion, once or on a schedule.
Rolling updates and rollbacks
A Deployment updates Pods gradually, keeping the app available. kubectl rollout status watches progress, kubectl rollout history lists revisions, and kubectl rollout undo reverts to a previous revision using the history Kubernetes retains. This makes releases reversible without recreating objects or losing managed state.
Requests, limits, taints, and tolerations
Resource requests tell the scheduler how much CPU and memory a Pod needs, driving placement decisions, while limits cap consumption at runtime. Taints on a node repel Pods unless the Pod carries a matching toleration, which is how nodes are reserved for specific workloads. Node affinity and nodeSelector express a Pod's preference for particular nodes.