CKA (Other exams): Workloads & Scheduling

The Workloads & Scheduling domain tests whether you can run applications reliably: Deployments and rolling updates, probes, resource requests and limits, ConfigMaps and Secrets, and scheduler constraints such as node selectors, affinity, taints, and tolerations. Most tasks are small YAML edits followed by rollout and scheduling checks.

Core rules

• A Deployment manages ReplicaSets; changing the Pod template creates a new ReplicaSet. kubectl rollout status and kubectl rollout undo operate on the Deployment, not on individual Pods.
• The rolling-update strategy uses maxSurge and maxUnavailable. Setting maxUnavailable: 0 keeps capacity during the update but requires room for a surge Pod.
• Requests are used by the scheduler to place Pods; limits are enforced at runtime. A Pod whose requests exceed every node's allocatable CPU or memory stays Pending.
• Readiness probes control Service endpoints; liveness probes restart containers; startup probes protect slow-starting containers from liveness restarts.
• Taints repel Pods; tolerations allow a Pod to be scheduled on a tainted node but do not force it there. nodeSelector and node affinity express placement preferences or requirements.

Worked example

A Deployment runs three replicas with maxUnavailable: 0 and maxSurge: 1. You update the image with kubectl set image deployment/web web=nginx:1.27. The new Pod stays Pending: kubectl describe pod shows 0/3 nodes are available: 3 Insufficient cpu. The old Pods cannot terminate because maxUnavailable is zero, so the rollout is stuck. The correct fix is to reduce the container's CPU request to a value the nodes can satisfy, or add capacity; then kubectl rollout status deployment/web completes. If the image itself is bad, kubectl rollout undo deployment/web returns to the previous ReplicaSet. The reasoning is that scheduling happens before readiness, so a Pending Pod is a capacity/constraint problem, not an image-pull problem.

Traps

• Editing a Pod directly instead of its Deployment; the controller replaces the Pod and your change disappears.
• Putting a readiness probe on the wrong port, so a healthy app never becomes Ready and the rollout stalls.
• Assuming a toleration makes a Pod go to a tainted node; combine it with nodeSelector or affinity when the placement must be specific.
• Confusing kubectl logs from a restarted container with --previous, which shows the crashed instance's logs.