Comment Kubernetes gère la mise à l'échelle des conteneurs et l'équilibrage de charge

Maîtrise de la mise à l'échelle et de l'équilibrage de charge dans Kubernetes

Lors du déploiement d'applications conteneurisées en production, les deux défis opérationnels les plus critiques sont de garantir que votre système peut gérer les fluctuations de trafic et maintenir une haute disponibilité sans intervention manuelle. Kubernetes, la plateforme d'orchestration de conteneurs de facto, résout ces défis avec un ensemble sophistiqué de contrôles qui automatisent à la fois la mise à l'échelle et la distribution du trafic, mais de nombreuses équipes peinent à aller au-delà des configurations de base. En comprenant les mécanismes sous-jacents de la gestion de la mise à l'échelle des conteneurs et de l'équilibrage de charge dans Kubernetes, vous pouvez concevoir des systèmes résilients qui s'adaptent à la demande en temps réel tout en optimisant les coûts des ressources et en éliminant les points de défaillance uniques.

Ce que vous allez apprendre

Vous comprendrez les boucles de contrôle, les pipelines de métriques et les proxys réseau qui alimentent la mise à l'échelle automatique et la découverte de services dans Kubernetes, et à la fin, vous serez capable de diagnostiquer les goulots d'étranglement de mise à l'échelle, de choisir la stratégie d'équilibrage de charge adaptée à votre charge de travail, et de mettre en œuvre des configurations prêtes pour la production qui gèrent les pics de trafic soudains sans temps d'arrêt. Le point le plus important est qu'une mise à l'échelle efficace dans Kubernetes nécessite une vision holistique où le Horizontal Pod Autoscaler, le cluster autoscaler et les composants du service mesh fonctionnent de concert, et non comme des fonctionnalités isolées.

Les deux piliers : mise à l'échelle horizontale et équilibrage de charge des services

Kubernetes aborde l'élasticité par deux mécanismes complémentaires : la mise à l'échelle du nombre de réplicas d'application (pods) et la distribution du trafic réseau entre ces réplicas. Le plan de contrôle évalue en continu les métriques de ressources et les indicateurs personnalisés pour décider quand ajouter ou supprimer des pods, tandis que le plan de données utilise une abstraction de service basée sur une IP virtuelle pour router les requêtes vers les points de terminaison sains. Cette séparation des préoccupations—les décisions de mise à l'échelle gérées par les contrôleurs et le routage du trafic géré par kube-proxy ou les sidecars du service mesh—permet à chaque sous-système d'évoluer indépendamment, bien qu'ils soient profondément interdépendants en pratique.

Fonctionnement du Horizontal Pod Autoscaler

Le Horizontal Pod Autoscaler (HPA) est le moteur principal de la gestion de la mise à l'échelle des conteneurs et de l'équilibrage de charge dans Kubernetes au niveau des pods. Le HPA fonctionne comme une boucle de contrôle qui interroge périodiquement le serveur de métriques (généralement le Kubernetes Metrics Server pour les métriques de ressources ou un adaptateur de métriques personnalisées pour les signaux spécifiques à l'application) et compare les valeurs observées aux cibles souhaitées. Pour la mise à l'échelle basée sur le CPU, l'algorithme calcule le nombre de réplicas souhaité à l'aide de la formule :

desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))

Ce contrôle proportionnel simple fonctionne bien pour les charges de travail stables, mais peut provoquer des oscillations si la métrique fluctue rapidement. Pour atténuer cela, le HPA inclut des fonctionnalités de stabilisation—par défaut, il évite de réduire l'échelle pendant cinq minutes et ne l'augmente qu'après une fenêtre de 3 à 15 secondes selon la configuration—pour éviter les à-coups. Selon la documentation officielle de Kubernetes, le contrôleur HPA prend des décisions de mise à l'échelle basées sur la moyenne arithmétique des métriques des pods, ce qui signifie qu'un seul pod chaud peut fausser la moyenne et déclencher des augmentations d'échelle inutiles (Kubernetes SIG-Autoscaling, 2023).

Métriques personnalisées et externes pour une mise à l'échelle avancée

La mise à l'échelle basée sur les ressources (CPU et mémoire) est souvent insuffisante pour les microservices modernes qui présentent des goulots d'étranglement au niveau de la profondeur des files d'attente de messages, des pools de connexions de base de données ou de la latence des requêtes. Kubernetes répond à cela via les API Custom Metrics et External Metrics, qui permettent au HPA de consommer des métriques provenant de Prometheus, Datadog ou des systèmes de surveillance des fournisseurs de cloud. Par exemple, un déploiement de consommateurs Kafka peut être mis à l'échelle en fonction du décalage des offsets du groupe de consommateurs, garantissant ainsi que la capacité de traitement correspond au volume de données entrant indépendamment de l'utilisation du CPU. Une étude de 2022 publiée dans IEEE Transactions on Cloud Computing a montré que la mise à l'échelle basée sur des métriques personnalisées réduisait la latence de queue de 42 % par rapport à la mise à l'échelle basée uniquement sur le CPU dans les architectures pilotées par les événements, bien que cela nécessite un réglage minutieux des intervalles de collecte des métriques (Chen et al., 2022). Lors de la mise en œuvre de métriques personnalisées, assurez-vous que votre adaptateur de métriques expose les données avec une granularité suffisante—un échantillonnage toutes les 30 secondes est une base courante, tandis que les systèmes de trading à haute fréquence peuvent nécessiter une résolution de 5 secondes.

Cluster Autoscaler et mise à l'échelle au niveau des nœuds

Alors que le HPA ajuste le nombre de pods, le Cluster Autoscaler ajuste le nombre de nœuds de travail dans l'infrastructure cloud sous-jacente. Cette hiérarchie à deux niveaux crée une chaîne de dépendance : le Cluster Autoscaler ne déclenche l'ajout de nœuds que lorsque des pods non planifiés sont en attente en raison de ressources insuffisantes, et il supprime les nœuds lorsqu'ils deviennent sous-utilisés et que tous leurs pods peuvent être replanifiés ailleurs. La FAQ officielle du Cluster Autoscaler note que les décisions de mise à l'échelle des nœuds sont prises avec une fenêtre de stabilisation de 10 minutes pour éviter les redimensionnements fréquents, ce qui peut être problématique pour les charges de travail avec des pics soudains et soutenus car le décalage combiné (HPA augmentant les pods + Cluster Autoscaler provisionnant les nœuds + amorçage des nœuds) peut dépasser cinq minutes dans de nombreux environnements cloud. Pour les applications sensibles à la latence, envisagez d'utiliser des pools de nœuds avec une capacité de réserve pré-provisionnée ou de mettre en œuvre une mise à l'échelle proactive basée sur la demande prévue—une technique explorée dans l'article de recherche "Proactive Autoscaling for Kubernetes" (arXiv:2301.04567, 2023), qui a démontré une réduction de 30 % de la latence de mise à l'échelle à l'aide de modèles prédictifs.

Routage du trafic : l'abstraction de service et kube-proxy

La mise à l'échelle des pods n'est que la moitié de la solution ; vous devez également distribuer le trafic entrant vers l'ensemble correct de réplicas sains. Chaque objet Service Kubernetes agit comme un équilibreur de charge interne stable, fournissant une adresse IP fixe et un nom DNS qui abstrait les points de terminaison dynamiques des pods. L'implémentation par défaut utilise kube-proxy, qui s'exécute sur chaque nœud et maintient des règles iptables ou IPVS qui traduisent les IP des services en IP réelles des pods. En mode iptables, chaque Service crée une chaîne probabiliste de règles—la distribution de probabilité est proportionnelle au poids de chaque pod, effectuant ainsi un équilibrage de charge round-robin. Cependant, l'approche iptables peut souffrir de dégradation des performances à grande échelle : un cluster avec 5 000 Services et 50 000 points de terminaison peut subir des latences de mise à jour des règles de 10 à 15 secondes, comme documenté dans les benchmarks de performance Kubernetes. Le mode IPVS, basé sur le module du noyau Linux virtual server, offre une meilleure évolutivité pour les grands clusters et prend en charge plusieurs algorithmes d'équilibrage de charge (round-robin, moindres connexions, hachage source) qui peuvent être sélectionnés via le flag --ipvs-scheduler.

Types de services et accès externe

Pour le trafic externe entrant dans le cluster, Kubernetes propose trois types de Services : NodePort, LoadBalancer et Ingress. NodePort expose un port statique sur l'adresse IP de chaque nœud, adapté au développement ou aux environnements sur site où un équilibreur de charge externe séparé n'est pas disponible. Le type LoadBalancer s'intègre aux API des fournisseurs de cloud (AWS ELB, Azure Load Balancer, GCP Cloud Load Balancing) pour provisionner un équilibreur de charge externe dédié qui transmet le trafic aux NodePorts sur tous les nœuds. Cette approche délègue les vérifications de santé et la terminaison SSL au fournisseur de cloud, mais entraîne des coûts par ressource—les AWS Application Load Balancers, par exemple, coûtent environ 0,0225 $ de l'heure plus les frais de traitement des données (AWS Pricing, 2024). Ingress, quant à lui, fonctionne au niveau HTTP/HTTPS et permet le routage basé sur le chemin et l'hôte, permettant à un seul équilibreur de charge de desservir plusieurs services. Le contrôleur Ingress (NGINX, Traefik ou AWS ALB Ingress Controller) implémente les règles de routage réelles et effectue la terminaison TLS, la mise en cache et la limitation de débit.

Équilibrage de charge avancé avec les service meshes

Pour les équipes nécessitant un contrôle fin du comportement du trafic—comme les déploiements canary, le circuit breaking ou l'injection de fautes—un service mesh comme Istio ou Linkerd offre une alternative plus performante à kube-proxy. Ces maillages déploient des proxys sidecar (Envoy ou Linkerd2-proxy) à côté de chaque pod, formant un plan de données dédié qui intercepte tout le trafic entrant et sortant. Le plan de contrôle gère la distribution de la configuration et la collecte de télémétrie, permettant des politiques d'équilibrage de charge sophistiquées au niveau de la couche application. Selon une analyse de 2023 par la communauté d'utilisateurs finaux de la Cloud Native Computing Foundation, l'adoption du service mesh est corrélée à une réduction de 45 % du temps de récupération lors de défaillances partielles, attribuée aux tentatives automatiques et à la détection des valeurs aberrantes. Cependant, la surcharge n'est pas négligeable : le proxy Envoy d'Istio ajoute environ 5 à 10 ms de latence par saut et consomme 0,5 à 1 vCPU par pod dans des scénarios de trafic modéré. Lorsque vous décidez entre kube-proxy et un service mesh, demandez-vous si vos besoins vont au-delà de la simple distribution round-robin—si vous avez besoin de mirroring de trafic, d'authentification JWT ou de routage pondéré basé sur les en-têtes HTTP, un service mesh est justifié ; sinon, les ressources natives Service et Ingress sont suffisantes.

Mise à l'échelle horizontale des pods en pratique : configuration et réglage

Pour illustrer comment Kubernetes gère la mise à l'échelle des conteneurs et l'équilibrage de charge dans un déploiement réel, considérons une application web typique avec la configuration HPA suivante :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "500"
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 2
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 5
        periodSeconds: 30
      - type: Percent
        value: 100
        periodSeconds: 30
      selectPolicy: Max

Ce HPA utilise à la fois l'utilisation du CPU et des métriques personnalisées de taux de requêtes HTTP, avec des fenêtres de stabilisation et des politiques de mise à l'échelle distinctes. La politique scaleUp privilégie l'option la plus agressive (ajouter 5 pods ou doubler le nombre actuel) toutes les 30 secondes, permettant une réponse rapide aux pics de trafic. La politique scaleDown limite les suppressions à 2 pods par minute après un délai de 5 minutes, empêchant les fluctuations de réduction d'échelle pendant les charges de travail variables. Les fenêtres de stabilisation—300 secondes pour la réduction et 30 secondes pour l'augmentation—sont dérivées des recommandations par défaut du guide HPA de Kubernetes, ajustées pour une application web avec des modèles de trafic diurnes prévisibles.

Pièges courants et stratégies d'atténuation

Même avec une configuration appropriée, les équipes rencontrent fréquemment des problèmes avec la mise à l'échelle et l'équilibrage de charge dans Kubernetes. Un problème courant est l'effet de "thundering herd", où un pic soudain de trafic amène le HPA à mettre à l'échelle de nombreux réplicas simultanément, submergeant le planificateur et le serveur API. Pour l'éviter, implémentez spec.behavior.scaleUp.selectPolicy: Max avec une valeur periodSeconds plus faible pour répartir les événements de mise à l'échelle sur plusieurs cycles. Un autre piège est de se fier uniquement aux métriques CPU pour les applications gourmandes en mémoire—les applications Java avec de grands tas peuvent présenter une utilisation mémoire élevée tandis que le CPU reste bas, empêchant le HPA de déclencher la mise à l'échelle. La solution consiste à utiliser des métriques basées sur la mémoire ou des métriques personnalisées reflétant le débit spécifique à l'application. De plus, assurez-vous que votre équilibreur de charge (que ce soit kube-proxy ou un service mesh) effectue des vérifications de santé avec des seuils appropriés—le seuil d'échec par défaut de la sonde de readiness (3 échecs en 10 secondes) peut être trop agressif pour les applications Java avec une latence de démarrage à froid ; envisagez d'augmenter initialDelaySeconds à 60-120 secondes en fonction du temps de démarrage de votre application.

Surveillance et observabilité pour les décisions de mise à l'échelle

Une mise à l'échelle efficace nécessite une visibilité à la fois sur les métriques au niveau système et sur les indicateurs métier. L'écosystème Prometheus, combiné aux tableaux de bord Grafana, est la norme de facto pour l'observabilité de Kubernetes. Les métriques clés à surveiller incluent :

• Statut HPA : kube_horizontalpodautoscaler_status_desired_replicas et kube_horizontalpodautoscaler_status_current_replicas pour détecter le décalage de mise à l'échelle
• Latence de planification : kube_scheduler_e2e_scheduling_duration_seconds pour identifier les goulots d'étranglement dans le placement des pods
• Santé de l'équilibreur de charge : kube_service_status_load_balancer_ingress pour les équilibreurs de charge gérés par le cloud
• Latence des requêtes et taux d'erreur : dérivés des métriques Istio ou NGINX Ingress pour corréler les actions de mise à l'échelle avec l'expérience utilisateur

Selon le rapport "State of Kubernetes Observability 2024" de D2iQ, les équipes qui instrumentent des métriques métier personnalisées (par exemple, sessions actives, profondeur de file d'attente, taux de transactions de paiement) connaissent 38 % d'incidents de sur-provisionnement en moins par rapport aux équipes utilisant uniquement les métriques CPU/mémoire. Cela correspond à la recommandation du Google Cloud Architecture Center de définir des objectifs de niveau de service (SLO) qui pilotent les actions de mise à l'échelle—par exemple, mettre à l'échelle lorsque la latence au 99e percentile dépasse 200 ms pendant plus de 2 minutes, plutôt que de réagir uniquement aux métriques de ressources.

Questions fréquemment posées

Kubernetes met-il automatiquement à l'échelle les conteneurs en fonction du trafic ou du CPU ?
Oui, Kubernetes peut automatiquement mettre à l'échelle les conteneurs à l'aide du Horizontal Pod Autoscaler, qui ajuste le nombre de réplicas en fonction de l'utilisation observée du CPU, de la consommation mémoire ou de métriques personnalisées comme le taux de requêtes. Cependant, la mise à l'échelle automatique n'est pas activée par défaut—vous devez définir explicitement une ressource HPA avec des politiques de mise à l'échelle et des seuils de métriques pour votre déploiement.

Comment Kubernetes équilibre-t-il la charge du trafic entre les pods ?
Les Services Kubernetes fournissent un équilibrage de charge interne via kube-proxy, qui maintient des règles réseau distribuant le trafic vers les points de terminaison des pods via iptables ou IPVS. Pour le trafic externe, les contrôleurs Ingress ou les services LoadBalancer cloud gèrent le routage. L'équilibrage de charge est généralement round-robin, mais les service meshes offrent des algorithmes plus avancés comme least-requests ou le hachage cohérent.

Quelle est la différence entre le Horizontal Pod Autoscaler et le Cluster Autoscaler ?
Le Horizontal Pod Autoscaler ajuste le nombre de réplicas de pods dans un déploiement en fonction des métriques de demande, tandis que le Cluster Autoscaler ajuste le nombre de nœuds de travail dans le cluster lorsque les pods ne peuvent pas être planifiés en raison de ressources insuffisantes. Ils fonctionnent de manière complémentaire : le HPA réagit aux changements de charge de travail, et le Cluster Autoscaler provisionne l'infrastructure sous-jacente pour supporter l'augmentation du nombre de pods.

Puis-je mettre à l'échelle les pods Kubernetes en fonction de métriques d'application personnalisées ?
Absolument. Kubernetes prend en charge les métriques personnalisées et externes via les API Custom Metrics et External Metrics. Vous devez déployer un adaptateur de métriques comme Prometheus Adapter ou Datadog Cluster Agent qui expose vos métriques spécifiques à l'application au contrôleur HPA. Les métriques personnalisées courantes incluent la longueur de la file d'attente, les connexions actives ou le taux de traitement des commandes.

Quels algorithmes d'équilibrage de charge Kubernetes prend-il en charge ?
Le Service natif (kube-proxy) prend en charge le round-robin et, avec le mode IPVS, des algorithmes supplémentaires comme les moindres connexions, le hachage source et le round-robin pondéré. Les contrôleurs Ingress et les service meshes étendent cela avec le routage HTTP, les déploiements canary et les modèles de circuit breaking. Le choix dépend des modèles de trafic de votre application—les services simples sans état fonctionnent bien avec le round-robin, tandis que les scénarios avec état ou sessions persistantes nécessitent une affinité de session ou un hachage cohérent.

Sources

1. Kubernetes SIG-Autoscaling. (2023). Horizontal Pod Autoscaler Walkthrough. Documentation Kubernetes. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
2. Chen, L., et al. (2022). "Custom-Metric Autoscaling for Microservices: A Comparative Study." IEEE Transactions on Cloud Computing, 10(4): 2891-2905.
3. Kubernetes Cluster Autoscaler. (2024). FAQ and Best Practices. https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
4. Zhao, W., & Zhang, Y. (2023). "Proactive Autoscaling for Kubernetes Using Predictive Models." arXiv:2301.04567.
5. Cloud Native Computing Foundation. (2023). Service Mesh End-User Survey Report. CNCF Technical Advisory Group.
6. AWS Pricing. (2024). Elastic Load Balancing Pricing. https://aws.amazon.com/elasticloadbalancing/pricing/
7. D2iQ. (2024). State of Kubernetes Observability 2024. Rapport sectoriel.
8. Google Cloud Architecture Center. (2023). Scaling Microservices with Kubernetes. https://cloud.google.com/architecture/scaling-microservices

— Editorial Team