En 2020, les équipes derrière Kubernetes ont annoncé que la prise en charge de DockerShim était terminée. À compter de cette date, Kubernetes n’a cessé de s’éloigner de Docker. Les deux entreprises occupantes des places relativement similaires sur le marché, Kubernetes semble bien parti pour supprimer complètement Docker de ses workflows. Même si cette situation laisse place à beaucoup d’interrogations, nous tâcherons dans cet article de comprendre ce que cela veut dire pour le monde du DevOps.
Vous souhaitez devenir complètement opérationnel sur le déploiement d’applications conteneurisées ? Notre formation Docker en inter et intraentreprise vous permettra de déployer des environnements applicatifs et à les automatiser.
Vous souhaitez devenir incollable sur Kubernetes et obtenir une maitrise complète de l’outil ? Notre formation Kubernetes vous apprendront tout ce qu’il y a à savoir afin que vous puissiez déployer, diriger et administrer des conteneurs applicatifs. Vous pourrez également passer des certifications afin de prouver vos compétences.
L’équipe Ambient IT
Kubernetes Vs Docker : rétrospective
Il y a environ une dizaine d’années, le développement logiciel tel que les développeurs le connaissaient s’est complètement transformé. Un nouveau système d’organisation et de déploiement d’applications modernes est né : le processus de création de nouveaux logiciels, également connu sous le nom de cycle de vie du développement logiciel (SDLC).
Cette pratique était au début lente et fastidieuse. Elle posait problème à chaque phase du cycle de vie d’un logiciel que cela soit le déploiement, la mise à l’échelle, la gestion et la cohérence.
Pour résoudre ces problèmes, les développeurs ont donc travaillé sur des plateformes dites de conteneurisation. Elles avaient pour but de transformer les lourds processus de développement en systèmes d’organisation légers.
Pour orchestrer ces applications conteneuriser, deux outils ont été créés : Docker en 2013 puis Kubernetes en 2014.
Pour les développeurs, Kubernetes et Docker offrent un espace pour construire des plateformes de manière ordonnée et organisée, ce qui rend plus accessible la réalisation de projets plus ambitieux et plus complexes.
Pour les équipes et les responsables informatiques, ils offrent une assistance inébranlable, un soutien logistique et une disponibilité maximale, ce qui permet aux entreprises d’économiser du temps et des ressources.
Les deux outils ont jusqu’à présent généralement fonctionnés main dans la main. Cette relation a néanmoins changé ces dernières années.
Qu’est-ce qui change avec Docker ?
L’annonce faite par les équipes Kubernetes est la suivante : la prise en charge de Docker en tant que moteur d’exécution de conteneur est supprimée.
Il faut néanmoins noter que Kubernetes ne gère pas réellement le processus d’exécution des conteneurs sur une machine. Il s’appuie plutôt sur un autre logiciel appelé « container runtime« . Kubernetes exécute les conteneurs sur un hôte, et indique à l’exécution du conteneur sur chaque hôte ce qu’il doit faire. Jusqu’à présent, l’option la plus populaire consistait à utiliser Docker en tant qu’exécution de conteneur. Ce qui n’est désormais plus possible.
Docker reste utilisable dans d’autres cas de figure, mais plus comme exécuteur de conteneurs sous Kubernetes.
Pourquoi ce changement ?
Docker ne met pas en œuvre l’interface d’exécution des conteneurs (CRI). Dans le passé, il n’y avait pas beaucoup de bonnes options pour les runtimes de conteneurs. Kubernetes avait donc implémenté le Docker shim, une couche supplémentaire qui sert d’interface entre Kubernetes et Docker. Aujourd’hui, avec le développement des outils DevOps, il existe de nombreux moteurs d’exécution qui implémentent le CRI, et il n’est plus logique pour Kubernetes de maintenir un support spécial pour Docker.
En réalité, Docker n’est pas réellement un runtime de conteneurs, mais plutôt une interface plus accessible et plus riche en fonctionnalités au-dessus d’un moteur d’exécution de conteneur distinct et un ensemble d’outils. Maintenant que Kubernetes peut utiliser directement containerd comme runtime de conteneur, Docker n’est plus nécessaire dans ce rôle d’intermédiaire.
Quel rôle pour Docker à l’avenir ?
Bien que Docker ne soit plus nécessaire en tant qu’exécution de conteneurs dans Kubernetes, il a toujours un rôle à jouer dans l’écosystème Kubernetes et dans les flux de travail DevOps.
Kubernetes continuera également à pouvoir tirer parti des registres Docker (tels que Docker hub). Docker restera donc un concurrent puissant pour gérer les images après la construction de celles-ci et restera donc un outil utile pour les opérations CI.
Des alternatives à Docker
Avec l’explosion du DevOps, de nombreuses alternatives à Docker sont apparues pour l’exécution de conteneurs et certaines sont aujourd’hui parfaitement adaptées aux besoins de grandes entreprises.
PodMan
Développé par RedHat, Podman est un moteur de conteneur open source et natif de Linux, considéré comme l’une des meilleures alternatives à Docker.
Parmi les avantages de l’outil, nous pouvons citer la bibliothèque lib pod, qui fournit une API de haut niveau pour la gestion des pods et des conteneurs. Elle offre également un support intégré pour les conteneurs sans racine et des fonctions de sécurité améliorées.
Podman est également très simple d’utilisation et supporte de nombreux formats de conteneurs, ce qui le rend très polyvalent pour vos environnements DevOps
Containerd
Containerd est un moteur d’exécution de conteneurs léger et fournit une interface cohérente et stable pour l’exécution des conteneurs. Conçu principalement pour gérer le cycle de vie des conteneurs en les démarrant et en les arrêtant, il fournit d’autres fonctionnalités telles que la gestion et le stockage d’images.*
Le principal avantage de Containerd est son faible besoin en ressource ainsi sa capacité à être utilisé avec une variété d’outils d’orchestration de conteneurs, tels que Kubernetes et Docker Swarm. Cela permet une plus grande flexibilité en termes de gestion et de mise à l’échelle des conteneurs.
LXD
LXD est un superviseur de conteneurs. Il permet à plusieurs systèmes Linux isolés (conteneurs) de fonctionner sur un seul hôte, offrant ainsi une alternative « light » aux machines virtuelles. C’est un outil très populaire et déjà largement utilisé par les équipes DevOps du monde entier.
En plus d’être léger et rapide, LXD est bien connu pour sa simplicité d’utilisation. LXD offre également un large panel de fonctions avancées, la migration en direct, la gestion du stockage et la gestion du réseau, ce qui vous permet de déplacer les conteneurs en cours d’exécution entre les hôtes sans interruption.
Chacune de ces alternatives à Docker a ses propres forces et faiblesses, il est donc important d’analyser les avantages et les inconvénients de chacune et d’étudier les besoins de votre entreprise avant de choisir l’une de ces alternatives à Docker.
