Un cluster Kubernetes tourne pendant des mois sans intervention. Puis une mise à niveau s’impose et l’on découvre combien d’éléments en dépendent.
Quiconque exploite un tel environnement connaît ces deux états. Au quotidien, le cluster demande peu d’attention. Les pods redémarrent, des nodes s’ajoutent ou disparaissent et le système compense de lui-même.
C’est précisément ce calme qui mène à l’erreur d’appréciation selon laquelle l’exploitation serait la tâche la plus légère. Elle n’est simplement que rarement visible.
Un cluster se compose de nombreux composants
Ce que l’on appelle le cluster est un assemblage : un control plane avec etcd, un plugin CNI pour le réseau, un ingress controller, des pilotes CSI pour le stockage et, selon l’environnement, cert-manager, metrics-server et une stack de monitoring.
Chacun de ces composants a son propre calendrier de releases et sa propre plage de versions prises en charge. Aucun de ces calendriers ne tient compte des autres.
Au moins deux mises à niveau de Kubernetes par an
Kubernetes publie une nouvelle version mineure trois fois par an. Chaque version reçoit ensuite des correctifs pendant environ quatorze mois, dont douze constituent la période standard.
Pour rester dans la plage prise en charge, il faut donc effectuer au moins deux mises à niveau par an.
Ce qu’une mise à niveau entraîne avec elle
Une mise à niveau ne s’arrête pas au control plane. Elle entraîne les composants voisins, car leurs plages de versions prises en charge se déplacent elles aussi.
Et elle touche vos propres manifestes, car les versions d’API sont d’abord marquées comme obsolètes, puis supprimées quelques versions plus tard.
Ce que l’on exploite n’est donc pas un logiciel isolé, mais une matrice de versions dans laquelle chaque élément doit être compatible avec tous les autres. Cette matrice se déplace d’elle-même, même si personne n’y touche.
L’effort arrive par vagues
Entre deux mises à niveau, l’effort est faible. Au moment des mises à niveau, il est important et difficile à estimer, car seule la préparation révèle quel élément ne suivra pas.
Un ingress controller qui a fonctionné sans changement pendant deux ans peut bloquer une mise à niveau parce que sa version prise en charge ne suit pas le saut.
Ce qui se trouve sous les applications
La sauvegarde d’etcd se met en place rapidement ; la restauration testée constitue le vrai travail.
La disponibilité du control plane dépend du fait qu’un seul ou plusieurs controllers tournent sur des zones séparées. Les certificats ont une durée de validité et ne se manifestent pas avant d’expirer.
Une année calme ne prouve rien
Un cluster qui a fonctionné sans problème pendant un an ne prouve pas que l’exploitation est maîtrisée. Il prouve que rien n’est arrivé à échéance cette année-là qui aurait mis la matrice en mouvement.
La question est celle des effectifs, pas des compétences
Sur le plan technique, ces tâches n’ont rien d’extraordinaire. Une équipe qui a introduit Kubernetes peut aussi les exécuter. La question plus difficile est autre. Peut-on maintenir durablement le savoir nécessaire pour quelque chose dont on a besoin deux fois par an ?
Des mois s’écoulent entre deux mises à niveau. Les personnes changent de poste ou d’entreprise et l’expérience du dernier passage n’est plus que partiellement disponible. Qui fait reposer ce travail sur une seule personne n’a pas un problème de savoir, mais un problème de disponibilité.
Les remèdes sont connus : documentation, une deuxième personne qui maîtrise le sujet, un cluster de test pour une répétition. Tous trois ont un coût permanent pour un bénéfice qui se concrétise deux fois par an.
Quand l’exploitation en interne est pertinente
Elle est pertinente lorsque la plateforme fait elle-même partie de votre produit ou lorsque les exigences imposent un contrôle sur chaque couche. Elle l’est moins lorsque le cluster sert de base aux applications et à rien d’autre.
Où la couche plateforme peut être confiée à un tiers
Le control plane, la version de Kubernetes et ses mises à niveau, le système d’exploitation et le patching des nodes, le réseau et le stockage peuvent être confiés à un tiers, tandis que la couche applicative reste en interne. Les namespaces, déploiements, images, ressources et autorisations ne changent pas de propriétaire pour autant.
La matrice ne disparaît pas, mais elle devient la tâche de quelqu’un d’autre.
Vous découvrirez où se situe cette limite chez Netstream et ce que coûte un cluster dédié sur une infrastructure suisse sur la page Managed Kubernetes.
