Kubernetes : test de défaillance de 30 % des nœuds

Tests de basculement Kubernetes : Éteindre 30 % des nœuds en production

L'équipe a désactivé 30 % des nœuds dans un cluster Kubernetes basé sur OKD en production pour révéler les faiblesses réelles de la résilience du système. Ce test a évalué la réaction du plan de contrôle, des composants d'infrastructure et des services applicatifs face à une panne majeure. Des problèmes liés aux contrôleurs webhook et à la répartition des réplicas — invisibles durant un fonctionnement normal — se sont clairement manifestés.

Architecture du cluster sous test

Le cluster fonctionne dans le cloud, réparti sur trois zones de disponibilité, chacune située dans un centre de données distinct avec une latence inférieure à 1 ms entre elles. La topologie entièrement connectée imite le comportement d'un réseau local.

Composants clés :

• Équilibreur de charge du trafic utilisateur : les backends sont constitués de 3 nœuds infra exécutant des pods Ingress et le contrôleur de volumes persistants.
• Équilibreur de charge API : les backends sont 3 nœuds maîtres hébergeant le plan de contrôle.
• Nœuds workers : répartis uniformément entre les zones, au total N.

Cette configuration permet de simuler une panne complète d'une zone sans perdre le quorum du cluster — etcd peut survivre à la perte de jusqu'à un nœud maître sur trois.

Préparation au test catastrophe

Le plan comprenait 8 étapes :

• Vérifier l'état de base du cluster et des services.
• Prendre des instantanés des nœuds maîtres et infra pour un retour rapide.
• Désactiver tous les nœuds d'une zone (ou 1 maître, 1 infra + 30 % des nœuds workers).
• Surveiller pendant 1 à 2 heures : logs d'erreurs, collecte de métriques, intervention des équipes support.
• Réactiver les nœuds désactivés.
• Valider à nouveau l'état du cluster.
• Clôturer le test.
• Documenter les actions à entreprendre.

Les instantanés sont préférés aux sauvegardes etcd pour les tests : récupération plus rapide, risque moindre. Les nœuds workers ne sont pas sauvegardés car leur état est stocké dans etcd. Les nœuds infra sont sauvegardés en raison des volumes persistants.

30 % est une cible équilibrée : scénario réaliste de panne (test de l'anti-affinité, des PDBs, de la réplication), mais non catastrophique. Le quorum des nœuds maîtres survit à une perte allant jusqu'à 33 %.

Critères de succès :

• L’API reste accessible.
• Les pods peuvent être créés et supprimés.
• Les volumes persistants restent disponibles.
• Les services continuent de fonctionner.
• La récupération des réplicas en 10 à 15 minutes.
• Les alertes sont résolues (sauf celles provenant des nœuds hors ligne).

Test #1 : Cluster de développement

Désactivation de 1/3 : 1 maître, 1 infra, environ 80 cœurs de workers. L’équilibreur de charge a retiré les backends défaillants en moins d’une minute. L’API est restée réactive, mais les nœuds sont entrés en état « Inconnu » pendant 300 secondes (délai par défaut), puis « NotReady / Inaccessible ».

Les pods n’ont pas redémarré pendant 10 minutes. Lors de la création de nouveaux pods :

Erreur du serveur (InternalError) : erreur lors de la création de "pod.yaml" : erreur interne s'est produite : appel du webhook "mutate.kyverno.svc-fail" a échoué : appel du webhook a échoué : Post "https://infra-kyverno-svc.infra-kyverno.svc:443/mutate/fail?timeout=30s" : dial tcp 10.128.4.174:9443 : connect : connection refused

Kyverno (webhook d'admission/mutation) avait un pod par type, dont 2 sur 3 situés dans la zone désactivée — désormais en état Terminating. Sans webhooks actifs, les modifications n'atteignent jamais etcd. Les espaces de noms système sont exclus de Kyverno pour éviter les blocages.

Augmentation du nombre de réplicas de Kyverno. Les événements ont montré un blocage du planificateur dû à une pénurie de ressources (implicite, bien que non explicitement mentionnée).

Problèmes et solutions

Kyverno : migré vers 3+ réplicas par type de webhook avec une répartition topologique consciente des zones.

Blocage du planificateur : vérification des quotas et limites de ressources dans les espaces de noms concernés.

Dans la production (tests #2 et #3), des scénarios similaires à grande échelle ont révélé des violations de PDB chez des services sans anti-affinité adéquate, ainsi que des retards dans le déplacement des volumes persistants.

Les équipes applicatives ont reçu une check-list :

• Minimum 3 réplicas.
• PodDisruptionBudget avec minAvailable.
• Contraintes de répartition topologique ou nodeAffinity.
• Demandes/limites de ressources.
• Probes de liveness/readiness avec des délais raisonnables.

Ce qui compte le plus

• Éteindre 30 % des nœuds met en lumière des problèmes cachés liés aux webhooks et au planificateur, invisibles en conditions normales.
• Kyverno nécessite plus d'une réplica, répartie équitablement entre les zones.
• Le délai de 300 secondes pour l'état « NotReady / Unreachable » est standard, mais impose une réserve de ressources.
• Les instantanés des nœuds maîtres et infra sont essentiels pour des tests sûrs.
• Récupération complète : 10 à 15 minutes pour les réplicas + résolution des alertes.

Recommandations pour les équipes

Pour les développeurs de services :

• Définir des PDB : minAvailable: 50 %.
• Utiliser topologySpreadConstraints pour une répartition entre zones.
• Fixer les demandes/mises à jour CPU / RAM à 80 % des pics observés.
• Probes avec timeout de 5 à 10 secondes et 3 tentatives.

Pour les administrateurs Kubernetes :

• S'assurer que Kyverno et autres webhooks ont plus de 3 réplicas avec haute disponibilité.
• Surveiller les élections du leader etcd.
• Prévoir une capacité avec une réserve de +30 %.
• Automatiser les instantanés avant chaque test.

Ces tests sont incontournables pour tout cluster de production comptant plus de 100 nœuds.

— Editorial Team