Load balancing Kubernetes : 5 approches techniques, exemples à l'appui

Qu'est-ce que le load balancing Kubernetes ?

Le load balancing Kubernetes est le processus automatisé de répartition du trafic réseau entre plusieurs Pods afin de garantir haute disponibilité, scalabilité et performances optimales. Il opère à deux niveaux principaux : la gestion interne au sein du cluster et l'exposition externe pour les utilisateurs extérieurs.

En masquant la complexité du routage et de la distribution des requêtes, Kubernetes permet aux développeurs de déployer des applications scalables sans gérer manuellement la répartition du trafic. Cette automatisation est essentielle pour la haute disponibilité, la tolérance aux pannes et les performances des environnements conteneurisés modernes.

Options techniques pour mettre en œuvre le load balancing dans Kubernetes :

• ClusterIP (interne) : utilise une IP virtuelle pour répartir le trafic entre les Pods à l'intérieur du cluster, ce qui en fait l'option par défaut pour la communication interne de service à service.
• NodePort : expose un Service sur un port statique sur chaque nœud du cluster, permettant aux clients externes d'accéder aux applications via <NodeIP>:<NodePort>.
• LoadBalancer : s'intègre aux load balancers du cloud ou de l'infrastructure pour fournir une adresse IP externe qui répartit le trafic entre les nœuds du cluster et les Pods back-end.
• Ingress : fournit un routage HTTP/HTTPS de couche 7, permettant à plusieurs Services de partager un point de terminaison externe unique avec des règles de routage basées sur l'hôte et le chemin.
• Gateway API : utilise des ressources dédiées Gateway et Route pour offrir une gestion avancée du trafic pilotée par des politiques, avec prise en charge de plusieurs protocoles et séparation entre équipes.

Cet article fait partie d'une série consacrée au scheduling Kubernetes.

Pourquoi le load balancing est indispensable dans Kubernetes

Les environnements Kubernetes sont dynamiques. Les pods peuvent être créés, arrêtés, replanifiés ou mis à l'échelle à tout moment en fonction de la demande applicative ou de l'état du cluster. Sans load balancing, le trafic pourrait continuer à affluer vers des pods surchargés ou indisponibles, entraînant des réponses lentes, des requêtes en échec ou des interruptions de service.

Le load balancing aide Kubernetes à maintenir des performances et une disponibilité applicatives constantes. Il répartit les requêtes entre les pods sains et redirige le trafic en cas de défaillance. Les applications peuvent ainsi continuer à servir les utilisateurs pendant les crashs de pods, les rolling updates ou les changements d'infrastructure.

Les principales raisons pour lesquelles le load balancing est indispensable dans Kubernetes :

• Éviter la surcharge de trafic sur un seul pod ou nœud
• Soutenir la mise à l'échelle horizontale en répartissant les requêtes entre les réplicas
• Maintenir une haute disponibilité en cas de défaillance d'un pod ou d'un nœud
• Permettre des déploiements sans interruption et des rolling updates
• Améliorer les temps de réponse et la fiabilité des applications
• Simplifier le routage du trafic dans des environnements de conteneurs dynamiques
• Permettre aux services de monter en charge automatiquement selon l'évolution du trafic

Comme les conteneurs sont éphémères et que les workloads évoluent en permanence, le load balancing automatisé est une exigence fondamentale pour un fonctionnement stable de Kubernetes.

5 méthodes pour mettre en œuvre le load balancing dans Kubernetes

1. ClusterIP (interne)

ClusterIP est le type de Service Kubernetes par défaut. Il crée une adresse IP virtuelle accessible uniquement depuis l'intérieur du cluster, ce qui le rend adapté à la communication entre services internes comme les workloads front-end, API et bases de données. Les clients externes ne peuvent pas accéder directement à un service ClusterIP, ce qui contribue à isoler les services back-end des réseaux publics.

Lorsqu'une requête est envoyée à l'adresse ClusterIP, kube-proxy intercepte le trafic et le transmet à l'un des Pods sains derrière le Service. Il met automatiquement à jour les règles de routage à mesure que des Pods sont ajoutés, supprimés ou remplacés, garantissant la répartition des requêtes entre les réplicas disponibles sans que les applications aient à suivre les adresses IP des Pods.

La décision de load balancing repose généralement sur iptables, IPVS ou des implémentations réseau basées sur eBPF, selon la configuration du cluster. Les applications communiquent avec un point de terminaison de Service stable tandis que Kubernetes gère les changements des Pods sous-jacents, faisant de ClusterIP la fondation de la plupart des communications internes de service à service.

2. NodePort

Un Service NodePort expose une application sur un port statique sur chaque nœud du cluster Kubernetes. Les clients peuvent accéder à l'application en envoyant des requêtes à <NodeIP>:<NodePort>, ce qui permet au trafic externe d'atteindre les workloads sans nécessiter de load balancer cloud dédié.

Une fois le trafic arrivé sur un nœud, kube-proxy achemine la requête vers l'un des Pods sélectionnés par le Service, même si ce Pod s'exécute sur un autre nœud. Kubernetes continue de répartir les requêtes entre les Pods sains à mesure que le nombre de réplicas évolue, tandis que le NodePort reste constant.

Comme chaque nœud écoute sur le même port, les utilisateurs peuvent se connecter à n'importe quel nœud du cluster pour atteindre l'application. NodePort est couramment utilisé dans les environnements de développement, les clusters on-premises ou comme fondation de services de plus haut niveau tels que LoadBalancer, même si l'exposition directe d'applications via des NodePorts est moins fréquente en production.

3. LoadBalancer

Un Service LoadBalancer s'appuie sur NodePort en intégrant Kubernetes à un load balancer externe fourni par une plateforme cloud ou une infrastructure compatible. Il provisionne une adresse IP publique ou privée que les clients utilisent pour accéder à l'application sans se connecter directement aux nœuds du cluster.

Le load balancer externe répartit les connexions entrantes entre les nœuds du cluster. Les requêtes sont ensuite transmises via le Service NodePort correspondant, où kube-proxy sélectionne un Pod back-end sain. On obtient ainsi un load balancing au niveau de l'infrastructure entre les nœuds et au niveau de Kubernetes entre les Pods.

La plupart des services Kubernetes managés provisionnent automatiquement des load balancers cloud-native auprès de fournisseurs comme AWS, Azure ou Google Cloud lors de la création de ce type de Service. Les contrôles de santé garantissent que le trafic n'est envoyé qu'aux nœuds sains, tandis que Kubernetes met continuellement à jour les points de terminaison back-end à mesure que les Pods sont mis à l'échelle ou remplacés.

4. Ingress

Ingress fournit un routage de couche 7 (HTTP/HTTPS) pour plusieurs applications via un point d'entrée unique. Au lieu d'exposer chaque Service avec sa propre adresse IP externe, une ressource Ingress définit des règles de routage basées sur les noms d'hôte, les chemins d'URL ou d'autres attributs HTTP. Un contrôleur Ingress, tel que Traefik, met en œuvre ces règles.

Lorsqu'un client envoie une requête HTTP ou HTTPS, le contrôleur Ingress évalue les règles de routage et transmet la requête au Service Kubernetes approprié. Le Service répartit ensuite le trafic entre ses Pods back-end. Cette approche simplifie l'exposition des applications tout en prenant en charge des fonctionnalités telles que la terminaison TLS, les redirections, l'authentification et la réécriture des requêtes.

Comme plusieurs Services peuvent partager le même point de terminaison externe, Ingress réduit le nombre d'adresses IP publiques et de load balancers nécessaires. Il est couramment utilisé pour exposer des applications web, des API et des microservices, tout en offrant une gestion centralisée du trafic HTTP et HTTPS.

5. Gateway API

Gateway API est un standard réseau Kubernetes plus récent qui offre une manière plus flexible et extensible de gérer le trafic applicatif. Il sépare la configuration de l'infrastructure du routage applicatif, permettant aux équipes plateforme de gérer les gateways tandis que les équipes applicatives définissent comment leurs services reçoivent le trafic.

Le trafic entre d'abord dans une Gateway, qui représente le point d'entrée réseau. Les ressources de routage, comme HTTPRoute, précisent comment les requêtes doivent être identifiées et transmises aux Services Kubernetes. Une fois qu'une requête atteint le Service sélectionné, Kubernetes la répartit entre les Pods disponibles à l'aide de ses mécanismes de load balancing standard.

Par rapport à Ingress, Gateway API offre un contrôle plus granulaire des politiques de routage, de la répartition du trafic et des environnements multi-tenant. Il prend également en charge plusieurs protocoles au-delà de HTTP, notamment TCP et gRPC, ce qui en fait un meilleur choix pour les besoins réseau complexes et les déploiements Kubernetes à grande échelle.

LoadBalancer, Ingress et API Gateway dans Kubernetes : quelles différences ?

Le tableau suivant résume les différences entre ces options :

Cas d'usage du load balancing Kubernetes

Load balancing interne de service à service

Le load balancing interne de service à service répartit le trafic entre les applications s'exécutant au sein d'un même cluster Kubernetes. Il permet aux services de communiquer via des points de terminaison stables tandis que Kubernetes achemine automatiquement les requêtes vers les pods disponibles. Cette approche aide à maintenir performances et disponibilité lorsque les workloads montent en charge ou que des pods sont remplacés.

Technologies concernées : Service Kubernetes (ClusterIP), kube-proxy, réseau basé sur eBPF, service mesh, découverte de services basée sur DNS.

Load balancing externe

Le load balancing externe gère le trafic entrant dans le cluster en provenance d'utilisateurs, d'applications ou de systèmes externes. Il fournit un point d'entrée public et répartit les requêtes entrantes entre les services back-end sains. Les applications peuvent ainsi absorber des volumes de trafic plus élevés tout en restant disponibles pendant les pannes, les opérations de maintenance ou les mises à l'échelle.

Technologies concernées : Service LoadBalancer, load balancers de couche 4, Ingress, Gateway API, terminaison TLS.

Gestion du trafic nord-sud

La gestion du trafic nord-sud traite le trafic circulant entre les clients externes et les workloads s'exécutant dans le cluster. Elle est couramment utilisée pour les applications exposées au public, les API et les intégrations partenaires. Au-delà du load balancing, elle inclut souvent le routage, l'application de règles de sécurité, le filtrage du trafic et le chiffrement pour contrôler la manière dont les requêtes externes accèdent aux services internes.

Technologies concernées : Ingress, Gateway API, routage de couche 7, terminaison TLS, politiques d'authentification et d'autorisation, intégration de pare-feu applicatif web.

Gestion du trafic est-ouest

La gestion du trafic est-ouest se concentre sur la communication entre les services au sein du cluster ou entre des environnements Kubernetes connectés. Dans les architectures de microservices, les applications échangent fréquemment des requêtes en interne, rendant une répartition efficace du trafic critique pour les performances et la fiabilité. Ce type de load balancing prend également en charge l'observabilité, les politiques de sécurité et le contrôle du trafic entre services.

Technologies concernées : Service Kubernetes, kube-proxy, service mesh, réseau basé sur eBPF, mTLS, politiques de trafic, découverte de services.

Load balancing multi-cluster et global

Le load balancing multi-cluster et global répartit le trafic entre plusieurs clusters Kubernetes situés dans différentes régions, zones de disponibilité, fournisseurs cloud ou centres de données. Il améliore la résilience en évitant qu'un cluster unique ne devienne un point de défaillance et peut réduire la latence en dirigeant les utilisateurs vers la localisation la plus adaptée. Il est couramment utilisé pour la reprise après sinistre, les applications mondiales et les déploiements à grande échelle.

Technologies concernées : Gateway API, load balancing global, routage du trafic basé sur DNS, réseau multi-cluster, service mesh, basculement du trafic, géo-routage.

Exemples de load balancing Kubernetes

Les exemples de cette section sont adaptés de la documentation Kubernetes.

Exemple de Service Kubernetes

Le Deployment suivant crée trois réplicas d'une application NGINX. Chaque Pod porte le label app: nginx, ce qui permet à un Service Kubernetes de sélectionner les Pods et de leur envoyer du trafic.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

Ce Deployment maintient trois Pods NGINX en fonctionnement. Si un Pod est supprimé ou tombe en panne, le ReplicaSet du Deployment crée un Pod de remplacement. La readiness probe aide Kubernetes à déterminer quand chaque Pod est prêt à recevoir du trafic via un Service.

Exemple de Service ClusterIP

Le Service ClusterIP suivant expose le Deployment NGINX à l'intérieur du cluster. Le Service sélectionne les Pods portant le label app: nginx et transmet le trafic du port 80 du Service vers le port 80 des Pods sélectionnés.

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Ce Service est accessible depuis l'intérieur du cluster. Les autres Pods peuvent s'y connecter via le nom de Service nginx-clusterip, à condition que le DNS du cluster soit disponible.

Exemple de Service LoadBalancer

Le Service suivant expose les mêmes Pods NGINX en externe, en s'appuyant sur un fournisseur cloud ou tout autre environnement prenant en charge les load balancers externes.

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

Lorsque ce Service est créé dans un environnement compatible, Kubernetes provisionne ou configure un load balancer externe et enregistre l'adresse externe dans le statut du Service. Le trafic envoyé à l'adresse externe est transmis au Service, puis aux Pods back-end correspondants.

Exemple d'Ingress

L'Ingress suivant achemine le trafic HTTP de example.com vers le Service interne nginx-clusterip.

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

Cet Ingress définit des règles de routage HTTP, mais ne fonctionne que si un contrôleur Ingress s'exécute dans le cluster. Le contrôleur Ingress met en œuvre le comportement de routage et transmet les requêtes correspondantes au Service back-end.

Exemple d'API Gateway

L'exemple suivant utilise la Gateway API de Kubernetes pour acheminer le trafic HTTP via une Gateway vers le Service interne nginx-clusterip. Gateway API est une famille d'API réseau Kubernetes dédiée au provisionnement dynamique d'infrastructure et au routage avancé du trafic ; les ressources HTTPRoute peuvent identifier les requêtes HTTP et les transmettre aux Services Kubernetes.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: api.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-api-route
spec:
  parentRefs:
    - name: nginx-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: nginx-clusterip
          port: 80

Dans cet exemple, la Gateway représente le point d'entrée de l'API gateway, tandis que la HTTPRoute définit comment les requêtes HTTP doivent être acheminées. Les requêtes envoyées à api.example.com/api sont acceptées par le listener de la Gateway, identifiées par la route, puis transmises au Service nginx-clusterip. Le Service répartit ensuite le trafic entre les Pods NGINX correspondants.

Remarque : cet exemple utilise NGINX Gateway Fabric comme implémentation de gateway class, à distinguer du contrôleur Ingress NGINX maintenu par la communauté.

Cette approche est similaire à Ingress, mais Gateway API propose un modèle plus expressif et orienté rôles. Les équipes infrastructure peuvent gérer les ressources Gateway, tandis que les équipes applicatives gèrent les ressources de routage comme HTTPRoute. Ce modèle est utile pour les patterns d'API gateway nécessitant un routage basé sur le nom d'hôte, un routage basé sur le chemin, un contrôle des politiques de trafic et une séparation plus nette entre configuration de la plateforme et routage applicatif.