Kubernetes ne suffit pas

Comme vous le savez, le cloud Native est au centre de toutes nos discussions ces dernières années. En bref le cloud Native est un ensemble de pratiques et d’outils qui permettent de construire des applications évolutives, résilientes et faciles à gérer dans des environnements de cloud computing. Donc des outils optimisés pour le cloud.

Dont Kubernetes, qui est devenu le standard de facto pour l’orchestration des conteneurs. Mais dans une application cloud native complexe, ou même dans une entreprise standard, Kubernetes ne suffit pas à lui seul. Kubernetes est si on peut le dire, le “chef d’orchestre”, mais si on n’ajoute pas les autres musiciens, le concert ne débutera jamais.

On doit ajouter de l’observabilité, de la sécurité, de la gestion des configurations, du stockage. Ajouter un container registry, un service mesh, des outils de CI/CD, et bien plus encore. Kubernetes est un excellent point de départ pour commencer dans le monde du cloud native, mais si on se met des œillères sur l’existence de ces autres outils. On perd toute la puissance que le monde de la tech nous offre.

Pourquoi Kubernetes ne suffit pas ?

Kubernetes, par définition est un orchestrateur de conteneurs, ni plus ni moins. Il gère le cycle de vie des conteneurs. Donc tout le côté CI/CD, observabilité, stockage… Il dépend totalement d’autres outils pour fonctionner de manière optimale.

Ne me faites pas dire ce que je n’ai pas dit, Kubernetes est un outil exceptionnel, on peut faire du rolling update, du scaling, de la gestion des ressources, de la haute disponibilité, de la résilience. Honnêtement c’est un des outils les plus puissants que j’ai pu utiliser dans ma très courte carrière.

On s’amuse bien avec Kubernetes, on le déploie, on le configure, on installe nos petites applications, on les scale, on les met à jour. Mais si on dézoome un peu, on se rend compte que Kubernetes est juste une partie de l’équation. Il faut penser aussi au déploiement, on ne va pas passer notre vie à lancer des commandes kubectl pour déployer nos applications. Les secrets, les configurations, les mises à jour, la sécurité, l’observabilité… Tout ça doit être pris en compte.

L’écosystème CNCF

Avec cette capture d’écran on est très vite submergé par la quantité d’outils disponibles dans l’écosystème CNCF. Il existe vraiment de TOUT, des options Open Source, des options SaaS, des options payantes. On peut trouver des outils pour la gestion des configurations, la sécurité, l’observabilité, le stockage… La liste est longue.

Avec ce genre de paysage complexe, il est facile de se perdre. On peut vite se retrouver avec une multitude d’outils avec des fonctionnalités qui se chevauchent, des intégrations compliquées, et une gestion de la complexité qui devient ingérable. C’est pour cela qu’il faut simplement connaître les outils disponibles, puis si jamais on a un besoin, on fait une courte étude de marché pour trouver l’outil qui correspond le mieux à nos besoins.

Par exemple voilà à quoi pourrait ressembler un stack vraiment cloud native :

Et j’en oublie sûrement, mais l’idée est là.

Après il ne faut pas être non plus dans l’excès, on n’est pas obligé de tout utiliser. On peut très bien se contenter de Kubernetes, d’un outil de CI/CD, et d’un outil de monitoring. Et ça peut marcher tout aussi bien. L’important est de comprendre que Kubernetes n’est qu’une brique de l’édifice, et qu’il faut l’accompagner d’autres outils pour construire une infrastructure complète et efficace.

Conclusion

Kubernetes m’a beaucoup appris. J’ai adoré découvrir son fonctionnement, le déployer, jouer avec, le casser aussi parfois. Mais au bout d’un moment, je me suis rendu compte d’une chose : Kubernetes, ce n’est qu’un début.

Ce qui compte vraiment, c’est tout ce qu’on construit autour. Les bons outils, les bons choix, la bonne architecture.

Alors si vous commencez avec Kubernetes : bravo. Mais n’oubliez pas de lever la tête, et d’explorer ce que le monde cloud native peut vraiment offrir.