1. Introduction et Concepts Fondamentaux
Dans l'écosystème Cloud Native, router le trafic externe exige une réactivité à la milliseconde. Pour les administrateurs débutants, il est crucial de ne pas confondre les différents composants réseau de Kubernetes.
Distinguer les rôles : Ingress Resource vs Ingress Controller
Voici un récapitulatif des responsabilités de chaque composant au sein du cluster :
| Élément | Rôle principal |
|---|---|
| Ingress | Ressource YAML qui déclare les règles de routage (hôtes, chemins). |
| IngressClass | Liaison logique qui associe une ressource Ingress à un contrôleur spécifique. |
| Ingress Controller | Le composant actif (ici HAProxy) qui surveille l'API et applique les règles. |
| Service | Expose l'application en interne et regroupe les Pods de manière logique. |
| Pod | Le conteneur applicatif qui exécute concrètent le code. |
La modernité de l'IngressClass
Aujourd'hui, Kubernetes standardise l'aiguillage des flux via le champ spec.ingressClassName plutôt que par les anciennes annotations obsolètes (kubernetes.io/ingress.class). L'IngressClass permet de faire cohabiter plusieurs contrôleurs distincts (HAProxy, NGINX, Traefik) au sein d'un même cluster, offrant une flexibilité totale par application.
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: haproxy
spec:
controller: haproxy.org/ingress-controller2. Pourquoi choisir HAProxy ? Comparatif Décisionnel
Le choix du point d'entrée réseau est structurant pour les performances et la robustesse d'une infrastructure de production.
Tableau Comparatif : HAProxy vs NGINX vs Traefik
| Critère | HAProxy | NGINX | Traefik |
|---|---|---|---|
| Performance | ⭐⭐⭐ (Maximale, ultra-faible latence) | ⭐⭐ (Très bonne) | ⭐ (Bonne, mais plus gourmand) |
| Configuration | ⭐⭐ (Dynamique via Runtime API) | ⭐ (Nécessite souvent des reloads) | ⭐⭐⭐ (Nativement Cloud Native) |
| Routage TCP/UDP | Excellent | Bon | Bon |
| Observabilité | Très bonne (Stick Tables, Stats) | Bonne | Très bonne |
| Gateway API | Oui (Supporté) | Oui | Oui |
Avantages spécifiques de l'architecture HAProxy
Les architectes privilégient HAProxy pour plusieurs raisons techniques majeures :
- Le mode Direct-to-Pod : HAProxy contourne le composant kube-proxy. Il interroge l'API des Endpoints pour router directement les paquets vers les adresses IP privées des Pods, réduisant le saut réseau.
- Les Stick Tables & le Rate Limiting : Fonctions natives en mémoire permettant de bloquer les attaques par déni de service (DDoS) ou de suivre les sessions applicatives avec une précision chirurgicale.
- Le support moderne des protocoles : Intégration transparente de la terminaison TLS, du Mutual TLS (mTLS) et de HTTP/2 / HTTP/3 (QUIC).
3. Architecture Haute Disponibilité en Production
Pour garantir la résilience face aux pannes, l'Ingress Controller ne doit jamais représenter un SPOF (Single Point of Failure).
Redondance et Résilience
En production, le déploiement de HAProxy s'effectue avec un nombre minimal de 3 répliques distribuées sur différents nœuds du cluster à l'aide de règles d'anti-affinité. Le service Kubernetes de type LoadBalancer (fourni par votre Cloud Provider ou par une solution sur site comme MetalLB) distribue le trafic entrant équitablement entre ces instances.
# Extrait de configuration values.yaml pour Helm
controller:
replicaCount: 3
antiAffinity:
type: hard4. Démonstration Pratique et Routage Avancé
Déploiement d'une règle d'infrastructure multi-hôtes et multi-chemins.
Cas concret : Isolation API et Interface Web
Le manifeste suivant illustre comment HAProxy gère simultanément la séparation par sous-domaine (api.rousseltm.fr vs app.rousseltm.fr) ainsi que le routage par chemin contextuel (/admin), le tout protégé par une redirection SSL globale.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: infrastructure-globale-ingress
annotations:
haproxy.org/ssl-redirect: "true"
haproxy.org/balance: "leastconn"
spec:
ingressClassName: haproxy
rules:
- host: app.rousseltm.fr
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80
- path: /admin
pathType: Strict
backend:
service:
name: admin-service
port:
number: 80
- host: api.rousseltm.fr
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80805. L'avenir du réseau K8s : L'intégration Gateway API
La spécification Ingress montrant ses limites pour les topologies complexes, la communauté migre vers l'écosystème Gateway API.
Support des ressources HTTPRoute
HAProxy Ingress Controller s'aligne nativement sur les évolutions de Kubernetes. Il supporte pleinement les spécifications de la Gateway API. Au lieu de concentrer toute la logique dans un seul Ingress, les responsabilités sont divisées : les administrateurs gèrent l'objet Gateway, tandis que les développeurs déploient de manière autonome des ressources HTTPRoute ou TCPRoute pour exposer leurs applications.
6. Observabilité Avancée et Révolution OpenTelemetry
Assurer le monitoring en temps réel et le traçage distribué des flux réseaux entrants à l'aide des standards ouverts les plus récents.
Le tournant OpenTelemetry natif (v3.4+)
Une évolution majeure a été franchie avec la sortie de la version 3.4 de l'Ingress Controller HAProxy, qui intègre désormais un support natif complet pour OpenTelemetry (OTel). Cette compatibilité native permet d'exporter directement des traces distribuées de niveau 7 sans surcharger l'infrastructure avec des agents sidecars complexes.
Lorsqu'une requête traverse HAProxy pour entrer dans le cluster, le contrôleur est capable d'injecter ou de propager le contexte de trace (W3C Trace Context). Cela permet de lier la latence réseau initiale observée à la frontière du cluster avec les traces internes générées plus en aval par vos microservices (par exemple dans Jaeger, Tempo ou Dynatrace), offrant une visibilité de bout en bout indispensable pour le diagnostic de performance.
Collecte de métriques Prometheus et Dashboards Grafana
En parallèle des traces, HAProxy continue d'exposer son endpoint de métriques au format standard Prometheus. L'architecture de supervision unifiée se décompose ainsi :
HAProxy Ingress ──(Métriques + Traces OTel)──> Prometheus / OpenTelemetry Collector ──> Grafana / Tempo
Cette approche hybride permet de corréler instantanément un pic d'erreurs HTTP (4xx/5xx) ou une dégradation des requêtes par seconde (RPS) visualisés sur Grafana avec les traces OpenTelemetry spécifiques pour identifier le goulot d'étranglement.
Conclusion
Synthèse pour les Certifications CKA & CKAD
Pour réussir vos examens de certification CKA/CKAD, retenez les principes fondamentaux suivants :
- L'Ingress Resource est uniquement un ensemble de règles théoriques.
- L'IngressClass sélectionne l'implémentation technologique.
- L'Ingress Controller est le moteur physique qui traduit et applique la configuration.
- HAProxy Ingress fournit la puissance L4/L7 et une observabilité moderne (OpenTelemetry, Prometheus) indispensable aux environnements industriels.