Kubernetes, l'orchestrateur de containers qui passe à l'échelle mondiale
Dévoilé en juin 2014 et livré en version stable 1.0 un an plus tard, Kubernetes (K8s pour les initiés) est issu d'une quinzaine d'années de R&D chez Google. L'orchestrateur de containers est la récriture en Go du système Borg utilisé par le géant américain en interne. Google Search, Maps, Gmail, Youtube, etc. L'ensemble des services du groupe de Mountain View reposent sur une architecture de containers, elle-même adossée à un gigantesque cluster de centaines de milliers de serveurs... Le tout est piloté grâce à Borg.
Via cet orchestrateur maison, Google arrête et redémarre pas moins de 2 milliards de containers chaque semaine. Kubernetes a été versé par Google en open source à la Cloud Native Computing Foundation (CNCF), elle-même partie prenante de la Linux Foundation.
Les clouds de Google et AWS compatibles
"Le projet open source Kubernetes prône la vision d'un système d'information consolidé sur un seul meta-cluster piloté via un orchestrateur de containers unique. Une infrastructure pouvant être, dans le même temps, découpée en sous-clusters géographiques distribués sur plusieurs clouds, privés et/ou publics. Le tout dans une logique de ressources informatiques partagées", analyse Didier Girard, directeur des opérations et de l'innovation au sein de l'ESN française Sfeir. Sur le papier, un tel framework permettrait de se soustraire d'un cloud unique en ouvrant la possibilité de répliquer et orchestrer des applications quelle que soit la plateforme ou le fournisseur. Naturellement, il regrouperait dans le même temps tous les types d'environnement (développement, test et production).
"La version 1.6 du framework peut gérer des clusters de 50 000 machines"
Kubernetes est-il vraiment capable de concrétiser cette vision ? Oui et non. Côté cloud public, la promesse commence à être en partie tenue. Face à Google Cloud Platform, l'orchestrateur est aussi implémenté chez Amazon Web Services. "Sa version 1.6 peut en outre prendre en charge des clusters de 50 000 machines tout en mettant en musique des sous-clusters régionaux", insiste Didier Girard, avant de pondérer : "Pour superviser l'infrastructure, et notamment s'assurer qu'une application ne cannibalise pas les ressources machines, des développements additionnels sont nécessaires en matière de monitoring."
Des pods au service de l'architecture
A la différence de ses concurrents, au premier rang desquels Docker Swarm, Kubernetes donne la possibilité de gérer dynamiquement la couche applicative via la notion de pod. "C'est très utile. Un pod encapsulera plusieurs containers d'application avec, en plus, un container dédié à leurs fichiers de configuration", explique Jacques Roussel, consultant au sein d'Objectif Libre. Et Maxime Cottret, lui-aussi consultant pour l'ESN open source, de préciser : "ce container pourra par exemple embarquer les informations de connexion à la base de données, ce qui évitera de disséminer ce type de secret partout. Ou encore être consacré à la récupération des logs."
Les pods de Kubernetes représentent par ailleurs un excellent moyen de structurer l'architecture logicielle. "On pourra rassembler dans un même Pod les composants d'une même brique fonctionnelle. L'idée étant d'en faire une unité de déploiement homogène", argue Didier Girard chez Sfeir.
"Docker Swarm propose une approche plus packagée"
Autre avantage, Kubernetes intègre par défaut toute une palette de scénarios de gestion de production informatique (déploiement blue-green, canary, rolling update...). "Les autres orchestrateurs ne contiennent pas d'emblée tous ces dispositifs", reconnait Maxime Cottret. Dans le même temps, la technologie de Google s'inscrit dans une approche orientée services. "Typiquement, il est possible via Kubernetes d'établir assez simplement différentes règles d'équilibrage de charge selon les Pods", évoque Jacques Roussel.
Ainsi, Kubernetes est avant tout taillé pour automatiser des parcs massifs de containers basés sur des architectures machines complexes. "Ce n'est pas la logique de Docker Swarm qui, via son approche beaucoup plus packagée, permettra de déployer des petits clusters rapidement en embarquant toute la couche d'abstraction et de pilotage à l'intérieur des containers", analyse Maxime Cottret. A la différence de Swarm dont le développement reste majoritairement porté par Docker, Kubernetes est un véritable projet open source, dans lequel Google, mais aussi Red Hat sont très impliqués. Revers de la médaille : Kubernetes ne bénéficie pas d'un service de support éditeur...
"Contrairement à Swarm, Kubernetes est en train d'évoluer pour prendre en charge d'autres types de container que Docker, par exemple Rocket", fait remarquer Maxime Cottret.
Des intégrations chez Red Hat, CoreOS et VMware
En termes d'outils périphériques, l'écosystème de Docker demeure de loin le plus réputé. "Mais plusieurs grands éditeurs proposent des solutions basées sur Kubernetes. C'est par exemple le cas de Microsoft avec l'application de déploiement continu Draft", relativise Didier Girard. Du côté des fournisseurs de technologies de cloud privé, Red Hat intègre le moteur d'orchestration (dans OpenShift), tout comme CoreOS (dans Tectonic) et plus récemment VMware (dans son offre de virtualisation réseau NSX). Quant à la communauté open source, elle n'est pas en reste. "Un outil comme Kubeadm permet de déployer des clusters Kubernetes aussi facilement qu'avec Docker Swarm", pointe notamment les deux consultants d'Objectif Libre en évoquant également Kubespray. Au final, la richesse de Kubernetes le rendra forcément plus difficile à prendre en main que Swarm. Une complexité qui continue, encore aujourd'hui, à lui coller à la peau.
| Points forts | Points faibles |
|---|---|
| - Orchestrateur mature, le plus riche fonctionnellement - Intégration aux principales plateformes cloud du marché |
- Complexité dans l'appréhension - Une approche solutions clés en main qui peut rebuter |