Kubernetes en production : les pratiques qui évitent les nuits blanches

La question mérite d'être posée avant toute autre : Kubernetes se justifie quand on exploite de nombreux services, avec des besoins réels d'orchestration, de montée en charge automatique et de standardisation des déploiements. Pour quelques applications stables, une plateforme applicative managée ou de simples conteneurs orchestrés par le fournisseur cloud offrent l'essentiel des bénéfices sans le coût d'exploitation. Adopter Kubernetes, c'est adopter un système distribué complexe qu'il faudra maintenir, mettre à jour plusieurs fois par an et sécuriser. Ce coût est justifié à l'échelle ; il ne l'est pas par principe.

Trois configurations conditionnent la stabilité, et leur absence explique une grande partie des incidents. Les demandes et limites de ressources : sans elles, l'ordonnanceur place les pods à l'aveugle et un service gourmand peut affamer ses voisins ; définir les demandes d'après la consommation observée, et manier les limites CPU avec discernement pour éviter les ralentissements artificiels. Les sondes : une sonde de démarrage pour les applications lentes à s'initialiser, une sonde de disponibilité qui reflète la capacité réelle à servir, et une sonde de vivacité prudente — trop agressive, elle abat des pods sains sous charge et transforme un ralentissement en panne en cascade. Les budgets d'interruption (PDB), enfin, sans lesquels une simple mise à jour de nœuds peut arrêter simultanément toutes les répliques d'un service. S'y ajoutent l'anti-affinité pour répartir les répliques sur des nœuds distincts, et des arrêts applicatifs propres qui honorent le signal de terminaison.

Un cluster fraîchement installé est permissif : tout pod peut parler à tout pod, et beaucoup de conteneurs tournent avec des privilèges inutiles. Les mesures de base relèvent de l'hygiène : conteneurs non privilégiés s'exécutant sans droits d'administrateur, standards de sécurité des pods appliqués par l'admission, politiques réseau qui n'autorisent que les flux nécessaires, secrets confiés à un gestionnaire externe plutôt qu'à des objets faiblement protégés, droits d'accès (RBAC) au moindre privilège, et images de provenance contrôlée, analysées dans la chaîne de livraison. Aucune de ces mesures n'est exotique ; leur absence cumulée fait d'un cluster compromis une autoroute.

À l'échelle, la gestion déclarative devient une nécessité : l'état souhaité du cluster décrit dans un dépôt Git, appliqué et réconcilié en continu par un opérateur dédié. Chaque changement est tracé, revu et réversible ; toute dérive manuelle est détectée et corrigée. Cette discipline rend accessoirement les clusters reconstructibles — la meilleure assurance qui soit. Reste le « jour 2 », où se joue la réussite réelle : suivre le rythme soutenu des versions de Kubernetes en testant les montées de version hors production, superviser le cluster lui-même et pas seulement les applications, et répéter les scénarios de restauration. Un cluster qu'on n'ose pas mettre à jour est une dette qui enfle en silence ; les équipes qui traitent ces fondamentaux comme des prérequis, et non comme des améliorations futures, font de Kubernetes ce qu'il devrait être — une plateforme qu'on oublie parce qu'elle fonctionne.