infra / kubernetes

Ingress

Leçon 101 exercice

Explication

Ce que vous allez apprendre

Expliquer pourquoi exposer chaque microservice avec son propre LoadBalancer devient coûteux et ingérable à grande échelle
Décrire le rôle de l'Ingress comme point d'entrée HTTP(S) unique routant vers plusieurs Services internes
Distinguer l'objet Ingress (règles déclaratives) de l'Ingress Controller (logiciel qui les applique réellement)
Router le trafic par nom d'hôte et par chemin d'URL, et combiner les deux
Diagnostiquer un Ingress qui "ne fait rien" en vérifiant qu'un contrôleur est bien installé dans le cluster

Dans quel contexte ?

Une startup lance dix microservices, chacun nécessitant un accès public HTTPS. Exposer chacun via un Service LoadBalancer coûterait dix IP publiques et dix équilibreurs de charge facturés séparément par le fournisseur cloud. En installant un seul Ingress Controller (nginx) et en définissant des règles de routage par nom d'hôte (api.exemple.com, admin.exemple.com...) et par chemin (/paiement, /notifications...), toute l'application est exposée via une seule IP publique et un seul LoadBalancer, réduisant drastiquement les coûts d'infrastructure.

Le problème d'un LoadBalancer par service

D'abord, rappelle-toi la leçon sur les Services : LoadBalancer provisionne une IP publique dédiée chez le fournisseur cloud.

Prérequis

Cette leçon suppose acquis les Services et notamment le type LoadBalancer (leçon 5) : l'Ingress Controller s'appuie généralement sur un Service de ce type pour recevoir le trafic entrant.

Ce que ça coûterait à grande échelle

Mais si ton application se compose de dix microservices exposés publiquement, faut-il dix équilibreurs de charge, dix IP, dix factures ? Ce n'est clairement pas raisonnable.

La solution : un point d'entrée unique et intelligent

C'est là qu'intervient l'Ingress : un point d'entrée HTTP(S) unique, capable de router le trafic vers le bon Service interne selon le nom de domaine ou le chemin de l'URL demandée.

Objet	Rôle
Ingress	Décrit les règles de routage (déclaratif, ne fait rien seul)
Ingress Controller (nginx, Traefik...)	Logiciel installé dans le cluster qui lit les règles et route réellement le trafic
LoadBalancer (Service)	Fournit l'unique IP publique d'entrée, utilisée par le contrôleur

Une pièce logicielle qu'il ne faut pas oublier

Contrairement à un Service géré directement par Kubernetes, un objet Ingress ne fait strictement rien tout seul : il décrit des règles de routage.

Qui applique réellement ces règles

C'est un logiciel tiers, l'Ingress Controller (nginx, Traefik, etc.), qui doit être installé dans le cluster pour lire ces règles et les appliquer réellement. Un débutant qui crée un Ingress sans avoir installé de contrôleur se retrouve avec un objet qui existe mais qui ne route aucun trafic.

Piège fréquent

Créer un objet Ingress sans avoir installé d'Ingress Controller dans le cluster produit un objet qui existe (kubectl get ingress l'affiche) mais qui ne route absolument aucun trafic. C'est l'une des confusions les plus fréquentes chez les débutants : l'Ingress décrit des règles, il ne les exécute jamais lui-même.

Router par domaine ET par chemin

Une fois le contrôleur en place, l'Ingress permet deux logiques de routage combinables : par nom d'hôte (app.example.com vers un service, api.example.com vers un autre) et par chemin (/api vers le backend, / vers le frontend, sur le même domaine).

Ce que cela permet concrètement

C'est ce qui permet de faire cohabiter plusieurs applications derrière une seule IP publique et un seul certificat.

HTTPS presque automatique

Pour aller plus loin, l'association avec cert-manager, un opérateur qui automatise l'émission et le renouvellement de certificats TLS via Let's Encrypt, est l'un des grands avantages pratiques de l'Ingress : du HTTPS géré de bout en bout, sans jamais manipuler un certificat à la main.

La leçon suivante s'attaque à un problème différent : ajuster automatiquement le nombre de Pods selon la charge réelle, avec le HPA.

Commandes & code

Ingress

Un Ingress route le trafic HTTP(S) externe vers des Services internes, en se basant sur le host/chemin — un seul point d'entrée pour plusieurs services.

# ingress.yaml (nécessite un Ingress Controller déployé, ex: nginx-ingress, traefik)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls          # généralement provisionné par cert-manager
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80

# Ingress multi-domaines : deux hosts routés vers des services différents
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-domain-ingress
spec:
  ingressClassName: nginx
  rules:
    - host: admin.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: admin-service
                port:
                  number: 80
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

kubectl apply -f ingress.yaml
kubectl get ingress
kubectl describe ingress app-ingress

# Debug local sans DNS réel : forcer la résolution via /etc/hosts
echo "127.0.0.1 app.example.com" | sudo tee -a /etc/hosts

Résumé

Un Ingress Controller (nginx, traefik...) doit être installé : l'Ingress seul ne fait rien.
pathType: Prefix route par préfixe de chemin, plusieurs hosts peuvent partager un Ingress.
tls: + cert-manager automatisent l'émission et le renouvellement des certificats.
Un Ingress remplace avantageusement plusieurs Services LoadBalancer coûteux.

Exercices pratiques

1 disponible

Mission : réduire la facture de dix LoadBalancer

Objectif : Remplacer dix Services LoadBalancer par un unique Ingress routant par domaine et par chemin, et diagnostiquer un Ingress qui ne route rien.

Contexte

Une startup expose actuellement dix microservices, chacun via son propre Service LoadBalancer, facturé séparément par le cloud provider. Le CTO demande de tout regrouper derrière un seul point d'entrée avant la fin du mois. Un stagiaire a déjà écrit un objet Ingress complet, mais kubectl get ingress montre l'objet créé alors qu'aucune requête HTTP n'arrive jamais à destination.

Résoudre l’exercice →