Une mise à jour Kubernetes n'est jamais un simple changement de numéro de version. Il y a un drain de nœud, un échange de binaire, une migration de plan de contrôle, une séquence d'éviction de pods, et — si vous êtes en bare-metal — personne à appeler quand ça tourne mal.

Les fournisseurs Kubernetes managés gèrent l'essentiel de cela pour vous. Les clusters auto-gérés vous font tout posséder. Cet article documente les deux côtés concrètement : ce qu'EKS, GKE et AKS font réellement lors d'une mise à jour, et ce que j'ai construit pour automatiser le même processus sur mon cluster k3s de 5 nœuds tournant sur des ThinkPads.

Les fournisseurs Kubernetes managés font paraître le patch de sécurité simple. Vous activez l'auto-mise à jour sur GKE, vous cliquez « mettre à jour le groupe de nœuds » sur EKS, et la CVE disparaît. Ce qui se passe réellement, c'est que le fournisseur patche l'image OS, remplace le nœud, valide le binaire, et restaure vos workloads — le tout dans le temps qu'il faut pour rafraîchir la console AWS.

Sur un cluster auto-géré, rien de cela n'est automatique. Vous possédez l'OS. Vous possédez le runtime. Vous possédez les images de base. Vous possédez les versions de charts Helm. Et quand une CVE tombe, vous possédez la décision sur la couche où elle vit et le mécanisme qui la fermera.

Cet article documente les cinq couches de patching sur minicloud — un cluster k3s de 5 nœuds sur des ThinkPads bare-metal — ce qui est automatisé, ce qui requiert une PR, et où étaient les manques et comment ils ont été comblés.

La plupart des comparatifs Kubernetes sont écrits par des gens qui n'ont utilisé que des services managés. Celui-ci est écrit par quelqu'un qui a un ThinkPad nommé set-hog posé sur un bureau, en train de faire tourner le serveur d'API en ce moment même.

Voici à quoi ressemble vraiment l'auto-gestion d'un plan de contrôle Kubernetes — comparé ligne par ligne à EKS, GKE et AKS.

Un modèle sort de l'entraînement à 28 Go. Tu le télécharges à 4.7 Go. Qui a fait la compression entre les deux — et pourquoi ?

Ce post répond à cette question, et explique comment les modèles open-source circulent depuis les labos de recherche jusqu'à ton cluster.

Un modèle 7B en FP32, c'est 28 Go de RAM. Mes ThinkPads en ont 16 à 32. Impossible de charger le modèle — sans parler de faire de l'inférence.

La quantization a résolu ce problème. Pas en sacrifiant la qualité — en changeant la façon dont les poids sont stockés.

Le matériel était provisionné. MAAS avait démarré quatre ThinkPads en PXE et cloud-init avait écrit les clés SSH et les noms d'hôte. La question suivante était : comment faire tourner concrètement Kubernetes sur cinq laptops ?

Il existe plus de façons d'installer Kubernetes qu'il n'y a de parcours de certification Kubernetes. J'ai fini avec k3s. Voici pourquoi — et exactement à quoi ressemblait l'installation.

Faire tourner des LLM sur du matériel CPU bare-metal vous force à comprendre les chiffres derrière les fichiers de modèles. Cet article documente comment nous raisonnons sur la taille des modèles, la quantification et le service d'inférence sur minicloud — et le changement concret que nous avons fait : remplacer phi4-mini par Qwen 2.5 7B sur les trois instances Ollama.

Chaque fois que je mettais à jour la config du dashboard Homer, je devais lancer kubectl rollout restart deployment/homer -n homer après qu'ArgoCD ait fini de synchroniser. Pareil pour LiteLLM quand le routage changeait. Pareil pour Backstage après toute mise à jour de catalogue ou de proxy. Le motif était identique à chaque fois : pousser vers git, attendre la synchronisation ArgoCD, puis déclencher manuellement un redémarrage de pod.

C'est une odeur opérationnelle. Si git est le seul chemin d'écriture, le redémarrage devrait être automatique aussi.

La plupart des plateformes cloud vous cachent l'infrastructure. Provisioning MAAS, séquences de boot PXE, agrégation de cartes réseau, backends de stockage, chaînes de certificats — tout est abstrait derrière quelques flags CLI ou un tableau de bord. Cette abstraction a de la valeur en production, mais elle peut aussi tenir les ingénieurs à distance des systèmes qu'ils sont censés comprendre en profondeur.

Ce projet est né d'une question simple : qu'est-ce qu'il faut vraiment pour construire une plateforme Kubernetes de qualité production from scratch ?