Hub de Connaissances DevOps
Hub de Connaissances DevOps

NodePort vs LoadBalancer vs Ingress : Choisir la meilleure exposition de service

Naviguez dans le choix critique d'exposer les Services Kubernetes en externe en comparant NodePort, LoadBalancer et Ingress. Ce guide détaille l'architecture, la couche opérationnelle (L4 vs L7), les cas d'utilisation et les différences clés en termes de coût et de complexité pour chaque méthode. Apprenez quand utiliser le simple NodePort pour les tests, le LoadBalancer dédié pour les services uniques, ou le puissant Ingress pour un routage L7 centralisé et rentable, ainsi que pour des environnements multi-services complexes.

33 vues

NodePort vs. LoadBalancer vs. Ingress : Choisir la meilleure exposition de service

Les services Kubernetes sont des objets fondamentaux qui fournissent une connectivité réseau stable à un ensemble dynamique de Pods. Bien que les services gèrent la communication interne du cluster, leur exposition externe – permettant aux utilisateurs ou aux applications externes d'interagir avec eux – nécessite une configuration spécifique. Le choix de la bonne méthode d'exposition est essentiel, car il a un impact sur la sécurité, le coût et la complexité.

Cet article propose une comparaison experte des trois principales méthodes d'exposition des services Kubernetes : NodePort, LoadBalancer et Ingress. Nous analyserons leurs mécanismes, leurs cas d'utilisation appropriés et les facteurs pratiques pour vous guider dans le choix de la solution optimale pour vos applications conteneurisées.

1. Type d'exposition de service : NodePort

Le type de service NodePort est la méthode la plus simple et la plus primitive pour exposer un service en externe. Lorsque vous définissez un service comme NodePort, Kubernetes ouvre un port statique spécifique sur chaque nœud du cluster. Tout trafic dirigé vers ce port sur n'importe quel nœud est acheminé directement vers le service.

Comment fonctionne NodePort

  1. Un port aléatoire dans une plage désignée (par défaut : 30000-32767) est sélectionné automatiquement.
  2. Ce port est ouvert sur tous les nœuds du cluster.
  3. Le service écoute sur ce NodePort, transférant le trafic vers les Pods appropriés.

Pour accéder à l'application, vous utilisez http://<IP_Nœud>:<NodePort>.

Cas d'utilisation et limitations

Caractéristique Description
Cas d'utilisation Environnements de développement, de test, ou lorsque l'équilibrage de charge externe est géré par un appareil externe non cloud.
Complexité Très faible.
Coût Zéro (si l'on ignore les coûts sous-jacents des machines virtuelles).
Limitation Nécessite la gestion manuelle des règles de pare-feu externes. Les adresses IP des nœuds sont souvent dynamiques. Restriction de la plage de ports (30000-32767).

Exemple de NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 8080
      # Optionnel : spécifier un NodePort, sinon un est choisi automatiquement
      # nodePort: 30001

⚠️ Avertissement : NodePort expose le service via tous les nœuds. Si un nœud est supprimé ou si son adresse IP change, l'accès externe est interrompu. Ceci n'est généralement pas recommandé pour les environnements de production qui dépendent de la stabilité.

2. Type d'exposition de service : LoadBalancer

Le type de service LoadBalancer est la méthode standard pour exposer les applications à l'Internet public dans les environnements cloud (AWS EKS, GCP GKE, Azure AKS).

Lorsqu'un service est défini comme LoadBalancer, Kubernetes provisionne automatiquement un équilibreur de charge cloud dédié de couche 4 (L4) (par exemple, AWS Classic ELB/NLB, Azure Load Balancer, GCP Network Load Balancer). Cela fournit une adresse IP externe stable et hautement disponible qui achemine le trafic directement vers les Pods du service.

Intégration avec le fournisseur de cloud

La principale caractéristique distinctive de LoadBalancer est son intégration profonde avec l'infrastructure cloud sous-jacente. Le fournisseur de cloud gère le cycle de vie de l'équilibreur de charge, les vérifications de santé et le routage.

Cas d'utilisation et implications financières

Caractéristique Description
Cas d'utilisation Applications simples et publiques nécessitant une adresse IP dédiée et stable. Adapté aux protocoles non HTTP/S (TCP/UDP).
Complexité Faible (en termes de configuration).
Coût Élevé. Chaque service LoadBalancer provisionne une ressource cloud dédiée, entraînant souvent des frais horaires.
Avantage Fournit une haute disponibilité immédiate et des vérifications de santé automatiques.

Exemple de LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-app-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: my-api-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Lors de la création, le cluster attribuera une adresse IP externe (visible dans le statut du service) gérée par le fournisseur de cloud.

3. Kubernetes Ingress : Routage de couche 7

Ingress est fondamentalement différent de NodePort et LoadBalancer. Ingress n'est pas un type de Service, mais plutôt un objet d'API qui définit les règles d'accès externe, généralement pour HTTP et HTTPS (couche 7).

Ingress agit comme un point d'entrée central, permettant un routage sophistiqué basé sur les noms d'hôte et les chemins d'URL. Cette approche est essentielle pour gérer plusieurs services derrière une seule adresse IP.

Le rôle du contrôleur Ingress

Pour que les règles Ingress fonctionnent, vous devez d'abord déployer un contrôleur Ingress (par exemple, Nginx, Traefik, Istio). Le contrôleur surveille les définitions de ressources Ingress et configure un proxy inverse / équilibreur de charge L7 sous-jacent en fonction de ces règles.

Crucialement, le contrôleur Ingress lui-même est généralement exposé à l'aide d'un seul service LoadBalancer ou NodePort.

Fonctionnalités avancées d'Ingress

Ingress excelle lorsque vous avez besoin de fonctionnalités de gestion de trafic avancées :

  1. Optimisation des coûts : Utilisez un seul LoadBalancer cloud (pour exposer le contrôleur) au lieu d'un LoadBalancer par service d'application.
  2. Hébergement virtuel : Routage du trafic basé sur les noms d'hôtes (api.example.com vers le Service A ; www.example.com vers le Service B).
  3. Routage basé sur les chemins : Routage du trafic basé sur les chemins d'URL (/v1/users vers le Service A ; /v2/posts vers le Service B).
  4. Terminaison SSL/TLS : Gestion centralisée des certificats et du déchiffrement.

Exemple de ressource Ingress

Cet exemple achemine le trafic pour api.example.com/v1 vers le service my-api-v1.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx # Spécifier le contrôleur utilisé
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api-v1
            port:
              number: 80
  # ... autres règles pour différents services/hôtes

4. Comparaison et guide de sélection

Choisir la méthode optimale implique de peser des facteurs tels que l'environnement, la complexité, l'ensemble des fonctionnalités et le coût opérationnel.

Tableau comparatif des fonctionnalités

Caractéristique NodePort LoadBalancer Ingress
Couche L4 (TCP/UDP) L4 (TCP/UDP) L7 (HTTP/S)
Stabilité (IP) Instable (utilise l'IP du nœud) Stable (IP Cloud dédiée) Stable (Utilise l'IP du contrôleur)
Coût Faible (coût opérationnel élevé) Élevé (coût des ressources par service) Modéré (un LoadBalancer pour le contrôleur)
Logique de routage Simple transfert de port Simple transfert de port Nom d'hôte, Chemin, Terminaison SSL
Dépendance Cloud Aucune Élevée Élevée (nécessite un contrôleur exposé par LoadBalancer)
Prêt pour la production Non Oui (Applications simples) Oui (Applications complexes)

Critères de décision : Choisir votre méthode d'exposition

  1. Pour un usage interne ou de test uniquement : Si vous avez simplement besoin de tester la connectivité au sein de votre cluster, ou si vous gérez vous-même le réseau externe (par exemple, dans un environnement bare-metal), utilisez NodePort.

  2. Pour une exposition L4 simple et dédiée : Si votre application utilise des protocoles non-HTTP (comme des protocoles TCP personnalisés ou UDP) ou si vous n'avez qu'une seule application publique nécessitant un accès L4 immédiat et dédié, utilisez LoadBalancer.

  3. Pour une exposition L7 complexe et multi-services : Si vous avez plusieurs services à exposer, que vous avez besoin d'un routage basé sur le chemin ou le nom d'hôte, que vous souhaitez une terminaison SSL centralisée ou que vous voulez minimiser les coûts cloud en partageant une seule adresse IP externe, utilisez Ingress.

Bonne pratique : Pour les déploiements en production dans des environnements cloud gérés, Ingress est généralement le choix privilégié. Il offre la sophistication nécessaire, la centralisation de la sécurité et l'efficacité des coûts pour gérer un nombre croissant de microservices.

Conclusion

Kubernetes offre un éventail de solutions pour l'exposition des services, allant du NodePort L4 de base, en passant par le LoadBalancer L4 intégré au cloud, jusqu'aux capacités de routage L7 sophistiquées d'Ingress. En comprenant la couche opérationnelle, le modèle de coûts et la logique de routage requise de chaque méthode, les ingénieurs peuvent concevoir des architectures réseau évolutives, sécurisées et rentables pour leurs charges de travail de production.