Lab: Deploy, expose and update an application

What you will learn in this TP

• Deploy and expose an application
• Do a rolling update
• Roll back

Application lifecycle #

What you will learn in this section

• Deploy and expose an application
• Do a rolling update
• Roll back

Context. You must ship a new application version with no downtime and be able to roll back if it misbehaves. Kubernetes provides exactly that with Deployments: you practise on a disposable local cluster.

Prerequisites: Docker, kind, kubectl  ·  Estimated time: 40 min

From manifest to zero-downtime update.

1. 1. Create the cluster and the Deployment

   Why? A Deployment maintains N replicas: if a pod disappears the controller recreates it with no intervention, that is the reconciliation loop.

   3 nginx 1.26 replicas with requests and a readinessProbe.

2. 2. Expose with a Service

   Why? Pods change IP address: the Service provides a stable access point other applications can use.

   Create a ClusterIP Service and test it with an ephemeral pod.

3. 3. Rolling update

   Why? The rolling update replaces pods one by one: the application stays available throughout the update.

   Move to nginx 1.27 and watch pods roll over.

4. 4. Rollback and scaling

   Why? Rollback is possible because Kubernetes keeps old ReplicaSets: a bad version is fixed with one command.

   Undo the update then scale to 5 replicas.

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