Orchestration de conteneurs : choisir sans se raconter d'histoires

C'est là que la question se pose. Pas celle de Docker — ça, c'est réglé depuis longtemps. La vraie question, c'est : qui va décider quel conteneur démarre où, qui le relance quand il meurt, qui le branche sur les autres. Cette décision, c'est l'orchestration de conteneurs.

Et cette décision, tu vas devoir la prendre. Autant la prendre en connaissance de cause.

Ce que l'orchestrateur fait vraiment

Un orchestrateur, c'est un programme qui regarde en permanence l'état de ton infrastructure et qui corrige l'écart entre ce que tu as décrit et ce qui tourne réellement.

Tu écris quelque part : « je veux trois instances de cette image, joignables sur ce port, avec ces variables d'environnement ». L'orchestrateur compare. Il en manque une ? Il la démarre. Une est sur un nœud qui vient de tomber ? Il la recrée ailleurs. Le nœud revient ? Il rééquilibre.

Cette boucle — décrire, comparer, corriger — c'est tout le sujet. Le reste, ce sont des détails d'implémentation, et ils sont nombreux.

Docker, sorti en 2013 par dotCloud, a réglé le problème du comment on emballe. Il a rendu le conteneur portable, reproductible, léger. Mais Docker seul ne te dit pas où poser tes trois cents conteneurs quand tu as six serveurs. Il ne te dit pas quoi faire quand un serveur tombe à trois heures du matin.

C'est cette lacune qui a produit Kubernetes.

Kubernetes, et pourquoi il a gagné

Google gérait depuis des années des millions de conteneurs en interne avec des outils maison, Borg puis Omega. En 2013, Craig McLuckie, Joe Beda et Brendan Burns ont pitché l'idée d'en faire une version ouverte. Le 10 juin 2014, Eric Brewer — alors vice-président de l'infrastructure chez Google — l'a annoncé publiquement à la DockerCon de San Francisco.

Le choix du lieu n'était pas anodin. Docker dominait la conteneurisation. En présentant Kubernetes là, Google le positionnait comme une couche au-dessus de Docker, pas comme un remplaçant. Kubernetes ne touchait pas au format de conteneur ni à la distribution. Il s'occupait de l'orchestration.

La version 1.0 est arrivée le 21 juillet 2015. Ce jour-là, Kubernetes est devenu utilisable en production. Microsoft, Red Hat, IBM et Docker avaient déjà rejoint la communauté en 2014. En 2016, la Cloud Native Computing Foundation — créée par la Linux Foundation — l'a repris comme projet hébergé. Ce transfert a compté : il a sorti Kubernetes de la sphère d'influence directe de Google et lui a donné une gouvernance neutre.

Depuis, il n'a plus vraiment eu de concurrent sérieux. Docker Swarm et Apache Mesos ont reculé. En 2018, Kubernetes était devenu le choix par défaut, sans que personne n'ait jamais organisé de vote.

Ce que ça te coûte

Voilà le point qu'on escamote souvent.

Kubernetes introduit un vocabulaire entier. Un pod — la plus petite unité exécutable, un ou plusieurs conteneurs qui partagent un réseau et un cycle de vie. Un service — une adresse stable devant des pods qui vont et viennent. Un deployment — la description de l'état voulu pour une application. Un namespace — un découpage virtuel du cluster, utile pour séparer dev, test et prod.

Tu configures tout ça en YAML. Tu pilotes avec `kubectl`. Et tu as intérêt à comprendre le réseau, le stockage, la sécurité et le monitoring, parce que Kubernetes ne t'en protège pas. Une mauvaise configuration, c'est une fuite, une facture cloud qui explose, ou les deux.

Le coût réel de Kubernetes n'est pas la licence. Elle est nulle. Le coût, c'est la personne qui sait le faire tourner, et le temps qu'elle met à l'apprendre.

C'est pour ça que des distributions et des services existent. OpenShift de Red Hat, Rancher, et les offres managées des grands clouds — GKE chez Google, EKS chez Amazon, AKS chez Microsoft. Tu leur donnes de l'argent, ils te donnent un control plane que tu ne maintiens pas toi-même. Le compromis est clair : tu perds une partie du contrôle, tu gagnes des nuits de sommeil.

Les alternatives, honnêtement

Docker Swarm existe toujours. Il est beaucoup plus simple que Kubernetes. Un `docker swarm init`, quelques `docker service create`, et tu as quelque chose qui tourne. La courbe d'apprentissage se compte en heures, pas en semaines.

Ce qu'il coûte : un écosystème réduit, moins d'outils tiers, une communauté qui s'est largely déplacée ailleurs. Docker Swarm n'est pas mort, mais il n'est plus porté par grand monde. Pour un petit cluster, une équipe de deux ou trois personnes, une charge prévisible, il fait le travail. Pour le reste, tu risques de te retrouver seul avec tes questions.

Nomad, de HashiCorp, occupe une position intéressante. Il orchestre des conteneurs, mais aussi des binaires classiques et des jobs batch. Si ton infrastructure n'est pas exclusivement conteneurisée, c'est un argument réel. Sa complexité se situe entre Swarm et Kubernetes. Sa communauté est plus petite que celle de Kubernetes, plus grande que celle de Swarm. Tu n'auras pas autant de tutoriels, mais tu auras de la documentation correcte.

Il y a aussi la question que peu de gens posent : as-tu besoin d'un orchestrateur ?

Si tu as une seule application, quelques conteneurs, un serveur, la réponse est probablement non. Docker Compose suffit. Systemd suffit. Un reverse proxy et deux scripts suffisent. Ajouter Kubernetes à ce tableau, c'est acheter un camion pour aller chercher le pain.

L'orchestration devient nécessaire quand le nombre de conteneurs dépasse ce que tu peux suivre à la main, quand la tolérance à la panne devient une exigence, quand tu dois déployer plusieurs fois par jour sans casser ce qui tourne.

Le seuil

Il n'y a pas de chiffre magique. Mais il y a un moment où tu le sens : quand tu commences à écrire des scripts pour redémarrer des choses, quand tu ne sais plus quel conteneur tourne où, quand une mise à jour te fait transpirer.

À ce moment-là, Kubernetes est le choix par défaut, et ce n'est pas une mauvaise raison. L'écosystème est là, les réponses à tes questions existent quelque part, et les gens que tu embaucheras l'auront déjà vu.

Mais si tu n'es pas encore à ce moment-là, ne l'anticipe pas. La complexité que tu ajoutes aujourd'hui, tu la porteras demain, et elle ne disparaîtra pas toute seule.

Kubernetes ne se contente pas de faire tourner des conteneurs. Il t'oblige à décrire précisément ce que tu veux, à penser en termes d'état désiré plutôt que d'actions. C'est une discipline. Elle a un prix, et ce prix n'est pas le même pour tout le monde.

Ce qui tranche, en fin de compte, ce n'est ni la taille de ton équipe ni le nombre de tes serveurs. C'est ta capacité à absorber la complexité sans la subir — et ça, personne ne peut la mesurer à ta place.