Aller au contenu

Kubernetes Mis à jour le 2026-05-27

Kubernetes : créer des ingresses

Exposer un service Kubernetes via un Ingress sur le Stack Harbor PaaS — comment le contrôleur d'ingress empaqueté (Traefik / NGINX / HAProxy) traite les specs.

Un Ingress Kubernetes est l’abstraction de répartiteur qui se place devant les ressources Service et route le trafic HTTP / HTTPS externe vers le cluster. Sur le Stack Harbor PaaS, le contrôleur d’ingress est celui que vous avez choisi à l’installation du cluster — NGINX, Traefik ou HAProxy — et il observe les ressources Ingress, analyse leurs specs et annotations spécifiques au contrôleur, et les traduit en règles de routage.

Cette page couvre la forme d’une spec Ingress, le choix recommandé de contrôleur, et un comportement spécifique à la plateforme : la sélection du contrôleur reste figée à vie sur le cluster.

Ingress vs NodePort

Les deux exposent un service au trafic hors cluster. Compromis :

  • Un NodePort lie le service à un port sur chaque nœud et est le chemin le plus simple. Un service, un port.
  • Un Ingress siège derrière une IP unique et route plusieurs services par nom d’hôte ou chemin. Le contrôleur ajoute réécriture de chemin, terminaison TLS, virtual hosting par nom, authentification et limitation de débit en standard.

Pour de vraies charges avec plusieurs services ou tout besoin de TLS ou de routage par nom d’hôte, l’Ingress est le bon outil. NodePort est pour l’exposition ponctuelle et les tests rapides.

Exemple d’Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  labels:
    app: myapp
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/router.middlewares: default-strip-prefix@kubernetescrd
spec:
  rules:
    - http:
        paths:
          - path: /myapp
            pathType: Prefix
            backend:
              service:
                name: myapp
                port:
                  number: 8080

Cette spec transfère les requêtes sous /myapp du domaine par défaut de l’environnement (https://${envName}.${platformDomain}/myapp) vers le service myapp sur le port 8080.

Quelques points à noter :

  • L’exemple utilise le groupe d’API networking.k8s.io/v1. Le groupe historique extensions/v1beta1 a été retiré ; les nouvelles specs doivent utiliser v1.
  • kubernetes.io/ingress.class sélectionne le contrôleur. Avec plusieurs contrôleurs installés, cette annotation est ce qui route l’Ingress vers le bon.
  • Le strip de préfixe (équivalent du PathPrefixStrip historique) est désormais piloté par middleware dans Traefik et par nginx.ingress.kubernetes.io/rewrite-target dans NGINX. Le contrôleur choisi dicte la surface d’annotations.

Pour le routage par hôte (plusieurs sites derrière un cluster), ajoutez un champ host: sous chaque règle. Pour TLS, ajoutez une section tls: pointant vers un Secret Kubernetes qui porte le certificat.

La sélection du contrôleur reste figée

Le contrôleur d’ingress choisi à l’installation ne peut pas être basculé depuis le module de gestion Kubernetes ni depuis aucune autre surface d’automatisation après le démarrage du cluster. La décision reste figée à vie sur le cluster.

Un basculement manuel est possible — désinstallez le contrôleur courant, installez le remplaçant, mettez à jour les ressources Ingress existantes pour pointer vers la nouvelle classe. Ce n’est pas une opération en un clic. Contactez le support Stack Harbor si vous devez le faire ; nous pouvons accompagner la migration.

C’est une contrainte plateforme, pas une contrainte Kubernetes. Planifiez le choix du contrôleur à l’installation.

Choisir un contrôleur

Trois contrôleurs sont livrés avec le paquet plateforme :

  • NGINX — défaut recommandé. La plus large surface d’annotations et la documentation la plus fournie. Gère proprement les réécritures complexes, l’auth et la limitation de débit.
  • Traefik — empreinte plus petite, middleware piloté par CRD déclaratif. Bon choix pour les équipes qui préfèrent le modèle de configuration Traefik.
  • HAProxy — haute performance et bien adapté aux charges à très haut volume de requêtes où le comportement de NGINX ne correspond pas.

Choisissez NGINX sauf raison spécifique d’en préférer un autre.

Voir aussi