Qu'est-ce qu'un Ingress et comment route-t-il le trafic externe vers les Services ?

Question

IT Interview Practice · Accepted Answer

Un **Ingress** est un objet Kubernetes qui définit des **règles de routage HTTP/HTTPS** — mappant des noms d'hôte et des paths d'URL vers des **Services** backend. Il est mis en œuvre par un **Ingress Controller** (nginx, Traefik, gateways cloud) et vous donne un point d'entrée unique, la terminaison TLS et le routage host/path au lieu d'un LoadBalancer par service.

## Le problème que l'Ingress résout

```text
Exposer de nombreux services avec type: LoadBalancer implique DE NOMBREUX LB cloud (et IP publiques)
— coûteux, et sans routage partagé par hostname/path ni TLS.
L'Ingress donne UN point d'entrée qui route par host & path vers des Services ClusterIP internes.
```

## Comment tout s'articule

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (a Pod, e.g. nginx; usually behind ONE LoadBalancer)
   │  reads Ingress rules│
   └─────┬──────────────┘
         │ routes by host / path
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (all ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (règles)  ≠  Ingress Controller (le proxy en cours d'exécution qui les applique)
```

## Un manifest d'Ingress

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls        # cert/clé TLS stockés dans un Secret
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
```

```text
shop.example.com/api/... → Service « api » → api Pods
shop.example.com/...     → Service « web » → web Pods
Le TLS est terminé au niveau du controller à l'aide du cert du Secret « shop-tls ».
```

## Points clés

```text
• Vous DEVEZ faire tourner un Ingress Controller — l'objet Ingress seul ne fait rien.
• ingressClassName sélectionne quel controller gère les règles.
• L'Ingress est HTTP/HTTPS (L7) uniquement. Pour du TCP/UDP brut, utilisez un Service ou la Gateway API.
• La Gateway API plus récente est le successeur en évolution, avec un routage plus riche et orienté rôles.
```

```bash
kubectl get ingress                  # lister les règles, hosts, adresses
kubectl describe ingress app-ingress # voir les backends & événements
```

## Pourquoi c'est important

L'Ingress est la façon standard d'exposer des applications HTTP/HTTPS au monde extérieur sur Kubernetes, donc le comprendre est une connaissance essentielle de networking pour les ingénieurs de niveau intermédiaire. Le problème qu'il résout est concret et courant : exposer de nombreux services via `type: LoadBalancer` implique de provisionner un load balancer cloud et une IP publique séparés par service — coûteux et sans routage partagé par hostname ni TLS — alors qu'un **Ingress** vous donne un point d'entrée unique qui route par **host et path** vers des Services ClusterIP internes et termine le **TLS** de façon centralisée. La distinction qui piège les gens est entre l'**objet Ingress** (les règles de routage déclaratives) et l'**Ingress Controller** (le proxy réellement en cours d'exécution — nginx, Traefik, une gateway cloud — qui surveille ces règles et les applique) ; les règles ne font rien sans controller installé, et `ingressClassName` sélectionne lequel les gère. Comprendre que l'Ingress opère au **L7 (HTTP/HTTPS uniquement)** — donc que le TCP/UDP brut nécessite un Service ou la Gateway API plus récente — et que la **Gateway API** est le successeur en évolution, plus expressif, reflète une connaissance actuelle et concrète. Parce que presque chaque application user-facing sur Kubernetes a besoin de routage host/path et de TLS depuis un point d'entrée unique, et parce que la distinction objet-vs-controller est une source fréquente de confusion tant en entretien qu'en pratique, une bonne maîtrise de l'Ingress est fondamentale pour exposer et exploiter des workloads web sur un cluster.

Le problème que l'Ingress résout

Comment tout s'articule

Un manifest d'Ingress

Points clés

Pourquoi c'est important

Questions connexes