Stage 7 · Master

CKA — Certified Kubernetes Administrator

Workloads & Scheduling (15%)

Deployments, rolling updates, taints, affinity, and resource limits — getting Pods on the right nodes.

9 min readExams & CertificationsMaster

Deployments and ReplicaSets

Deployments manage ReplicaSets, which manage Pods. This indirection enables rolling updates and rollbacks. Always create Deployments, never create ReplicaSets or Pods directly.

Create a Deployment imperatively


kubectl create deployment nginx --image=nginx:1.25 --replicas=3 --dry-run=client -o yaml > deploy.yaml
kubectl apply -f deploy.yaml

# Scale the deployment
kubectl scale deployment nginx --replicas=5

The --dry-run=client -o yaml pattern generates a YAML manifest without applying it. Review the output, then apply it with kubectl apply.

Rolling Updates and Rollbacks

Kubernetes performs rolling updates by default. It gradually replaces old Pods with new ones using maxSurge and maxUnavailable to control the update speed.

Parameter	Description	Example
maxSurge	Maximum Pods above desired count during update	25% means 1 extra Pod per 4 desired
maxUnavailable	Maximum Pods below desired count during update	0 means no downtime

Update and rollback


# Update the image
kubectl set image deployment/nginx nginx=nginx:1.26

# Watch the rollout
kubectl rollout status deployment/nginx

# Rollback to the previous revision
kubectl rollout undo deployment/nginx

# Rollback to a specific revision
kubectl rollout undo deployment/nginx --to-revision=2

# View rollout history
kubectl rollout history deployment/nginx

Rolling updates ensure zero-downtime deployments. If the new Pods fail health checks, the rollout stalls. Check events with kubectl describe deployment nginx.

Resource Requests and Limits

Resource requests tell the scheduler how much CPU and memory a Pod needs. Resource limits cap the maximum a Pod can use. Requests affect scheduling. Limits affect runtime behavior.

Resource specification


apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

250m means 0.25 CPU cores. 128Mi means 128 mebibytes of memory. If a Pod exceeds its memory limit, it is OOMKilled. If it exceeds CPU limits, it is throttled.

Always set resource limits

On the CKA exam, always set resource requests and limits unless instructed otherwise. A Pod without limits can consume all node resources, starving other Pods and causing cascading failures.

Taints and Tolerations

Taints are applied to nodes. They repel Pods that do not have matching tolerations. This is how you reserve nodes for specific workloads or prevent certain Pods from running on specific nodes.

Taint and toleration commands


# Taint a node (NoSchedule prevents new Pods without tolerations)
kubectl taint nodes node1 key=value:NoSchedule

# Taint for dedicated nodes
kubectl taint nodes node1 dedicated=gpu:NoSchedule

# Remove a taint
kubectl taint nodes node1 key=value:NoSchedule-

# Add toleration to a Pod (in YAML spec)
# tolerations:
# - key: "key"
#   operator: "Equal"
#   value: "value"
#   effect: "NoSchedule"

NoSchedule means new Pods are not scheduled unless they tolerate the taint. PreferNoSchedule is a soft version. NoExecute evicts existing Pods that do not tolerate the taint.

Node and Pod Affinity

Affinity rules attract Pods to specific nodes. Node affinity selects nodes based on labels. Pod affinity co-locates Pods. Pod anti-affinity separates Pods for high availability.

Node affinity example


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disktype
          operator: In
          values:
          - ssd
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - web
        topologyKey: kubernetes.io/hostname

requiredDuringScheduling means the rule must be met or the Pod will not be scheduled. preferredDuringScheduling is a soft preference. IgnoredDuringExecution means the rule is not enforced after scheduling.

DaemonSets and StatefulSets

DaemonSets run one Pod per node. They are used for node-level agents like kube-proxy, log collectors, and monitoring agents. StatefulSets provide stable network identities and persistent storage for stateful applications.

Workload	Pod Identity	Scaling	Use Case
Deployment	Random	Replica count	Stateless applications
StatefulSet	Stable (pod-0, pod-1)	Ordinal	Databases, message queues
DaemonSet	One per node	Automatic	Node agents, log collectors
Job	Fixed	Completions	Batch processing

Key Commands

Workload commands


kubectl get deployments -A
kubectl describe deployment my-deploy
kubectl rollout status deployment my-deploy
kubectl rollout history deployment my-deploy
kubectl set image deployment my-deploy app=new-image:tag
kubectl scale deployment my-deploy --replicas=3
kubectl top pods
kubectl top nodes

The kubectl top commands require Metrics Server. If Metrics Server is not installed, use kubectl describe node to check allocated resources instead.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.