Ingress Controller : le guide de production

1. Le rôle de l'Ingress Controller dans Kubernetes #

Pour exposer des services HTTP/HTTPS au monde extérieur, Kubernetes s'appuie sur un mécanisme en trois parties : la ressource Ingress, l'IngressClass et l'Ingress Controller.

Comprendre la chaîne de routage #

• Ingress Resource : Un objet YAML qui définit les règles de routage. C'est une déclaration d'intention : 'Je veux que le trafic pour api.mondomaine.com aille vers le service api-service'.
• IngressClass : Une ressource qui lie une règle Ingress à un contrôleur spécifique. Elle permet de faire cohabiter plusieurs Ingress Controllers (HAProxy, Nginx, etc.) dans un même cluster.
• Ingress Controller : Le moteur actif. C'est un pod (ou un ensemble de pods) qui surveille l'API Kubernetes, lit les ressources Ingress et configure dynamiquement son proxy interne (ici, HAProxy) pour appliquer les règles de routage.

Pourquoi HAProxy est un choix de premier plan #

Si Nginx est souvent l'Ingress par défaut, HAProxy est privilégié dans les environnements à très haute performance pour sa faible latence, sa consommation mémoire optimisée et ses fonctionnalités avancées de load balancing.

2. Architecture 'Direct-to-Pod' : La clé de la performance #

L'un des avantages majeurs de l'Ingress Controller HAProxy est sa capacité à router le trafic directement vers les pods, en contournant une partie du réseau interne de Kubernetes.

Contourner kube-proxy #

Par défaut, le trafic dans Kubernetes passe par kube-proxy, qui utilise des règles iptables ou IPVS pour rediriger le trafic vers les pods d'un service. L'Ingress HAProxy, lui, s'abonne directement à l'API des Endpoints de Kubernetes. Il connaît ainsi en temps réel les adresses IP privées de chaque pod applicatif.

Résultat : le trafic va directement de l'Ingress Controller au pod de destination, ce qui réduit la latence, simplifie le dépannage réseau et offre des algorithmes de répartition de charge plus intelligents que le simple round-robin de kube-proxy.

3. Déploiement et configuration de base #

Mettons en place un routage simple pour exposer une application.

Déploiement avec Helm #

La méthode la plus simple pour déployer l'Ingress Controller HAProxy est d'utiliser son chart Helm officiel.

helm repo add haproxy-ingress https://haproxy-ingress.github.io/charts
helm install haproxy-ingress haproxy-ingress/haproxy-ingress

Cette commande déploie le contrôleur et crée un service de type LoadBalancer pour l'exposer sur Internet.

Exemple de ressource Ingress #

Voici un exemple de ressource Ingress qui route le trafic pour app.mondomaine.com vers un service nommé webapp-service sur le port 8080.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
spec:
  ingressClassName: haproxy # On spécifie quel contrôleur utiliser
  rules:
  - host: app.mondomaine.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 8080

4. Gestion du TLS (HTTPS) #

La sécurisation du trafic est une étape cruciale. HAProxy peut gérer la terminaison TLS, déchargeant ainsi les applications de cette tâche.

Terminaison TLS avec un Secret Kubernetes #

Pour activer le HTTPS, vous devez d'abord stocker votre certificat et votre clé privée dans un Secret Kubernetes de type kubernetes.io/tls.

kubectl create secret tls mon-cert-tls \
  --cert=path/to/cert.pem \
  --key=path/to/key.pem

Ensuite, il suffit de référencer ce secret dans la ressource Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress-tls
  annotations:
    haproxy.org/ssl-redirect: "true" # Force la redirection de HTTP vers HTTPS
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - app.mondomaine.com
    secretName: mon-cert-tls # On référence le secret
  rules:
  - host: app.mondomaine.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 8080

L'annotation haproxy.org/ssl-redirect est une bonne pratique pour s'assurer que tout le trafic passe par une connexion chiffrée.

5. Haute Disponibilité et Scalabilité #

En production, un Ingress Controller ne doit jamais être un point de défaillance unique (SPOF).

Déployer plusieurs répliques #

Il est impératif de déployer au moins 2 ou 3 répliques du pod de l'Ingress Controller. Le service de type LoadBalancer en amont se chargera de répartir le trafic entre ces répliques. On utilise généralement des règles d'anti-affinité pour s'assurer que les pods du contrôleur sont déployés sur des nœuds physiques différents.

Exemple de configuration (values.yaml Helm) :

controller:
  replicaCount: 3
  # Force le déploiement des pods sur des nœuds différents
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - haproxy-ingress
        topologyKey: "kubernetes.io/hostname"

Conclusion : Un choix robuste pour la production #

HAProxy s'impose comme une solution mature et extrêmement performante pour gérer le trafic entrant dans Kubernetes.

Synthèse #

En choisissant HAProxy comme Ingress Controller, vous bénéficiez de :

• Performances de pointe grâce à son architecture optimisée et au routage Direct-to-Pod.
• Fonctionnalités avancées de load balancing et de sécurité (ACLs, rate limiting).
• Une configuration dynamique qui s'adapte en temps réel aux changements dans le cluster.
• Une compatibilité avec les standards de l'écosystème, y compris la future Gateway API.

C'est un choix technique solide pour les applications qui ne peuvent se permettre aucun compromis sur la latence et la fiabilité.