Exercice 07 : Projet Capstone - Application Kubernetes en Production

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

• ✅ Créer un Deployment avec rolling update et politique de rollback
• ✅ Externaliser la configuration avec ConfigMap et les secrets avec Secret
• ✅ Exposer l'application en HTTPS via un Ingress
• ✅ Configurer des liveness et readiness probes
• ✅ Mettre en place un HorizontalPodAutoscaler

Durée estimée : 1h

Difficulté : ⭐⭐⭐⭐⭐ (Expert)

Prérequis :

• Exercice 06 Kubernetes complété
• Minikube avec le plugin ingress activé
• Module Kubernetes Avancé complété

📖 Contexte

Votre application doit passer en production. Vous allez remplacer le Pod simple par un Deployment pour la haute disponibilité, externaliser la configuration sensible, exposer l'application via un Ingress (reverse proxy Kubernetes), et configurer l'auto-scaling.

📋 Énoncé

Déployez une application avec toutes les pratiques de production Kubernetes : Deployment, ConfigMap, Secret, Ingress, probes, resource limits, et HPA.

🧭 Déroulement de l'exercice

Tâche 1 : Créer un ConfigMap

Créez un ConfigMap app-config contenant :

• APP_PORT: 80
• APP_ENV: production
• NGINX_WORKER_PROCESSES: auto

Indice : kubectl create configmap app-config --from-literal=APP_PORT=80 --from-literal=APP_ENV=production --from-literal=NGINX_WORKER_PROCESSES=auto -n web-app. Alternativement, en YAML avec data:.

Vérification : kubectl get configmap app-config -n web-app -o yaml affiche les 3 clés.

Tâche 2 : Créer un Secret

Créez un Secret app-secret contenant :

• DB_PASSWORD: supersecret
• API_KEY: my-api-key-12345

Indice : kubectl create secret generic app-secret --from-literal=DB_PASSWORD=supersecret --from-literal=API_KEY=my-api-key-12345 -n web-app. Les valeurs sont encodées en base64 dans l'objet Secret (mais pas chiffrées par défaut !).

Vérification : kubectl get secret app-secret -n web-app -o yaml affiche les valeurs encodées en base64. kubectl get secret app-secret -n web-app -o jsonpath='{.data.DB_PASSWORD}' | base64 -d retourne supersecret.

Tâche 3 : Créer un Deployment

Créez un fichier deployment.yaml avec :

• 3 replicas de l'application nginx:1.25-alpine
• Injection du ConfigMap comme variables d'environnement (envFrom)
• Injection du Secret DB_PASSWORD comme variable d'environnement individuelle
• resources.requests et resources.limits définis
• liveness et readiness probes HTTP sur /
• Stratégie RollingUpdate avec maxUnavailable: 1 et maxSurge: 1

Indice : envFrom injecte tout un ConfigMap comme variables d'env. env avec valueFrom.secretKeyRef injecte un secret spécifique.

Vérification : kubectl get deployment web-deploy -n web-app affiche 3/3 READY. kubectl get pods -n web-app liste 3 pods.

Tâche 4 : Activer l'Ingress et créer la ressource

Activez le addon Ingress de Minikube (minikube addons enable ingress). Créez un fichier ingress.yaml qui route le trafic HTTP vers web-svc pour le host web.local.

Indice :

`yaml

spec:

rules:

- host: web.local

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: web-svc

port:

number: 80

`

Ajoutez 127.0.0.1 web.local (ou l'IP Minikube) dans /etc/hosts pour tester.

Vérification : kubectl get ingress -n web-app affiche une ADDRESS. curl -H "Host: web.local" http://$(minikube ip) retourne du HTML.

Tâche 5 : Tester le rolling update et le rollback

Mettez à jour le Deployment pour utiliser nginx:1.26-alpine avec kubectl set image. Observez le rolling update se dérouler. Ensuite, simulez un problème et effectuez un rollback.

Indice : kubectl set image deployment/web-deploy nginx=nginx:1.26-alpine -n web-app. kubectl rollout status deployment/web-deploy -n web-app suit la progression. kubectl rollout undo deployment/web-deploy -n web-app revient à la version précédente.

Vérification : kubectl rollout history deployment/web-deploy -n web-app liste 2 révisions. Après rollback, l'image est revenue à nginx:1.25-alpine.

Tâche 6 : Configurer le HorizontalPodAutoscaler

Activez le metrics-server sur Minikube (minikube addons enable metrics-server). Créez un HPA qui maintient entre 2 et 5 replicas en ciblant 50% d'utilisation CPU.

Indice : kubectl autoscale deployment web-deploy --cpu-percent=50 --min=2 --max=5 -n web-app. kubectl get hpa -n web-app affiche l'état du HPA. Le HPA peut prendre quelques minutes à se stabiliser.

Vérification : kubectl get hpa -n web-app affiche web-deploy avec les min/max et le target CPU.

🗂️ Mini-Projet : Stack Kubernetes complète

Arborescence des manifests :

k8s/
├── namespace.yaml
├── configmap.yaml
├── secret.yaml
├── deployment.yaml
├── service.yaml
└── ingress.yaml

Déploiement en ordre :

# Prérequis
minikube addons enable ingress
minikube addons enable metrics-server

# Déploiement
kubectl apply -f k8s/namespace.yaml
kubectl apply -f k8s/configmap.yaml
kubectl apply -f k8s/secret.yaml
kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/service.yaml
kubectl apply -f k8s/ingress.yaml

# Attendre que tout soit prêt
kubectl rollout status deployment/web-deploy -n web-app

# État complet
kubectl get all -n web-app
kubectl get ingress -n web-app
kubectl get hpa -n web-app

# Test
curl -H "Host: web.local" http://$(minikube ip)

Checkpoints de validation :

• kubectl get deployment web-deploy -n web-app → 3/3 READY
• kubectl get secret app-secret -n web-app -o jsonpath='{.data.DB_PASSWORD}' | base64 -d retourne supersecret
• kubectl get ingress -n web-app affiche une ADDRESS
• kubectl rollout history deployment/web-deploy -n web-app liste 2 révisions
• kubectl get hpa -n web-app affiche le HPA avec les limites min/max
• Les probes sont configurées (kubectl describe deployment web-deploy -n web-app)