1. Vous êtes perdus...

Cela fait maintenant plusieurs mois, voire plus d’un an que vous êtes intellectuellement convaincus de l’approche de Docker et des conteneurs applicatifs : portabilité, universalité, volatilité.

La promesse est tenue et vous avez déjà remporté quelques victoires en développant localement et sur quelques environnements d’intégration, bravo.

C’est à ce moment que la question du passage à l’échelle se pose et d’un coup, le signal se brouille. Vous êtes soudainement noyés sous un déluge de noms et d’acronymes barbares. Et surtout, vous sentez comme une odeur de poudre. Il y a du rififi au pays des moteurs de clustering Docker. Rien qu’à l’évocation de ces noms, « Docker Swarm, Kubernetes, Rancher, Mesos, Marathon, Titus, Nomad, Fleet ou encore Deis », vous vous sentez fébrile, en retard sur le dernier framework hype et peut-être en train de passer à côté de LA solution ultime.

« Écoute, on t'connaît pas, mais laisse nous t'dire que tu t'prépares des nuits blanches... Des migraines... Des "nervous breakdown", comme on dit de nos jours. »

Michel Audiard (Les Tontons flingueurs – 1963)

Nous vous proposons ici quelques éléments pour y voir un peu plus clair dans l’opposition Kubernetes/Swarm.

Commençons par regrouper tout ces produits comme étant (au moins sur une partie de leur périmètre) des CaaS, pour Container as a Service. Le conteneur Docker est alors l’unité de déploiement d’une offre de service plus vaste comprenant la gestion du cycle de vie des conteneurs, leur orchestration, leur placement, leurs interconnexions…

2. Un état de guerre ouverte

Si c’est autour de Mesos, Kubernetes et Docker Swarm que se concentrent les attentions, c’est bien entre Google (géniteur de Kubernetes) et Docker Inc que s’entretiennent les plus fortes tensions.

L’enjeu de cette guerre froide est sans appel : celui qui remportera la bataille des orchestrateurs dominera le monde.

« Mais moi les dingues, j'les soigne, j'm'en vais lui faire une ordonnance, et une sévère, j’vais lui montrer qui c’est Raoul. Aux quatre coins d'Paris qu'on va l’retrouver, éparpillé par petits bouts façon puzzle... Moi, quand on m’en fait trop j'correctionne plus, j'dynamite, j'disperse, et j'ventile. »

Michel Audiard (Les Tontons flingueurs – 1963)

Dans la bataille, les deux belligérants engagent toutes leurs forces de frappe pour montrer leur supériorité : animation des communautés les plus grandes, multiplication des partenariats, création de standards, de fondations et lobbies, participation aux conférences les plus en vogues, saturation de l’actualité geek avec des annonces permanentes, billets de blog et tweets assassins, refus de pull requests, distribution de tee-shirts à baleine bleue et autres concours du plus grand nombre de stickers sur les MacBooks des développeurs.

Jusque là nous étions restés dans une guerre propre. C’était sans compter sur la “Rocket” que Google et CoreOS ont lancé pour essayer de torpiller le porte-conteneurs Docker. Cette initiative avait pour vocation de proposer un standard de conteneurisation alternatif en dehors du périmètre d'influence de Docker Inc.

« Le flinguer comme ça de sang froid, sans être tout à fait de l’assassinat, y'aurait quand même comme un cousinage ! »

Michel Audiard (Ne nous fâchons pas – 1966)

Docker Inc arrive sur le marché de l’orchestration avec une légitimité toute naturelle : ce sont eux qui ont proposé le concept disruptif et crédible du conteneur. Cette vision est en ligne avec les paradigmes les plus swags du moment (DevOps, intégration et déploiement en continu, cattle vs. pet, rebuild vs upgrade) et a connu, à juste titre, une explosion de popularité auprès des développeurs in. Il serait donc naturel de croire que Docker Inc va avoir une approche tout aussi efficace pour gérer tout un écosystème de conteneurs jusqu’à la prod. La stack UCP (Universal Control Plane) se fait clairement l’écho de cette ambition.

Google d’un autre côté a habilement saisi au vol la manne céleste du conteneur et peut se targuer d’avoir l’expérience de la gestion de centaines de milliers de ces petites boites en production (sur une technologie interne, antérieure à Docker : Borg), et ce depuis plus de 10 ans. On peut être enclin à les croire quand ils annoncent que Kubernetes est en fait un concentré de ce savoir-faire, expressément réécrit pour Docker.

3. Notre position

Difficile de prédire l’avenir dans notre métier, puisque les roadmaps annoncées sont à prendre avec des pincettes. Pourtant, notre expérience accumulée depuis plusieurs mois nous permet de faire aujourd’hui une préconisation assez tranchée : si vous devez vous lancer aujourd'hui, partez sur Kubernetes.

C’est à notre sens la stack technologique la plus mature et prometteuse pour un projet de CaaS en production.

3.1 Couverture fonctionnelle : Swarm versus Kubernetes

Kubernetes offre les fonctions natives que l’on peut être en droit d’attendre d’un gestionnaire de clusters en production. Citons en particulier le self-healing, un orchestrateur capable de réagir à des changements de topologie des nœuds, notamment le crash, ce qui n’est pas (encore) le cas dans Swarm (la version 1.1 de Swarm sortie en même temps que Docker 1.10 le propose uniquement en expérimental).

Citons également la gestion native des secrets, des comptes de services, des namespaces, des autorisations, le load-balancing, l’autoscaling de conteneurs (en version ß), bref nous voilà en face d’une solution presque complète.

3.2 Sur les épaules d’un Géant

Pour mesurer tout le potentiel de Kubernetes, c’est du côté de RedHat qu’il faut porter le regard, en particulier sur OpenShift Origin.

L’éditeur a pris clairement position dans la bataille au côté de Google et CoreOS en prenant une certaine distance vis-à-vis de Docker Inc qui rend coup pour coup.

En faisant le pari de bâtir sa nouvelle mouture d’OpenShift v3 sur Kubernetes, RedHat propose un trait d’union entre le CaaS et le PaaS. On se trouve donc en face d’une solution hybride, capable de proposer simultanément les 2 étages de la fusée :

• Le PaaS : avec sa double capacité à :
  • accepter directement du code source en entrée (PHP, Node, Python, Ruby, Java…) et à prendre en charge ensuite le build et le déploiement
  • instancier des topologies de conteneurs rassemblés sous forme de blueprints (ou templates)
• Le CaaS : la gestion très fine de l’assemblage de tous types de conteneurs Docker dans des topologies 100% personnalisables, en dehors de tout cadre rigide

3.3 Des philosophies aux antipodes

C’est principalement dans l’approche et les paradigmes de Kubernetes que l’on mesure l’avance par rapport à Swarm.

3.3.1 Kubernetes : la production en ligne de mire

Google a directement pensé Kubernetes (ou k8s pour les intimes) pour répondre à des problématiques de production, là où Swarm et Docker ajouteront progressivement des fonctions pourtant majeures :

• Approche basée sur des namespaces isolant les ressources entre elles
• Authentification via OpenIDConnect, certificats clients, …
• Développement d’outils (sous forme de conteneurs) de collecte de métriques des conteneurs (CAdvisor, Heapster), de DNS dynamique, ...

Docker Swarm et Kubernetes s’opposent également dans leur philosophie :

• Simple mais limité : Swarm a fait le choix de rendre transparente l’utilisation des conteneurs en local ou sur un cluster distant. Cette promesse est très séduisante mais sous prétexte de masquer la complexité au développeur, elle devient limitante dans la modélisation des contraintes d’exploitabilité.
• Puissant mais complexe : Kubernetes assume une modélisation riche (crédible jusqu’en production), même si cela est moins confortable pour les développeurs.

Installer une stack Kubernetes complète sur son poste de développement est peut-être trop fastidieux pour un développeur, qui, finalement, pourrait se satisfaire des fonctionnalités de Swarm.

3.3.2 Kubernetes : une modélisation plus aboutie

Kubernetes propose un modèle de description des applications autour de 4 concepts majeurs : la mécanique de Labels/Selectors, les Services, les Pods et les ReplicationControllers. À partir d’idées unitairement simples, il devient possible de gérer facilement :

• des pools de conteneurs d’un rôle identique
• leur load-balancing
• leur rolling-update
• le tout, avec une capacité naturelle à s’adapter aux aléas (pannes, plantages de conteneurs)

Ces notions sont moins simples à appréhender que celles de Docker Compose mais montrent également bien plus de potentiel et de puissance. Nous pensons que plus nous nous rapprochons des vraies contraintes de la production plus les capacités offertes par ces concepts deviennent nécessaires (scalabilité, résilience et sécurité).

«- Faut reconnaître... C'est du brutal.

- Vous avez raison, c'est curieux hein

- J'ai connu une polonaise qui en prenait au petit-déjeuner.»

Michel Audiard (Les Tontons flingueurs – 1963)

3.4 Le poids de l’Histoire (oui, déjà)

Docker a fait un choix discutable en misant sur Fig (qui deviendra plus tard Docker Compose). Ce choix tactique est à ce jour un caillou dans la chaussure de Docker Inc. Il manque certains concepts dans le format v1 de Docker Compose et l’arrivée du format 2.0 a été un passage obligé pour apporter plus de subtilité au prix d’une migration laborieuse. Le mot-clé services: en est la matérialisation. Mais la route est encore longue et s’annonce périlleuse. À ce jour la notion de service de Compose n’apporte pas les fonctions de load-balancing des services natives à Kubernetes. On regrette également qu’il ne soit pas possible de préciser le nombre absolu de copies des conteneurs à faire tourner dans Swarm...

3.5 Là où notre avis n’est pas (encore) tranché

Il serait naïf de penser que tout est parfait dans le monde merveilleux de Kubernetes et que Swarm n’est qu’une pale tentative vouée à l’échec. Dans la réalité, les choses sont bien entendu plus nuancées.

Côté poste de développement, nous l’avons évoqué, faire du Docker Machine + Docker Engine + Docker Compose est plus naturel à utiliser que Kubernetes. kmachine vient en partie réduire la complexité de déploiement de k8s en montant une instance locale mono-nœud à moindre frais. Cela ne dispense cependant pas de connaître et de manipuler les concepts de Kubernetes.

D’un autre côté, penser qu’un fichier Docker Compose utilisé en développement va directement pouvoir passer en production est illusoire. L’utilisation de networks de type overlay, de volumes externes sont autant de subtilités qui ne sont pas a priori un sujet de préoccupation en phase de développement et qu’il faudra pourtant bien adresser même dans le monde de Docker Inc.

L’approche multi-réseaux applicatifs est un point fort de Swarm/Docker, et Kubernetes ne peut pas rivaliser aujourd’hui avec ce niveau de segmentation. Nous sommes à la KubeCon 2016 avec beaucoup d’attentes sur ce sujet précis.

Côté stockage, l’approche à base de PersistentVolume / PersistentVolumeClaim de Kubernetes ne nous a pas totalement séduits. Là aussi, le modèle n’est pas encore abouti. Certaines promesses de la future version 1.2 de Kubernetes pourraient améliorer les choses, mais gardons-nous de nous réjouir prématurément.

Il reste des domaines sur lesquels nos belligérants se rejoignent tristement et doivent faire preuve d’une nette amélioration : la gestion des logs, la supervision et l’administration du cluster. Les solutions proposées sont aujourd’hui encore bien lourdes à mettre en œuvre et à intégrer au reste du SI.

4. Épilogue : Empires et Fondations

Comme dans la plupart des projets OpenSource, la sélection naturelle va faire son œuvre, mais elle laisse pour l’instant un goût très amer.

« Patricia, mon petit, je ne voudrais pas te paraître vieux jeux et encore moins grossier... L'homme de la pampa parfois rude, reste toujours courtois... Mais la vérité m'oblige à te le dire : Ton Antoine commence à me les briser menu ! »

Michel Audiard (Les Tontons flingueurs – 1963)

Bien que la guerre soit loin d’être terminée, notre recommandation pour Kubernetes ne fait pas de doute.

Swarm manque actuellement de fonctions majeures pour pouvoir prétendre à rattraper son retard : un orchestrateur complet, une gestion des pools de conteneurs, le load-balancing natif, le multi-tenant...

De son côté Kubernetes a encore du chemin à parcourir pour tenir pleinement sa promesse : le cloisonnement réseau et la gestion des stockages persistants sont à améliorer profondément.

En définitive, nous nous demandons si ce conflit des orchestrateurs ne va pas avoir un impact collatéral sur le standard des conteneurs lui-même, et de fait pénaliser les utilisateurs. Que va-t-il advenir du rêve d’un standard partagé dans cette belle fondation qu’est l’Open Container Initiative ?

Pendant ce temps, d’autres projets sont également dans nos radars et font l’objet d’une surveillance constante : Rancher (pour sa simplicité et sa vision cross-cloud) et Nomad d’HashiCorp (pour son paradigme Datacenter Aware).

Pour aller plus loin, notre formation Docker aborde une grande partie des ces sujets.