Exploration des défis et solutions dans Kubernetes
Introduction
Kubernetes en production, c'est 80% de situations que les tutoriels ne couvrent pas. Des DNS qui timeout, des pods qui redémarrent en boucle la nuit, des PVC qui refusent de se monter, des nodes qui disparaissent. Après 8 ans à opérer des clusters en production, voici les défis les plus courants et les solutions que j'ai mises en place.
Le défi du DNS interne Kubernetes
Le DNS est la source de problèmes la plus sous-estimée en Kubernetes. Chez Bloomflow, des timeouts intermittents affectaient les appels inter-services. Après investigation, le problème était le cache DNS de CoreDNS saturé par 20 services qui faisaient des résolutions intensives. La solution : augmenter le cache CoreDNS (cache 60 au lieu du défaut 30), ajouter des replicas CoreDNS (3 au lieu de 2), et configurer le ndots: 2 dans le pod spec (par défaut Kubernetes résout avec 5 suffixes de recherche, ce qui multiplie les requêtes DNS). Chez TEKYN, un problème similaire était causé par l'utilisation de dnsPolicy: Default au lieu de ClusterFirst, ce qui faisait sortir les requêtes DNS du cluster. Ces problèmes DNS sont invisibles tant qu'on ne monitore pas la latence DNS, que j'ajoute systématiquement dans mes dashboards Grafana.
Le défi de l'eviction et de l'OOM
Les pods evicted et les OOMKilled sont des problèmes récurrents. Chez Cardiologs, un pod de traitement d'ECG était régulièrement OOMKilled : il consommait plus de mémoire que sa limit. L'investigation a révélé un memory leak dans une bibliothèque de traitement d'images qui n'était visible que sur des fichiers volumineux. La solution immédiate : augmenter la memory limit et ajouter un monitoring de la consommation mémoire avec alerte Datadog. La solution définitive : corriger le leak avec un pool de mémoire fixe. Pour les evictions, la cause est souvent un node sous pression mémoire. Chez Metronome, j'ai configuré les eviction thresholds du kubelet à des valeurs plus conservatrices (90% au lieu de 95%) pour avoir plus de marge avant l'eviction.
Le défi des mises à jour de cluster
La mise à jour d'un cluster Kubernetes est un moment critique. Chez Coopengo sur AWS EKS, le passage de la version 1.24 à 1.25 a nécessité des modifications car le PodSecurityPolicy (PSP) était supprimé au profit de PodSecurityAdmission. J'avais préparé la migration en déployant PSA en mode "warn" pendant 2 mois pour identifier les workloads non conformes, puis en mode "enforce" avant l'upgrade. Le drain des nodes se faisait un par un avec validation des métriques entre chaque node. Chez KNDS sur OVH, la même opération nécessitait un plan de rollback documenté et testé, car le cluster hébergeait des applications critiques. La mise à jour a pris 4 heures avec zéro interruption de service, grâce aux PDB et aux anti-affinities configurées en amont.
Le défi du stockage persistant
Le stockage dans Kubernetes est notoirement complexe. Chez Bloomflow, un incident mémorable : un PersistentVolumeClaim qui refusait de se monter après un redémarrage de pod car le volume était encore attaché au node précédent (le détachement prend jusqu'à 6 minutes sur certains cloud providers). La solution : utiliser des volumeBindingMode: WaitForFirstConsumer pour que le volume ne se crée que quand le pod est schedulé, et des reclaimPolicy: Retain pour les volumes critiques. Pour les bases de données, j'ai toujours recommandé des services managés (RDS, Cloud SQL) plutôt que des StatefulSets dans Kubernetes. Le seul usage de stockage persistant que j'approuve en Kubernetes est pour des caches (Redis, Memcached) et des files d'attente (RabbitMQ) où la perte de données est acceptable.
Le défi de la sécurité runtime
La sécurité ne s'arrête pas au déploiement. Chez KNDS, j'avais déployé Falco pour la détection d'anomalies runtime : un pod qui ouvre un shell, un processus qui accède à des fichiers système, une connexion réseau vers une IP inconnue. En 3 mois, Falco a détecté 2 anomalies (bénignes dans les deux cas, mais le système fonctionnait). Les profils seccomp restreignaient les appels système autorisés par chaque conteneur. Chez Okeiro, la PodSecurityAdmission en mode "restricted" empêchait tout container de tourner en root, d'utiliser des capabilities Linux non standard, ou d'accéder au système de fichiers du host. Ces mesures, combinées aux NetworkPolicies, créent une défense en profondeur qui complique considérablement la progression d'un attaquant.
Conclusion
Les défis de Kubernetes en production sont réels mais surmontables. La clé est l'expérience : avoir déjà rencontré (et résolu) ces problèmes permet de les anticiper et de les prévenir. DNS, OOM, mises à jour de cluster, stockage persistant et sécurité runtime sont les 5 domaines où j'ai vu le plus d'incidents. Chacun a des solutions éprouvées qui, appliquées systématiquement, transforment un cluster fragile en une plateforme résiliente.