PodDisruptionBudget : contre quoi il protège vraiment
Ce qu'un PodDisruptionBudget garde : évictions volontaires, pas crashs de nœud, minAvailable contre maxUnavailable, et les erreurs qui bloquent les drains.
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.
Requests et limits Kubernetes : throttling, OOMKill et QoS
Ce qui se passe vraiment quand un pod Kubernetes dépasse sa limite CPU ou mémoire, les classes QoS, le débat des limites, et une méthode de réglage.
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.