Le Contrôleur Ingress dans Kubernetes : Pilier de la Gestion des Traitements HTTP/S
L'Ingress Controller : Le Point d'Entrée de Votre Cluster
L'Ingress Controller est le premier composant que je configure après le déploiement d'un cluster Kubernetes. C'est lui qui route le trafic HTTP/S externe vers vos services. Et le choix du controller, ainsi que sa configuration, a un impact direct sur la performance, la sécurité et la fiabilité de vos applications.
Mon Choix : NGINX Ingress Controller
Après avoir testé NGINX, Traefik, HAProxy, et l'AWS ALB Ingress Controller, mon choix par défaut est NGINX Ingress Controller. Les raisons :
- Maturité : c'est le plus ancien et le plus testé en production
- Configuration : les annotations permettent un contrôle fin du routage
- Performance : NGINX est un reverse proxy éprouvé qui gère des milliers de requêtes par seconde
- Communauté : la documentation et le support communautaire sont excellents
Chez un client e-commerce, NGINX Ingress routait le trafic de 3 000 requêtes par seconde vers 15 services différents, avec du rate limiting, de la réécriture d'URL, et de la terminaison TLS. Tout ça avec 2 réplicas qui consommaient moins de 500 Mo de RAM chacun.
Le Combo Ingress + Cert-Manager
L'un des patterns les plus puissants que je déploie systématiquement : NGINX Ingress Controller + cert-manager pour le TLS automatique via Let's Encrypt. Le workflow est simple :
- Vous créez une ressource Ingress avec l'annotation
cert-manager.io/cluster-issuer: letsencrypt-prod - Cert-manager détecte l'annotation, demande un certificat à Let's Encrypt
- Le certificat est stocké dans un Secret Kubernetes
- NGINX Ingress utilise automatiquement ce certificat pour la terminaison TLS
Sur le site WizOps.fr lui-même, c'est exactement ce setup qui tourne. Le certificat TLS est renouvelé automatiquement 30 jours avant expiration, sans aucune intervention manuelle.
Les Cas Spéciaux
AWS : ALB Ingress Controller
Sur EKS, j'utilise parfois l'AWS Load Balancer Controller qui crée des ALB (Application Load Balancers) natifs AWS au lieu de passer par NGINX. L'avantage : intégration native avec WAF, Shield, et ACM (pour les certificats). L'inconvénient : chaque Ingress crée un ALB, et chaque ALB coûte environ 20 dollars par mois.
Mon approche : un ALB pour les services publics (avec WAF activé) et NGINX pour le routage interne.
Le Sidecar NGINX
Chez une startup e-commerce, nous avions un pattern particulier : un container NGINX sidecar dans chaque pod applicatif pour servir les assets statiques et faire du caching. L'Ingress Controller routait vers le sidecar NGINX, qui forward ensuite au container applicatif. Ce pattern a réduit la latence de 40% sur les pages avec beaucoup de CSS/JS.
Bonnes Pratiques de Configuration
Rate Limiting
Toujours configurer un rate limiting sur les endpoints publics pour se protéger contre les abus et les DDoS légers. L'annotation nginx.ingress.kubernetes.io/limit-rps est votre amie.
Health Checks
Configurer des health checks backend personnalisés pour que l'Ingress ne route pas le trafic vers des pods en erreur. Les readiness probes des pods sont utilisées par défaut, mais des checks supplémentaires au niveau Ingress ajoutent une couche de protection.
Logs et Monitoring
Activer les access logs de l'Ingress Controller et les envoyer vers Loki. Ces logs sont précieux pour le debugging, l'analyse de trafic, et la détection d'anomalies. J'ai résolu de nombreux problèmes de production en analysant les patterns de requêtes dans les logs Ingress.
L'Ingress Controller est le portail de votre cluster. Prenez le temps de le configurer correctement, c'est un investissement qui rapporte sur chaque requête que votre application reçoit.