15 février 2019

Kubernetes overdose

Sur le net, en conférence, en entreprise, tout le monde en parle: Kubernetes est sur toutes les lèvres. Il permet de résoudre tous nos problèmes, réchauffement climatique et faim dans le monde inclus (surtout couplé à une architecture microservice !). Quand est-il vraiment en réalité ? Existe-il des alternatives ?

Docker

La route vers Kubernetes commence généralement par Docker. Les entreprises veulent absolument packager leurs applications avec Docker, pour différentes raisons. Parfois, elles pensent que cela simplifiera le packaging de leurs applications (pas de dépendances système, image immutable…​), parfois le déploiement.

Je trouve que Docker est une technologie intéressante, mais comme toute technologie ce n’est pas la solution à tout. J’aimerais que les gens ayant un existant et voulant se tourner vers Docker se posent déjà ces questions:

  • Avez vous une plateforme d’intégration continu ?

  • Pouvez vous mettre en production vos applications à tout moment ? Changer rapidement la version d’une application sur un environnement ?

  • Etes vous capable de reconstruire rapidement un environnement semblable à la prod "from scratch" ?

  • Pouvez vous facilement provisioner de nouveaux serveurs ? Votre infrastructure est-elle totalement automatisée ?

  • Etes vous tolérant aux pannes ?

  • Monitorez-vous vos applications et serveurs (logs, metriques, alertes en cas d’incidents…​) ?

Si vous répondez "non" à ces questions, vous n’avez probablement pas la maturité suffisante pour faire des conteneurs en production. Pensez vous vraiment que rajouter Docker à une architecture bancale réglera vos soucis ?

Pour l’anecdote personnelle, j’ai connu une entreprise qui voulait se mettre à Docker, par contre les outils d’automatisations comme Ansible étaient interdit car trop avancés/compliqués. Et ça, c’est le problème numéro un de Docker: la technologie est souvent utilisée car "aujourd’hui il faut tout passer sur Docker", sans vraiment de justifications.
En passant, c’est la même chose pour les architectures microservices que l’on voit fleurir un peu partout on ne sait trop pourquoi (et qui d’ailleurs viennent souvent avec Kubernetes).

Orchestrateurs

Ca y est, l’entreprise commence à build ses premiers conteneurs, il faut maintenant les déployer. Pas question de lancer des docker run à la main (ou avec Ansible ou autre) sur les machines, il faut un orchestrateur pour les gérer !

Premier problème: aujourd’hui, Kubernetes a littéralement cannibalisé l’écosystème conteneur: Rancher s’est tourné vers Kubernetes, Docker Swarm se rend compatible Kubernetes, on entend plus trop parler non plus de Mesos/Marathon, le seul orchestrateur faisant un peu de résistance étant Nomad de Hashicorp (mais qui reste largement moins populaire que Kubernetes).

J’espère que d’autres solutions arriveront à tirer leurs épingles du jeu. Je ne veux personnellement pas être forcé à utiliser Kubernetes pour l’unique raison que c’est la seule solution sur le marché. De plus, comme je le montrerais ensuite, Kubernetes est une solution complexe à mettre en oeuvre.
Je suis persuadé qu’il existe un marché pour un orchestrateur simple, permettant de déployer des conteneurs sur quelques dizaines ou centaines de noeuds (ce qui couvrirait le besoin de 99 % des entreprises).

L’intégration de Kubernetes dans un existant

Enfin, vous décidez de partir sur Kubernetes. Un grand nombre de gens arrêtent leur analyse ici quand il s’agit de déployer Kubernetes en production.

Pourtant, Kubernetes va amener plein de nouvelles problématiques, par exemple:

  • Comment je monitore les composants de mon cluster ainsi que les conteneurs tournant dessus ?

  • Comment je gère les logs de mes conteneurs ?

  • Comment le gère le cycle de vie de mon Cluster Kubernetes (déploiement, montée de version, ajout/suppression de noeuds…​)

  • Comment je gère mes manifests et le déploiement de ces manifests sur le cluster ?

  • Comment je construis mes images Docker ?

  • Comment je gère le réseau de mon cluster/route vers mes pods/m’intègre avec les services qui sont hors du cluster ?

etes vous prêt à dérouler la pelote de laine Kubernetes ?

Etes vous prêt à dérouler la pelote Kubernetes jusqu’au bout ?

Vous n’utilisiez pas Prometheus pour le monitoring de vos applications ? Pas de chance, c’est plus ou moins l’unique solution aujourd’hui pour monitorer Kubernetes. Votre solution de collecte de logs a du mal à travailler avec Kubernetes ? Là aussi, on vous dira de passer sur fluentd, outil conseillé par la Cloud Native Computing Foundation (CNCF).

Sans trop vous en rendre compte, vous commencez à refondre l’intégralité de votre SI pour intégrer une techno. Ce n’est pas Kubernetes qui s’adaptera à vous, c’est à vous de vous adapter à Kubernetes, et ce coût d’adaptation est généralement élevé.

Gestion du cluster

Et ensuite, il vous restera à trouver comment déployer et mettre à jour le cluster. Je ne crois pas du tout aux solutions comme kops ou kubespray. Ces solutions sont le meilleur moyen de se retrouver avec un cluster configuré de la mauvaise façon: en gros, c’est comme ça qu’on finit avec son cluster ouvert sur Internet.
Ce super article de Julia Evans me confirme dans mon opinion que ces solutions de déploiement de cluster ne sont pas faites pour de la production. C’est seulement en déployant vous même Kubernetes que vous comprendrez comment tous ses composants s’assemblent et se paramètrent.

Ensuite, amusez vous bien avec la gestion des permissions (RBAC). J’espère aussi que vous avez un bon ingénieur réseau sous la main (Calico, Flannel, BGP, VXLAN …​ ça vous parle ?).

Mais c’est pas fini ! Il faut aussi que vous passiez sur Istio/Envoy comme Ingress (c’est votre archi revenant de $CONFERENCE qui vous l’a dit), que vous ajoutiez un outil de tracing (bah oui, sinon comment vous allez analyser performances dans tout ce machin) etc…​

Buzzword driven development

La communauté est responsable de cela.

Jamais on ne parle aux conférences de la difficulté de maintenir un cluster Kubernetes en production, des problématiques de monitoring, des problèmes réseaux ou même des problèmes qu’apportent les systèmes distribués de façon générale…​
Non, on veut faire du "Wahoo", on montre que nous on peut "scaler", on présente de beaux dashboards…​ Peut être aussi parce que pas mal de gens présentant Kubernetes ne l’utilisent en fait pas en production ?

On parle également rarement du pourquoi Kubernetes. Ou alors on l’évoque en disant comme ça je peux déployer facilement plusieurs instances de mon application. Très bien, mais on sait faire cela depuis très longtemps. Qu’apporte vraiment Kubernetes ?

Quand je vais à une conférence et que les talks sur Kubernetes s’enchainent toute la journée, je comprends également que les gens aient l’impression d’être "à la traine" si ils ne font pas eux même du Kubernetes.

C’est le problème avec le buzzword driven dévelopment: ça s’auto alimente. On a des gens qui vont faire du Kubernetes car c’est la techno du moment, et ces gens là parleront ensuite de Kubernetes à des gens qui se diront ah mais moi j’en fais pas, faut que je m’y mette aussi !.

Puis les entreprises s’y mêlent (rien ne me fait plus marrer que les boites qui se vendent en disant nous, on fait du Kubernetes et du microservice comme si c’était un gage de qualité). On commence à voir des offres d’emplois demandant de l’expérience en Kubernetes, les nouveaux projets partent directement sur Kubernetes pour attirer le chaland, et la boucle est bouclée.

On ne parle également jamais des solutions alternatives qui ont fait leurs preuves. Pourquoi cette course en avant sur Docker et Kubernetes alors qu’il est tout à fait possible d’avoir des architectures robustes (et beaucoup plus simples) sans tout cela ?

Je pense également qu’une partie du problème est que ces technologies sont généralement poussées voir mises en place par des développeurs. Quand j’étais en société de service, il était rare de voir de vrais profils ops sur les projets. On avait donc les devs n’ayant jamais gêré un serveur de leur vie qui poussaient allègrement Kubernetes en production.

Enfin, les développeurs ont pris le contrôle de la production

Enfin, les développeurs ont pris le contrôle de la production !

Cela se voit aussi aux conférences "mainstream" (du moins en France): généralement pas d’ops dans les speakers ni dans le public. Le devops en 2019, c’est un développeur Java faisant vite fait du Docker, du Jenkins et qui sait écrire un playbook Ansible.

Commencer par le commencement

Essayez déjà de répondre aux questions que je pose en début d’article. Mettez en place une plateforme de continuous delivery, gérez vos logs et métriques correctement, automatisez le provisioning de votre infrastructure et vos déploiements…​
Cela est 100 % réalisable sans conteneurs et sans Kubernetes (ce sera probablement l’occasion d’un prochain article de ma part).

De plus, faire tourner Kubernetes ne vous dispensera pas de provisioner votre infrastructure de façon automatisée, d’avoir du monitoring solide, une plateforme d’intégration continue efficace…​ Kubernetes viendra en plus de tout cela.

Ce que vous ferez ne sera pas perdu. Vous aurez également toujours des applications qui tourneront en dehors du cluster, qui elles aussi devront être correctement déployées.

Kubernetes as a service

La majorité des entreprises n’ont selon moi pas le besoin (et souvent pas les compétences) de déployer du Kubernetes par elles même. L’avenir est-il sur les solutions de Kubernetes as a service que l’on rencontre de plus en plus ?

Peut être, mais je ne crois pas au tout Kubernetes Il y aura toujours des services et applications en dehors du cluster (car certains trucs n’ont pas d’intêret à être "Dockerisés"). Vouloir partir sur du Kubernetes trop vite est clairement une erreur selon moi.

Conclusion

Kubernetes est une technologie intéressante, et je suis sûr qu’elle résout de nombreux problêmes dans de nombreuses entreprises. Sauf que tout le monde n’a pas les mêmes besoins que Netflix, et ce n’est pas une solution miracle.
Il est également de notre responsabilité de proposer à nos entreprises et clients les technologies permettant de mener à bien un projet, et non de se construire un CV (pratique malheureusement courante).

les grands gagnants de tout cela ? Les sociétés de service. Entre la réécriture des applications monolithiques en microservice, les passages sur Kubernetes, le déploiement et maintien de tout ça en production, c’est le jackpot. Il y a quelques années, la vache à lait était le Big Data et le NoSQL, on peut maintenant rajouter Kubernetes et les microservices.

Le projet avec une architecture simple et efficace qui devrait demander 5 personnes en demande 50 aujourd’hui, pour un truc souvent compliqué à maintenir en prod.

personnes dormant sur un lit de billet

Les commerciaux de votre société de service quand le client accepte la refonte de son application legacy en microservice.

la mode dans pas mal de groupes étant de ne plus recruter de profils technique en interne et de tout déléguer aux sociétés de service n’arrange rien: les entreprises ne sont même plus capables de juger si ce qu’on leur vend est pertinent ou pas. Ce sujet mériterait d’ailleurs un article à lui tout seul…​

En conclusion, ne sautez pas trop vite dans le train Kubernetes. Choisissez vos technologies pour de bonnes raisons.

A suivre.

Tags: devops ansible rant kubernetes
Top of page