Module 6 · Mise en situation¶

Objectifs

Mobiliser tout ce qui précède sur un cas concret, en autonomie.
Adopter une méthode de déploiement et de debug reproductible.
Durée : variable (compte ~1 h 30) · Pré-requis : le cœur du parcours (et le module 5 si tu as fait l'EKS).

Projet fil rouge - « Déployer & exploiter une appli »¶

Tu vas déployer une petite application (frontend + backend + base) sur un cluster, l'exposer, la configurer, et survivre à quelques pannes - le tout piloté depuis k9s.

Étape 1 - Déploiement¶

[ ] Crée un namespace app.
[ ] Déploie un backend (ex: hashicorp/http-echo ou une API simple) + un frontend (nginx).
[ ] Branche la config via ConfigMap et un Secret.
[ ] Vérifie chaque objet dans k9s (:deploy, :cm, :secret, :po).

Étape 2 - Exposition¶

[ ] Crée des Services ClusterIP pour chaque composant.
[ ] Ajoute un Ingress (ou un Service LoadBalancer si tu es sur EKS).
[ ] Vérifie le chemin navigateur → Ingress → Service → Pod.

Étape 3 - Résilience & ressources¶

[ ] Ajoute requests/limits à chaque deployment.
[ ] Ajoute des probes (liveness, readiness).
[ ] Scale le frontend à 3 réplicas, observe la répartition dans k9s.

Étape 4 - Pannes surprises (le mentor en déclenche)¶

Le mentor casse quelque chose pendant que tu as le dos tourné. À toi de diagnostiquer uniquement avec k9s :

[ ] Un pod en CrashLoopBackOff → trouve la cause dans les logs.
[ ] Un Service qui ne répond plus → vérifie les endpoints / labels.
[ ] Un déploiement bloqué → describe + rollout undo.
[ ] Un pod Pending → ressources / quota.

Étape 5 - Nettoyage¶

[ ] Supprime proprement (namespace, et cluster EKS si applicable).
[ ] Rédige un mini post-mortem : quelles pannes, comment trouvées, en combien de temps.

Grille d'auto-évaluation¶

Compétence	🟥 Non acquis	🟧 En cours	🟩 Acquis
Naviguer dans k9s sans hésiter
Debug describe → events → logs
Déployer + exposer une app
Gouverner (RBAC, ressources, placement)
Packager & déployer (Helm, GitOps) (si modules faits)
Provisionner & détruire un EKS (si module fait)
Diagnostiquer une panne en autonomie

Pratique¶

L'épreuve de synthèse auto-évaluée, dans le terminal de ta sandbox - une fois le projet en main :

tp start capstone-1   # déployer, exposer, configurer, brancher la config - en autonomie

Joue-la avec le moins d'indices possible : c'est la mesure de ce que tu sais faire seul.

Pour aller plus loin (bonus)¶

GitOps : déployer via ArgoCD (comme l'infra de Timothé).
Observabilité : Prometheus + Grafana, lire les métriques dans k9s (:pulses).
Sécurité : popeye pour auditer un cluster, NetworkPolicies.
CI/CD : build d'image multi-arch + déploiement automatique.

Quiz éclair¶

Avant de te déclarer autonome, vérifie que ces réflexes sont automatiques.

1. Un pod ne répond plus. Par quoi commences-tu, systématiquement ?

describe → events → logs. L'état du pod et les events disent 90 % des causes ; les logs (--previous si crash) le reste.

2. Un Service ne route plus le trafic. Que vérifies-tu en premier ?

Ses endpoints (kubectl get endpoints <svc>) : s'ils sont vides, c'est un problème de labels/selector entre le Service et les pods.

3. Tu as fini la session sur EKS. Quelle est la dernière chose à faire ?

Détruire : supprimer les LoadBalancer, eksctl delete cluster, et vérifier la console AWS. Le coût maîtrisé fait partie de l'autonomie.

🎉 Bravo ! À ce stade tu pilotes un cluster au k9s, tu debugges en autonomie, et tu sais monter/détruire un cluster managé. La fiche de suivi peut être finalisée.