Skip to content

Workloads and Scheduling

How to run application code on a cluster and keep it running: choosing the right workload controller, telling the scheduler where pods are and aren't allowed to go, and sizing/scaling pods so the cluster doesn't starve or waste capacity.

If you already know what a Deployment is and just need Service or Ingress details, skip ahead to Networking.

Read in this order

  1. Deployment Strategies — RollingUpdate vs. Recreate, tuning maxSurge/maxUnavailable, and rollout/rollback with kubectl
  2. StatefulSets — ordered deployment, stable network identity, and per-pod persistent storage for stateful workloads
  3. DaemonSets — running exactly one pod per (matching) node for agents like log collectors and CNI plugins
  4. Scheduling, Affinity, and Taints — how the scheduler actually picks a node, and how to steer or restrict that choice
  5. Resource Requests, Limits, and QoS — how requests and limits drive scheduling, throttling, and eviction order
  6. Autoscaling — HPA, VPA, and Cluster Autoscaler/Karpenter, and how they interact (and conflict)

Deployments cover most workloads

Most application workloads are stateless and belong in a Deployment. Reach for a StatefulSet or DaemonSet only when the workload genuinely needs stable identity/storage or one-per-node placement — both add operational complexity a plain Deployment doesn't have.

Next

Once your workloads are scheduled and scaling correctly, continue to Networking to get traffic to and between them.