Free lesson · CKAD Prep Program · Module 2: Application design and build

Shape Apps That Scale Horizontally

Scaling out only works when every replica is disposable and identical. This lesson turns that slogan into a checklist: statelessness, shared nothing local, health-gated traffic, and verification after every scale.

12 min reading

Objectives

List what makes a workload horizontally scalable and what breaks it
Move session state out of the pod so replicas become interchangeable
Choose Deployment replicas plus probes so rollouts stay available
Read a scale event and confirm every replica serves traffic

Why this matters

kubectl scale is one command, but the exam grades everything around it: whether the app tolerates the scale, whether traffic reaches only ready pods, and whether the rollout keeps serving. Applications that keep sessions on local disk or assume one instance scale into outages, and the failure looks like Kubernetes misbehaving when the design is at fault.

Concepts

Horizontally scalable means any replica can die at any time with no user-visible effect. That requires three habits. First, no local state that matters: sessions, uploads and caches live in shared stores (Redis, database, object storage), never on the pod filesystem. Second, startup that converges: the app must reach ready without manual steps, because new replicas join during incidents, not demos. Third, shutdown that drains: SIGTERM handling plus a readiness gate that flips before the endpoint disappears.

Deployments encode the desired count; Services with selectors spread traffic across ready endpoints only. Readiness probes decide membership in that set, so a correct readiness check is load-balancer configuration, not decoration. Rollouts then become safe by construction: maxUnavailable plus maxSurge bound how many pods change at once, and the old replicas keep serving until the new ones pass readiness.

Worked example

Three interchangeable replicas behind one service, verified end to end:

kubectl create deployment web --image=nginx --replicas=3
kubectl expose deployment web --port=80
kubectl get endpoints web  # three addresses, all ready
kubectl scale deployment web --replicas=5
kubectl rollout status deployment/web
kubectl get endpoints web  # five addresses
kubectl top pods  # even-ish CPU when traffic flows

Endpoints are the receipts: the service sends traffic exactly to the listed ready addresses. If an address is missing, read the pod's readiness probe before blaming the network.

Exam notes

Stateful data on emptyDir evaporates with the pod and breaks scaling silently until traffic shifts. Readiness and liveness serve different masters: readiness guards traffic, liveness guards restarts, and swapping them causes either cascading restarts or dead pods still receiving traffic. Scale first, then verify endpoints, then declare victory: in that order, every time.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Exercise

Take a fictional single-replica app that stores uploads on local disk and sessions in memory. List the three changes that make it horizontally scalable, then write the scale-plus-verify command sequence for 1 to 4 replicas with the check that proves traffic reaches all four.

Pass criteria

Three changes cover shared state, readiness gating and graceful shutdown; sequence is scale, rollout status, endpoints check with the correct expectation.