Workloads & Scheduling

Kubernetes workload resources manage how Pods are created and maintained over time.

Deployments

The most common workload. A Deployment manages a ReplicaSet, which in turn manages Pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app
        image: myapp:v2
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

Rolling Updates

By default, Deployments use a RollingUpdate strategy:

• Gradually replaces old Pods with new ones
• maxSurge: how many extra Pods can exist during update
• maxUnavailable: how many Pods can be down during update

kubectl rollout status deployment/web-app
kubectl rollout undo deployment/web-app    # rollback
kubectl rollout history deployment/web-app

StatefulSets

For stateful apps (databases, queues) that need:

• Stable network identities: pod-0, pod-1, pod-2
• Ordered deployment: pod-0 ready before pod-1 starts
• Persistent storage: each Pod gets its own PVC

kind: StatefulSet
# ...
volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: ["ReadWriteOnce"]
    resources:
      requests:
        storage: 10Gi

DaemonSets

Ensures one Pod runs on every node (or a subset). Used for:

• Log collectors (Fluentd, Filebeat)
• Monitoring agents (Prometheus node-exporter)
• Network plugins (CNI agents)

Jobs & CronJobs

Kind	Purpose
Job	Run a task to completion (one-off)
CronJob	Run a Job on a schedule (cron syntax)

kind: CronJob
spec:
  schedule: "0 2 * * *"   # every day at 02:00
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tool:latest
          restartPolicy: OnFailure

Scheduler & Node Selection

The scheduler picks the best node based on:

1. Filtering: remove nodes that don't meet requirements
2. Scoring: rank remaining nodes

Influencing Scheduling

# Node selector (simple)
spec:
  nodeSelector:
    disktype: ssd

# Node affinity (expressive)
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: zone
            operator: In
            values: ["us-east-1a", "us-east-1b"]

# Taints & Tolerations — prevent pods from landing on tainted nodes
# Taint a node:
kubectl taint nodes node1 dedicated=gpu:NoSchedule
# Tolerate it in a Pod:
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

Resource Management

• Requests: what the scheduler uses to fit the Pod on a node
• Limits: hard cap; CPU is throttled, memory triggers OOM kill

QoS Classes:

Class	Condition
Guaranteed	requests == limits for all containers
Burstable	requests < limits
BestEffort	no requests or limits set

Summary

• Deployments are the go-to for stateless apps with rolling updates
• StatefulSets give stable identity + ordered pods for databases
• DaemonSets guarantee one pod per node
• Resource requests drive scheduling; limits cap consumption