Avec Docker EE 2.0, Docker intègre Kubernetes et fait sa révolution
Docker Inc planche depuis plusieurs mois déjà sur l'intégration de Kubernetes. Ce projet avait été annoncé lors de son événement européen (la Dockercon Europe) en octobre dernier à Copenhague. Le chantier a été achevé. Swarm, l'orchestrateur maison de Docker, n'est désormais plus le seul à être supporté dans Docker Enterprise Edition (Docker EE). Le portage de Kubernetes est introduit à l'occasion de la sortie ce 17 avril d'une toute nouvelle version de la plateforme de pilotage d'architectures containérisées : Docker EE 2.0. Un numéro choisi par l'éditeur de San Francisco pour bien marquer l'importance que revêt pour lui ce virage stratégique.
"D'un coup, Kubernetes bénéficie de tous les avantages de Docker EE", insiste Patrick Chanezon, membre de l'équipe technique de Docker. Les outils de développement et workflows de déploiement de la plateforme (Docker Compose, Docker Stack Deploy…) sont désormais utilisables pour dessiner des architectures Kubernetes. A partir d'un même Compose files, il est possible de choisir entre Swarm et Kubernetes pour générer un cluster de containers complet.
Techniquement, Docker EE s'adosse néanmoins à Swarm pour faire tourner les grappes Kubernetes. Un choix d'architecture transparent pour l'utilisateur. Quel avantage ? Cette combinaison permet de faire tourner au sein du même cluster à la fois des nœuds (ou serveurs) sous Swarm et d'autres sous Kubernetes. "Il est possible de convertir à la volée un nœud Swarm en nœud Kubernetes, et réciproquement. A ma connaissance, nous sommes les seuls capables de réaliser ce tour de passe-passe", souligne Patrick Chanezon.
Grâce à Docker EE, il serait même envisageable de piloter les mêmes nœuds successivement via Swarm et Kubernetes. "Nous déconseillons néanmoins de le faire en production sous peine d'effets de bord. L'un des deux orchestrateurs peut en effet être amené à cannibaliser toute la ressource machine du cluster sans que l'autre s'en rende compte immédiatement", argue Patrick Chanezon.
La sécurité comme argument phare
Les architectures Kubernetes bénéficieront également des modules de sécurité de Docker EE : Docker Content Trust (pour certifier la qualité des containers) ou encore Docker Security Scanning (pour détecter les vulnérabilités dans les images de container). Elles pourront tirer parti de ses dispositifs de chiffrement, d'authentification des nœuds, de tolérance de panne... "Comparé à ce qu'offre Kubernetes, Docker EE permet une gestion des politiques d'accès plus granulaires, avec la possibilité de définir des droits en lecture et/ou écriture jusqu'à chaque objet de l'API Kubernetes", insiste Patrick Chanezon. "Vous pourrez même réaliser un partitionnement logique et physique du cluster, et ainsi assigner par exemple des équipes de développeurs à telle ou telle machine. Ce qui n'est pas réalisable nativement via le role based access control' de Kubernetes."
"Les frameworks orientés serverless et machine learning sont beaucoup plus nombreux dans l'écosystème Kubernetes"
Pour l'heure, Docker EE ne peut intégrer de serveurs Windows au sein de cluster Kubernetes, mais uniquement des serveurs Linux (de type CentOS, RHEL, Ubuntu, Suse ou Oracle Linux). Mais la situation devrait évoluer dans les mois qui viennent. "Une future version de Kubernetes attendue d'ici la fin de l'année doit en effet introduire le support de Windows Server via l'intégration du moteur d'exécution containrd (disponible à la fois pour Linux et Windows, ndlr)", rappelle Patrick Chanezon. En attendant, il est toujours possible de se tourner vers Swarm qui, lui, supporte déjà les deux OS.
Docker continuera-t-il à commercialiser Swarm ? La réponse est oui. Raison invoquée par l'entreprise : le fait de conserver son propre orchestrateur pourra lui permettre de continuer à se démarquer. "Comparé à Kubernetes qui est un projet open source avec un processus de développement communautaire assez long, nous resterons capables de réagir plus rapidement à de nouveaux besoins du marché", explique Patrick Chanezon. Proposer une alternative à Kubernetes représente pour Docker un potentiel levier de différentiation technologique. "N'oublions pas que Swarm a été le premier à intégrer la gestion des secrets, bien avant Kubernetes", rappelle Patrick Chanezon. Désormais aussi implémenté par Kubernetes, ce mécanisme, basé sur la notion de système de fichier temporaire, est dessiné pour protéger certaines informations critiques (les mots de passe d'accès aux bases de données par exemple).
Une portabilité sans couture
Qu'en est-il des principaux besoins identifiés par Docker autour de Kubernetes ? Sur ce plan, l'éditeur a cerné deux cas d'usage. Le serverless d'une part. L'intelligence artificielle d'autre part. "Les frameworks orientés serverless et machine learning sont beaucoup plus nombreux dans l'écosystème Kubernetes comparé à l'écosystème Swarm. C'est un fait. La communauté des développeurs s'oriente massivement vers Kubernetes dans ces domaines", constate Patrick Chanezon. Et il n'a pas échappé à Docker que l'IA et le serverless représentent actuellement deux des tendances majeures sur le créneau du cloud (tant public que privé). "En intégrant Kubernetes, nous répondons clairement à une demande", martèle Patrick Chanezon.
Pour finir, les architectures Kubernetes vont pouvoir bénéficier de la portabilité offerte par Docker EE. Elles pourront venir se nicher sur des clouds privés motorisés par la plateforme (couvrant infrastructure Windows, Linus, mainframe...). Mais aussi sur les clouds publics qui l'ont intégrée : AWS, Google Cloud Platform, IBM Cloud et Microsoft Azure.