Lab: Rolling update, canary and rollback on Kubernetes

What you will learn in this TP

• Configure a safe rolling update
• Run a canary deployment
• Roll back with kubectl

Introduction #

What you will learn in this section

• Configure a safe rolling update
• Run a canary deployment
• Roll back with kubectl

Context. The team is moving to Kubernetes and wants progressive deployments. You validate update and rollback behaviour on a local cluster.

Prerequisites: Docker, kubectl and kind installed on your machine  ·  Estimated time: 50 min

Controlled progressive deployments and a one-command rollback.

Hands-on #

Guided steps, with their solution.

1. 1. Create the cluster and deploy v1

   Why? maxUnavailable: 0 and a readiness probe ensure no request reaches a pod that is not ready.

   Create a kind cluster and deploy 4 replicas of hashicorp/http-echo showing "v1", with a careful RollingUpdate strategy and a readiness probe, exposed by a Service.

2. 2. Zero-downtime rolling update

   Why? Watch pods being replaced one by one while traffic continues.

   Start a request loop from the client pod, then move to v2 with a change-cause annotation. Follow the rollout and the history.

3. 3. Block a broken version

   Why? A missing image or a pod that never becomes ready halts the rolling update: old pods keep serving.

   Deploy a non-existent image, see that rollout status fails after a timeout and that the service still answers v2.

4. 4. Roll back

   Why? Kubernetes keeps previous ReplicaSets: rollback is immediate.

   Undo the last revision, check all pods are ready, then explicitly go back to revision 1.

5. 5. Canary deployment

   Why? Without a service mesh, a canary is approximated by splitting replicas behind the same Service.

   Create a web-canary Deployment (1 replica, text "v3-canary", label track: canary) sharing the app: web label. Measure its share of traffic, then promote or delete the canary.

Difficulty level : ●●●○○ (3/5)