Publié le 6 février 2020, mis à jour le 25 octobre 2023.
Pour migrer l’ensemble de votre infrastructure informatique sur Kubernetes, le plus dur, c’est de se lancer.
On vous facilite un peu la tâche en vous expliquant par quel bout attaquer cet ambitieux projet, quelles sont les étapes à ne pas rater et quels sont les éléments clés pour réussir sa migration Kubernetes.
La marche à suivre pour une migration Kubernetes réussie
Définir le périmètre de la migration
Il faut avant tout déterminer le périmètre de la migration en auditant l'existant:
- est-ce que je migre l’ensemble de mon infra ou seulement une partie ?
- comment est-ce que je découpe mon infra pour la migrer étape par étape ?
Par exemple, mon infra est composée de 4 APIs A, B, C et D, et je décide de migrer A, B et C sur Kubernetes.
Définir des objectifs clairs
Si la réponse paraît assez intuitive, il est essentiel de prendre le temps d’y réfléchir en équipe car de là, découlent toutes les actions et la définition des priorités du projet.
Pour définir les véritables objectifs, vous pouvez commencer par vous poser (entre autres) les questions suivantes :
- pourquoi souhaite-t-on faire une migration Kubernetes ? (réduction des coûts, résilience de l’infra, meilleur environnement de développement ?)
- est-ce que j’ai une contrainte de temps forte ?
- est-ce que j’ai les ressources nécessaires pour migrer à l’heure actuelle ?
- est-ce que l’entreprise est prête à migrer à l’heure actuelle ?
- est-ce que la migration Kubernetes impacte d’autres projets ?
À partir de ces réponses, est-ce que mes objectifs sur le projet sont :
- d’avoir un plan de migration clair et des équipes de devs formées au nouvel environnement ? (pour une migration qui aura potentiellement lieu plus tard)
- d’avoir migré l’ensemble de mon infra sur Kubernetes et d’avoir des équipes de devs autonomes sur le nouvel environnement ?
- d’avoir migré une partie de mon infra sur Kubernetes et d’avoir des équipes de devs autonomes sur le nouvel environnement ?
- d’avoir un environnement de développement satisfaisant ?
Il est important de définir 2 à 3 objectifs maximum pour ne pas s’éparpiller sur les sujets et rester focus sur l’essentiel.
Définir les indicateurs de réussite de ces objectifs
Un bon objectif s’accompagne toujours d’un indicateur de réussite.
Exemples de bons indicateurs :
Objectif |
Date cible |
État |
Indicateur |
En tant qu’Ops j’ai migré l’API avocado |
03/12 |
OK / KO ? |
- les anciens environnements sont éteints - en tant que développeur j’utilise le nouveau flux de déploiement |
En tant qu’Ops je sais recréer un environnement de staging en moins de 10 minutes |
15/12 |
9 minutes |
temps de création d’un environnement de staging |
Définir des jalons pour la migration
À cette étape, on peut commencer à définir les jalons de la migration, c’est-à-dire les étapes principales sur lesquelles il faut travailler avant de pouvoir migrer. Chaque situation est spécifique, mais voilà un exemple de jalons classiques pour une migration Kubernetes :
l’équipe est au courant de la migration |
j’ai une procédure de test |
j’ai dockerisé mon app |
j’ai déployé mon app dans le cluster Kubernetes |
j’ai un plan de migration |
j’ai des logs en place pour le monitoring |
j’ai fait les tests de montée en charge |
J’ai fait la recette de la prod |
D-Day : je migre sur Kubernetes |
De la même manière que pour les objectifs, il faut être capable de définir comment on valide chacun de ces jalons et leur donner une mesure précise.
Exemple sur le dimensionnement :
Jalon |
Date cible |
État |
Indicateur |
ETQOps j’ai fait les tests de montée en charge |
18/04 |
OK / KO ? |
Mon infra tient X utilisateurs en Y temps* |
*avec X et Y à définir selon les besoins de l’équipe
Planifier les jalons dans le temps
Une fois les jalons déterminés, il s’agit de les planifier. Étape délicate car il faut anticiper au maximum les problèmes qu’on sera susceptible de rencontrer, prévoir suffisamment de temps pour chaque étape tout en mettant du rythme pour ne pas démotiver les troupes !
Deux éléments clés pour cette partie :
- anticiper au maximum les dépendances extérieures qu’il peut y avoir sur chaque jalon et les lever le plus tôt possible
- accorder ce planning à la roadmap des développeurs et vérifier qu’il n’y ait pas d’incohérences entre les deux (l’idéal DevOps étant d’avoir une roadmap combinée)
Il existe milles manières de représenter ce planning, avec un niveau de complexité et de détail plus ou moins élevé. Je vous en partage une :
Ici, le niveau d’information est assez épuré (on présente seulement les jalons) mais la représentation permet de voir d’un coup d’oeil où on en est à date. Est-qu’on est dans les temps ? Est-ce qu’on a pris du retard ? Quel est l’impact sur les autres jalons et le projet au global ?
Il est possible d’afficher davantage de détails, par exemple :
- les dépendances extérieures pour chaque jalon
- les problèmes rencontrés et les causes du retard
… etc
Décliner les jalons en tâches quotidiennes
Une fois le plan de vol en place, reste à passer au niveau de granularité le plus élevé : le découpage en tâches.
Plus les tâches techniques seront découpées finement, plus elles feront ressortir les problématiques techniques et nous pousserontt à nous poser les bonnes questions et à identifier rapidement les dépendances externes.
Pour appréhender les (très) nombreuses tâches qu’implique une migration Kubernetes, travailler en mode agile (avec des sprint d’une à deux semaines) permet d’entamer ce grand chantier par petits bouts tout en ayant des guidelines (les jalons) précises.
De nombreux outils permettent de créer et gérer ses tâches au quotidien, notamment Trello (simple et intuitif) ou JIRA (plus complet et complexe).
Suivre l’avancée au jour le jour
Il faut maintenant faire les tâches ! Il est important de faire un suivi quotidien et de mettre à jour les outils de suivi, au niveau micro (les tâches) et macros (les jalons) pour toujours être au clair sur :
- où on en est
- ce qu’il reste à faire
- où a-t-on rencontré des problèmes
- où va-t-on rencontrer des problèmes
Les éléments clés de la réussite
L’équipe
Sans aucun doute le facteur de réussite le plus important.
Pour constituer une équipe solide, les questions à se poser sont les suivantes :
- est-ce que les membres de l’équipe sont motivés par la migration Kubernetes et prêts à s’impliquer ?
- est-ce qu’ils sont experts ou maîtrisent suffisamment les technos et l’infrastructure ?
- est-ce qu’ils ont dégagé du temps de leurs tâches quotidiennes ?
Si le niveau d’expertise n’est pas suffisant ou s’il n’y a pas d’équipe Ops en place, on peut toujours se faire aider par des acteurs extérieurs : par des équipes expertes de Kubernetes, par des freelances...
Le deuxième réflexe à avoir en amont du projet est d’identifier les acteurs clés dans l’entreprise (PM/PO, Lead Dev, Sponsor...) et les préparer à la migration Kubernetes : quel est son intérêt, quelle est la timeline, sur quels points on aura besoin de leur aide.
Lever les dépendances externes
Anticiper au maximum les dépendances externes permet de les lever rapidement et de ne pas se retrouver bloqué pendant plusieurs jours ou plusieurs semaines au milieu du projet.
Quelques exemples :
- est-ce que je sais qui est présent quand ? (je connais les congés de l’équipe, les jours sur lesquels l’équipe travaille sur la migration…)
- est-ce que toute l’équipe a les accès nécessaires pour le projet ?
- est-ce que mes jalons sont indépendants de la roadmap dev ?
Impliquer les développeurs
Dans une optique DevOps, il est important d’impliquer les développeurs le plus tôt possible : la migration va les impacter et changer leurs habitudes de travail. Plus tôt on les inclut dans le projet, en communiquant, en les formant, en produisant de la documentation qu’ils pourront utiliser, plus la transition sera simple.
Se remettre en question
Se lancer sur une migration Kubernetes, c’est souvent ouvrir une douzaine de boîtes de Pandore simultanément. Et face à toutes ces problématiques qui remontent soudainement, on a vite tendance à s’enfoncer dans les détails techniques. Attention à prendre du recul sur les sujets, à se remettre en question et à se challenger en permanence sur :
- quel est notre objectif ?
- quelle est notre priorité ?
- est-ce qu’on est en train d’aller dans la bonne voie ?
- est-ce qu’on se pose les bonnes questions ?
Un bon moyen de prendre du recul est de se faire challenger régulièrement (à chaque sprint par exemple) par une personne (tech ou non-tech) qui ne prend pas part au projet sur le plan technique, mais qui connaît bien les enjeux et les problématiques (le CTO, un coach agile...).
La théorie est simple, la pratique l’est moins : une migration Kubernetes implique d’avoir de longues discussions sur les enjeux techniques, une architecture claire en tête, de savoir comment gérer les imprévus et les dépendances, contourner ou résoudre tel problème technique… et autres joies du quotidien d’un Ops ! Le message à retenir de cet article, c’est qu’avoir des outils clairs de gestion de projet est certes important, mais que l’humain derrière est essentiel : motiver l’équipe, impliquer les développeurs, se challenger, former et communiquer sont les clés d’une migration Kubernetes réussie !