"Kubernetes c’est bien que pour les grosses entreprises", "On est pas Netflix et Google", "Sans milliers de conteneurs ça sert à rien"…​ Vous avez déjà vu ces commentaires sur Kubernetes ? Ces gens ont tout faux. Voici pourquoi.

Mais d’abord, repartons 10-15 ans en arrière, avant 2015 et donc avant Kubernetes.

Docker vient tout juste d’apparaître, et on en voit nulle part en production sauf exception (un peu de Mesos vers 2015).

On voit déjà beaucoup d’outils d’infrastructure as code (Ansible, Puppet, Chef…​) pour gérer la configuration des machines (bare metal ou virtuelles) et le déploiement des applications. Le cloud est bien sûr déjà très présent mais beaucoup de boîtes n’ont pas encore fait leur "move to cloud".

Ce qui est intéressant, c’est que les problématiques étaient similaires à aujourd’hui: on essayait d’avoir des infrastructures tolérantes aux pannes, faciles à administrer, reproductibles, avec des déploiements fréquents, une flexibilité sur la configuration des machines et des applications, autonomie des équipes de dev pour les déploiements…​
Bref, comme aujourd’hui. Et tout ça, on en a besoin même si on ne s’appelle pas Netflix ou Google, dès qu’on a des équipes de développement qui maintiennent plusieurs applications en production on commence à travailler sur ces sujets.

Bref, comment on faisait pour gérer de manière fiable un certain nombre d’applications en production?

Réseau

On va commencer par décrire certains patterns en lien avec le réseau et le load balancing.

On avait souvent un étage de load balancing sur des machines virtuelles, avec HAProxy par exemple. Keepalived, un autre composant installé sur ces machines, permettait d’avoir de l’actif/passif sur les load balancers via une IP flottante qui pouvait se "déplacer" sur un autre noeud en cas de panne du noeud actif.

Ça marche, mais ça reste de l’actif/passif avec un peu de downtime pendant la bascule. Mais ce n’était pas pour moi le plus gros problème concernant le load balancing.

Les règles de load balancing entre plusieurs applications en fonction de préfixes, du nom de domaine (TLS SNI), ou autre en fonction des besoins se faisaient également dans les fichiers de configuration de manière spécifique à chaque outil de load balancing.

Service discovery et rollout

Dans l’exemple montré, on voit qu’il y a 3 instances de l’application derrière le load balancer. Les IP/port de ces backend devaient être dans la configuration du load balancer. Rajouter une nouvelle instance demande de mettre à jour le fichier de configuration.

De la même façon, enlever une instance (même temporairement: en cas de mise à jour de l’application par exemple) était pénible. Pour faire ça proprement, il faut:

On faisait ça par exemple avec Ansible, qui allait faire cette orchestration en plusieurs machines à chaque modification de l’infrastructure. Un rollout complet en cas de nouvelle version d’une application pouvait se lancer, instance par instance, avec Ansible en serial: 1 par exemple, et c’était à nous (sysadmin) de concevoir toute cette logique de mise à jour.

D’ailleurs, comment fonctionnait le service discovery? Comment l’outillage savait quelle application était sur quelle machine, notamment en cas d’ajout ou suppression? On voyait généralement 2 patterns:

Bien sûr, ça ne s’arrêtait pas là. Quand vous aviez 5, 10, 15…​ applications qui parlaient ensemble, il fallait bien gérer le truc. On peut aussi parler d’iptables qui devait se configurer également sur chaque machine et être mis à jour à chaque changement de topologie.

Tolérance aux pannes

On voyait assez peu d’auto-rémédiation en cas de panne. J’ai déjà montré l’exemple de Keepalived avant, quand ça plantait d’un côté, on allait debug, et on relançait. De la même manière, si on perdait une machine, généralement on allait voir ce qu’il se passait, éventuellement on en démarrait rapidement une autre et voilà.

On voyait déjà certains patterns plus avancés, sur le cloud par exemple, avec des autoscaling group pilotant un pool de machines virtuelles avec mise à jour automatique des load balancers en cas de changement, mais globalement les infrastructures étaient assez statiques, avec peu voire pas du tout de boucles de réconciliation.

Ce point sera important pour la suite.

Gestion des ressources

On avait donc des machines virtuelles ou serveurs physiques pour les applications: 4 CPU et 8GB de mémoire, 16 GB et 32GB…​ et c’était à nous d’aller déclarer dans l’infra as code "on veut cette application sur cette machine".

Je trouve que ça créait beaucoup de gaspillage car réaliser ce travail d’allocation à la main était pénible et pouvait être source de problèmes (voire de sécurité en cas de non isolation des applications). Un pattern courant était de mettre une application par machine, et voilà: ça simplifiait aussi les maintenances car sinon mettre à jour un noeud pouvait vite devenir complexe.

Gérer de l’affinity/anti affinity était aussi très pénible, et passait aussi généralement via les inventaires des outils d’infrastructure as code.

Sécurité

La gestion et distribution de certificats TLS pouvait aussi être pénible (là aussi, très statique et à intégrer dans le cycle de vie de l’application). J’ai déjà mentionné iptables avant qui était un enfer à gérer.

Côté secrets/credentials, on voyait un peu de tout mais souvent ça faisait de l’ansible vault ou l’équivalent dans d’autres outils (Puppet etc).

Gestion des logs

Configuration via logrotate, systemd et journald pour les plus chanceux qui avaient accès à des distributions récentes…​ c’était pénible à gérer car à configurer pour chaque application.

Packaging

Chaque "stack" (Java, Python, Ruby…​) ou chaque application d’infrastructure (Kafka, Logstash…​) avait sa façon de se déployer. On avait pas la standardisation de Docker donc on voyait de tout:

Il fallait ensuite se farcir la configuration des services (systemd quand on avait de la chance, ou du script shell degueu avec init pour les autres).

Et je n’ai même pas parlé de cronjobs et autres joyeusetés.

Stockage

Là aussi, si votre application avait besoin de configuration de stockage spécifique (volumes, nfs…​), c’était par machine. L’application devait se déplacer sur une autre machine? Enjoy ton petit playbook pour détacher d’un côté/rattacher de l’autre tout comme il faut.

Boucles de réconciliations

Comme dit précédemment dans la partie Tolérance aux pannes, on n’était pas vraiment sur de l’infrastructure dynamique. Quand un truc plantait, on faisait en sorte que ça ne cause pas de downtime mais on n’était pas vraiment dans une logique d’automatisation de la remédiation (même si on tentait d’éviter les drifts via l’infrastructure as code en faisant tourner les outils régulièrement).