Maîtrisez les outils et bonnes pratiques DevOps - DevOps Knowledge Hub Maîtrisez les outils et bonnes pratiques DevOps - DevOps Knowledge Hub

Choisir le bon type de Service Kubernetes : ClusterIP vs NodePort vs LoadBalancer

Comparez ClusterIP, NodePort et LoadBalancer pour exposer vos applications Kubernetes avec le type de service approprié.

Choisir le bon type de service Kubernetes : ClusterIP vs NodePort vs LoadBalancer

Choisir le bon type de service Kubernetes détermine qui peut accéder à votre application et comment le trafic y parvient. Un mauvais choix peut rendre votre application inaccessible, trop exposée, ou adossée à des ressources cloud inutiles.

Ce guide propose une comparaison complète des trois types de services Kubernetes fondamentaux : ClusterIP, NodePort et LoadBalancer. En comprenant le cas d'usage, le mécanisme d'implémentation et les compromis associés à chaque type, vous pourrez prendre des décisions éclairées qui s'alignent parfaitement avec les besoins réseau de votre application, garantissant une gestion efficace de la communication interne et de l'accessibilité externe.

Comprendre les services Kubernetes

Avant de plonger dans les types spécifiques, il est crucial de rappeler le rôle d'un service Kubernetes. Les pods sont éphémères ; leurs adresses IP changent lorsqu'ils sont créés, détruits ou réaffectés. Un service fournit un point de terminaison stable (une adresse IP fixe et un nom DNS) pour un ensemble de pods dynamiques, permettant une communication fiable au sein du cluster.

Les services sont définis à l'aide d'un manifeste d'objet Service, spécifiant généralement un selector pour trouver les pods pertinents et un type pour définir comment ce service est exposé.

ClusterIP : Communication interne

ClusterIP est le type de service par défaut et le plus basique. Il expose le service sur une adresse IP interne au cluster. Ce service n'est accessible que depuis l'intérieur du cluster.

Cas d'usage pour ClusterIP

  • Services backend : Idéal pour les bases de données, les API internes, les couches de cache ou les microservices qui n'ont besoin de communiquer qu'avec d'autres services ou applications frontend s'exécutant dans le même cluster Kubernetes.
  • Découverte interne : Il exploite le DNS interne de Kubernetes pour fournir des noms de service de découverte stables (par exemple, ma-base-de-donnees.namespace.svc.cluster.local).

Détails d'implémentation

Lorsqu'un service ClusterIP est créé, Kubernetes lui attribue une adresse IP virtuelle qui n'est routable qu'à l'intérieur du réseau du cluster. Le trafic externe ne peut pas atteindre cette IP directement.

Exemple de manifeste (ClusterIP) :

apiVersion: v1
kind: Service
metadata:
  name: api-interne
spec:
  selector:
    app: service-backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Astuce : Si vous construisez un système distribué où tous les composants résident dans le cluster, ClusterIP est le choix le plus sécurisé et le plus efficace car il évite une exposition externe inutile.

NodePort : Exposer les services via les nœuds du cluster

NodePort est le moyen le plus simple d'exposer un service en externe. Il ouvre un port spécifique sur chaque nœud (VM ou machine physique) du cluster et achemine le trafic externe arrivant sur ce port vers le service.

Cas d'usage pour NodePort

  • Développement et tests : Utile pour tester rapidement des services accessibles de l'extérieur pendant le développement, lorsqu'une configuration complète d'équilibreur de charge cloud est excessive.
  • Environnements non cloud : Essentiel dans les installations Kubernetes sur site ou sur métal nu où les intégrations natives d'équilibrage de charge cloud ne sont pas disponibles.

Détails d'implémentation

Lorsqu'un service NodePort est créé, Kubernetes sélectionne un port statique dans la plage configurée (par défaut 30000–32767) sur chaque nœud. Le service expose l'application via :

http://<IP-du-Noeud>:<NodePort>

Si vous avez trois nœuds avec les IP 10.0.0.1, 10.0.0.2 et 10.0.0.3, et que le NodePort est 30080, vous pouvez accéder au service via n'importe laquelle de ces trois IP sur le port 30080.

Exemple de manifeste (NodePort) :

apiVersion: v1
kind: Service
metadata:
  name: app-web-test
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30080 # Optionnel : spécifier le port externe, sinon Kubernetes en choisit un
  type: NodePort

Attention : Comme le service est exposé sur chaque nœud, votre couche de routage externe doit toujours éviter les nœuds défaillants. La plage de NodePort par défaut est 30000-32767, bien que les administrateurs du cluster puissent configurer une plage différente.

LoadBalancer : Exposition externe native cloud

LoadBalancer expose un service via un équilibreur de charge externe lorsque votre cluster dispose d'une intégration capable d'en provisionner un. C'est courant sur les plateformes Kubernetes cloud gérées. Dans de nombreuses configurations de production, vous pouvez également placer un Ingress ou une Gateway devant plusieurs services internes au lieu de créer un équilibreur de charge par application.

Cas d'usage pour LoadBalancer

  • Déploiements en production : Fournit un accès externe robuste et hautement disponible qui s'intègre parfaitement à l'infrastructure du fournisseur cloud.
  • Gestion automatique des IP : Il abstrait la nécessité de connaître les IP individuelles des nœuds ou de gérer les conflits de ports.

Détails d'implémentation

Lorsqu'un service de type LoadBalancer est créé dans un environnement pris en charge, le gestionnaire de contrôle cloud ou le contrôleur d'équilibreur de charge provisionne un équilibreur de charge externe et le configure pour acheminer le trafic vers le service.

L'adresse externe est attribuée par le fournisseur. Elle peut être stable pour la durée de vie du service, mais ce n'est pas toujours une IP statique réservée, sauf si vous la configurez via des paramètres spécifiques au fournisseur.

Exemple de manifeste (LoadBalancer) :

apiVersion: v1
kind: Service
metadata:
  name: service-web-public
spec:
  selector:
    app: public-facing
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Lorsque cela est créé, la sortie (en utilisant kubectl get svc) montrera une IP externe attribuée :

NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
service-web-public    LoadBalancer   10.96.45.11   34.120.200.55    80:30021/TCP   1m

L'application est désormais accessible via http://34.120.200.55.

Meilleure pratique : Pour HTTPS, utilisez le modèle que votre plateforme supporte le mieux : annotations d'équilibreur de charge cloud, un contrôleur Ingress ou l'API Gateway Kubernetes. Gardez la configuration TLS dans une couche bien maîtrisée plutôt que de la répartir sur chaque Pod.

Tableau comparatif récapitulatif

Fonctionnalité ClusterIP NodePort LoadBalancer
Utilisation principale Communication interne des services Accès externe simple (Tests/Métal nu) Production, accès externe natif cloud
Accessibilité Uniquement dans le cluster Chaque nœud sur un port statique (30000-32767) IP externe gérée par le fournisseur cloud
Stabilité IP IP interne stable IP de nœud stable, mais nécessite de connaître le port IP externe stable (selon le fournisseur)
Dépendance cloud Aucune Aucune Nécessite une intégration d'équilibreur de charge
Coût Pas d'équilibreur de charge externe Utilise les ressources du nœud Généralement facturé comme ressources d'équilibreur de charge externes
Complexité de configuration La plus faible Faible Modérée (nécessite une configuration cloud)

À retenir

Sélectionner le type de service correct est une étape fondamentale dans la mise en réseau Kubernetes :

  1. Commencez par l'interne (ClusterIP) : Si votre service n'a jamais besoin d'être accessible depuis l'extérieur du cluster, utilisez toujours ClusterIP. Cela minimise la surface d'attaque et la surcharge.
  2. Test/Métal nu (NodePort) : Si vous avez besoin de tests externes de base ou si vous exécutez Kubernetes en dehors d'un environnement cloud majeur, NodePort fournit un accès externe immédiat, bien que moins robuste.
  3. Production cloud (LoadBalancer) : Pour toute application de production hébergée sur AWS, GCP ou Azure nécessitant un point d'entrée externe durable, stable et dédié, LoadBalancer est le choix correct, exploitant l'infrastructure cloud pour la résilience.

En alignant le type de service sur l'accessibilité requise et l'environnement de déploiement, vous garantissez des performances, une sécurité et une intégration optimales au sein de votre architecture d'orchestration de conteneurs.