D'ECS à EKS : leçons pratiques d'une migration
Il y a un moment dans la vie de chaque ingénieur où il change d'outils cloud en se disant : « Ça ne peut pas être si terrible. » Pour de plus en plus de monde, ce moment arrive lors du passage d'AWS ECS (Elastic Container Service) à EKS (Elastic Kubernetes Service). Ça ressemble à une évolution naturelle, puisque ce sont deux services d'orchestration de conteneurs sous la bannière AWS. Qu'est-ce qui pourrait mal tourner ?
Eh bien, beaucoup de choses. Et aussi… beaucoup de choses se passent bien, ce qui est tout le paradoxe de Kubernetes.
La lune de miel : rêves de scripts avec Terraform
On commence avec de bonnes intentions. Au milieu d'un fil Reddit rempli de récits de guerre Kubernetes, un utilisateur a parfaitement résumé la situation :
« J'ai tout scripté dans Terraform pour que ce soit reproductible, mais amorcer un tout nouveau cluster paraît bien lourd pour une mise à niveau de version mineure. »
Exactement, et c'est là que tout commence. Vous vous sentez organisé, armé d'Infrastructure as Code, prêt à conquérir le monde. L'époque d'ECS allait bien, peut-être trop bien, parce qu'elle masquait une grande partie des détails ingrats. En passant à EKS, vous gagnez en visibilité et en contrôle, mais vous ouvrez aussi une boîte de Pandore faite de YAML, de CRD et d'états mystérieux.
De la clarté au chaos : quand K8s riposte
Un autre commentateur a lâché cette perle :
« K8s m'a aidé à forger mon caractère. »
C'est un mécanisme d'adaptation plus qu'un compliment, et pourtant c'est aussi très vrai. Kubernetes déploie votre appli et, au passage, il met à l'épreuve votre patience, votre compréhension des systèmes distribués et parfois votre sens de l'identité.
Une mise à niveau de cluster déraille, et d'un coup vous vous retrouvez avec 78 pods coincés dans les limbes du « pending », sans logs ni événements, rien d'autre que des impressions. Comme l'a noté un utilisateur avec ironie : « Un pod ne peut pas ne plus répondre s'il est en pending. » Techniquement vrai, et émotionnellement dévastateur.
L'attrait d'EKS : de la stabilité dans le chaos
Malgré tout ce drame, beaucoup d'ingénieurs préfèrent vraiment EKS. Un utilisateur est intervenu pour dire :
« EKS va te simplifier la vie ☺️ Pareil pour moi (ECS vers EKS). »
C'est ça le plus fou. Une fois passé la lassitude du YAML, la rage contre les charts Helm et les cauchemars de kubectl describe pod, EKS offre bien quelque chose qu'ECS n'a pas : un terrain de jeu doté d'une vraie puissance.
Avec ECS, vous êtes enfermé dans la vision simplifiée des conteneurs selon AWS. Avec EKS, c'est vous qui menez la danse, avec des groupes de nœuds, des autoscalers, des service meshes et plus encore. C'est AWS qui vous dit : « Voilà Kubernetes. Essayez de ne pas vous blesser. »
Le budget calvitie : ce que coûtent vraiment les mises à niveau
Même les mises à niveau mineures n'ont rien de mineur. Des utilisateurs plaisantaient sur le fait qu'une mise à niveau de cluster tient moins de la « mise à niveau » que de « l'expérience spirituelle ». Quelqu'un a demandé à un autre s'il lui restait des cheveux, ce qui est une question légitime.
Et puis il y a le sommeil. Un commentateur a répondu « Quel sommeil ? », comme si Kubernetes lui volait activement ses cycles de sommeil paradoxal, et c'est parfois le cas. Un Persistent Volume Claim bloqué pendant la mise à niveau d'un pool de nœuds peut ressembler à une blague cosmique, sauf que vous ne riez pas. Vous rafraîchissez la page d'état toutes les 10 secondes.
L'humour Kubernetes : quand la douleur fait rire
Ce qui rend la communauté Kubernetes vraiment à part, c'est son humour noir partagé. Un utilisateur a répondu à une AMA sérieuse sur les mises à niveau par :
« Est-ce qu'etcd a consenti à ce changement ? »
C'est le genre d'humour pince-sans-rire que seuls les gens de K8s apprécient. Un autre a enchaîné :
« Il y avait un quorum, mais toutes les parties n'étaient pas d'accord. »
Ce mélange de précision technique et d'épuisement émotionnel fait toute la richesse du parcours EKS. Vous souffrez, mais vous n'êtes pas seul. Vous déboguez, puis vous en faites un mème.
Qu'est-ce qui fait que ça en vaut la peine ?
EKS en vaut la peine. Malgré la courbe d'apprentissage raide, le contrôle et la souplesse que vous offre Kubernetes sont sans égal. ECS vous a peut-être simplifié la vie à court terme, mais EKS ouvre la voie à une vraie maturité cloud native. Vous pouvez adopter GitOps, faire des déploiements sans temps d'arrêt, dimensionner finement, et tout cela d'une manière pour laquelle ECS n'est tout simplement pas conçu.
L'un des meilleurs conseils est venu d'un utilisateur qui l'a exposé sans détour :
« Tu gardes la configuration du cluster dans Terraform et tout ce qui relève de k8s en dehors de Terraform. Honnêtement, les mises à niveau ne posent en général aucun problème. La 1.24 était une grosse étape. Ça dépend de ce que tu fais tourner comme vieilleries. »
Autrement dit, définissez bien vos limites. Sachez ce qui a sa place dans Terraform et ce qui a sa place dans vos manifestes Kubernetes, et sachez toujours, toujours, vers quelle version vous faites la mise à niveau.
Pour conclure : bienvenue au club
Passer d'ECS à EKS, c'est comme passer de la conduite d'une Toyota Camry à la construction de votre propre véhicule tout-terrain. La Camry était fiable, mais un peu ennuyeuse. Désormais, c'est vous qui contrôlez et repoussez les limites, mais vous devrez aussi réparer vous-même vos crevaisons en chemin.
Kubernetes mettra votre patience à l'épreuve, vous fera douter de vos choix et vous obligera de temps à autre à devenir un magicien du YAML à 2 h du matin. Mais il vous apprendra aussi comment les systèmes distribués fonctionnent sous le capot, et ce genre de pouvoir vaut bien la douleur.
Alors bienvenue dans le monde magnifiquement chaotique de Kubernetes. Vous allez le détester, et puis, allez savoir comment, vous ne voudrez plus jamais le quitter.