Introduction

Dans Kubernetes, l’un des plus grands défis est la gestion du trafic entrant vers les applications.

Quand plusieurs services tournent dans un cluster Kubernetes, il faut un moyen intelligent pour :

• Exposer les applications à Internet
• Gérer le routage
• Sécuriser les connexions HTTPS
• Contrôler les flux réseau
• Éviter de créer un Load Balancer par service

Pendant longtemps, Kubernetes utilisait principalement Ingress.

Mais avec l’évolution des architectures cloud natives, Kubernetes introduit progressivement une solution plus puissante : Gateway API.

Architecture Globale

Avant de comparer Ingress et Gateway API, voyons comment fonctionne le trafic dans Kubernetes.

Utilisateur
    |
    v
Internet
    |
    v
Load Balancer Cloud
    |
    v
Ingress Controller
    |
    v
Service Kubernetes
    |
    v
Pods

Qu’est-ce que Kubernetes Ingress ?

Ingress est une ressource Kubernetes permettant de gérer l’accès HTTP/HTTPS vers les applications.

Il sert à centraliser le routage.

Au lieu de créer un Load Balancer pour chaque service :

BAD PRACTICE

Service A -> LoadBalancer
Service B -> LoadBalancer
Service C -> LoadBalancer

On utilise :

GOOD PRACTICE

1 seul Ingress
      |
      +----> Service A
      +----> Service B
      +----> Service C

Exemple Réel

Imaginons que tu as :

• une API
• un frontend
• un dashboard admin

Tu veux :

Ingress permet cela.

Exemple Concret Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: company-ingress
spec:
  rules:
  - host: api.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

  - host: company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

Ce Qui Se Passe Réellement

Utilisateur -> api.company.com

Ingress lit le host

if host == api.company.com:
    redirect vers api-service

Schéma Réel Ingress

                        +----------------+
Internet -------------> |   Ingress      |
                        +----------------+
                           /         \
                          /           \
                         v             v
                 +-------------+  +-------------+
                 | API Service |  | Frontend    |
                 +-------------+  +-------------+

Limites Réelles de Ingress

Ingress fonctionne bien.

Mais il devient limité.

Limitation 1: HTTP uniquement

Ingress gère principalement :

• HTTP
• HTTPS

Mais pas naturellement :

• TCP
• UDP
• Kafka
• Redis
• MQTT
• Database traffic

Limitation 2: Vendor Lock

Chaque Ingress Controller ajoute ses propres annotations.

Exemple NGINX

annotations:
  nginx.ingress.kubernetes.io/rewrite-target: /

Exemple HAProxy

annotations:
  haproxy.org/path-rewrite: /

Problème :

Tu changes de controller → tu dois réécrire la config.

Limitation 3: Peu Flexible

Impossible facilement de faire :

• Canary Release
• Traffic Mirroring
• Header Routing
• Traffic Split
• A/B Testing

Pourquoi Gateway API Existe

Gateway API corrige les limites de Ingress.

Kubernetes a créé une nouvelle génération de networking.

Vision Gateway API

Ingress = Simple Routing
Gateway API = Traffic Platform

Architecture Gateway API

GatewayClass
      |
      v
    Gateway
      |
      v
   HTTPRoute
      |
      v
   Service

Comprendre Chaque Objet

1. GatewayClass

Décrit :

• quel contrôleur utiliser
• quelles capacités existent

Exemple :

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx
spec:
  controllerName: k8s.io/nginx-gateway-controller

2. Gateway

Gateway représente un vrai point d’entrée.

Equivalent moderne d’un Ingress Controller.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80

3. HTTPRoute

HTTPRoute remplace Ingress.

Il contient les règles.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: main-gateway

  hostnames:
  - api.company.com

  rules:
  - backendRefs:
    - name: api-service
      port: 80

Schéma Gateway API

                    +-------------------+
Internet ---------->| Gateway           |
                    +-------------------+
                             |
                             v
                    +-------------------+
                    | HTTPRoute         |
                    +-------------------+
                             |
                             v
                    +-------------------+
                    | Kubernetes Service|
                    +-------------------+

Exemple Réel Complet

Cas Entreprise

Tu as :

• Frontend
• API
• Dashboard
• Microservices

Objectif

company.com -> frontend
api.company.com -> api
admin.company.com -> dashboard

Gateway

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: company-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80

HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: frontend-route
spec:
  parentRefs:
  - name: company-gateway

  hostnames:
  - company.com

  rules:
  - backendRefs:
    - name: frontend-service
      port: 80

Deuxième Route

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: company-gateway

  hostnames:
  - api.company.com

  rules:
  - backendRefs:
    - name: api-service
      port: 80

Traffic Split

Gateway API permet cela.

Exemple Canary Deployment

70% trafic → Version Stable
30% trafic → Nouvelle Version

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-route
spec:
  parentRefs:
  - name: main-gateway

  rules:
  - backendRefs:
    - name: app-v1
      port: 80
      weight: 70

    - name: app-v2
      port: 80
      weight: 30

Résultat

Utilisateur
      |
      v
    Gateway
      |
      +------> app-v1 (70%)
      |
      +------> app-v2 (30%)

Header Routing

Tu peux router selon un header.

Exemple

rules:
- matches:
  - headers:
    - name: version
      value: beta

  backendRefs:
  - name: beta-service
    port: 80

Ce Qui Se Passe

Request Header:

version: beta

-> redirection vers beta-service

TCP Support

Ingress ne gère pas bien TCP.

Gateway API peut gérer.

Exemple TCPRoute

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: redis-route
spec:
  parentRefs:
  - name: gateway

  rules:
  - backendRefs:
    - name: redis-service
      port: 6379

Comparaison Finale

Diagramme Architecture Enterprise

                        +---------------------+
                        |      Internet       |
                        +---------------------+
                                  |
                                  v
                        +---------------------+
                        |      Gateway        |
                        +---------------------+
                            /       |       \
                           /        |        \
                          v         v         v
                   +----------+ +----------+ +----------+
                   | Frontend | | API      | | Admin    |
                   +----------+ +----------+ +----------+

Installer CRD Gateway API

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

Vérifier Installation

kubectl get gatewayclass

Utilise Ingress si :

• petit projet
• routing simple
• HTTP uniquement
• besoin rapide

Utilise Gateway API si :

• microservices
• traffic avancé
• cloud architecture
• besoin long terme
• architecture scalable

Conclusion

Ingress a révolutionné Kubernetes networking.

Mais Gateway API représente le futur.

Ingress = configuration simple

Gateway API = plateforme réseau complète

               INTERNET
                    |
                    v
            +---------------+
            | Gateway API   |
            +---------------+
                    |
         +----------+-----------+
         |          |           |
         v          v           v
      Service A  Service B  Service C

Gateway API n’est pas juste une amélioration.

C’est une nouvelle manière de penser le networking Kubernetes.

Si tu travailles sur :

• AKS
• EKS
• GKE
• OpenShift
• Microservices
• DevOps Enterprise