Migration Kubernetes : bonnes et mauvaises raisons

Tous les comités de direction veulent en parler. Tous les CV en font une compétence à mettre en avant. Les conférences techniques en mettent à toutes les sauces.

Et pourtant, quand on regarde de plus près, une migration Kubernetes réussie se joue largement avant le premier cluster : dans le cadrage des objectifs, des prérequis et de la trajectoire des équipes. Les organisations qui prennent ce temps de cadrage en tirent une plateforme solide et un vrai retour sur investissement. Celles qui le sautent accumulent une complexité évitable : un cluster qui tourne, mais une équipe qui rame et des coûts qui grimpent. C’est précisément ce travail de cadrage en amont que nos missions de conseil structurent avec nos clients, pour sécuriser la décision comme l’exécution.

Cet article propose une grille de lecture honnête. Quand passer à Kubernetes. Quand ne pas y aller. Et surtout : quoi régler avant même de poser la question. Notre angle est issu de nos missions de conseil et d’accompagnement.

À garder en tête en lisant cet article. Les points développés ici ne représentent qu’un échantillon volontairement réduit des sujets qu’une migration Kubernetes soulève. Chacun mérite un approfondissement détaillé, propre à votre contexte technique, organisationnel et métier. L’objectif de cet article est d’ouvrir des pistes de réflexion et de donner des repères de décision. Il ne saurait, à lui seul, tenir lieu de feuille de route stratégique : construire cette feuille de route demande un diagnostic dédié, que nos équipes Axians mènent en mission d’audit et d’accompagnement.

Migration Kubernetes : les trois promesses qui justifient le pas

Avant de trancher pour ou contre une migration, remettons à plat ce que la plateforme apporte réellement. Trois promesses tiennent la route en production : l’automatisation, la haute disponibilité, et le passage à l’échelle. Le reste du discours marketing dérive en général de ces trois axes.

Migration Kubernetes et automatisation : la promesse des Operators

En effet, le pattern operator est probablement la promesse la plus sous-estimée. Un operator est un controller qui encode le savoir-faire d’un DBA / SYS Admin / Data Scientist spécialisé dans une logique de réconciliation continue (le pattern Operator). Précisément, l’opérateur lit l’état désiré dans des objets Kubernetes (CustomResourceDefinitions), compare avec l’état réel du cluster, et applique les changements nécessaires pour les rapprocher. En boucle, à l’infini, sans intervention humaine.

À titre d’exemple, l’operator CloudNativePG est parlant pour nos clients PostgreSQL. Concrètement, il automatise le provisioning, les backups, la PITR, les upgrades minor et major, le failover automatique et la réplication multi-AZ. Sur Docker pur, vous écrivez ces routines à la main, vous les maintenez, et vous priez pour qu’elles se déclenchent au bon moment. Nous avions documenté l’usage de cet operator dans PostgreSQL sur Kubernetes avec CloudNativePG.

Nous accompagnons nos clients à la montée en compétence de l’Opérateur CNPG ; n’hésitez pas si vous souhaitez en discuter formulaire de contact,

Toutefois, cette automatisation ne tombe pas du ciel. Choisir un bon Opérateur demande de la rigueur (communauté active, tests d’upgrade, observabilité native, modèle de licence). Or, quand il est bien choisi et bien opéré, vous gagnez plusieurs jours-homme par mois sur l’exploitation. En somme, c’est pour beaucoup d’équipes la vraie raison qui justifie le passage.

La haute disponibilité réelle de Kubernetes

Pourtant, la haute disponibilité reste l’argument le plus mal employé. En effet, beaucoup de migrations s’appuient dessus, mais sans en payer le prix réel. Concrètement, une vraie HA Kubernetes commence par au moins trois nœuds control-plane, distribués sur des zones de panne indépendantes (datacenters, baies, alimentations électriques). C’est ce que recommande la doc Kubernetes officielle sur la topologie HA.

Pourquoi trois et pas deux ? Parce que la couche d’état du cluster (etcd) repose sur l’algorithme de consensus Raft (raft.github.io). Concrètement, Raft demande un quorum strict pour valider toute écriture : floor(n/2) + 1.

Prenons trois cas pour fixer les idées. Avec trois membres, le quorum est deux, et le cluster tolère la panne d’un seul nœud. En revanche, avec cinq membres, le quorum monte à trois, et on tolère deux pannes simultanées. À l’inverse, avec deux membres seulement, le quorum est deux : la panne d’un seul nœud bloque tout.

Si la mécanique vous intrigue, la visualisation Raft de The Secret Lives of Data explique tout cela en visualisations interactives. C’est probablement la meilleure ressource pédagogique sur le sujet.

En pratique, une vraie HA Kubernetes demande plusieurs briques. D’abord, trois control-plane sur trois sites distincts. Ensuite, des liens réseau de faible latence (sub-10 ms entre etcd). Puis des disques SSD / NVMe locaux performants pour etcd. Un load balancer dédié pour l’apiserver. Des workers répartis sur les mêmes zones. Enfin, un système de stockage distribué pour les volumes persistants. En revanche, si votre infrastructure ne peut pas livrer ces prérequis, ne vous faites pas d’illusions, votre cluster Kubernetes n’aura pas une meilleure disponibilité qu’un déploiement Docker bien paramétré.

Le passage à l’échelle horizontal

Le scaling horizontal de Kubernetes répond à une demande claire. Concrètement, multiplier les instances d’une application en fonction de la charge, sans intervention humaine.

Deux composants travaillent ensemble pour cela. D’abord, le HorizontalPodAutoscaler ajuste le nombre de pods à partir de métriques (CPU, mémoire, ou métriques custom via le Custom Metrics API). Ensuite, le ClusterAutoscaler provisionne des nœuds supplémentaires quand les pods n’ont plus de place où atterrir.

Toutefois, attention à l’écueil classique sur le scaling : penser que tout workload bénéficie automatiquement de cette élasticité. C’est faux. En effet, une application stateful, mono-écriture, avec une « sticky session » ou une dépendance forte à un cache local, ne se duplique pas en deux clics.

Concrètement, le scaling horizontal demande des applications conçues pour. Stateless ou correctement externalisées. Idempotentes sur leurs traitements. Supportant la coexistence de versions différentes le temps d’un rolling update.

Migration Kubernetes et API extensible : la promesse parfois sous-estimée des CRDs

Les trois promesses précédentes sont les arguments commerciaux les plus visibles. Voici une quatrième promesse qui pèse lourd dans le quotidien des équipes mais qu’on entend moins en réunion direction : l’API Kubernetes est massivement extensible. Et dans une organisation où la gestion de multiples APIs internes finit par devenir chaotique, c’est souvent la promesse qui fait pencher la balance.

Nous accompagnons nos clients sur l’étude de transition vers Kubernetes; n’hésitez pas si vous souhaitez en discuter formulaire de contact,

Le piège de la prolifération des APIs internes

En pratique, avant Kubernetes, beaucoup d’organisations finissent par accumuler des couches d’APIs internes. Une API maison pour provisionner des VMs. Un script Ansible pour configurer un load balancer. Une UI custom pour gérer les certificats. Côté backups, un wrapper Bash dédié. Pour la rotation des secrets, un job Jenkins. Et pour publier les flux DNS, encore un autre script Python.

Et chaque outil a son auth, son format de configuration, son cycle de vie, ses bugs spécifiques. Concrètement, l’équipe qui hérite de cette stack passe plus de temps à maintenir le glue code qu’à livrer de la valeur métier.

Dans ces contextes, l’argument clé pour la migration Kubernetes n’est ni la HA ni le scaling. C’est la consolidation : une seule API, un seul modèle de droits (RBAC), un seul langage déclaratif (YAML), un seul outil d’audit (kubectl + audit logs). Tout devient un objet manipulable de la même manière. Sauvegardable de la même manière. Versionnable de la même manière dans Git.

Les CRDs : votre API étendue avec la même rigueur que le core

Précisément, le mécanisme qui rend ça possible repose sur le système des CustomResourceDefinitions (CRDs). Une CRD permet d’enregistrer un nouveau type d’objet dans l’API Kubernetes, avec sa propre validation OpenAPI, ses permissions RBAC dédiées, et sa propre logique de réconciliation portée par un controller (souvent appelé operator). Cet objet est ensuite manipulable via kubectl, stockable dans Git, déployable via Argo CD ou Flux, observable via les events Kubernetes, exactement comme un Deployment ou un Service.

Quelques exemples qui illustrent l’éventail :

cert-manager : ajoute des objets Certificate, Issuer, ClusterIssuer. Vous demandez un certificat Let’s Encrypt avec un YAML de 10 lignes, le controller s’occupe du renouvellement et de la rotation.
external-secrets : synchronise un Vault, un AWS Secrets Manager ou un Azure Key Vault vers des Secrets natifs Kubernetes. Vos applications consomment des secrets standards, sans coupling au backend.
cloudnative-pg.io (CloudNativePG) : un objet Cluster PostgreSQL déclare la topologie souhaitée, le controller monte 3 instances en streaming replication, gère les backups WAL, applique les upgrades.
ArgoCD lui-même est un controller : ses objets Application et AppProject sont des CRDs synchronisées en continu avec un repo Git.
Knative, Crossplane, Istio : tous étendent l’API avec leurs propres objets pour le serverless, l’IaC multi-cloud et le service mesh.

L’effet cumulatif est puissant. À la fin, votre cluster héberge votre métier ET vos outils de plateforme dans un même modèle déclaratif.

La valeur de cette consolidation ne se voit pas immédiatement après la migration. Elle se voit deux ans plus tard, quand il faut recruter ou former une nouvelle personne. Concrètement, cette personne apprend une seule technologie pour devenir productive sur l’ensemble de l’écosystème. Plutôt que de maîtriser cinq outils maison documentés dans cinq wikis distincts.

Les raisons qui ne suffisent pas à justifier une migration Kubernetes

Voici les motivations qu’on voit le plus souvent en première intention, et qui ne tiennent pas la route à elles seules. Aucune de ces raisons n’est à pointer du doigt : ce sont des symptômes valides. Le problème, c’est de croire que Kubernetes les guérira tout seul.

« On a déjà beaucoup de containers Docker »

Pourtant, le nombre de containers en production n’est pas un indicateur de maturité Kubernetes. Par exemple, une stack Docker Compose avec quarante services peut tourner parfaitement sur deux serveurs bien dimensionnés, supervisés par Watchtower ou Diun, et sauvegardés correctement. En revanche, un cluster Kubernetes mal dimensionné, même avec seulement cinq pods, peut se retrouver à genoux sur un simple OOM kill du kubelet.

À retenir : le critère pertinent n’est pas le nombre de containers. C’est : votre Docker actuel répond-il aux exigences de disponibilité, de scaling, de sécurité et d’opérabilité que votre métier vous impose ? Si oui, le nombre de containers est un faux problème. En revanche, si non, attaquez-vous d’abord aux exigences en question, séparément de la question Kubernetes.

« On va recréer le cloud chez nous »

C’est probablement la plus dangereuse des mauvaises idées. Elle se traduit par cette phrase qu’on entend souvent en mission : « on va tout mettre sur Kubernetes ». La stack d’observabilité. GitLab. Vault. Les applications métier. L’outil de documentation. Le SSO. Keycloak. Les bases de données.

D’abord, sur le papier, ça semble cohérent : un seul plan de contrôle, une seule logique opérationnelle, une seule équipe.

En pratique, vous reconstituez un IaaS interne, avec une dette opérationnelle équivalente à ce que vous fuyiez.

Voici quelques exemples concrets. GitLab Runner sur Kubernetes ajoute une dépendance circulaire : vous ne pouvez plus pousser le manifeste qui répare le cluster si GitLab tombe avec le cluster. Vault sur Kubernetes demande des secrets pour démarrer, ce qui pose un problème d’amorçage. Une stack Prometheus + Loki + Tempo + Grafana à scaler correctement représente facilement 30 à 50 % des ressources nodes du cluster. Et le jour d’un incident sérieux, vos outils d’observabilité tombent en même temps que ce qu’ils sont censés observer.

À retenir, la règle pragmatique : Kubernetes pour les workloads métier, et pour le reste, envisagez sérieusement d’externaliser ou de garder une infrastructure dédiée. Un GitLab managé chez SaaS ou auto-hébergé sur une VM dédiée vous coûtera moins cher en exploitation qu’un GitLab dans le cluster qui consomme des ressources et complique chaque postmortem.

« Tout le monde fait du Kubernetes »

La pression sociale est un argument de migration parfois inavoué. En effet, les recruteurs exigent du Kubernetes sur les CV. Par ailleurs, les conférences ne parlent que de cela. Les directions, elles, craignent de paraître en retard. Et les équipes ont peur de perdre des compétences si elles n’y vont pas.

Toutes ces inquiétudes sont compréhensibles. Mais aucune n’est une raison technique de migrer.

Concrètement, une organisation qui adopte Kubernetes par peur accumule de la dette technique sans capter de valeur. Si la décision est purement défensive, mieux vaut assumer une stratégie alternative. Concrètement : Docker bien fait, avec une infrastructure stable et des équipes formées en interne. Et garder Kubernetes comme option, à activer le jour où un besoin réel le justifiera.

Ce qu’il faut adresser avant la migration Kubernetes

Voici la partie qui change tout. Avant de provisionner le moindre cluster, trois questions doivent trouver une réponse. Si elles ne sont pas résolues, votre migration Kubernetes ne fera qu’aggraver les problèmes.

L’état réel de votre chaîne CI/CD

En effet, Kubernetes est conçu pour des cycles de déploiement courts. En particulier, l’écosystème GitOps (Argo CD, Flux) tire pleinement parti de cette plasticité. Couplé à un projet comme argocd-image-updater (argoproj-labs), vous obtenez un pipeline qui détecte les nouvelles images du registry, met à jour automatiquement les manifests, et synchronise le cluster. Cette boucle complète, du commit à la production, peut tomber sous la dizaine de minutes.

Toutefois, cette belle mécanique suppose que votre chaîne CI/CD existe et qu’elle fonctionne. Et dans la réalité, ce n’est pas toujours le cas.

En effet, plusieurs scénarios bloquent. Vous êtes en environnement air-gapped (sans accès Internet sortant). Le déploiement se fait par tarball poussé à la main sur les serveurs. La mise à jour d’une image demande une demande de change validée par trois personnes en quatre jours. Au final, dans ces cas, Kubernetes ne va pas vous aider. Il va simplement vous donner un mécanisme plus complexe pour faire la même chose, lentement.

À retenir : le bon réflexe est progressif. Avant la migration Kubernetes, investissez d’abord dans une registry interne accessible. Pour les contextes air-gapped, déployez-la au moins en DMZ. Ensuite, automatisez la promotion d’images entre environnements. Enfin, validez que vos équipes peuvent déclencher un déploiement sans grande cérémonie. Concrètement, une fois ces briques en place, Kubernetes devient un accélérateur. En revanche, avant cela, c’est une couche supplémentaire qui ralentit tout.

Nous accompagnons nos clients sur la mise en conformité des chaines CI/CD; n’hésitez pas si vous souhaitez en discuter formulaire de contact,

L’architecture applicative

En pratique, une partie significative des plantages en production ne vient ni de Docker ni de Kubernetes. Elle vient de l’application elle-même ou du dimensionnement de l’infrastructure.

Concrètement, voici les coupables typiques. Un mauvais paramétrage de pool JDBC. Une fuite mémoire dans un worker. Une configuration de logs qui sature un disque. Un service qui dépasse son allocation CPU et se fait killer par le scheduler.

Or, ces problèmes existent sous Docker. De même, ils existeront aussi sous Kubernetes. En effet, ils seront plus difficiles à diagnostiquer, parce qu’il y a une couche de plus à investiguer.

À noter, avant de migrer, faites l’inventaire honnête : combien de vos incidents production viennent d’un défaut applicatif réparable directement (paramétrage, code, sizing) et pas de l’orchestrateur ? Donc, si la majorité de vos pannes ont une cause applicative, Kubernetes ne les résoudra pas. À noter : investir d’abord dans la fiabilité applicative donne souvent un meilleur retour que la migration.

Ce travail de remise à plat a un nom : c’est de la modernisation applicative, et elle a de la valeur indépendamment de toute migration Kubernetes. Externaliser un état, corriger un pool de connexions, instrumenter correctement une application, revoir un dimensionnement : autant de chantiers que nous menons en accompagnement avec nos clients, qu’un projet Kubernetes suive ou non. Bien souvent, c’est même par là qu’il faut commencer.

La culture des équipes

En effet, Kubernetes n’est pas une technologie qu’on apprend en un week-end. Concrètement, comprendre vraiment la chaîne complète (apiserver, scheduler, controller-manager, kubelet, kube-proxy, CNI, CSI, RBAC, NetworkPolicy, PodSecurityStandards, admission webhooks,…) demande plusieurs mois d’usage régulier en production. De plus, un débutant Kubernetes qui prend une décision d’architecture peut produire des dégâts qui ne se voient qu’à l’incident.

Si votre équipe est composée de bons sysadmins Docker, mais que personne n’a opéré du Kubernetes en production, attention. La migration doit s’accompagner d’un programme de formation sérieux. Et d’un compagnonnage par des profils expérimentés.

À défaut, vous obtiendrez un cluster qu’aucun membre de l’équipe n’ose toucher. Et au premier incident sérieux, vous appellerez à l’aide. Sur ce point précis, nous reviendrons en fin d’article.

Migration Kubernetes : choisir sa distribution selon votre contexte

Une migration Kubernetes commence aussi par le choix de la distribution. Kubernetes vanilla, K3s, distributions managées chez les hyperscalers, OpenShift, Rancher : chaque option correspond à un profil d’organisation. Se tromper de distribution coûte plusieurs mois de retard.

Kubernetes vanilla et kubeadm

Pour qui veut comprendre la plateforme en profondeur, vanilla via kubeadm reste la référence pédagogique. Concrètement, vous gérez chaque composant explicitement. Vous voyez où sont les certificats. Vous comprenez la chaîne complète.

Toutefois, c’est aussi l’option qui demande le plus de compétences. Upgrades manuelles. Monitoring du control-plane. Intégration des add-ons (CNI, ingress, monitoring) à votre charge. À retenir : bon choix pour les équipes qui veulent tout maîtriser. En revanche, mauvais choix si vous cherchez à livrer vite.

K3s pour les environnements légers et la périphérie

K3s est une distribution Rancher pensée pour la légèreté : binaire unique d’une cinquantaine de Mo, etcd remplaçable par SQLite ou MySQL, démarrage en quelques secondes, faible consommation mémoire. En pratique, c’est notre choix pour beaucoup de labs internes, de POC clients et de cas edge computing (industrie, retail, IoT). Par ailleurs, le code source est conformal Kubernetes, donc vos manifests passent sans modification vers une distribution plus robuste le jour où la prod l’exige. En revanche, à éviter pour des charges très lourdes : ce n’est pas le compromis pour lequel le projet a été conçu.

Distributions managées : EKS, AKS, GKE

Quand l’organisation est à l’aise avec un cloud public, les distributions managées simplifient le démarrage. AWS EKS, Azure AKS et Google GKE délèguent la gestion du control-plane à l’hyperscaler.

En pratique, vous payez quelques dizaines de dollars par mois et par cluster pour ne plus gérer apiserver, etcd, scheduler. GKE Autopilot va encore plus loin. Il provisionne aussi les nœuds workers selon les pods.

C’est l’option avec le plus haut levier opérationnel. À condition que la culture cloud existe déjà dans l’équipe. Et que la facturation usage-based soit acceptable.

Attention au piège des distributions managées : croire que « managé » signifie « sans compétences ». Faux. Configurer correctement un EKS demande de connaître IAM, VPC peering, RBAC, IRSA, security groups. Plus la liste des add-ons à installer : CNI, EBS CSI driver, autoscaler, ALB controller. Le control-plane est managé. Le reste ne l’est pas.

OpenShift et Rancher : les distributions opinionées

Red Hat OpenShift et SUSE Rancher embarquent un Kubernetes vanilla enrichi de composants intégrés. Ingress (HAProxy ou Nginx). Monitoring (Prometheus, Grafana). Logging. Registre interne. Builds (Tekton ou OpenShift Pipelines). Et une UI complète pour les développeurs.

OpenShift impose ses choix techniques. PSS très restrictifs par défaut. Certifications. Support 24/7. Et il facture en conséquence : licence par nœud ou par socket. Cela peut représenter plusieurs dizaines de milliers d’euros annuels selon la taille du cluster.

Précisément, le bon profil OpenShift, c’est l’organisation régulée. Elle veut un produit packagé avec un support contractuel, et peut absorber le coût de licence. Le bon profil Rancher, c’est l’équipe qui veut une UI multi-cluster sans enfermement commercial. Le cœur Rancher est open-source.

Avant de vous engager sur ces distributions, évaluez sérieusement l’alternative kubeadm + add-ons à la carte. Cette voie reste viable pour des équipes solides.

Migration Kubernetes : le coût d’une heure d’indisponibilité comme critère

Concrètement, s’il fallait garder un seul critère pour trancher, ce serait celui-ci : quelle perte représente une heure d’indisponibilité de votre application ? En effet, cette question force la conversation à sortir du registre technique pour entrer dans le registre métier.

À titre d’exemple, prenons un cas concret. Un site de vente de fleurs en ligne le 14 février représente 30 à 40 % du chiffre d’affaires annuel de la marque, concentré sur 72 heures. Une heure d’indisponibilité ce jour-là, c’est plusieurs centaines de milliers d’euros perdus. Plus l’effet réputationnel auprès des clients qui n’ont pas reçu leur commande.

Donc, pour ce profil d’application, investir dans une vraie HA Kubernetes est mathématiquement justifié. Comprenez : 3 control-plane multi-DC, stockage répliqué, load balancers redondants, observabilité 24/7. Concrètement, le coût annuel d’opération du cluster, même conséquent, reste inférieur au coût d’une seule indisponibilité majeure.

À l’inverse, un outil interne RH consulté trois fois par mois par cinq personnes ne justifie pas le même investissement. Une indisponibilité de quatre heures un samedi matin n’a aucun impact métier. Pour ce type d’application, la vraie HA Kubernetes serait un gaspillage de budget. Concrètement, un docker-compose sur une VM avec un backup nocturne suffit largement.

Concrètement, le calcul à faire avant la migration : (coût moyen d’une heure d’indisponibilité) × (nombre d’heures d’indisponibilité par an évitées par K8s) > (coût annuel d’opération du cluster). Donc, si l’inéquation n’est pas satisfaite, la migration n’est pas rentable. Toutefois, cette formule est volontairement caricaturale, mais elle force le bon dialogue avec le métier avant de signer la décision.

Le vrai coût d’une migration Kubernetes au-delà des serveurs

Le devis initial d’une migration Kubernetes ne reflète quasiment jamais le coût total d’opération. Voici les postes systématiquement sous-estimés par les directions techniques en phase d’évaluation.

L’overhead infrastructure du control-plane et des add-ons

Un cluster Kubernetes consomme des ressources avant même de démarrer un pod applicatif. Trois nœuds control-plane, le CNI, le DNS interne (CoreDNS), le metrics-server, l’ingress controller, le monitoring, le logging, le ServiceAccount controller, le scheduler. Comptez 2 à 4 vCPU et 4 à 8 GiB de RAM par nœud worker juste pour ces composants, sur lesquels vous ne déploierez aucune application métier. À l’échelle d’un cluster de 10 nœuds, c’est 20 à 40 % de vos ressources qui partent dans la plomberie.

Les Requests et Limits mal calibrés

Le scheduler Kubernetes alloue les pods en fonction des resource requests déclarées (QoS). Trop basses, vos pods se retrouvent en compétition CPU et throttlés. Trop hautes, vous gâchez de la capacité que personne n’utilise; nous abordons ce point en détail dans notre formation « Introduction à Kubernetes et aux Opérateurs ».

Une étude récurrente du FinOps Foundation est révélatrice. La majorité des clusters d’entreprise tournent avec un taux d’utilisation effectif des ressources allouées entre 15 et 40 % (voir le FinOps Foundation – Kubernetes Working Group).

Atteindre un bon taux demande des outils dédiés. VerticalPodAutoscaler. KubeCost. Goldilocks. Et de la rigueur de gouvernance que peu d’équipes mettent en place dès le départ.

La dette opérationnelle : upgrades, certifs, CVE

Kubernetes publie une nouvelle version mineure tous les quatre mois environ. La fenêtre de support officielle est de 14 mois. Pour rester sur une version supportée, vous devez planifier au moins un upgrade par an. Parfois deux.

Chaque upgrade demande de tester les CRDs custom. Vérifier la compatibilité de vos add-ons. Suivre la deprecation des APIs (v1beta1 supprimées en pagaille).

À cela s’ajoutent les CVE régulières. Du control-plane. Du kubelet. De containerd. Du CNI. Des controllers tiers. Sur une infrastructure Docker stable, ce coût n’existe quasiment pas.

Le coût humain : formation, recrutement, attrition

Les certifications CKA, CKAD et CKS demandent chacune plusieurs jours de préparation. Et environ 400 € de frais par certification. Ajoutez la formation continue : KubeCon, conférences, veille technique.

Sans oublier le risque d’attrition. Un bon opérateur K8s reçoit régulièrement des sollicitations sur LinkedIn. Ce coût humain est très réel. Et il pèse plus lourd que la facture cloud sur trois ans.

Migration Kubernetes et complexité opérationnelle

En effet, Kubernetes ajoute une couche d’abstraction. Cette couche apporte des bénéfices, mais elle a aussi un coût en complexité opérationnelle qu’il faut nommer.

Migration Kubernetes : le débogage devient une discipline à part entière

En pratique, sur Docker, déboguer un service qui plante consiste à enchaîner quelques commandes. docker logs. docker inspect. docker exec -it sh. Et la lecture des logs systemd de l’hôte. En général, trois ou quatre commandes suffisent à comprendre ce qui se passe.

À l’inverse, sur Kubernetes, le même diagnostic peut nécessiter d’enchaîner plusieurs commandes :

kubectl describe pod pour les events,
kubectl logs avec le bon container,
kubectl get events --sort-by pour la chronologie,
kubectl exec pour rentrer dans le pod,
kubectl get networkpolicy pour vérifier le trafic,
kubectl get rolebinding pour les permissions,
et parfois kubectl debug avec une image éphémère pour inspecter un container distroless.

Par ailleurs, quand on ajoute le service mesh, l’ingress, et les CRDs custom, le scope explose. En théorie, un opérateur Kubernetes confirmé maîtrise ces réflexes. En pratique, un débutant se retrouve perdu.

Quand Docker reste pertinent

Au final, cela peut sembler hérétique pour un article qui parle de Kubernetes. Toutefois, c’est probablement la conclusion qu’on tire le plus souvent en mission de conseil. Docker en production reste une solution efficace, à condition d’être bien opéré.

Voici les ingrédients d’un Docker en bonne santé. Une stack Docker Compose avec supervision propre. Des sauvegardes régulièrement testées. Une registry interne. Des images figées en version sémantique. Des healthchecks. Un reverse proxy correctement configuré. Tout cela tient des années sans incident majeur.

À retenir : une partie des migrations Kubernetes gagnent à être précédées de six mois d’effort sur l’existant Docker. Mais distinguer les cas où Docker suffit encore de ceux où Kubernetes apporte une vraie valeur n’a rien d’une évidence : c’est un diagnostic, et c’est exactement l’objet de l’audit d’opportunité que nous menons avec nos clients.

Migration Kubernetes pour les workloads IA en 2026

En effet, un argument fait franchement basculer la balance en 2026 : Kubernetes devient la plateforme de référence pour les workloads d’inférence et d’entraînement de modèles. Trois évolutions concrètes l’ancrent dans cette position.

Dynamic Resource Allocation et le partage GPU

À l’origine, l’écueil historique de Kubernetes pour l’IA résidait dans la consommation grossière des ressources spécialisées. En effet, un GPU était assigné en bloc à un pod, sans possibilité de le partager finement entre plusieurs workloads. Dynamic Resource Allocation (KEP-4381) change cette mécanique. Précisément, DRA permet aux pods de demander des ressources arbitraires et structurées, dont le partage de GPU (MIG sur NVIDIA, time-slicing, allocation par mémoire VRAM). À noter, cette feature est passée en stage stable (GA) sur Kubernetes 1.34 et est activée par défaut depuis. Donc, pour qui exploite des GPU coûteux, c’est un changement majeur de modèle de coût.

Kubeflow et l’écosystème ML

Kubeflow chez la CNCF est en stage incubating depuis juillet 2023. Le projet fournit une plateforme de bout en bout pour les pipelines ML.

Kubeflow Pipelines : orchestration des entraînements,
Katib : hyperparameter tuning,
KServe : serving des modèles,
Notebooks : environnement Jupyter pour les data scientists.

À retenir : l’écosystème reste actif en 2026. Cependant, certains signaux invitent à la prudence (croissance ralentie des contributeurs). À retenir : la maturité de l’outillage ML sur Kubernetes est aujourd’hui sans commune mesure avec ce que vous trouvez sur Docker pur.

vLLM et le serving de modèles à grande échelle

Concrètement, pour le serving d’inférence LLM, le projet vLLM s’est imposé comme la référence open-source. Le repo officiel embarque le chart Helm officiel de vLLM, et le projet vLLM Production Stack (annoncé janvier 2025) fournit une stack production complète avec router, autoscaling, observabilité et cache distribué KV. En pratique, vous pouvez déployer un endpoint compatible OpenAI sur votre cluster en quelques heures. En somme, c’est typiquement un cas où la migration Kubernetes prend tout son sens : le couplage GPU + scaling + observabilité + GitOps fait gagner un temps considérable par rapport à un montage docker run sur un serveur dédié.

Donc, si vos prochaines feuilles de route incluent du déploiement de modèles, même de taille modeste, la question de la migration Kubernetes mérite d’être posée sérieusement. Par ailleurs, pour ce qui touche à l’inférence LLM, ne jamais oublier que les contraintes de mémoire VRAM et de latence imposent des choix d’architecture spécifiques que nous traitons dans nos missions de conseil. À titre d’exemple complémentaire, distribuer du contenu read-only à un pod nginx via monter une image OCI comme volume Kubernetes illustre une autre facette de la flexibilité Kubernetes pour les workloads modernes.

Migration Kubernetes progressive : pourquoi le Big Bang échoue

Une fois la décision prise d’engager une migration Kubernetes, comment l’exécuter sans tout casser ? La pire approche est le Big Bang : geler la prod Docker un vendredi soir, basculer le trafic sur Kubernetes le lundi matin.

Les retours d’expérience que nous voyons sur ce type de bascule sont systématiquement douloureux. Incidents en cascade. Rollback impossible parce que les bases de données ont déjà migré. Équipes sur le pont 72 heures. Confiance ébranlée pour les six mois suivants. Évitez.

Le pattern Strangler Fig

Le pattern le plus solide est emprunté à Martin Fowler : Strangler Fig Application (Martin Fowler). L’idée : faire grandir progressivement une nouvelle infrastructure (Kubernetes) à côté de l’ancienne (Docker), et basculer service par service en commençant par les moins critiques. Le routage entre les deux infrastructures se fait au niveau d’un load balancer ou d’un reverse proxy (Nginx Proxy Manager, Traefik, HAProxy). À chaque service migré, vous validez sur quelques jours en production que tout fonctionne, puis vous démantelez l’ancienne version. Au bout de quelques mois, l’ancienne infra a disparu sans qu’aucune bascule risquée n’ait eu lieu.

Lift-and-shift, replatform ou refactor ?

Trois stratégies de migration coexistent, et il faut choisir consciemment laquelle s’applique à chaque service.

Lift-and-shift : on prend le docker-compose et on le traduit en manifests Kubernetes équivalents, sans rien changer côté applicatif. Rapide à exécuter, faible valeur ajoutée. Bon pour démarrer la migration et démontrer la faisabilité.
Replatform : on adapte légèrement l’application pour tirer parti de Kubernetes. Externaliser les sessions vers Redis, sortir les logs vers stdout, accepter SIGTERM proprement, ajouter readiness/liveness probes. Effort modéré, valeur réelle dès le scaling horizontal.
Refactor : on retravaille l’architecture pour le cloud-native. Découper en plusieurs services, basculer vers une architecture événementielle, ajouter de l’observabilité OpenTelemetry. Effort élevé, valeur maximale, mais ne pas s’engager sur ce chemin sans budget en conséquence.

La bonne pratique : commencer par lift-and-shift sur 2 ou 3 services peu critiques pour valider la chaîne, puis replatform progressivement, et garder le refactor pour les nouveaux services développés directement cloud-native. Tenter le refactor sur l’ensemble du parc en même temps est la garantie d’un projet qui dépasse deux fois son budget initial.

L’écueil du multi-cluster prématuré

Un piège récurrent : démarrer la migration Kubernetes en provisionnant tout de suite trois clusters. Dev, staging, production, sur trois environnements distincts.

Sur le papier, c’est propre. En pratique, vous triplez la charge opérationnelle. Avant même d’avoir validé que vous savez opérer un seul cluster.

Notre recommandation : commencer par un cluster unique, multi-namespace. Avec des ResourceQuotas et NetworkPolicies pour isoler les environnements. Vous gagnez en simplicité, vous formez vos équipes. Et vous repoussez la complexité multi-cluster aux moments où elle apporte vraiment de la valeur. Souveraineté de la donnée. RPO/RTO différenciés. Multi-cloud.

Migration Kubernetes : les cas où il vaut mieux différer

En pratique, voici les profils où nous recommandons à nos clients de ne pas engager de migration Kubernetes :

Application stable depuis plusieurs années, charge prévisible, pas d’évolution majeure prévue dans les 24 mois.
Équipe qui maîtrise Docker sereinement, sans personne avec une expérience Kubernetes production.
Coût d’une heure d’indisponibilité inférieur à quelques milliers d’euros, RTO de 4 à 8 heures acceptable.
Environnement régulé (santé, défense, finance) où chaque composant ajouté demande une recertification de sécurité.
Budget contraint qui ne permet pas d’investir 6 à 12 mois dans la formation et la mise en place.

En effet, dans ces cas, une stack Docker bien opérée délivrera, à court terme, plus de valeur métier qu’un Kubernetes en surcouche. Faire ce choix en conscience demande une certaine maturité, parce qu’il va à contre-courant de la mode. C’est pourtant souvent la bonne décision à l’instant T. Un point important toutefois : « pas maintenant » ne veut pas dire « jamais ». Le bon réflexe est alors de préparer le terrain, en travaillant la chaîne CI/CD, la fiabilité applicative et la montée en compétences des équipes, pour que la question se repose plus tard dans de bonnes conditions. Nos missions d’accompagnement couvrent aussi cette phase de préparation : c’est elle qui rend une future migration nettement plus sûre et plus rapide le jour où elle devient pertinente.

Migration Kubernetes : une décision de gouvernance avec des moyens concrets

En revanche, si vous décidez de partir, mettez les bonnes conditions de réussite dès le premier jour. En effet, la migration Kubernetes échoue rarement pour des raisons techniques. Concrètement, elle échoue parce que la décision a été prise sans engagement de gouvernance, sans budget de formation, sans temps protégé pour les équipes. À retenir : c’est un investissement organisationnel autant qu’un investissement technique.

Un sponsorship direction explicite et durable

Une migration Kubernetes qui se présente comme un sujet « d’équipe ops » sans sponsor au comité de direction se cassera la figure dès le premier arbitrage budgétaire.

Concrètement, la direction doit acter explicitement. « Nous migrons vers Kubernetes pour ces raisons précises. Sur cet horizon. Avec ce budget. Et nous acceptons de moins livrer sur d’autres sujets le temps de la transition. »

En effet, sans cet engagement écrit et communiqué, les équipes seront sommées de tout faire en parallèle. Et la migration deviendra le fil le plus facile à couper au premier trimestre tendu.

Un plan concret de montée en compétences

Attention au mythe le plus dangereux : « on va apprendre en faisant ». En pratique, on apprend Kubernetes correctement uniquement avec une stratégie de formation structurée. Voici ce que nous mettons en place dans nos missions d’accompagnement, et qui marche en pratique :

Formation initiale : 3 jours pour l’ensemble de l’équipe technique impactée. Pas seulement les ops, aussi les développeurs et le management qui doit comprendre les arbitrages.
Certification ciblée : viser la CKA pour 1 ou 2 personnes pivots dans les 6 mois. La certification force un niveau de rigueur que la pratique seule n’apporte pas, et c’est mesurable.
Compagnonnage avec un profil expérimenté : pendant 3 à 6 mois, un consultant ou un prestataire qui revoit les choix d’architecture, les manifests, les incidents. Cette présence accélère la courbe d’apprentissage de manière spectaculaire.
Du temps protégé : 20 à 30 % du temps des équipes alloué officiellement à la migration et à la montée en compétences pendant 6 à 12 mois. Sans ce temps protégé, la migration ralentit pendant que la dette technique s’accumule.
Un environnement de pratique : un cluster lab dédié, ne servant pas la production, où les équipes peuvent casser des choses et apprendre. K3s convient parfaitement à cet usage.

Mesurer la réussite : KPIs et garde-fous

En effet, une migration Kubernetes sans indicateurs de succès est une migration où personne ne sait quand s’arrêter. Concrètement, définissez en amont un petit nombre de KPIs lisibles par la direction et par les équipes :

Nombre de services migrés / total prévu (avec dates jalons réalistes).
Temps moyen de déploiement avant et après migration.
Nombre d’incidents production par mois liés à l’orchestration (objectif : retrouver le niveau pré-migration dans les 6 mois après bascule, pas immédiatement).
Coût opérationnel mensuel cluster (ressources cloud + licences + formation) versus coût pré-migration.
Score de confort de l’équipe sur les outils Kubernetes (sondage simple trimestriel, à faire évoluer).

En pratique, ces KPIs servent à arbitrer. En effet, si après 12 mois le confort équipe ne progresse pas, c’est un signal d’alerte. De même, si les incidents ne diminuent pas, c’est un autre signal. Soit il manque de la formation, soit du compagnonnage. Soit la décision elle-même mérite d’être réexaminée.

Mieux vaut admettre tôt qu’on s’est trompés et corriger. Plutôt que continuer à investir par cohérence avec une décision passée.

Conclusion : une décision réfléchie, jamais subie

En somme, la migration Kubernetes n’est pas une réponse universelle, ni un passage obligé. En effet, c’est une décision technique, financière et culturelle qui mérite d’être prise lucidement. D’abord, faites le calcul réel du coût d’une indisponibilité métier. Ensuite, inventoriez vos incidents passés et leur cause racine. Puis, mettez à plat votre chaîne CI/CD, votre culture d’équipe, vos contraintes d’environnement. Enfin seulement, posez la question : Kubernetes est-il la meilleure réponse ?

À noter : « non » et « pas tout de suite » sont des réponses légitimes, au même titre que « oui, maintenant ». Le coût d’attendre 18 mois pour mûrir un sujet est souvent inférieur à celui d’une migration mal préparée. Dans tous les cas, cette décision gagne à être instruite avec un partenaire qui a déjà vu plusieurs trajectoires aboutir, dans un sens comme dans l’autre. C’est tout l’intérêt de l’audit d’opportunité que nous présentons ci-dessous : repartir avec une recommandation argumentée et un plan d’action clair, quelle que soit la réponse.

Aller plus loin sur la migration Kubernetes avec Axians

Si cet article vous a fait douter de votre projet de migration, ou au contraire confirmé que Kubernetes est la bonne direction, parlons-en. Axians est certifié Kubernetes et accompagne des organisations de toutes tailles sur leurs sujets cloud-native, en production, sur des clusters qui portent du trafic réel.

À ce titre, notre angle pour cet article : nous proposons un audit d’opportunité. Concrètement, l’objectif est de trancher en quelques semaines si Kubernetes est pertinent dans votre contexte, et d’identifier les pré-requis à adresser avant tout démarrage.

Audit d’opportunité : analyse de votre stack actuelle, chiffrage du coût d’indisponibilité, recommandation argumentée pour ou contre la migration.
Modernisation applicative et conteneurisation : avant même la question Kubernetes, nous accompagnons la remise à niveau des applications et la montée en compétence des équipes sur Docker et la conteneurisation. C’est souvent le chantier qui débloque le plus de valeur à court terme.
Accompagnement : plan de migration applicatif, gouvernance, adaptation des pratiques Dev / Ops. Nous travaillons avec vos équipes existantes, pas à leur place.
Formations Kubernetes : trois formats, dont notre best-seller « Introduction à Kubernetes et aux opérateurs », « Kubernetes pour la production » (Helm, ArgoCD), et « CNPG Operator » (Axians est référencé par EnterpriseDB comme support officiel).
MCO Kubernetes : trois niveaux d’engagement, du coup de pouce ponctuel (Silver) à l’astreinte 24 / 7 avec SLA stricts (Platinium), en passant par la supervision en heures ouvrées (Gold).

En pratique, une heure d’échange suffit en général à clarifier votre situation. Vous pouvez nous joindre via le formulaire de contact, ou directement à votre interlocuteur Axians habituel.