Ingress Controller

Vue d'ensemble

Un ingress controller gère l'accès externe aux services au sein de votre cluster Kubernetes. Il écoute les ressources Ingress et configure le routage du trafic selon les règles définies.

Nous vous proposons trois options d'ingress controllers, chacune adaptée à différents besoins :

Option	Description	Cas d'usage
NGINX	NGINX Ingress Controller	Compatibilité historique et environnements qui reposent encore sur des annotations NGINX
TRAEFIK_NGINX_COMPAT	Traefik en mode compatibilité NGINX	Migration progressive depuis NGINX avec conservation des Ingress existants
TRAEFIK	Traefik en mode natif	Nouveaux clusters, nouvelles expositions HTTP(S), Gateway API
(vide)	Aucun ingress controller	Cas particuliers sans exposition HTTP(S) gérée par la plateforme

Le mode recommandé pour les nouveaux clusters est TRAEFIK.

Ce que chaque mode active réellement

Mode	Providers / ressources actives	Recommandation
NGINX	Ingress Kubernetes classique	A conserver pour les déploiements qui dépendent encore fortement de NGINX
TRAEFIK_NGINX_COMPAT	Gateway API, CRDs Traefik, lecture des Ingress NGINX existants	Idéal pour migrer progressivement depuis NGINX
TRAEFIK	Gateway API, CRDs Traefik, provider Ingress natif Traefik	Le mode cible pour les nouveaux usages

En pratique :

• les clusters en TRAEFIK_NGINX_COMPAT continuent de comprendre les ressources Ingress existantes qui reposent sur les annotations NGINX les plus courantes,
• les clusters en TRAEFIK sont orientés vers Gateway API pour les nouvelles expositions HTTP(S),
• dans les deux modes Traefik, les CRDs Traefik comme Middleware sont disponibles.

Quel mode choisir ?

• Choisissez NGINX si vous devez conserver un comportement historique strict et que votre application repose encore sur NGINX.
• Choisissez TRAEFIK_NGINX_COMPAT si vous voulez migrer sans réécrire immédiatement vos objets Ingress existants.
• Choisissez TRAEFIK si vous démarrez un nouveau projet ou si vous voulez utiliser Gateway API comme modèle de routage principal.

Pour un guide détaillé avec cas d'usage et stratégie de migration, consultez Choisir sa solution d'exposition.

CRDs Traefik et middlewares sur des Ingress classiques

Sur les clusters Ziosting configurés en TRAEFIK ou en TRAEFIK_NGINX_COMPAT, le provider Traefik kubernetesCRD est activé. Cela signifie que les ressources CRD Traefik sont disponibles dans le cluster, notamment les Middleware.

En mode TRAEFIK, vous pouvez donc combiner :

• un objet Kubernetes Ingress standard
• un Middleware Traefik défini comme CRD
• l'annotation traefik.ingress.kubernetes.io/router.middlewares

Autrement dit, il n'est pas nécessaire d'utiliser IngressRoute pour profiter des middlewares Traefik sur Ziosting.

En mode TRAEFIK_NGINX_COMPAT, les CRDs Traefik restent disponibles, mais l'annotation traefik.ingress.kubernetes.io/router.middlewares sur un Ingress standard ne doit pas être utilisée comme mécanisme de compatibilité. Si vous avez besoin d'attacher un Middleware Traefik à un routeur HTTP, utilisez le mode TRAEFIK ou une ressource Traefik dédiée.

Exemple :

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: brotli-compress
  namespace: demo
spec:
  compress:
    encodings:
      - br
    minResponseBodyBytes: 256
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  namespace: demo
  annotations:
    traefik.ingress.kubernetes.io/router.entrypoints: web
    traefik.ingress.kubernetes.io/router.middlewares: demo-brotli-compress@kubernetescrd
spec:
  ingressClassName: nginx
  rules:
    - host: demo.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: demo
                port:
                  number: 80

La référence du middleware suit le format <namespace>-<nom>@kubernetescrd.

Gateway API pour les nouvelles expositions HTTP(S)

Sur les clusters en mode TRAEFIK ou TRAEFIK_NGINX_COMPAT, Ziosting s'appuie sur Gateway API pour exposer les services HTTP(S). Ce modèle utilise principalement :

• un Gateway pour le point d'entrée,
• un HTTPRoute pour les règles de routage,
• et, si nécessaire, des Middleware Traefik pour des fonctions comme la restriction d'IP ou la basic auth.

Ce modèle est particulièrement adapté aux nouveaux déploiements et aux services exposés par la plateforme elle-même.

Configuration des Ingress

Annotations - NGINX / TRAEFIK_NGINX_COMPAT

Lorsque vous utilisez NGINX ou TRAEFIK_NGINX_COMPAT, utilisez les annotations NGINX standard :

La liste des annotations prises en charge par Traefik en mode compatibilité NGINX est disponible dans la documentation officielle : https://doc.traefik.io/traefik/master/reference/routing-configuration/kubernetes/ingress-nginx/

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-service
  annotations:
    # Réécriture d'URL
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    # Rate limiting
    nginx.ingress.kubernetes.io/limit-rps: "10"
    # Force vers HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    # CORS
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "*"
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

Annotations - TRAEFIK natif

Avec Traefik en mode natif, les annotations sont préfixées par traefik.ingress.kubernetes.io :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-service
  annotations:
    # Middleware (Traefik natif)
    traefik.ingress.kubernetes.io/router.middlewares: "default-authentication@kubernetescrd"
    # Réécriture d'URL (via middleware)
    traefik.ingress.kubernetes.io/router.entrypoints: "websecure"
spec:
  tls:
    - hosts:
        - example.com
      secretName: example-tls
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

Modifier l'Ingress Controller

Étapes de modification

1. Préparation : Validez que vos Ingress sont compatibles avec le nouveau contrôleur
2. Changement via console ou API : Mettez à jour le type d'ingress controller
3. Synchronisation : Un sync du cluster applique la modification
4. Vérification : Attendez que les nouveaux pods soient en running et testez vos services

Impacts sur les services

⚠️ Points d'attention :

Impact	Détail
Downtime	Généralement minimal (quelques secondes) lors du remplacement des pods. Les connexions existantes peuvent être interrompues
Configuration	Les annotations change entre NGINX et Traefik natif. Si vous changez sans adapter, les Ingress peuvent ne pas fonctionner correctement
DNS/Certificats	Pas d'impact si vos certificats et routes sont configurés correctement
Services	L'adresse IP externe peut changer lors du passage entre contrôleurs

Changement via Console Ziosting

1. Ouvrez la page de votre cluster RKE2
2. Allez à l'onglet Paramètres
3. Section Contrôleur Ingress : sélectionnez le nouveau type
4. Cliquez Enregistrer les modifications
5. Un sync est lancé automatiquement

L'onglet Ingress affichera les métriques adaptées au nouveau contrôleur.

Changement via API

Mutation pour changer l'ingress controller :

mutation UpdateIngressController {
    updateKaas(input: {
      id: "/api/kaass/1",
      ingressControllerType: "TRAEFIK"
    }) {
        clientMutationId
        kaas {
            id
            ingressControllerType
        }
    }
}

Options : NGINX, TRAEFIK, TRAEFIK_NGINX_COMPAT, ou null (aucun)

Ensuite, synchronisez le cluster :

mutation SyncKaas {
    syncKaas(input: {
      id: "/api/kaass/1"
    }) {
        clientMutationId
    }
}

Checklist de migration

Avant de changer d'ingress controller :

• Lister tous vos Ingress : kubectl get ingress -A
• Exporter leur configuration : kubectl get ingress -A -o yaml > ingress-backup.yaml
• Vérifier les annotations utilisées (NGINX vs Traefik)
• Adapter les annotations si nécessaire
• Planifier le changement en heures creuses
• Tester sur un environnement de staging si possible
• Après le changement, valider que tous les services sont accessibles