Je n’avais pas besoin de Kubernetes, et vous non plus probablement

(benhouston3d.com)

19 points par GN⁺ 2024-11-28 | 12 commentaires | Partager sur WhatsApp

Pourquoi j’ai quitté Kubernetes pour choisir Google Cloud Run

Contexte de l’adoption de Kubernetes

Sur la plateforme d’édition 3D en ligne Clara.io, lancée en 2013, l’infrastructure avait été optimisée avec des serveurs bare metal, mais la gestion du matériel et la supervision demandaient un travail excessif.
En 2018, Kubernetes a été choisi pour le projet Threekit.com. À l’époque, Azure, AWS, Docker adoptaient Kubernetes comme standard, ce qui l’a imposé dans le courant dominant.

Les limites de Kubernetes

Problème de coût :
- Le coût de base pour mettre en place un cluster est élevé, avec les nœuds de gestion, la redondance du cluster, etc.
- L’auto-scaling lent oblige à surprovisionner les services, ce qui génère des coûts liés à des ressources inutilisées.
Difficulté à gérer les workloads :
- L’ordonnancement des tâches est complexe, et le scheduler intégré comme Argo sont inefficaces à grande échelle.
Surcharge de complexité :
- La richesse fonctionnelle rend complexes même les tâches simples.
- L’administration de Kubernetes nécessite des équipes DevOps dédiées, ce qui augmente encore les coûts.

Passage à Google Cloud Run

Cloud Run remplace la complexité de Kubernetes par un environnement plus simple et plus rentable.

Nouvelle configuration

Infrastructure basée sur des conteneurs Docker :
- Inclut des services avec auto-scaling et des conteneurs pour les tâches de longue durée.
- Cloud Run automatise le déploiement des conteneurs, le scaling, la gestion des interruptions et l’exécution des tâches.

Les avantages de Cloud Run

Efficacité des coûts :
- La facturation dépend du temps d’utilisation du CPU et de la mémoire.
- Les services inactifs ne coûtent rien.
- Exemple : le site Web3D Survey peut gérer 500,000 visites par mois pour 4 $/mois.
Auto-scaling rapide et fiable :
- Le scaling s’effectue en quelques secondes, plus rapidement qu’avec Kubernetes.
- Cela permet d’absorber rapidement les pics de demande.
Aucune charge d’administration Kubernetes :
- Cloud Run repose sur Borg de Google, ce qui évite d’avoir à gérer un cluster Kubernetes.
Tâches asynchrones simplifiées :
- Avec Cloud Run Tasks, il est facile d’exécuter des traitements massifs avec reprise automatique en cas d’échec.

Problème potentiel de Kubernetes : le verrouillage sur le cluster

Dépendre des fonctionnalités de Kubernetes rend plus difficile l’intégration ou l’extension avec des ressources externes au cluster.
On finit par dépendre d’une infrastructure spécifique, ce qui complique l’extension et la migration tout en augmentant les coûts.

Questions fréquentes sur l’usage de Cloud Run

« Vous n’êtes pas inquiet d’une dépendance à GCP ? »

Avec une configuration basée sur Docker, une migration vers un autre cloud comme AWS est possible en environ une semaine.
En pratique, en dehors de facteurs politiques, il est rare de changer de fournisseur cloud.

« Cloud Run n’est-il pas au final un Kubernetes managé ? »

Cloud Run utilise l’interface Knative, mais fonctionne sur Borg de Google, et non sur Kubernetes.
Il élimine la complexité de Kubernetes et fournit une interface simplifiée.

Inconvénients du workflow actuel

Gestion peu pratique des noms de service :
- Une couche d’abstraction est nécessaire pour maintenir une configuration cohérente en local et sur le serveur.
- Les capacités de gestion des noms de Kubernetes sont absentes.
Manque d’émulation pour Cloud Run Task :
- Il n’existe pas d’environnement d’émulation simple en local pour développer des tâches, notamment pour capturer et suivre les logs.

Conclusion

Cloud Run est la meilleure solution du point de vue du coût, de la vitesse, de la scalabilité et de la simplicité
Pour les grandes entreprises ou les besoins complexes, Kubernetes peut rester pertinent, mais
Pour les projets où simplicité et efficacité priment, Cloud Run est bien plus pratique
PS : il serait peut-être possible de résoudre ces problèmes en ajoutant certaines extensions à Kubernetes, mais cela ne ferait qu’ajouter de la complexité, et l’auteur ne souhaite pas dépendre d’un environnement Kubernetes surdimensionné par rapport à des besoins simples.

12 commentaires

blurblah 2024-12-01

Il n’existe pas de solution miracle. L’important, c’est sans doute de bien l’utiliser en fonction du contexte haha.
Adopter Kubernetes sans esprit critique simplement parce que c’est tendance peut rendre les choses plus difficiles, mais je pense quand même que c’est un bon outil dans des environnements d’une certaine ampleur.
Même si on l’adopte, si on s’arrête à l’adoption elle-même, on risque de ne pas pouvoir l’utiliser correctement.
Et comme pour n’importe quel outil, il ne peut pas satisfaire à 100 % les besoins des développeurs ou des utilisateurs, donc un niveau d’automatisation approprié me semble indispensable.

bungker 2024-11-29

Une fois Kubernetes mis en place, il ne reste plus qu’à se la couler douce... 😭

riki3 2024-11-29

Kubernetes, c’est mon gagne-pain, et il fut un temps où je croyais que c’était la bonne réponse. Mais plus le temps passe, plus je me retrouve à accumuler les problèmes et à perdre du temps.

Je recommande k8s aux autres, mais je ne pense pas l’utiliser pour mon propre service. Et au-delà de k8s, je suis simplement fatigué des conteneurs eux aussi.

joon14 2024-11-28

Si vous utilisez AWS, on peut considérer que c’est similaire à ECS ?

tujuc 2024-11-29

Oui, c’est bien ça. :)

eclipsense 2024-11-28

Le vrai problème, c’est de ne pas savoir utiliser Kubernetes ; de là à dire que Kubernetes n’est pas terrible, c’est un peu exagéré.

tujuc 2024-11-28

Je pense un peu comme l’auteur.
Notre entreprise n’a pas encore la taille qui justifie l’utilisation de kube non plus.

Je pensais à tort que tous les développeurs pourraient gérer les choses avec Kube.
Au final, il vaut mieux fournir des guides pour mettre en place l’infrastructure et résoudre les problèmes, même à un niveau inférieur à la moyenne des développeurs de l’entreprise...

doolayer 2024-11-28

???: Je n’avais pas besoin de l’IA, et vous non plus, probablement.

ilbanin00 2024-11-28

Quel que soit le produit, il y aura forcément des compromis à faire.

bbulbum 2024-11-28

Comme j’utilisais un service managed, je n’ai pas vraiment eu l’impression que l’administration était difficile…
Je pense que n’importe quel outil est utile tant qu’on l’utilise avec mesure, mais j’ai l’impression que, pour Kubernetes en particulier, c’est surtout le fait de « permettre des configurations complexes » qui est critiqué.