Configuration du routage basé sur l'hôte et le chemin

Définir les règles du jeu : diriger le trafic HTTP/S

Maintenant qu'un contrôleur Ingress est déployé et prêt à écouter, nous pouvons enfin définir les règles qui lui indiqueront comment acheminer le trafic HTTP/S entrant vers nos différents services internes. C'est le coeur de l'objet `Ingress` : la section `spec.rules`.

Ces règles permettent un routage de niveau 7 (L7) basé sur les caractéristiques de la requête HTTP, principalement le nom d'hôte demandé (via l'en-tête `Host`) et le chemin d'URL. Cela nous permet de partager une seule adresse IP d'entrée (celle du contrôleur Ingress) entre plusieurs applications ou services distincts.

Nous allons explorer comment configurer ces deux types de routage fondamentaux : basé sur l'hôte (virtual hosting) et basé sur le chemin.

Routage basé sur l'hôte (Virtual Hosting)

Le routage basé sur l'hôte permet de diriger le trafic vers différents services en fonction du nom de domaine demandé par le client. Par exemple, vous pouvez vouloir que `blog.example.com` pointe vers le service de votre blog, tandis que `api.example.com` pointe vers le service de votre API, le tout arrivant sur la même adresse IP du contrôleur Ingress.

Cela est configuré dans la section `spec.rules`. Chaque élément de cette liste peut spécifier un `host`.

Exemple :

apiVersion: networking.k8s.io/v1 # API group pour Ingress
kind: Ingress
metadata:
  name: virtual-host-ingress
spec:
  rules:
  - host: "foo.example.com" # Trafic pour foo.example.com
    http:
      paths:
      - path: /        # Pour tous les chemins sous cet hôte
        pathType: Prefix # Type de correspondance de chemin
        backend:
          service:
            name: service-foo # Service cible
            port:
              number: 80    # Port du service cible
  - host: "bar.example.com" # Trafic pour bar.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service-bar
            port:
              number: 8080

Dans cet exemple :

• Les requêtes arrivant avec l'en-tête `Host: foo.example.com` sont dirigées vers le port 80 du Service nommé `service-foo`.
• Les requêtes arrivant avec l'en-tête `Host: bar.example.com` sont dirigées vers le port 8080 du Service nommé `service-bar`.

Prérequis DNS : Pour que cela fonctionne, vous devez bien sûr configurer vos enregistrements DNS externes pour que `foo.example.com` et `bar.example.com` pointent tous deux vers l'adresse IP externe de votre contrôleur Ingress.

Si une requête arrive sans en-tête `Host` correspondant à une règle ou si la section `rules` est omise, le trafic est généralement dirigé vers le `spec.defaultBackend` (si défini) ou géré selon la configuration par défaut du contrôleur Ingress (souvent une page 404).

Routage basé sur le chemin (Path Based Routing)

En plus du routage par hôte, ou en combinaison avec celui-ci, vous pouvez router le trafic en fonction du chemin d'URL demandé. C'est utile pour exposer différentes fonctionnalités ou microservices d'une même application via des chemins distincts sous un même nom d'hôte.

Chaque règle sous `spec.rules[].http.paths` définit un `path` et le `backend` (Service et port) vers lequel le trafic correspondant doit être envoyé. Vous devez également spécifier un `pathType` pour indiquer comment le chemin doit être interprété :

• `pathType: Prefix` (le plus courant) : Correspondance basée sur le préfixe de l'URL. Par exemple, `path: /api` correspondra à `/api`, `/api/users`, `/api/v2/`, etc. Le contrôleur Ingress est responsable de la correspondance exacte (par exemple, s'assurer que `/api` correspond bien avant `/api/v2`).
• `pathType: Exact` : Correspondance exacte du chemin. Par exemple, `path: /login` ne correspondra qu'à la requête pour `/login` exactement, pas `/login/` ou `/login/user`.
• `pathType: ImplementationSpecific` : La correspondance dépend de l'implémentation spécifique du contrôleur Ingress (par exemple, il pourrait autoriser les expressions régulières via des annotations). C'est le type par défaut si non spécifié, mais il est recommandé de toujours spécifier `Prefix` ou `Exact` pour la portabilité.

Exemple :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-based-ingress
spec:
  rules:
  - host: "myapp.example.com"
    http:
      paths:
      - path: /api # Trafic vers /api/*
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8000
      - path: /     # Trafic vers la racine et tout le reste (ordre important !)
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
      - path: /admin # Trafic spécifique pour /admin
        pathType: Exact
        backend:
          service:
            name: admin-console-service
            port:
              number: 9090

Ici, pour l'hôte `myapp.example.com` :

• Le trafic vers `/api` et ses sous-chemins va à `api-service` sur le port 8000.
• Le trafic exact vers `/admin` va à `admin-console-service` sur le port 9090.
• Tout autre trafic (y compris `/`) va à `frontend-service` sur le port 80.

Ordre de priorité : Le contrôleur Ingress évalue généralement les chemins du plus spécifique au moins spécifique. La correspondance exacte (`Exact`) a souvent priorité sur la correspondance par préfixe (`Prefix`). La manière exacte dont les conflits de chemins sont résolus peut dépendre légèrement du contrôleur Ingress, il est donc bon de consulter sa documentation spécifique.

Backend par défaut (Default Backend)

Vous pouvez définir un `spec.defaultBackend` dans votre Ingress. C'est un Service vers lequel le trafic sera envoyé si aucune des règles (combinaison hôte/chemin) ne correspond à la requête entrante.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-with-default
spec:
  defaultBackend:
    service:
      name: default-404-service
      port:
        number: 80
  rules:
  - host: "specific.example.com"
    http:
      # ... paths pour cet hôte ...

Si une requête arrive pour `other.example.com` (ou sans en-tête Host correspondant), elle sera dirigée vers `default-404-service`. Si `defaultBackend` n'est pas défini, le comportement par défaut dépend du contrôleur Ingress (souvent une page 404 générée par le contrôleur lui-même).

IngressClass

Dans les clusters où plusieurs contrôleurs Ingress pourraient coexister, l'objet `IngressClass` (introduit dans les versions plus récentes de Kubernetes) et le champ `spec.ingressClassName` dans l'objet Ingress permettent de spécifier explicitement quel contrôleur Ingress doit gérer cet Ingress particulier.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-specific-ingress
spec:
  ingressClassName: "nginx-external" # Spécifie quel contrôleur utiliser
  rules:
  # ...

Cela évite les conflits si, par exemple, vous avez un contrôleur pour le trafic externe et un autre pour le trafic interne.

Conclusion : flexibilité du routage déclaratif

Les règles de routage basées sur l'hôte et le chemin définies dans l'objet Ingress offrent une flexibilité considérable pour gérer le trafic HTTP/S entrant dans votre cluster Kubernetes. Elles permettent de consolider l'accès à de multiples services derrière un seul point d'entrée et de diriger les requêtes de manière intelligente en fonction des besoins de l'application.

En définissant ces règles de manière déclarative, vous bénéficiez des avantages de l'infrastructure en tant que code (IaC) et du versionnement. La prochaine étape consiste à sécuriser ces connexions en ajoutant la terminaison TLS (HTTPS).