Pouvez-vous utiliser Kubernetes sans Docker ?

Getty Images/iStockphoto

L'émergence des conteneurs a engendré des possibilités passionnantes pour le développement de logiciels et les opérations de charge de travail dans l'entreprise moderne. Mais la croissance spectaculaire de la popularité des conteneurs pose des problèmes de gestion des conteneurs que les moteurs tels que Docker ne peuvent pas gérer.

Des plates-formes telles que Kubernetes relèvent ces défis complexes de gestion des conteneurs grâce à l'automatisation et à l'orchestration. Kubernetes est une plate-forme gratuite et efficace qui prend en charge de nombreux environnements d'exécution de conteneurs, y compris Docker Engine.

Étant donné que Docker et Kubernetes sont apparus au début de l'ère des conteneurs, les deux sont étroitement liés depuis des années, au point qu'ils sont parfois référencés de manière interchangeable. Mais bien que Docker et Kubernetes soient complémentaires, ce sont des types d'outils différents qui servent des objectifs distincts dans les environnements informatiques.

Un conteneur est un type spécialisé de machine virtuelle. Comme toute machine virtuelle, un conteneur regroupe et gère les logiciels, en les faisant abstraction de l'environnement informatique sous-jacent des serveurs, du stockage et des réseaux. Cette abstraction facilite le déplacement des conteneurs et des machines virtuelles entre les environnements informatiques.

Contrairement aux machines virtuelles, qui incluent un système d'exploitation, les conteneurs incluent uniquement le code et les dépendances nécessaires pour exécuter la charge de travail du conteneur, tels que les runtimes, les outils système, les bibliothèques système et les paramètres correspondants. Le résultat est un package agile et économe en ressources qui peut fonctionner avec peu d'exigences, voire aucune, quel que soit l'environnement informatique.

Les deux composants non empaquetés dans un conteneur sont le système d'exploitation et le moteur de conteneur. Le système d'exploitation prend en charge le code exécuté dans le conteneur et le moteur de conteneur gère les mécanismes de chargement et d'exécution du conteneur lui-même.

Un conteneur est créé et stocké en tant qu'image de conteneur. L'appel d'un conteneur charge le fichier image dans le moteur de conteneur, transformant ainsi l'image en conteneur en cours d'exécution. Cet emballage et cette abstraction garantissent qu'un conteneur fonctionne de la même manière sur presque toutes les infrastructures.

Un moteur de conteneur est une plate-forme logicielle ou une couche nécessaire pour charger, exécuter et gérer des conteneurs. Les moteurs de conteneurs sont souvent appelés hyperviseur ou système d'exploitation pour conteneurs, car ils occupent la même couche que l'hyperviseur dans une machine virtuelle.

Docker est l'un des nombreux moteurs de conteneurs populaires. Une fois que Docker ou un autre moteur de conteneur est disponible sur un ordinateur, le système peut charger et exécuter des conteneurs au-dessus de la couche moteur de conteneur.

Docker offre les fonctionnalités clés suivantes :

Le cœur de tout moteur de conteneur, y compris Docker, est l'environnement d'exécution du conteneur. Un environnement d'exécution de conteneur effectue le gros du travail de chargement et d'exécution de conteneurs, ainsi que la mise en œuvre d'espaces de noms et de groupes de contrôle ou de constructions de système d'exploitation logique pour les conteneurs.

De nombreux runtimes de conteneurs sont disponibles, notamment containerd, CRI-O, runC et Mirantis Container Runtime. Certains environnements d'exécution intègrent des fonctionnalités de niveau supérieur telles que le déballage des conteneurs, la gestion et le partage d'images. Certains fournissent également une API pour permettre aux développeurs de créer des logiciels qui interagissent directement avec le runtime.

Les conteneurs sont devenus extrêmement populaires en raison de leur facilité d'utilisation et de leur empreinte informatique relativement réduite. Les serveurs d'entreprise peuvent héberger des dizaines, voire des milliers de conteneurs qui composent des applications et des services pour l'entreprise.

Mais le nombre élevé et le cycle de vie court de nombreux conteneurs posent un sérieux défi aux administrateurs informatiques qui doivent déployer et gérer manuellement de grandes flottes de conteneurs dynamiques. Orchestrer le déploiement des conteneurs et effectuer la gestion en temps réel nécessite des outils hautement automatisés.

C'est le rôle de la plateforme Kubernetes, parfois abrégée en K8. Développé à l'origine par Google, Kubernetes est un outil d'automatisation et d'orchestration open source qui gère le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Avec Kubernetes, les administrateurs informatiques peuvent organiser, planifier et automatiser la plupart des tâches nécessaires aux architectures basées sur des conteneurs.

Kubernetes n'est certainement pas la seule plate-forme d'automatisation et d'orchestration de conteneurs disponible. Par exemple, Docker a son propre outil appelé Docker Swarm. Les fournisseurs de cloud proposent également des services Kubernetes gérés, tels qu'Azure Kubernetes Service et Amazon Elastic Kubernetes Service. D'autres alternatives tierces incluent SUSE Rancher et HashiCorp Nomad.

Les fonctionnalités étendues de Kubernetes, l'absence d'étiquette de prix, la large prise en charge de l'exécution des conteneurs et l'extensibilité ont consolidé sa place en tant que plate-forme d'automatisation et d'orchestration de premier plan. Les principales fonctionnalités de Kubernetes sont les suivantes :

De toutes les fonctionnalités de Kubernetes, la prise en charge et l'extensibilité des conteneurs sont les plus puissantes. Ces caractéristiques permettent à Kubernetes d'interagir avec une variété d'exécutions de conteneurs, y compris containerd, CRI-O et toute autre implémentation de l'interface d'exécution de conteneur Kubernetes (CRI).

De plus, Kubernetes fournit une API qui a engendré tout un écosystème d'outils open source pour Kubernetes. Il s'agit notamment du maillage de services Istio et de la plate-forme informatique sans serveur Knative.

Bien que Docker et Kubernetes soient liés, les deux sont des outils d'infrastructure distincts qui sont déployés et gérés séparément dans les environnements informatiques. Plus précisément, Docker est un moteur de conteneur : la couche logicielle ou la plate-forme sur laquelle les conteneurs virtualisés se chargent et s'exécutent. En revanche, Kubernetes est une plate-forme d'automatisation et d'orchestration : l'outil logiciel qui organise et gère les relations entre les conteneurs.

Au début du développement de Kubernetes, Docker était de loin le moteur de conteneur dominant, et la prise en charge de son exécution de conteneur était codée en dur dans Kubernetes sous la forme d'un composant Kubernetes appelé dockershim. Un shim fait référence à toute modification logicielle qui intercepte et modifie le flux de données pour fournir des fonctionnalités ou des fonctions supplémentaires.

Le composant dockershim a permis à Kubernetes d'interagir avec Docker comme si Docker utilisait un runtime compatible CRI. Au fur et à mesure de l'évolution de Kubernetes, il a adopté des runtimes de conteneur supplémentaires, et le CRI a été inventé afin que tout runtime de conteneur puisse interagir avec Kubernetes de manière standardisée. Finalement, les dépendances posées par dockershim sont devenues un problème hérité qui a entravé le développement ultérieur de Kubernetes.

Avec la sortie de Kubernetes 1.24 au début de 2022, la Cloud Native Computing Foundation - désormais les dépositaires et développeurs de Kubernetes - a décidé de déprécier le composant dockershim. En éliminant dockershim, les développeurs de Kubernetes avaient l'intention de rationaliser et de simplifier le code du projet en supprimant la prise en charge héritée au profit d'un environnement d'exécution standardisé.

Bien que le projet Kubernetes ait déprécié dockershim, les conteneurs Docker fonctionnent toujours avec Kubernetes, et les images produites avec la commande docker build fonctionnent toujours avec toutes les implémentations CRI. Cependant, la suppression de dockershim soulève des problèmes potentiels pour les utilisateurs de Docker.

Les outils Docker et les interfaces utilisateur qui dépendaient de dockershim pourraient ne plus fonctionner. De même, les conteneurs planifiés avec le runtime de conteneur ne seront plus visibles pour Docker, et la collecte d'informations à l'aide des commandes docker ps ou docker inspect ne fonctionnera pas.

Étant donné que les conteneurs ne sont plus répertoriés, les administrateurs ne peuvent pas obtenir de journaux, arrêter des conteneurs ou exécuter quelque chose à l'intérieur d'un conteneur à l'aide de docker exec. Et bien que les administrateurs puissent toujours extraire ou créer des images à l'aide de docker build, ces images ne seront pas visibles pour l'environnement d'exécution du conteneur et Kubernetes.

Compte tenu de ces problèmes, les utilisateurs de Docker ont deux options principales.

La première est de continuer à utiliser Docker comme toujours. Les conteneurs existants fonctionneront : Mirantis et Docker se sont tous deux engagés à maintenir dockershim après son obsolescence par Kubernetes, afin que les utilisateurs aient accès à un composant dockershim approprié dans un avenir prévisible.

La seconde consiste à migrer vers un moteur de conteneur différent qui utilise un environnement d'exécution de conteneur conforme au CRI, tel que containerd ou CRI-O. Un large éventail de projets et d'outils de conteneurs utilisent les deux environnements d'exécution, et les moteurs de conteneurs et les versions de Kubernetes pris en charge par les fournisseurs de cloud sont tous conformes au CRI. Une entreprise qui gère une infrastructure de conteneurs et une version de Kubernetes prise en charge par le fournisseur dans le cloud ne devrait pas être directement affectée par la dépréciation de dockershim.

Aujourd'hui, d'autres moteurs de conteneurs et outils d'automatisation et d'orchestration gagnent en popularité dans les environnements conteneurisés. Les offres vont des environnements d'exécution simples de bas niveau aux plates-formes cloud natives complètes :

De même, les responsables informatiques peuvent choisir parmi une liste croissante de plates-formes d'automatisation et d'orchestration pour organiser et gérer de vastes flottes de conteneurs. Les alternatives Kubernetes, souvent basées sur le code open source de Kubernetes, incluent des options basées sur le cloud et tierces :

Le choix d'un moteur de conteneur ou d'une plate-forme d'automatisation et d'orchestration dépend de facteurs tels que le coût, la complexité, les performances, la stabilité, l'ensemble de fonctionnalités, la sécurité et l'interopérabilité. Comme pour tout choix d'infrastructure critique, testez et évaluez des combinaisons d'outils pour vous assurer qu'elles répondent aux exigences techniques et commerciales.

Besoin d'un remplacement? Essayez ces 5 alternatives Docker