Webhooks d'admission Kubernetes : mécanique et pièges
Un webhook d'admission est un point de défaillance unique explicite. failurePolicy: Fail peut bloquer tout le cluster si le webhook devient injoignable.
Migration d'infrastructure legacy vers Kubernetes, sans coupure
Le problème
Votre infrastructure tourne : des VM, des scripts, un hyperviseur vieillissant, peut-être un début de conteneurisation. Elle fait tourner le business, et c’est précisément pour ça que personne n’ose y toucher.
Vu de la direction, le risque a trois visages. Le coût : licences, matériel, temps humain passé à maintenir plutôt qu’à construire : une ligne budgétaire qui monte pendant que la vélocité descend. La dépendance : deux ou trois personnes savent encore comment tout tient, et chaque départ est un incident différé. L’incident lui-même : chaque intervention est risquée, chaque montée de version est un projet, et le scénario du « grand soir » (tout basculer un week-end en priant) est exactement celui qui finit en cellule de crise.
La bonne nouvelle : une migration vers Kubernetes ne se joue pas dans le cluster, elle se joue dans la trajectoire. Passer des machines virtuelles aux conteneurs service par service, de façon progressive, réversible, sans interruption : c’est une méthode, pas un pari.
La méthode
Cartographier l'existant
Audit de l'infrastructure réelle : services, dépendances, flux, et les risques qui comptent vraiment, pas ceux du slide deck. On décide quoi migrer, dans quel ordre, et quoi laisser mourir tranquillement.
Poser le socle
Cluster, réseau, stockage, sécurité, GitOps : un socle Kubernetes dimensionné pour votre contexte, pas pour une conférence. Tout est versionné, documenté, reproductible.
Migrer par étapes
Service par service, avec coexistence assumée entre l'ancien et le nouveau monde. Le trafic bascule progressivement, chaque bascule est répétée, réversible, avec un plan de rollback testé. La prod ne s'arrête pas.
Transférer l'autonomie
Runbooks, documentation, montée en compétences pendant la mission, pas en PowerPoint de fin. Je pars quand vos équipes opèrent la plateforme sans moi.
Sur le terrain
Pas de promesses hors-sol : des articles qui montrent comment je travaille, sur de vrais systèmes.
Karpenter ou Cluster Autoscaler : au-delà des groupes de nœuds
Le Cluster Autoscaler reste prisonnier des groupes de nœuds préconfigurés. Karpenter provisionne l'instance exacte dont le pod a besoin, sans ce détour.
Classes QoS : l'ordre d'éviction que personne n'a choisi
La classe QoS d'un pod fixe son ordre d'éviction, déduite des requests/limits, jamais choisie explicitement. Un service critique sans limits part en premier.
GitOps avec ArgoCD : le déploiement déclaratif expliqué
Comment ArgoCD réconcilie en continu l'état du cluster avec Git, la différence entre push et pull deployment, et ce que la dérive (drift) révèle vraiment.
GitOps à l'échelle : ApplicationSets, le piège du tenant
Gérer un Application ArgoCD par service tient à dix équipes. À cent, ApplicationSets automatise la génération, mais déplace le vrai problème d'isolation.
Format de mission
- En direct avec moi, du cadrage à la bascule : pas de sous-traitance, pas de junior facturé senior.
- Sur site (axe Lille–Bruxelles) ou à distance, selon les phases.
- Découpage en jalons : chaque étape laisse l'infrastructure dans un état stable, documenté et réversible.
- Peut démarrer par le diagnostic de 5 jours ci-dessous : le plan vous appartient ensuite, avec ou sans moi.
Questions fréquentes
- Faut-il couper la production pour migrer ?
- Non. La migration se fait service par service, avec une coexistence entre l'ancienne infrastructure et le cluster. Chaque bascule de trafic est progressive, préparée par des répétitions, et réversible : le plan de rollback est testé avant, pas improvisé pendant.
- Kubernetes n'est-il pas surdimensionné pour une structure comme la nôtre ?
- Parfois, oui, et le diagnostic sert précisément à le dire. Si votre contexte appelle une solution plus simple, c'est ce que la restitution recommandera. Vous achetez un avis d'ingénieur, pas une plateforme.
- Nos équipes ne connaissent pas Kubernetes. On devient dépendants de vous ?
- C'est l'inverse qui est prévu : le transfert d'autonomie est la dernière étape de la méthode, et il se prépare dès la première. Vos équipes participent à la migration, les runbooks et la documentation sont livrés au fil de l'eau, et la mission se termine quand elles opèrent seules.
- Combien de temps dure une migration ?
- Cela dépend du périmètre, et toute réponse avant l'audit serait un chiffre inventé. C'est exactement ce que le diagnostic de 5 jours produit : un plan en jalons, avec un ordre de migration et des étapes dont chacune a une valeur propre. Vous pouvez vous arrêter à n'importe quel jalon avec une infrastructure plus saine qu'avant.
- Pourquoi un indépendant plutôt qu'une ESN ?
- Vous savez qui fait le travail. Une ESN vend un dispositif, avec ses intermédiaires et sa rotation de profils ; ici, la personne qui audite est celle qui migre, et celle qui décroche quand quelque chose se passe mal. Et l'objectif de la mission n'est pas de durer : le transfert d'autonomie fait partie de la méthode, pas des options.
- Ça tient aussi à plusieurs clusters ou plusieurs équipes, pas juste une seule appli ?
- Oui, et c'est même là que la discipline posée dès le départ paie le plus : isolation multi-équipes sur la même plateforme GitOps, rollout coordonné entre plusieurs clusters ou régions. Poser ces bases correctement dès une seule application évite de tout reprendre quand la deuxième arrive.