Statement — Project: First Steps with Kubernetes (Pods, Deployments, Services)

Practice · Module 07 — Kubernetes: basic concepts · Level beginner → intermediate

Try alone first! Complete the project with this brief only. The solution (commented YAML manifests + kubectl commands) is in the README.md, folded. Open it only after you have tried.

---

No need for minikube!

You have nothing extra to install: Docker Desktop includes a built-in Kubernetes cluster.

1. Open Docker Desktop → Settings (⚙️) → Kubernetes.
2. Check “Enable Kubernetes”, click Apply & Restart, wait until the indicator turns green.
3. Check in a terminal:

   powershell

   kubectl get nodes

   You should see a docker-desktop node in the Ready state.

(Possible alternatives: minikube start or kind create cluster. The project works there too, provided you load the image — see 02-COMMANDES.md.)

---

Goal

Deploy a small web application on Kubernetes in several replicas (Pods), expose it via a Service, then practice everyday gestures: scaling, rolling update, rollback, and self-healing.

---

Expected result

When you reload the page, the name of the Pod that answers changes: proof that the Service distributes the load across the Pods.

---

Work to do

Part 1 — Build the image

1. Reuse the web app from module 06 (or write an app that, on /, displays its hostname = the Pod name).
2. Build the image locally and name it demo-k8s:1.0.

Part 2 — The Deployment (the Pods)

3. Write a Deployment manifest with 3 replicas, consistent labels (app: demo-web) and a probe (readinessProbe / livenessProbe) on /health.
4. Apply it, then list and inspect your Pods (kubectl get pods, kubectl describe pod ..., kubectl logs ...).

Part 3 — The Service (expose + distribute)

5. Write a Service of type NodePort (port 30080) that points to the Pods via the label selector.
6. Open http://localhost:30080 and reload: check that the Pod name changes.

Part 4 — Configuration (ConfigMap + env variables)

7. Create a ConfigMap containing APP_TITLE, APP_VERSION, and BG_COLOR, and inject it into the Pods (envFrom).
8. Change BG_COLOR, re-apply the ConfigMap, restart the Pods (kubectl rollout restart), and observe the new color.

Part 5 — Everyday gestures

9. Scaling: go to 5 replicas (kubectl scale) then back to 3.
10. Rolling update: change APP_VERSION, apply, and follow the progressive deployment (kubectl rollout status).
11. Rollback: go back to the previous version (kubectl rollout undo).
12. Self-healing: delete a Pod by hand (kubectl delete pod ...) and see that Kubernetes recreates one by itself.

---

Reflection questions

• What is the difference between a Pod, a ReplicaSet, and a Deployment?
• Why do we go through a Service instead of contacting a Pod directly by its IP?
• What is the label selector between the Service and the Pods for?
• Why separate configuration (ConfigMap) from code (Docker image)?
• What does Kubernetes do when a Pod fails? And during a rolling update?

---

Deliverables

• The app/ folder (code + Dockerfile) and the k8s/ folder (configmap.yaml, deployment.yaml, service.yaml).
• A screenshot showing at least 2 different Pod names in the browser (or via curl).
• The output of kubectl get pods showing 3/3 Pods Running.
• A screenshot of a kubectl rollout status during a rolling update.

---

Success criteria

---

Stuck? The README.md contains the full solution (commented manifests + commands), and the command cheat sheet lists every useful kubectl — read them after you have tried.