Optimisation de la Distribution des Pods Kubernetes : Maîtrise de l'Affinité et de l'Anti-Affinité

Optimisation de la Distribution des Pods Kubernetes : Maîtrise de l'Affinité et de l'Anti-Affinité

Dans les environnements Kubernetes à forte charge, il n'est pas rare de rencontrer des problèmes de performance localisés malgré une capacité globale suffisante. Un scénario courant est celui de quelques nœuds physiques saturés à 100% de leur CPU, tandis que la majorité des autres restent sous-utilisés. Ce déséquilibre peut entraîner une dégradation critique des performances, comme une latence P99 passant de 20 ms à 5000 ms, causée par la famine de ressources CPU et le phénomène de throttling.

L'enquête révèle souvent que le planificateur par défaut de Kubernetes, le kube-scheduler, a regroupé des Pods gourmands en ressources sur un nombre restreint de machines physiques. Ce n'est pas un bug applicatif, mais une conséquence de l'algorithme de planification statique de Kubernetes et des mécanismes d'isolation des ressources de cgroups au niveau du système d'exploitation.

Cet article explore les limites du planificateur par défaut et présente comment les règles d'affinité et d'anti-affinité des Pods, combinées au Descheduler, permettent de gérer finement la distribution des charges de travail, d'éliminer les points chauds CPU et d'optimiser le débit des microservices.

  1. Les Illusions du Planificateur par Défaut : Pourquoi les "Trous Noirs" de Calcul Apparaissent

De nombreux développeurs pensent qu'en définissant les resources.requests et limits dans leurs fichiers YAML, Kubernetes assurera un équilibre parfait des ressources. Cependant, cette vision est souvent trompeuse en production.

1.1. Un Mécanisme de Notation Statique Rigide

Lorsqu'un nouveau Pod doit être planifié, le kube-scheduler utilise une logique d'évaluation statique. Il parcourt les nœuds disponibles, filtre ceux qui peuvent accueillir le Pod (phase de Filter), puis attribue un score à chaque nœud restant (phase de Score). Ce score est souvent basé sur l'agrégation des requests déclarées par les Pods existants.

Exemple de scénario catastrophique : Si un service de transcodage vidéo, initialement peu sollicité, est configuré avec requests.cpu: 500m, le planificateur peut, voyant des ressources disponibles, placer de nombreux Pods de ce service sur le même nœud. En cas de pic de trafic, ces Pods sollicitent intensivement les cœurs physiques, faisant exploser la charge du nœud.

1.2. Le Throttling CPU Implacable du CFS Linux

Lorsque le CPU d'une machine physique est saturé, le système d'exploitation Linux active le mécanisme de throttling des ressources via cgroups.

Le planificateur CFS (Completely Fair Scheduler) vérifie les paramètres cpu.cfs_quota_us et cpu.cfs_period_us de chaque cgroup (correspondant aux Pods). Si les threads Java d'un Pod épuisent leur quota CPU (par défaut, 100 ms) en un laps de temps trop court, le planificateur retire violemment ces threads de la file d'attente d'exécution des cœurs physiques. Pendant le reste de la période, le Pod est gelé, incapable de traiter de nouvelles requêtes, ce qui entraîne des latences exorbitantes.

  1. Fragmenter les Charges : L'Anti-Affinité des Pods

Pour contrer l'accumulation de points chauds CPU, il est impératif d'empêcher les Pods de même nature, à forte consommation, de cohabiter physiquement. C'est le rôle de l'anti-affinité de Pods (Pod Anti-Affinity), qui crée des forces de répulsion au niveau de la planification.

2.1. Définir le Domaine Topologique (topologyKey)

Kubernetes permet de définir des domaines topologiques via la clé topologyKey. Cette clé peut s'appliquer à un nœud (kubernetes.io/hostname), un rack, une zone de disponibilité (topology.kubernetes.io/zone) ou même une région (topology.kubernetes.io/region). Elle permet de spécifier si les Pods doivent être dispersés à l'intérieur de ces limites.

2.2. Contraintes Fortes vs. Contraintes Souples

Lors de la configuration de l'anti-affinité, Kubernetes propose deux types de contraintes aux implications différentes :

Type de Contrainte Comportement du Planificateur Effets Secondaires Potentiels Cas d'Usage Clés en Production
Required (Forte) Exclusion physique absolue. Si aucun nœud ne satisfait les conditions, le Pod reste en Pending indéfiniment. Bloque l'extension du cluster si le nombre de nœuds est insuffisant. Composants primaires/secondaires critiques (ex: Zookeeper, nœuds Redis maîtres/esclaves) nécessitant une isolation stricte.
Preferred (Souple) Tente de disperser les Pods. Si les ressources sont limitées, les Pods peuvent être regroupés. Peut créer des points chauds mineurs en cas de forte charge si les ressources sont très contraintes. Microservices sans état à haute concurrence (ex: passerelles Web, services Java calcul intensif) nécessitant flexibilité et tolérance.
  1. Cas Pratique : Anti-Affinité pour la Dispersion de Charge

Voici un exemple d'application de l'anti-affinité souple pour un service de transcodage vidéo gourmand en CPU, afin d'assurer sa dispersion sur différents nœuds physiques.

3.1. Contrainte Souple (Preferred) pour la Dispersion Physique

Pour la plupart des déploiements de microservices, la contrainte souple (Preferred) est recommandée. Elle permet à l'HPA (Horizontal Pod Autoscaler) de démarrer de nouveaux Pods même en cas de ressources physiques limitées, évitant ainsi un blocage. Nous utilisons ici un poids élevé (weight: 100) pour maximiser l'effet de dispersion.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-transcodage-video
spec:
  replicas: 10
  selector:
    matchLabels:
      app: transcode-video
  template:
    metadata:
      labels:
        app: transcode-video
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100 # Priorité élevée pour la dispersion (1-100)
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - transcode-video
              topologyKey: kubernetes.io/hostname # Cible le niveau du nœud physique
      containers:
      - name: conteneur-transcodeur-java
        image: registre.mon-entreprise.com/transcodage:v1.0
        resources:
          requests:
            cpu: "2"
          limits:
            cpu: "4"

3.2. Analyse de l'Exécution Physique

Après l'application de ce manifeste YAML, le kube-scheduler modifiera son processus de notation. Pour chaque nœud potentiel, s'il héberge déjà un Pod avec le label app: transcode-video, son score de planification sera considérablement réduit (déduction de 100 points). Cela forcera les 10 Pods à être distribués sur 10 nœuds physqiues distincts, maximisant ainsi l'utilisation équilibrée des ressources CPU du cluster Kubernetes.

  1. Latence Zéro RTT : L'Affinité des Pods

Si l'anti-affinité permet de disperser les points chauds CPU, l'affinité de Pods (Pod Affinity) est cruciale pour éliminer un autre goulot d'étranglement : la latence réseau (RTT) entre services fortement couplés.

4.1. Le Problème du Trafic Réseau Inter-Nœuds

Imaginez un service Java effectuant des dizaines de milliers de requêtes par seconde vers un cache Redis local. Si, par défaut, le Pod Java est déployé dans la zone A et le Pod Redis dans la zone B, chaque requête subira un RTT de plusieurs millisecondes. Pour 100 000 requêtes, cela peut ajouter des centaines de millisecondes à la latence globale, impactant gravement les performances de l'application.

4.2. Colocation Forcée avec l'Affinité de Pods

Pour éliminer ce coût réseau, l'affinité de Pods permet de "coller" des Pods étroitement liés (comme une application et son cache) sur le même nœud physique ou dans la même zone de disponibilité.

4.3. Contrainte Forte (Required) pour la Colocation

Dans cet exemple, nous utilisons une contrainte forte (Required) pour garantir que l'application Java et le cache Redis sont déployés sur le même nœud. Si cette condition n'est pas remplie, le Pod Java ne sera pas planifié.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: moteur-negociation-haute-frequence
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: moteur-negociation
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: component
                operator: In
                values:
                - cache-redis-local # Cible le Pod Redis local
            topologyKey: kubernetes.io/hostname # Co-localisation sur le même nœud
      containers:
      - name: app-springboot-negociation
        image: registre.mon-entreprise.com/negociation:v2.0

Avec cette contrainte, le kube-scheduler s'assurera que les cinq Pods moteur-negociation sont déployés sur les mêmes nœuds physiques que les Pods cache-redis-local. Cela réduit le trafic inter-nœuds, transformant les communications réseau en IPC (Inter-Process Communication) ou même en bouclage local, optimisant ainsi drastiquement le débit.

  1. Fragmentation du Cluster et "Dérive Spatiale-Temporelle" : Le Point Faible de la Planification Statique

Les règles d'affinité et d'anti-affinité sont très efficaces au moment de la création des Pods. Cependant, un cluster Kubernetes est un environnement dynamique. Avec le temps, le phénomène d'entropie (ou de fragmentation du cluster) peut apparaître, menant à une "dérive spatiale-temporelle" des Pods.

5.1. L'Effondrement du "Liage Statique"

Considérons un cluster avec 10 nœuds où 10 Pods de transcodage vidéo sont parfaitement dispersés grâce à l'anti-affinité. Un mois plus tard, cinq nœuds sont retirés (Node Scale-Down), et les cinq Pods restants sont évincés. Le contrôleur ReplicaSet redémarre alors ces Pods sur les cinq nœuds restants.

Problème : Étant donné que nous avons utilisé une contrainte souple (Preferred), le planificateur, contraint par le manque de nœuds, regroupera les nouveaux Pods sur les cinq machines déjà occupées. Pire, si 10 nouveaux nœuds sont ajoutés par la suite, les Pods regroupés ne migreront pas automatiquement vers ces nœuds disponibles. Le kube-scheduler est un processus "à usage unique" pour les Pods en cours d'exécution ; il ne réagit pas aux changements ultérieurs de la topologie du cluster.

5.2. Fusion des Ressources Locales Basée sur cgroups

Ces nœuds surchargés se retrouvent de nouveau dans un état de CPU Throttling, avec le planificateur CFS suspendant les threads Java et les nouveaux nœuds restant inactifs. Le débit du cluster de transcodage est réduit de moitié, et la latence P99 remonte à des niveaux inacceptables.

  1. Le Grand Nettoyage : Le Descheduler à la Rescousse

Pour contrer cette "dérive spatiale-temporelle", il faut utiliser le Descheduler. Cet outil externe à Kubernetes scanne la topologie du cluster et, lorsqu'il détecte des Pods qui enfreignent les règles de dispersion ou d'utilisation des ressources, il les évince (Evict) via l'API Kubernetes. Cela force le ReplicaSet à les recréer sur des nœuds appropriés et potentiellement inactifs.

6.1. Stratégies de Nettoyage Cruciales

Le Descheduler est configuré via un fichier Policy spécifiant les règles d'éviction :

  • RemoveDuplicates : Évince les Pods appartenant au même ReplicaSet et cohabitant sur le même nœud.
  • RemovePodsViolatingInterPodAntiAffinity : Cible les Pods qui, bien que contraints par une anti-affinité souple, ont été regroupés suite à une pénurie temporaire de nœuds et qui peuvent maintenant être dispersés.
# Stratégie de politique Descheduler pour un rééquilibrage dynamique
apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  RemoveDuplicates:
    enabled: true
    params:
      removeDuplicates:
        excludeOwnerKinds:
        - "DaemonSet"

  RemovePodsViolatingInterPodAntiAffinity:
    enabled: true

  LowNodeUtilization:
    enabled: true
    params:
      nodeResourceUtilizationThresholds:
        thresholds:
          "cpu": 20
          "memory": 20
          "pods": 20
        targetThresholds:
          "cpu": 50
          "memory": 50
          "pods": 50

6.2. Contrôle Temporel du Nettoyage

Exécuter le Descheduler trop fréquemment peut entraîner une instabilité du cluster (Pod Flapping). Les microservices seraient constamment redémarrés, perdant les optimisations du compilateur JIT et créant des tempêtes de requêtes TCP.

Recommandations :

  • Utiliser un CronJob Kubernetes pour exécuter le Descheduler pendant les périodes de faible activité (ex: 3h à 4h du matin).
  • Activer le paramètre maxNoOfPodsToEvictPerNode pour limiter le nombre de Pods évincés par nœud et éviter des interruptions de service généralisées.
  1. Matrice Complète : Isolation des Points Chauds CPU

Voici une matrice récapitulative pour guider la stratégie d'optimisation des ressources CPU dans Kubernetes :

Méthode d'Isolation / Optimisation Planification par Défaut (Statique) Anti-Affinité de Pods Descheduler + Anti-Affinité
Distribution des Charges Risque élevé de regroupement de Pods homogènes. Parfaite au moment de la création, disperse les Pods gourmands. Parfaite sur le cycle de vie complet, élimine la fragmentation dynamique.
Réponse au Scaling Dynamique Ignorance totale (nœuds ajoutés restent inactifs, nœuds anciens surchargés). Ignorance partielle (les Pods regroupés ne migrent pas seuls). Extrêmement réactive (évince les Pods surchargés pour les recréer sur de nouveaux nœuds).
Débit JVM et Latence P99 Très incertain (peut déclencher des throttlings de plusieurs secondes). Très élevé (isolation des Pods, maximisation du temps CPU par machine). Très élevé (stabilité à long terme, prévient les pannes localisées).
Coût de Configuration / Opération Nul (déploiement "aveugle"). Très faible (ajout de règles simples dans YAML). Élevé (nécessite une orchestration précise du CronJob et des limites d'éviction).
  1. Pièges à Éviter : Zones Mortes de la Planification Avancée

L'utilisation de la planification avancée nécessite une compréhension approfondie pour éviter des problèmes critiques :

Piège 1 : Mauvaise Compréhension de topologyKey

Scénario : Un développeur souhaite co-localiser un Pod Java et un Pod Redis dans le même datacenter (zone de disponibilité AZ) et utilise kubernetes.io/hostname comme topologyKey.

Problème : hostname désigne un nœud physique spécifique. Si ce nœud est déjà plein, le Pod Java, avec une contrainte Required, restera bloqué en état Pending indéfiniment.

Solution : Pour la co-localisation au niveau de la zone de disponibilité, utilisez topology.kubernetes.io/zone. Cela permet au planificateur de trouver un nœud disponible au sein d'une zone plus large.

Piège 2 : Anti-Affinité Asymétrique

Scénario : Pour isoler les nœuds de données Elasticsearch des Pods Java, un développeur configure l'anti-affinité dans le YAML d'ES pour repousser les Pods Java. Cependant, le YAML des Pods Java n'inclut aucune règle d'anti-affinité.

Problème : Si les Pods ES sont déployés avant les Pods Java, le planificateur peut ignorer la règle d'anti-affinité des Pods ES, car elle ne s'applique qu'au moment de leur propre planification. Les Pods Java pourraient alors être déployés sur les mêmes nœuds que les Pods ES.

Solution : L'anti-affinité doit être bidirectionnelle et symétrique. Si A doit éviter B, B doit aussi éviter A. Configurez l'anti-affinité dans les deux déploiements pour une isolation mutuelle.

Piège 3 : Complexité de Calcul de l'Affinité Élevée

Scénario : Dans un grand cluster de 5000 nœuds, un développeur configure des règles d'affinité souple (Preferred) complexes pour la plupart des déploiements.

Problème : Le kube-scheduler passe un temps considérable à évaluer ces règles complexes lors de la phase de scoring, ce qui peut faire passer le temps de planification de quelques millisecondes à plusieurs dizaines de secondes. Cela ralentit le déploiement de nouveaux Pods et peut bloquer l'API Server.

Solution : Dans les très grands clusters, utilisez les règles Preferred avec parcimonie. Pour des besoins d'isolation stricts, privilégiez les Taints (taches) et Tolerations (tolérances), combinés à l'Affinité de Nœud (Node Affinity). Cette approche, basée sur des étiquettes de nœuds, réduit la complexité de calcul du planificateur de O(N²) à O(1).

Conclusion : Reprendre le Contrôle des Ressources Physiques

L'ère des microservices et de la conteneurisation nous a habitués à un déploiement "facile" des applications sur Kubernetes. Cependant, sous la pression d'un trafic massif, les illusions de simplicité s'effondrent face aux réalités des transistors physiques.

Ce qui détermine la survie de votre système n'est pas seulement la finesse de votre code, mais votre capacité à comprendre les interactions profondes : comment les processus Java luttent pour chaque microseconde de temps CPU dans des pipelines cgroups étroits ; comment le RTT entre zones de disponibilité étire les chaînes de microservices, engorgeant les tampons TCP ; et surtout, comment manipuler l'Affinité et le Descheduler pour découper des chemins d'exécution isolés, sans interférence.

Un véritable architecte cloud-natif ne se contente pas de commandes kubectl apply. Il perce le voile du planificateur de Kubernetes, comprend les phases de filtrage et de scoring, et utilise les règles topologiques les plus efficaces pour coller les composants dépendants sur le même rack ou disperser les bêtes de calcul sur des continents physiques différents. C'est en maîtrisant ces principes fondamentaux que vous pourrez bâtir une forteresse inébranlable capable de gérer les pics de trafic les plus exigeants.

Étiquettes: kubernetes Pod Affinity Pod Anti-Affinity kube-scheduler Descheduler

Publié le 14 juillet à 10h45

Étiquettes Populaires

©2026 L'Atelier Monstre