Running Workloads With Controllers

Goal

You verify by hand the differences among the four controllers Deployment, ReplicaSet, DaemonSet, and StatefulSet, then adjust rolling update parameters and perform an actual rollout and rollback.

Why it matters

"Push an image and roll back if something goes wrong" is a staple exam problem. But if you do not know why rolling back works, you fall into a trap. rollout undo is not magic; it scales back up the old ReplicaSet that remains with 0 replicas. That is why you cannot roll back if you set revisionHistoryLimit to 0, and why putting the image back by hand is not a rollback but just piles up one more revision.

The criteria for choosing among the four controllers are also clear. Use a Deployment for replicas that do not need to be distinguished from each other, a DaemonSet for exactly one per node, and a StatefulSet when name, order, and volume must be fixed. The reason a StatefulSet requires a headless Service is to give each Pod its own DNS name.

Steps

1. Create the namespace cka-workloads and create the Deployment web. Image nginx:1.25, 2 replicas.
2. Scale web to 4 replicas and confirm 4/4 Ready.
3. Set the strategy of web to RollingUpdate with maxSurge: 2, maxUnavailable: 0, and revisionHistoryLimit: 3.
4. Create the Deployment api (image nginx:1.25, 3 replicas). Then replace the image with nginx:1.27 and wait until the rollout finishes.
5. Save the rollout history of api to /root/cka-workloads/history.txt. At least 2 revisions must appear.
6. Roll api back to the previous revision. After rolling back, the image must be nginx:1.25 again.
7. In cka-workloads, create the DaemonSet node-agent. Image busybox:1.36, and give it a long-running command so the container does not exit immediately. It must be Ready on every node, one per node.
8. Create a headless Service db-headless (clusterIP None, port 5432, selector app=db) and create the StatefulSet db. serviceName db-headless, 2 replicas, image nginx:1.27, and an updateStrategy of RollingUpdate with partition: 1. Confirm 2/2 Ready.

Reference

• You can wait for completion with kubectl rollout status deployment/api -n cka-workloads.
• Use kubectl get rs -n cka-workloads to see with your own eyes that a ReplicaSet remains for each revision.
• Common mistake 1: putting the old tag back with set image in step 6. That is not a rollback but a new revision.
• Common mistake 2: leaving the StatefulSet's Pod labels and the headless Service selector mismatched in step 8. They must match as app=db.

Create a Deployment

Create the namespace cka-workloads and create the Deployment web. Image nginx:1.25, 2 replicas.

It is quicker to create a skeleton with kubectl create deployment and edit only the values you need. You must match the image tag exactly as well.

Scale and confirm Ready

Scale web to 4 replicas and confirm 4/4 Ready.

The scale command is the fastest, but you can also edit the manifest and apply it. It takes a moment for status.readyReplicas to reach the target.

Adjust rolling update parameters

Set the strategy of web to RollingUpdate with maxSurge: 2, maxUnavailable: 0, and revisionHistoryLimit: 3.

The two values go under strategy.rollingUpdate. Both integers and percentages are allowed, but this time they must be integers. revisionHistoryLimit is outside strategy, directly under spec.

Replace the image and wait for the rollout to finish

Create the Deployment api (image nginx:1.25, 3 replicas). Then replace the image with nginx:1.27 and wait until the rollout finishes.

Changing it with set image creates a new ReplicaSet. Wait for completion with rollout status. Grading checks the existence of the new revision and observedGeneration.

Check and save the revision history

Save the rollout history of api to /root/cka-workloads/history.txt. At least 2 revisions must appear.

rollout history prints a table with a REVISION column. Seeing at least 2 revisions means you can roll back.

Roll back to the previous revision

Roll api back to the previous revision. After rolling back, the image must be nginx:1.25 again.

Do not put the image back by hand. That is not a rollback but creates one more new revision, and grading checks that difference. Use the rollout undo command.

Deploy a DaemonSet

In cka-workloads, create the DaemonSet node-agent. Image busybox:1.36, and give it a long-running command so the container does not exit immediately. It must be Ready on every node, one per node.

A DaemonSet does not use replicas. Check that one is running on each node with desiredNumberScheduled and numberReady in status. Give it a long-running command so the container does not end right away.

Combine a headless Service and a StatefulSet

Create a headless Service db-headless (clusterIP None, port 5432, selector app=db) and create the StatefulSet db. serviceName db-headless, 2 replicas, image nginx:1.27, and an updateStrategy of RollingUpdate with partition: 1. Confirm 2/2 Ready.

A StatefulSet's serviceName must point to a headless Service that exists. partition is under updateStrategy.rollingUpdate, and means that only Pods with that ordinal or higher are updated.