Maîtriser les Ingress Kubernetes

Mise à jour : 09/03/2025

Un Ingress est une ressource Kubernetes qui permet de gérer l’accès aux applications déployées dans un cluster. Il agit comme un reverse proxy en dirigeant les requêtes entrantes vers les bons Services en fonction des règles définies (routes, sous-domaines, SSL, authentification, etc.).

Pourquoi utiliser un Ingress ?

Sans Ingress, il faudrait utiliser des LoadBalancers coûteux ou des NodePorts peu flexibles. L’Ingress résout ce problème en agissant comme une passerelle unique qui gère le routage du trafic, le support du HTTPS et l’authentification.

Contrairement aux Services LoadBalancer de type LoadBalancer, un Ingress offre un routage avancé et permet de gérer plusieurs applications avec un seul point d’entrée. Il est particulièrement utile pour les applications web, les API, les applications multi-tenant et les applications nécessitant un routage fin.

Comment fonctionne un Ingress ?

Lorsqu’un utilisateur tente d’accéder à une application exposée via un Ingress, plusieurs étapes se déroulent :

Requête entrante : L’utilisateur envoie une requête HTTP/HTTPS vers le cluster Kubernetes (exemple : https://mon-app.com).
L’Ingress Controller intercepte la requête : Il analyse les règles définies dans l’Ingress pour déterminer où diriger le trafic.
Routage vers le bon service : L’Ingress Controller transmet la requête au Service Kubernetes correspondant.
Le Service redirige vers les Pods : Le Service distribue la requête vers l’un des Pods disponibles, assurant l’équilibrage de charge.
Réponse vers le client : Le Pod répond, et la réponse suit le même chemin en sens inverse jusqu’à l’utilisateur.

Prérequis pour tester les exemples

Avant de manipuler les StorageClasses dans Kubernetes, il est essentiel de disposer d’un environnement fonctionnel et des outils adéquats. Voici ce dont vous aurez besoin :

L’outil `kubectl` pour interagir avec le cluster

kubectl est l’outil en ligne de commande indispensable pour gérer un cluster Kubernetes. Il permet de :

Appliquer des fichiers de configuration YAML
Lister et vérifier l’état des StorageClasses, PV et PVC
Debugger les éventuels problèmes liés au stockage

L’outil `helm` pour installer des provisionneurs

Helm est un gestionnaire de paquets pour Kubernetes, qui facilite l’installation et la gestion des applications complèxes. Il est souvent utilisé pour déployer des provisionneurs de stockage CSI (Container Storage Interface) dans un cluster.

Un cluster Kubernetes opérationnel

Pour tester les StorageClasses et le provisionnement dynamique de volumes, vous devez disposer d’un cluster Kubernetes fonctionnel. Deux options s’offrent à vous :

Un cluster en production ou hébergé sur le cloud (AWS EKS, Azure AKS, Google GKE, OpenShift, etc.)
Un cluster local pour les tests et l’apprentissage Minikube est une solution simple à mettre en place sur une machine locale.

Vérifiez que votre cluster est bien opérationnel avec la commande :

kubectl cluster-info
Kubernetes control plane is running at https://192.168.50.141:8443
CoreDNS is running at https://192.168.50.141:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Si votre cluster est en place, vous devriez voir une sortie indiquant l’adresse de l’API Kubernetes.

Un éditeur de code pour manipuler les fichiers YAML

Pour éditer et appliquer vos fichiers de configuration Kubernetes, il est recommandé d’utiliser un éditeur de code adapté comme :

VS Code avec l’extension Kubernetes
Vim ou Nano si vous préférez un éditeur en ligne de commande
IntelliJ IDEA avec le plugin Kubernetes

Qu’est-ce qu’un Ingress Controller ?

Sans Ingress Controller, les ressources Ingress ne sont que des configurations sans effet. Il faut impérativement en déployer un pour que les règles soient appliquées.

Il existe plusieurs Ingress Controllers compatibles avec Kubernetes, chacun ayant ses spécificités :

Ingress Controller	Points forts
NGINX Ingress Controller	Le plus utilisé, stable, supporte HTTPS et annotations avancées.
Traefik	Léger, dynamique, parfait pour les microservices et le cloud natif.
HAProxy Ingress	Très performant, idéal pour les charges élevées.
Contour	Optimisé pour l’intégration avec Envoy Proxy.
Istio Gateway	Utilisé dans les architectures service mesh pour un contrôle avancé du trafic.

Avant de pouvoir utiliser un Ingress, il faut donc installer un Ingress Controller dans le cluster Kubernetes. Nous allons voir comment installer NGINX Ingress Controller. Pour installer NGINX Ingress Controller, vous pouvez utiliser Helm :

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install my-ingress ingress-nginx/ingress-nginx

Une fois installé, Kubernetes peut maintenant utiliser les ressources Ingress pour gérer le trafic.

Configurer un Ingress

Maintenant que nous avons installé un Ingress Controller, nous allons voir comment créer un Ingress pour exposer une application.

Préparer une application et un Service Kubernetes

Avant de créer un Ingress, il faut d’abord disposer d’une application exposée via un Service. Voici un exemple avec une application web simple.

Déploiement de l’application (webapp-deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: nginx
        ports:
        - containerPort: 80

Création du Service (webapp-service.yaml)

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Appliquez ces fichiers :

kubectl apply -f webapp-deployment.yaml
kubectl apply -f webapp-service.yaml

Créer un Ingress pour exposer l’application

Nous allons maintenant créer un Ingress qui redirige le trafic externe vers notre Service.

Fichier webapp-ingress.yaml :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: webapp.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80

Appliquez cet Ingress :

kubectl apply -f webapp-ingress.yaml

Tester l’accès à l’application

Si vous êtes en local (Minikube, Kind, etc.) Ajoutez l’IP du cluster et le nom de domaine dans le fichier /etc/hosts :

echo "127.0.0.1 webapp.local" | sudo tee -a /etc/hosts

Puis testez l’accès à l’application :

curl http://webapp.local

Si vous utilisez un cluster cloud (GKE, AKS, EKS, etc.) Récupérez l’IP publique de l’Ingress et testez :

kubectl get ingress webapp-ingress

Résultat

✅ Nous avons maintenant un Ingress fonctionnel ! Il permet de rediriger le trafic vers notre application sans exposer directement les Pods.

Configurer un Ingress avancé : multi-domaines, HTTPS et sécurité

Maintenant que nous avons un Ingress fonctionnel, voyons comment le rendre plus puissant et sécurisé avec des fonctionnalités avancées :

Gérer plusieurs domaines et sous-domaines
Rediriger des chemins spécifiques vers différentes applications
Sécuriser l’Ingress avec HTTPS (Let’s Encrypt, Cert-Manager)
Ajouter une authentification basique

Gérer plusieurs domaines et sous-domaines

Un Ingress peut gérer plusieurs applications à la fois, en fonction du nom de domaine ou du chemin de la requête.

Exemple d’usage :

app.monsite.com redirige vers une application web
api.monsite.com redirige vers un backend API

Fichier multi-domain-ingress.yaml :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-app-ingress
spec:
  rules:
  - host: app.monsite.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80
  - host: api.monsite.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Déployez cet Ingress :

kubectl apply -f multi-domain-ingress.yaml

Si vous êtes en local, ajoutez les domaines à /etc/hosts

echo "127.0.0.1 app.monsite.com api.monsite.com" | sudo tee -a /etc/hosts

Ajouter un certifica avec Let’s Encrypt et Cert-Manager

Par défaut, un Ingress fonctionne en HTTP. Pour sécuriser les connexions, on peut utiliser Let’s Encrypt avec Cert-Manager pour générer et gérer automatiquement des certificats SSL.

Dans un premier temps, installez Cert-Manager :

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.0/cert-manager.yaml

Vérifiez si une version plus récente est disponible sur le site officiel de Cert-Manager ↗.

Puis créer un ClusterIssuer pour Let’s Encrypt :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: votremail@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Le ClusterIssuer permet de définir les paramètres de connexion à Let’s Encrypt et de générer des certificats SSL.

Déployez-le :

kubectl apply -f cluster-issuer.yaml

Configurer l’Ingress avec HTTPS

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - monsite.com
    secretName: monsite-tls
  rules:
  - host: monsite.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80

Le simple fait d’ajouter l’annotation cert-manager.io/cluster-issuer permet à Cert-Manager de générer un certificat SSL pour le domaine spécifié.

Déployez cet Ingress sécurisé :

kubectl apply -f secure-ingress.yaml

Votre Ingress est maintenant en HTTPS !

Ajout d’une authentification basique

Si vous souhaitez protéger l’accès à certaines routes, vous pouvez ajouter une authentification basique avec NGINX Ingress Controller.

Commencez par créer un fichier auth contenant un nom d’utilisateur et un mot de passe chiffré avec htpasswd :

htpasswd -c auth myuser
kubectl create secret generic basic-auth --from-file=auth

Je vous recommande de regarder les sealed-secrets pour chiffrer les secrets.

Ensuite ajoutez les annotations suivantes à votre Ingress :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auth-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-type: "basic"
    nginx.ingress.kubernetes.io/auth-secret: "basic-auth"
    nginx.ingress.kubernetes.io/auth-realm: "Veuillez vous identifier"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
  spec:
  tls:
  - hosts:
    - monsite.com
    secretName: monsite-tls
  rules:
  - host: monsite.com
    http:
      paths:
      - path: /admin
        pathType: Prefix
        backend:
          service:
            name: admin-service
            port:
              number: 80

Déployez cet Ingress :

kubectl apply -f auth-ingress.yaml

Désormais, toute requête sur /admin demandera un nom d’utilisateur et un mot de passe !

Aller plus loin

La plupart des Ingress Controllers offrent des annotations pour personnaliser le comportement de l’Ingress. Voici quelques exemples avec NGINX Ingress Controller :

Limiter l’accès à certaines IPs

Si vous souhaitez restreindre l’accès à votre application à une liste d’adresses IP spécifiques (exemple : limiter l’accès à un réseau interne ou à certaines IPs autorisées), vous pouvez utiliser les annotations NGINX Ingress suivantes :

metadata:
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.1.0/24, 203.0.113.42"

Explication : Seules les IPs 192.168.1.0/24 (réseau interne) et 203.0.113.42 (IP spécifique) pourront accéder à l’application. Toutes les autres seront bloquées.

Rate Limiting et Headers de sécurité

Les attaques par déni de service (DDoS), le brute force et d’autres types d’abus peuvent affecter vos applications exposées via un Ingress. Kubernetes et les Ingress Controllers permettent d’atténuer ces risques avec :

Rate Limiting (limitation du nombre de requêtes par client) :

metadata:
  annotations:
    nginx.ingress.kubernetes.io/limit-rpm: "100"
    nginx.ingress.kubernetes.io/limit-burst-multiplier: "5"

Explication :

limit-rpm: 100 → Chaque IP ne pourra pas dépasser 100 requêtes par minute.
limit-burst-multiplier: 5 → Autorise un pic temporaire de 500 requêtes avant de ralentir.

Ajout de Headers de sécurité

Protégez votre application contre les vulnérabilités courantes en ajoutant des headers HTTP de sécurité :

metadata:
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_set_headers "X-Frame-Options: DENY";
      more_set_headers "X-XSS-Protection: 1; mode=block";
      more_set_headers "X-Content-Type-Options: nosniff";

Explication :

X-Frame-Options: DENY → Empêche l’application d’être chargée dans un iframe (protection contre le clickjacking).
X-XSS-Protection: 1; mode=block → Active la protection contre les attaques XSS.
X-Content-Type-Options: nosniff → Empêche les navigateurs d’essayer de deviner le type de contenu (protection contre le MIME sniffing).

La liste des annotations NGINX Ingress

Vous pourrez trouver des exemples d’Ingress avancés dans la documentation officielle de NGINX Ingress ↗.

Débogage d’un Ingress Kubernetes

Même avec une configuration soignée, un Ingress peut rencontrer des problèmes : erreurs d’accès, mauvais routage, problèmes de performances…

Voici quelques étapes pour déboguer un Ingress et résoudre les problèmes courants.

Vérifier les logs de l’Ingress Controller

Lorsqu’un Ingress ne fonctionne pas comme prévu, la première chose à faire est de consulter les logs de l’Ingress Controller.

Récupérer les logs du contrôleur NGINX Ingress :

kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

Que chercher dans les logs ?

404 Not Found : Le chemin ou le service cible n’existe pas.
502 Bad Gateway : Le service backend est inaccessible.
503 Service Unavailable : Aucune instance disponible pour gérer la requête.

Comprendre et corriger les erreurs courantes

Erreur 404 - Page non trouvée :

Cause : L’Ingress ne trouve pas de règle correspondant à la requête. Solution : Vérifier que l’Ingress et le Service existent et sont bien configurés.

kubectl get ingress
kubectl describe ingress <nom-de-l’ingress>
kubectl get svc

Erreur 502 - Bad Gateway :

Cause : Le Service est inaccessible ou ne répond pas. Solution : Vérifier l’état des Pods et du Service associé.

kubectl get pods -l app=<nom-app>
kubectl get svc <nom-service>
kubectl describe pod <nom-pod>

Erreur 503 - Service Unavailable :

Cause : Aucun Pod n’est disponible pour gérer les requêtes. Solution : Vérifier si les Pods sont en état Running.

kubectl get pods
kubectl describe pod <nom-du-pod>

Si des Pods sont en CrashLoopBackOff ou Pending, inspectez leurs logs :

kubectl logs <nom-du-pod>

Optimiser les performances d’un Ingress

Un Ingress bien configuré ne doit pas seulement fonctionner, il doit aussi offrir des performances optimales pour éviter les ralentissements et réduire la charge sur votre infrastructure.

Activer la mise en cache (Caching)

La mise en cache permet de réduire la charge sur les services backend en servant directement certaines réponses depuis l’Ingress Controller.

Avec NGINX Ingress, ajoutez ces annotations :

metadata:
  annotations:
    nginx.ingress.kubernetes.io/cache-enable: "true"
    nginx.ingress.kubernetes.io/cache-key: "$host$request_uri"
    nginx.ingress.kubernetes.io/cache-methods: "GET HEAD"

Avantages : Moins de requêtes aux services backend, amélioration des performances.

Activer la compression des réponses (Gzip, Brotli)

Activer la compression des réponses HTTP réduit le temps de chargement des pages et optimise l’utilisation de la bande passante.

Avec NGINX Ingress, ajoutez :

metadata:
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      gzip on;
      gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Avantages : Réduction de la taille des réponses, amélioration du temps de chargement.

Optimiser le Load Balancing entre les Pods

Si vous avez plusieurs Pods derrière un Ingress, Kubernetes répartit les requêtes entre eux via un Service en mode ClusterIP. Vous pouvez améliorer cette répartition en modifiant la stratégie de load balancing :

metadata:
  annotations:
    nginx.ingress.kubernetes.io/load-balance: "round_robin"

Modes possibles :

Round Robin (par défaut) : envoie les requêtes aux Pods de manière équilibrée.
Least Connections : priorise les Pods avec le moins de connexions actives.
IP Hash : maintient la session d’un utilisateur sur un même Pod.

Conclusion

Dans ce guide, nous avons découvert les Ingress et leur rôle essentiel dans la gestion du trafic au sein d’un cluster Kubernetes. Vous avez vu comment ils permettent de simplifier l’accès aux applications, de gérer plusieurs domaines, d’activer HTTPS et de sécuriser les connexions.

Mais ce n’est que le début ! Un Ingress Controller offre bien d’autres fonctionnalités avancées, et selon votre besoin, certains contrôleurs comme NGINX, Traefik, HAProxy ou Istio peuvent être plus adaptés que d’autres.

Dans de prochains guides, nous explorerons plus en détail certaines de ces solutions :

Configurer NGINX Ingress Controller pour un usage avancé
Découvrir Traefik, une alternative légère et dynamique

L’avenir des Ingress : la montée en puissance des API Gateway

Si les Ingress sont aujourd’hui largement utilisés, Kubernetes évolue et une nouvelle ressource commence à les remplacer progressivement : Gateway API.

Pourquoi cette transition ? :

Plus de flexibilité : meilleure gestion des routes et des stratégies avancées.
Standardisation : un modèle plus adapté aux architectures modernes et multi-cloud.
Extensibilité : intégration plus poussée avec des solutions comme Istio ou Contour.

Que faire aujourd’hui ? :

Les Ingress restent une solution stable et fiable pour la majorité des cas d’usage. Cependant, si vous démarrez un projet long terme, il peut être intéressant d’explorer les Gateway API pour assurer une transition en douceur.

Nous verrons dans de futurs guides comment migrer d’un Ingress vers une API Gateway et quelles sont les bonnes pratiques à adopter ! Abonnez-vous à mon compte linkedin ↗ pour être informé des prochaines publications.