Workloads & Scheduling Knowledge

A Deployment manages stateless applications. It creates and manages ReplicaSets, maintains the desired replica count, supports rolling updates, keeps rollout history, and can roll back to an earlier revision.

A bare Pod is not replaced if it dies or the node disappears. A Deployment replaces failed Pods, manages rollout strategy, scales replicas, and gives you controlled updates and rollbacks.

A ReplicaSet maintains a stable set of Pod replicas. A Deployment manages ReplicaSets and adds rollout and rollback logic. During an update, the Deployment creates a new ReplicaSet and scales the old one down.

Use kubectl scale deployment web --replicas=5. You can also edit the Deployment spec or apply YAML with spec.replicas: 5. If an autoscaler owns replicas, check HPA behavior before manually scaling.

Use kubectl rollout history deployment/myapp. For more detail on a revision, add --revision=<number>. Meaningful history is easier when change causes are recorded or managed through Git.

Use kubectl rollout undo deployment/myapp. You can target a specific revision with --to-revision=<number>. After rollback, watch kubectl rollout status deployment/myapp and verify Pods, events, and service endpoints.

Recreate deletes old Pods before creating new ones, causing downtime but avoiding mixed old/new versions. RollingUpdate gradually replaces Pods and can keep service available when readiness probes, capacity, and rollout settings are correct.

Common causes include readiness probes never passing, insufficient cluster resources, maxUnavailable too strict, PodDisruptionBudget constraints, volume attach delays, missing ConfigMaps or Secrets, affinity rules, or app startup failures.

A DaemonSet ensures one Pod runs on every matching node, or on selected nodes. It is commonly used for log collectors, monitoring agents, CNI components, storage plugins, and security agents.

A Job runs Pods until a task completes successfully. It is useful for migrations, batch processing, one-off maintenance, and data tasks. The Job controller tracks completions and retries failed Pods according to its backoff settings.

A CronJob creates Jobs on a cron schedule for periodic or recurring tasks. Use it for scheduled backups, reports, cleanup, sync jobs, or recurring maintenance. Watch concurrency policy, missed schedules, and job history limits.

A Job runs work to completion and then stops. A Deployment keeps long-running Pods alive. Use Jobs for finite tasks and Deployments for services or processes that should continuously run.

A StatefulSet manages stateful applications with stable Pod identities, stable network names, ordered deployment or termination, and persistent storage tied to each ordinal. It is useful when replicas are not interchangeable.

Taints repel Pods from nodes. Tolerations allow Pods to schedule onto tainted nodes, but they do not force placement. They are commonly used for dedicated nodes, GPU nodes, control-plane nodes, and maintenance scenarios.

Node affinity constrains or prefers Pod scheduling based on node labels. Required rules must be satisfied; preferred rules influence scoring. Use it for placement by zone, hardware type, node pool, compliance boundary, or workload class.

Pod affinity schedules Pods close to other Pods based on labels, often within the same node, zone, or topology domain. It is useful when workloads benefit from locality, but required affinity can make scheduling harder if capacity is tight.

Pod anti-affinity spreads Pods away from other matching Pods to improve availability. It is often used to avoid placing all replicas on one node or zone. Required anti-affinity is strict; preferred anti-affinity is more flexible.

Readiness probes determine when a Pod should receive traffic. If readiness fails, the Pod remains running but is removed from Service endpoints. This protects users from containers that started but are not ready to serve.

Liveness probes detect containers that are stuck or unhealthy and should be restarted. A bad liveness probe can create restart loops, so it should check process health rather than slow downstream dependencies.

Readiness controls traffic. Liveness restarts unhealthy containers. Startup gives slow-starting apps time before liveness begins. Startup probes are useful when an app has long initialization but should still be restarted if it later hangs.

Use kubectl run test --image=busybox --command -- sleep 3600. The --command -- separator tells kubectl that the following tokens are the container command and arguments.

A Horizontal Pod Autoscaler adjusts replica count based on CPU, memory, or custom/external metrics. It needs metrics availability and realistic resource requests. It changes Pod count, not node count.

Use kubectl create deployment web --image=nginx --dry-run=client -o yaml. Redirect it to a file if you want a starter manifest, then edit labels, replicas, probes, resources, and strategy before applying.

A PriorityClass defines scheduling priority for Pods. Higher-priority Pods can be scheduled ahead of lower-priority Pods and may preempt lower-priority Pods when resources are scarce. Use it carefully for truly critical workloads.