Exercice 03 : Exposer les applications via Ingress

🎯 Objectifs

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

• ✅ Activer le contrôleur Ingress dans minikube
• ✅ Créer un Ingress qui route le trafic vers plusieurs services
• ✅ Utiliser les annotations nginx pour configurer le comportement
• ✅ Tester le routing avec curl -H "Host:"

Durée estimée : 25 minutes

Difficulté : ⭐⭐⭐⭐☆ (Avancé)

Prérequis : minikube démarré, maîtrise des Services et Deployments

📖 Contexte

Un Service NodePort expose un port par application. En production, on préfère un seul point d'entrée HTTP/HTTPS qui route vers les bons services selon l'URL et le nom de domaine. C'est le rôle de l'Ingress : il agit comme un reverse-proxy géré par Kubernetes.

📋 Énoncé

Vous allez déployer deux applications (nginx et httpd), les exposer via un seul Ingress qui route selon le chemin (/app1 → nginx, /app2 → httpd), puis configurer le routing par hôte virtuel.

Résultat attendu :

• Routing basé sur les paths et les virtual hosts
• Accès via un seul point d'entrée

🧭 Déroulement de l'exercice

Tâche 1 : Activer le contrôleur Ingress

Activez l'addon ingress de minikube et vérifiez que le contrôleur est démarré.

Indice : minikube addons enable ingress puis attendre que le pod ingress-nginx-controller soit Running dans le namespace ingress-nginx.

Vérification : kubectl get pods -n ingress-nginx affiche le contrôleur en Running.

Tâche 2 : Déployer les applications backend

Créez deux Deployments (app1 avec nginx, app2 avec httpd) et leurs Services ClusterIP respectifs.

Indice : Chaque Service expose le port 80. Le Service n'a pas besoin d'être NodePort car l'Ingress s'en charge.

Vérification : kubectl get svc liste app1-svc et app2-svc de type ClusterIP.

Tâche 3 : Créer un Ingress basé sur les paths

Créez un Ingress demo-ingress qui route /app1 vers app1-svc:80 et /app2 vers app2-svc:80.

Indice : pathType: Prefix pour les paths. L'annotation nginx.ingress.kubernetes.io/rewrite-target: / est nécessaire pour réécrire le path.

Vérification : kubectl get ingress demo-ingress affiche une ADDRESS (IP minikube).

Tâche 4 : Tester le routing par path

Obtenez l'IP minikube et testez le routing avec curl en passant l'en-tête Host.

Indice : minikube ip donne l'IP. curl -H "Host: demo.local" http://<ip>/app1

Vérification : /app1 retourne la page nginx, /app2 retourne la page Apache.

Tâche 5 : Configurer le routing par virtual host

Modifiez l'Ingress pour ajouter deux hôtes virtuels : app1.local → app1-svc et app2.local → app2-svc.

Indice : Chaque spec.rules[] peut avoir un host différent.

Vérification : curl -H "Host: app1.local" http://$(minikube ip) retourne nginx, app2.local retourne Apache.

🗂️ Mini-Projet : Ingress de production avec TLS (self-signed)

# multi-host-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: production-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  ingressClassName: nginx
  rules:
    - host: app1.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app1-svc
                port:
                  number: 80
    - host: app2.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app2-svc
                port:
                  number: 80

Checkpoints :

• kubectl get ingress production-ingress affiche une ADDRESS
• curl -H "Host: app1.local" http://$(minikube ip) retourne la page nginx
• curl -H "Host: app2.local" http://$(minikube ip) retourne la page Apache
• kubectl describe ingress production-ingress liste les règles de routing
• Ajouter $(minikube ip) app1.local app2.local dans /etc/hosts permet le test sans -H