En moins d’une décennie, Kubernetes est devenu un standard dans l’informatique moderne. Toutes les grandes entreprises qu’elles soient technologiques ou pas l’utilisent pour héberger tout leur système d’informations. Et c’est bien normal, car cette technologie comporte bon nombre de fonctionnalités comme de l’auto-remédiation ou du scaling horizontal et vertical pour assurer qu’une infrastructure soit résiliente et élastique à la charge. Cependant, est-elle l’unique solution actuelle pour répondre à ces besoins ? Quelles sont les limites de Kubernetes et l’avantage de ces concurrents ?
Table des matières
Les faiblesses de Kubernetes
Eco-système trop complexe
Kubernetes est construit pour être une immense API extensible à l’infini afin de lui ajouter des fonctionnalités. C’est pourquoi, après l’installation fraîche d’un cluster, certaines d’entre elles sont absentes ou peu exploitable en l’état. Il faut souvent commencer son aventure Kubernetes en installant un contrôleur Ingress (pour gérer l’exposition des applications en HTTPS) ou bien encore un fournisseur de stockage (pour les volumes persistants). De plus, pour rajouter des services annexes de monitoring, de sécurité ou autre, c’est encore vers d’autres technologies qui vous faudra vous tourner.
Tous ces compléments vont d’une part vous demander de les maîtriser techniquement, de savoir les installer, les configurer et de les maintenir à jour. De plus, ces composants vont avoir besoin de ressources processeur et mémoire ce qui va augmenter la facture mensuelle de votre cluster.
Changement de méthodologie de déploiement
Avec Kubernetes, on change radicalement de philosophie par rapport à ce qu’on faisait 10 ans en arrière. Le temps où la mise en production d’une application était juste une simple copie des fichiers source d’un serveur vers un autre est terminée. Il faut maintenant compiler le code, construire une image, la pousser dans un registre et changer la version dans les manifestes.
Aurait-on régresser par rapport à ce qu’on faisait avant ? Pas si cette rupture s’accompagne d’un vrai outillage compatible aux nouvelles coutumes. Utiliser Kubernetes sans mécanisme d’intégration continue et de livraison automatisées est, pour moi, une immense aberration. La construction d’un vrai workflow GitOps est nécessaire tant pour le gain de temps que pour la confiance et la sérénité gagnées dans vos déploiements. Cependant, cela engendre de nouvelles technologies à maîtriser et des coûts supplémentaires.
Coût trop élevé
Afin d’assurer la résilience et la mise à échelle, Kubernetes, comme n’importe quel système de cluster, va demander plus de ressources que nécessaire. Si on rajoute à ça, le surplus technologique quasiment obligatoire évoqué au premier paragraphe, on arrive très vite à une addition très salée pour héberger pas grand chose. Et même les solutions managées (GKE, EKS, AKS, etc…) qui offrent un peu plus de flexibilité au niveau de la taille du cluster (provisionnement automatique des noeuds, instances ponctuelles) peuvent être très chères si le budget n’est pas correctement géré.
De plus, pour pouvoir maintenir cette infrastructure, il faut une équipe dédiée et correctement formée à cette technologie. En attendant l’arrivée sur le marché du travail de profils de techniciens (bac+2/3) spécialistes du domaine, ce genre de mission est donné à des profils ingénieurs ce qui fait vite grimper la masse salariale.
La force de ces concurrents
Mais d’abord qui sont-ils ? Pour moi, les principaux concurrents de Kubernetes sont les services de PaaS (Platform as a Service), de FaaS (Function as a Service) ou de CaaS (Container as a Service). J’exclue ici les Kubernetes-like comme Openshift ou Nutanix Karbon, car elles souffrent des mêmes symptômes que leur grand frère.
Le PaaS et le FaaS sont assez similaires puisque il s’agit de code informatiques qui vont être déployé et exécutés dans des environnements cloisonnés. Le FaaS sont des environnements éphémères destinés à produire une action après un événement donné alors que le PaaS est destiné à des applications plus permanentes (sites Web, backend). Le CaaS quant à lui permet d’exécuter une image d’un conteneur donnée.
Voici une petite liste non-exhaustives des services du genre:
| PaaS | FaaS | CaaS |
|---|---|---|
| Amazon App Runner | Amazon Lambda | Amazon Elastic Container Service |
| Azure App Service | Azure Functions | Azure Container Apps |
| DigitalOcean App Platform | DigitalOcean Functions | DigitalOcean App Platform |
| Google App Engine | Google Cloud Function | Google Cloud Run |
| Heroku | ||
| Vercel |
Le premier avantage des ces services est la simplicité d’utilisation. On se connecte, on configure et hop en 10 minutes, c’est plié ! Tout est pris en charge (load balancer, certificats TLS, etc…), pas besoin de connaître la technologie derrière (même si c’est à 99% de chances un conteneur dans un cluster Kubernetes), ça juste marche. Adieu les mises à jour nocturnes avec un cierge allumé pour pas que tout casse et les migrations de datacenters le dimanche. Egalement pour les PaaS et les FaaS, vous n’avez même pas à créer une image Docker pour votre application ce sont les plateformes qui font le travail pour vous ! Elle est pas belle la vie ?
Bien sûr toutes ces avantages de complexité ont un prix sur votre liberté d’action. Par exemple, les platformes FaaS supportent peu de langages de programmation, c’est un peu mieux pour les CaaS car vous disposez d’une liberté totale pour vos images Docker.
Le plus gros avantage de ces plateformes est le prix : pour seulement quelques euros par mois, vous pouvez héberger votre application et bénéficier de la mise à échelle automatique ou d’un certificat TLS. Attention, cependant aux coûts cachés de certaines plateformes pour avoir des métriques sur votre service ou un nombre limite de déploiement par mois.
Pourquoi Kubernetes gagne à la fin
Bien que concurrents sont féroces, leur cas d’usage ne s’étend pas aussi loin que celui de Kubernetes.
Infrastructure self-hosted / hybride
Premièrement, ces services sont tous hébergés dans des datacenters qui ne vous appartiennent pas donc cela pose un problème de confidentialité du code source de votre application et/ou des données potentiellement sensibles qui y transitent.
Kubernetes, par son universalité et par la faible puissance de calcul demandée, peut être lancée sur n’importe quelle machine du RaspeberryPi à un serveur ultra puissant en passant par des instances Cloud.
Applications Stateful
D’autres part, les services vus à la partie précédente ne peuvent héberger que des application sans état (stateless). Votre application devant être scalable et résiliente, il est impossible de garder les données qui sont éventuelles créées lors de l’exécution de votre programme (cache, fichiers de logs, etc …). Oubliez donc l’idée d’héberger une base de données dessus, ça ne marche pas ! Il faudra plutôt vous tourner vers des services Cloud spécialisés (MongoAtlas, CloudSQL, etc…).
Kubernetes, lui il s’en fout ! Bon pas vraiment car il est plus beaucoup plus simple de gérer des services sans états que le contraire. Mais, avec les StatefulSets et les volumes persistants, faire tourner une base de données sur Kubernetes est largement possible et utilisable en production.
Votre logique business dans Kubernetes
On vient sûrement au cas d’usage qui est le plus puissant même si ce n’est pas le premier auquel on pense. Kubernetes est une API extensible permettant d’implémenter votre logique business au sein de votre Infra. Vous pouvez créer, par exemple, une nouvelle ressource personnalisée appelée « Client » qui une fois sur le cluster, permet de gérer une feuille de style personnalisée ou une nouvelle entrée DNS.
C’est une méthode assez universelle s’appliquant dans quasiment tous les cadres et qui vous permet de profiter des mécanismes offertes de base par Kubernetes comme la reconciliation. Associé à du GitOps, vous pouvez effectuer des actions et lancer des services juste en modifiant un simple fichier dans un repo git.
Conclusion
Kubernetes, bien qu’étant assez peu facile d’accès, se présente bien comme une solution complète et sans faille pour supporter une infrastructure globale. Cependant, pour des premières phases de développement d’une application, les plateformes PaaS / FaaS vous permettront d’héberger vos services plus facilement en faisant des économies.