Une fois la décision prise de migrer vers Kubernetes (couvert dans le cadre de décision PME-ETI), une deuxième question précède toutes les autres : qui opère le cluster. Un service managé (EKS, GKE, AKS) et un cluster auto-géré (kubeadm, k3s, ou l’équivalent sur votre propre infrastructure) ne déplacent pas la même charge de travail vers le même endroit.

Ce que le fournisseur managé prend réellement en charge

Les trois grands fournisseurs gèrent le control plane (API server, etcd, scheduler, controller-manager) : sa haute disponibilité, ses montées de version, ses correctifs de sécurité. C’est un vrai transfert de responsabilité, pas cosmétique : etcd mal opéré est une des causes les plus fréquentes d’incident cluster majeur, et c’est précisément la partie qui disparaît de votre liste de préoccupations.

# Ce qui reste identique, quel que soit le fournisseur :
# kubectl parle au même control plane, avec les mêmes verbes
kubectl get nodes
kubectl apply -f deployment.yaml

Ce que le control plane managé ne couvre pas, dans les trois cas : les nœuds worker restent votre responsabilité pour le dimensionnement, les mises à jour d’OS, et souvent une partie non négligeable de la sécurité (patchs kernel, configuration CIS Benchmark). EKS Fargate, GKE Autopilot et AKS Automatic poussent l’abstraction plus loin en gérant aussi les nœuds, au prix d’une flexibilité réduite sur ce qui peut tourner dessus (DaemonSets et privilèges élevés souvent restreints ou interdits).

Le coût caché de l’auto-géré : le temps, pas seulement les serveurs

Un cluster auto-géré élimine les frais de gestion du control plane facturés par le fournisseur (de l’ordre de quelques dizaines à une centaine d’euros par mois et par cluster selon le fournisseur), mais déplace ce coût vers du temps d’ingénieur : quelqu’un doit maîtriser la mise à jour d’etcd sans interruption de service, la rotation des certificats internes du control plane, et la réponse à un incident sur cette même infrastructure critique, souvent le week-end. Pour un cluster unique de taille modeste, ce temps dépasse largement l’économie réalisée sur la facture ; l’équation s’inverse à mesure que le nombre de clusters grandit, parce que la compétence acquise se répartit sur plus d’infrastructure.

Le vrai critère : la compétence déjà en interne, pas le coût affiché

Une équipe qui opère déjà des serveurs Linux en propre, avec une astreinte rodée et une culture d’exploitation établie, absorbe l’auto-géré à un coût marginal raisonnable : la compétence de base existe, Kubernetes s’ajoute dessus. Une équipe qui n’a jamais opéré d’infrastructure bas niveau paie, avec l’auto-géré, un double apprentissage (Kubernetes et l’exploitation système qui va avec) que le managé absorbe en grande partie à sa place. Le choix se pose différemment aussi selon la contrainte de souveraineté ou de localisation des données : certains contextes réglementés imposent un contrôle total de l’infrastructure sous-jacente que même un service managé sur un cloud public ne satisfait pas.

Ce qui ne change pas selon le choix

Le GitOps à l’échelle, les stratégies de rollout progressif, la gestion des secrets : rien de tout cela ne dépend de qui opère le control plane. Un cluster managé bien exploité et un cluster auto-géré bien exploité convergent vers les mêmes pratiques d’équipe une fois le control plane hors de l’équation ; c’est la partie de la décision qui compte le plus une fois qu’on a choisi, et elle est identique des deux côtés.

À retenir

Le choix entre Kubernetes managé et auto-géré ne se tranche pas sur le prix affiché du control plane, mais sur la compétence d’exploitation système déjà présente en interne et sur des contraintes de souveraineté éventuelles. Un fournisseur managé transfère la charge la plus critique (etcd, API server) contre une facture régulière ; l’auto-géré transfère cette même charge vers du temps d’ingénieur, rentable seulement si la compétence de base existe déjà. Ce choix se pose au tout début d’une migration Kubernetes, avant même le premier service migré.