Certains tests ne tiennent pas dans un runner de CI. Dans le cas traité ici, un logiciel robotique est validé par une simulation physique headless : chaque scénario démarre un simulateur, joue une situation et enregistre ce que le logiciel a fait, et une campagne complète occupe une dizaine de CPU pendant plus d'une heure. Ces campagnes tournaient déjà sur un cluster Kubernetes, sous forme de Jobs lancés à la main depuis un service web, si bien qu'une régression pouvait atteindre la branche principale sans que personne ne pense à lancer un run. Les brancher sur les pull requests pose plusieurs questions : que bloquer quand les résultats sont bruités, comment donner à la CI le droit de créer des Jobs sans lui donner plus, comment partager une capacité limitée, et comment récupérer un verdict. Cet article décrit les choix faits pour chacune.

En EKS Auto Mode, AWS gère les nœuds, le réseau des pods, le stockage et les load balancers. La supervision des applications reste en revanche à la charge du client : le modèle de responsabilité partagée d'Auto Mode le dit explicitement. Un cluster fraîchement créé n'envoie à CloudWatch aucune métrique de pod et aucune ligne de log applicatif. Un pod qui redémarre en boucle ou une API qui renvoie des erreurs 500 ne laissent alors de trace que dans kubectl, tant que les pods existent encore. Sur un cluster auto-hébergé, ce rôle revient à Prometheus et Loki. Sur AWS, le service natif est CloudWatch. Cet article décrit comment y raccorder un cluster EKS, et les réglages par défaut à corriger dès l'installation.

Promtail, l'agent qui pousse les logs vers Loki, est en fin de vie depuis le 2 mars 2026 : il ne reçoit plus de correctifs. Un cluster qui collecte ses logs avec lui doit changer d'agent, et la migration ne doit casser ni les dashboards ni les requêtes qui reposent sur ses labels. Le même cluster lance souvent un agent par signal : Promtail pour les logs, des exporters pour les métriques, un OpenTelemetry Collector dès que des traces apparaissent. Grafana Alloy, le remplaçant désigné de Promtail, est une distribution de l'OpenTelemetry Collector qui collecte métriques, logs, traces et profils dans un seul processus. Cet article décrit son modèle de configuration, la collecte des logs des pods et des événements Kubernetes, et ce qu'il faut reprendre de Promtail pour une bascule sans rupture.

Un serveur qui plante sans laisser de trace ne donne aucune piste de diagnostic. Dans le cas traité ici, un serveur domestique sous Ubuntu, sans écran ni clavier, s'est arrêté trois fois en quelques jours ; à chaque fois, le journal système s'interrompait net, sans message d'erreur, et la machine restait figée jusqu'à un appui sur le bouton d'alimentation. Trois problèmes se posent alors : capturer la cause du crash, faire redémarrer la machine sans intervention, et être prévenu qu'un redémarrage a eu lieu. Cet article décrit la chaîne qui répond aux trois, kdump, sysctl de panic, watchdog matériel et alerte Prometheus, puis la façon de la valider avant le prochain crash.

Un snapshot de volume ne suffit pas à sauvegarder une base de données. Dans le cas traité ici, une application web stocke ses données dans MariaDB et ses fichiers joints sur un second volume, tous deux sur Longhorn avec des snapshots quotidiens. Restaurer le snapshot du volume de MariaDB revient à redémarrer la base après une coupure de courant : InnoDB sait le plus souvent rejouer son journal, mais rien ne garantit que l'état obtenu corresponde à un instant où l'application était cohérente, et le snapshot n'est lisible que par Longhorn. Un dump logique, produit par la base elle-même, donne une copie cohérente, portable et lisible. Cet article décrit un CronJob qui produit ce dump avec l'archive des fichiers joints, vérifie le résultat avant de le publier et gère sa propre rotation, sur le même principe que la sauvegarde des volumes Docker.

Un Grafana configuré à la main garde dans sa base un état que rien ne trace. Dans le cas traité ici, l'inventaire d'un Grafana en service depuis la création du cluster a relevé une datasource pointant vers un serveur MySQL décommissionné, une autre créée pour un essai et jamais utilisée, des dashboards modifiés au fil des besoins sans trace de qui avait changé quoi ni pourquoi, et un écran d'affichage dont les liens dépendaient de dashboards qu'une fausse manipulation pouvait casser. Surtout, l'ensemble vivait dans la base SQLite de Grafana, sur un unique volume persistant : sa perte effaçait des mois de travail, sans aucune copie. Les manifests du cluster étaient tous versionnés et relus ; Grafana faisait exception. Cet article décrit comment faire de Git la source de ses dashboards et datasources, et les pièges de la transition.

Un stockage objet S3 hébergé sur un seul serveur finit par buter sur la taille de son disque. Dans le cas traité ici, une instance Garage déployée sur un cluster Kubernetes disposait d'environ 500 Go, et un besoin de 2 To est apparu. Aucune machine du cluster ne porte un disque de cette taille, il n'existe pas de baie de stockage, et un volume Longhorn ne peut pas dépasser le disque d'un nœud. La capacité existe pourtant : plusieurs nœuds ont des disques en grande partie libres. Garage sait agréger ces disques, à condition de tourner sur plusieurs machines et de former un cluster. Le faire sous Kubernetes pose une difficulté moins visible : Kubernetes traite les pods comme interchangeables, alors qu'un nœud de stockage distribué ne l'est pas. Cet article décrit ce décalage, les pannes qu'il a provoquées lors du passage d'un à quatre nœuds, et la façon de les éviter.

Sur un hôte Docker, l'essentiel des pannes se lit dans les métriques de la machine et des conteneurs : disque, mémoire, redémarrages. Sur un cluster Kubernetes, une part importante des incidents ne se voit qu'au niveau des objets de l'API : un Deployment dont le rollout ne termine pas, un pod bloqué en Pending faute de ressources, un CronJob de sauvegarde qui échoue chaque nuit, un volume répliqué qui a perdu une copie, un certificat du plan de contrôle qui approche de son expiration. Ces états ne produisent ni pic de CPU ni erreur applicative. Cet article fait suite à l'article Alertmanager et construit un socle d'alertes pour un cluster kubeadm déployé avec le chart prometheus-community/prometheus : sources de métriques, collecte, règles par domaine, pièges propres aux métriques d'état et routage.

Un nœud Kubernetes équipé d'une carte NVIDIA n'expose rien de plus qu'un autre : le kubelet ne connaît que le CPU, la mémoire et le stockage éphémère, et un conteneur ne voit pas les périphériques /dev/nvidia* de l'hôte. Pour qu'un pod d'entraînement ou d'inférence obtienne une carte, plusieurs couches doivent coopérer : le pilote sur l'hôte, un runtime de conteneurs capable d'injecter le GPU, un composant qui annonce les cartes au scheduler, et des labels qui permettent de choisir entre des cartes différentes. Cet article décrit cette chaîne sur un cluster kubeadm hétérogène, ses pièges et la supervision des cartes.

Un cluster Kubernetes sans IP publique expose souvent ses services par un VPN maillé comme Tailscale : le reverse proxy reçoit une adresse sur le réseau privé virtuel, et le DNS public de *.apps.example.com pointe vers cette adresse. Seuls les postes membres du VPN atteignent les services, y compris ceux qui se trouvent physiquement sur le même réseau local que les serveurs. Ouvrir un accès direct depuis ce réseau local se heurte à des contraintes fréquentes en entreprise : le DNS et le DHCP de l'organisation sont gérés par une autre équipe, aucune adresse fixe n'est réservable, et le DNS public doit rester inchangé pour les utilisateurs du VPN. Cet article décrit une solution qui combine des externalIPs sur le Service du reverse proxy et un CoreDNS dédié, interrogé uniquement par les postes configurés à cet effet.