Remarque perev. : Nous avons déjà écrit plus d'une publication (voir les liens à la fin de l'article) sur les temps d'exécution des conteneurs (temps d'exécution des conteneurs) - en règle générale, ils sont discutés dans le contexte de Kubernetes. Cependant, souvent, ces documents ont suscité des questions des lecteurs, indiquant un manque de compréhension de l'origine du prochain projet, de la manière dont il est lié aux autres et de ce qui se passe généralement dans tout ce «zoo» de conteneurs.
Un récent article de Phil Estes, directeur technique d'IBM Watson & Cloud Platform pour les conteneurs et l'architecture Linux, offre une excellente rétrospective sur la façon de naviguer et de mieux comprendre qui a perdu (ou jamais attrapé) le fil des événements. En tant que responsable des projets Moby et containerd, membre des comités techniques de l'Open Container Initiative (OCI) et Moby, et ayant également le statut de Docker Captain, l'auteur écrit sur le passé, le présent et l'avenir du nouveau monde merveilleux des temps d'exécution des conteneurs. Et pour les plus paresseux, le matériel commence par un TL; DR compact sur le sujet ... Constatations clés
- Au fil du temps, le choix entre les temps d'exécution des conteneurs s'est élargi, offrant plus d'options que le moteur Docker populaire.
- L'Open Container Initiative (OCI) a réussi à normaliser le concept de conteneur et d'image de conteneur afin de garantir l'interopérabilité («interopérabilité» - environ. Trad.) Entre les environnements d'exécution.
- Kubernetes a ajouté la Container Runtime Interface (CRI), qui permet aux conteneurs de se connecter aux environnements d'exécution avec la couche d'orchestration sous-jacente dans K8s.
- Les innovations dans ce domaine permettent aux conteneurs de tirer parti de la virtualisation légère et d'autres techniques d'isolation uniques pour répondre aux exigences de sécurité croissantes.
- Avec OCI et CRI, l'interopérabilité et le choix sont devenus une réalité dans l'écosystème des environnements de conteneur d'exécution et d'orchestration.
La technologie de conteneurisation existe depuis un certain temps dans le monde des systèmes d'exploitation Linux - les premières idées sur des espaces de noms séparés pour les systèmes de fichiers et les processus sont apparues il y a plus de dix ans. Et dans un passé relativement récent, le LXC est apparu et est devenu le moyen standard pour les utilisateurs de Linux d'interagir avec la puissante technologie d'isolation cachée dans le noyau Linux.
Cependant, même en dépit des tentatives
du LXC de cacher la complexité de la combinaison de divers "intérieurs" technologiques de ce que nous appelons habituellement un conteneur aujourd'hui, les conteneurs sont restés une sorte de magie et ne sont devenus plus forts que dans le monde des conteneurs particulièrement bien informés, et n'étaient pas largement répandus parmi les masses.
Tout a changé en 2014 avec
Docker , lorsqu'un nouveau wrapper convivial pour les développeurs pour la même technologie de noyau Linux que LXC avait en service est apparu - après tout, les premières versions de Docker «en coulisses» utilisaient LXC, et les conteneurs sont devenus - un véritable phénomène de masse, car les développeurs ont été imprégnés de la simplicité et des possibilités de réutilisation des images de conteneur Docker et des commandes simples pour travailler avec eux.
Bien sûr, Docker n'était pas le seul à vouloir gagner une part du marché des conteneurs alors que le battage médiatique qui les accompagnait ne pensait pas se calmer après le premier intérêt explosif en 2014. Au fil des ans, une variété d'idées alternatives ont émergé pour les environnements de conteneurs exécutables de
CoreOS (rkt) ,
Intel Clear Containers ,
hyper.sh (virtualisation basée sur des conteneurs légers), ainsi que
Singularity et
shifter dans le monde de la recherche en calcul haute performance (HPC).
Le marché a continué de croître et de mûrir, et avec l'
Open Container Initiative (OCI) est venu l'effort de normaliser les idées initiales promues par Docker. Aujourd'hui, de nombreux environnements exécutables de conteneurs sont déjà compatibles avec OCI, ou en voie de l'être, offrant aux fabricants des conditions égales pour promouvoir leurs fonctionnalités et capacités axées sur une application particulière.
Popularité de Kubernetes
L'étape suivante de l'évolution des conteneurs consistait à combiner des conteneurs informatiques distribués à la microservices avec des conteneurs - et tout cela dans le nouveau monde des itérations de développement et de déploiement rapides (on peut dire que DevOps), qui gagnait activement du terrain avec la popularité de Docker.
Bien
qu'Apache Mesos et d'autres plates-formes d'orchestration logicielle
aient existé avant la domination de
Kubernetes , les
K8 ont décollé rapidement d'un petit projet Open Source de Google vers le projet principal de la
Cloud Native Computing Foundation (CNCF) .
Remarque perev. : Savez-vous que la CNCF est apparue en 2015 à l'occasion de la sortie de Kubernetes 1.0? Dans le même temps, le projet a été transféré par Google à une nouvelle organisation indépendante qui est devenue partie intégrante de la Fondation Linux.
Événement de sortie de K8s 1.0 sponsorisé, entre autres, Mesosphere, CoreOS, Mirantis, OpenStack, Bitnami
D'après les informations sur la sortie de Kubernetes 1.0 sur ZDNetMême après que Docker a publié la plate-forme d'orchestration rivale,
Swarm , intégrée à Docker et dotée de la simplicité de Docker et d'une concentration sur la configuration de cluster sécurisé par défaut, cela ne suffisait plus à endiguer l'intérêt croissant pour Kubernetes.
Cependant, de nombreuses parties prenantes en dehors des communautés natives du cloud en croissance rapide étaient confuses. Un observateur moyen ne pouvait pas comprendre ce qui se passait: les Kubernetes se battent avec Docker ou leur coopération? Parce que Kubernetes n'était qu'une plate-forme d'orchestration, un environnement de conteneur exécutable était nécessaire pour lancer directement les conteneurs orchestrés dans Kubernetes. Dès le début, Kubernetes a utilisé le moteur Docker et, malgré la tension concurrentielle entre Swarm et Kubernetes, Docker était toujours le moteur d'exécution par défaut et était requis pour que le cluster Kubernetes fonctionne.
Avec un petit nombre d'exécutions de conteneurs autres que Docker, il semblait clair que l'association de l'exécution avec Kubernetes nécessiterait une interface spécialement écrite - shim - pour chaque exécution. L'absence d'une interface claire pour implémenter les temps d'exécution des conteneurs a rendu très difficile l'ajout de la prise en charge des nouveaux temps d'exécution dans Kubernetes.
Interface d'exécution du conteneur (CRI)
Pour résoudre la complexité croissante de l'implémentation des runtimes dans Kubernetes, la communauté a défini une fonction spécifique à l'interface que le runtime du conteneur doit implémenter dans Kubernetes - en la nommant
Container Runtime Interface (CRI) (il est apparu dans Kubernetes 1.5 - environ Transl.) . Cet événement a non seulement aidé le problème du nombre croissant de fragments de la base de code Kubernetes affectant l'utilisation des temps d'exécution des conteneurs, mais a également aidé à comprendre exactement quelles fonctions devraient être prises en charge par les temps d'exécution potentiels s'ils veulent se conformer à CRI.
Comme vous pouvez le deviner, CRI attend des choses très simples de l'exécution. Un tel environnement devrait être capable de démarrer et d'arrêter des pods, de gérer toutes les opérations avec des conteneurs dans le contexte des pods (démarrer, arrêter, suspendre, tuer, supprimer), et également de prendre en charge la gestion des images de conteneurs à l'aide du registre. Il existe également des fonctions auxiliaires pour collecter les journaux, les métriques, etc.
Lorsque de nouvelles fonctionnalités apparaissent dans Kubernetes, si elles dépendent de la couche d'exécution du conteneur, ces modifications sont apportées à l'API CRI versionnée. Cela crée à son tour une nouvelle dépendance fonctionnelle sur Kubernetes et nécessite la publication de nouvelles versions de runtimes qui prennent en charge de nouvelles fonctionnalités (un exemple récent est les espaces de noms des utilisateurs).
Paysage actuel du CRI
Depuis 2018, il existe plusieurs options à utiliser en tant que runtime de conteneur dans Kubernetes. Comme le montre l'illustration ci-dessous, l'une des vraies options est toujours Docker avec son
dockershim qui implémente l'API CRI. Et en fait, dans la plupart des installations de Kubernetes aujourd'hui, c'est lui, Docker, qui reste le runtime par défaut.
L'une des conséquences intéressantes de la tension entre la stratégie d'orchestration de Docker avec Swarm et la communauté Kubernetes a été un projet commun, qui a pris la base du runtime de Docker et en a rassemblé un nouveau projet Open Source développé conjointement -
containerd . Au fil du temps, containerd a été transféré à la CNCF, la même organisation qui gère et détient le projet Kubernetes.
( Note trad .: Nous avons décrit l'apparence de containerd plus en détail dans un article séparé .)
De l' annonce de containerd sur le blog DockerContainerd, étant une implémentation simple, basique et
indépendante de l' entreprise
(sans opinion) du runtime pour Docker et Kubernetes (via CRI), a commencé à gagner en popularité en tant que remplaçant potentiel de Docker dans de nombreuses installations Kubernetes. À ce jour, IBM Cloud et Google Cloud ont tous deux des clusters basés sur containerd en mode d'accès anticipé / bêta. Microsoft Azure a également promis de passer à containerd à l'avenir, et Amazon envisage toujours différents temps d'exécution pour ses solutions de conteneur (ECS et EKS), tout en continuant à utiliser Docker.
Red Hat est entré dans l'espace d'
exécution du conteneur en créant une implémentation CRI simple appelée
cri-o basée sur l'implémentation de référence OCI,
runc . Docker et containerd sont également basés sur runc, mais les créateurs de cri-o affirment que leurs temps d'exécution sont "juste assez" pour Kubernetes et qu'ils n'en ont pas besoin de plus - ils ont juste ajouté les fonctions les plus nécessaires pour implémenter Kubernetes CRI sur le binaire runc de base.
( Note trad .: Nous avons écrit plus sur le projet CRI-O dans cet article , et ici sur son développement ultérieur sous la forme de podman.)Projets de virtualisation légers: Intel Clear Containers et hyper.sh - sont apparus dans la nature de la Fondation OpenStack,
conteneurs Kata , et offrent leur vision de conteneurs virtualisés pour une isolation supplémentaire en utilisant une implémentation CRI appelée
frakti . Cri-o et containerd fonctionnent également avec les conteneurs Kata, de sorte que leur runtime compatible OCI peut être sélectionné comme option enfichable.
Prédire l'avenir
Dire que vous savez que l'avenir n'est généralement pas très sage, mais nous pouvons au moins corriger certaines tendances émergentes alors que l'écosystème des conteneurs passe de l'enthousiasme et du battage publicitaire à une étape plus mature de notre existence.
Au début, on craignait que l'écosystème des conteneurs ne forme un environnement fragmenté, dont les différents participants proposeraient des idées différentes et incompatibles sur ce qu'est un conteneur. Grâce au travail d'OCI et aux actions responsables des principaux fournisseurs et participants, nous avons constaté un environnement sain dans l'industrie parmi les offres de logiciels qui préféraient la compatibilité avec OCI.
Même dans les environnements plus récents où la norme d'utilisation Docker rencontrait moins de résistance en raison des restrictions existantes - par exemple, dans HPC - toutes les tentatives de création d'environnements de conteneurs conteneur non basés sur Docker ont également attiré l'attention sur l'OCI. Des discussions sont en cours pour savoir si le BEC peut être une solution viable pour les besoins spécifiques des communautés de scientifiques et de chercheurs.
En ajoutant à cela la standardisation des temps d'exécution des conteneurs de plug-ins dans Kubernetes à l'aide de CRI, nous pouvons imaginer un monde où les développeurs et les administrateurs peuvent choisir les bons outils et les piles de logiciels pour leurs tâches, en attendant et en observant l'interopérabilité à travers tout l'écosystème de conteneurs.
Prenons un exemple spécifique pour mieux comprendre ce monde:
- Un développeur avec un MacBook utilise Docker pour Mac pour développer son application et utilise même le support intégré de Kubernetes (Docker fonctionne comme le runtime CRI ici) pour essayer de déployer la nouvelle application sur les pods K8s.
- L'application passe par CI / CD dans le logiciel du fournisseur, qui utilise runc et du code spécial (écrit par le fournisseur) pour empaqueter l'image OCI et la charger dans le registre d'entreprise des conteneurs pour les tests.
- L'installation de cluster Kubernetes sur site, en utilisant containerd en tant qu'exécution CRI, exécute un ensemble de tests pour l'application.
- Cette société, pour une raison quelconque, a choisi des conteneurs Kata pour certaines charges de travail en production, donc lorsque vous déployez l'application, elle démarre dans des pods avec containerd configuré pour utiliser les conteneurs Kata comme runtime au lieu de runc.
L'ensemble du scénario décrit fonctionne à merveille en raison de la compatibilité avec la spécification OCI pour les environnements d'exécution et les images, et du fait que CRI offre la flexibilité de choisir l'exécution.
Cette flexibilité et ce choix possibles rendent l'écosystème de conteneurs vraiment remarquable et sont également une condition très importante pour la maturité de l'industrie, qui a connu une croissance si rapide depuis 2014. Au seuil de 2019 et des années suivantes, je vois un brillant avenir avec des innovations et une flexibilité continues pour ceux qui utilisent et créent des plateformes basées sur des conteneurs.
De plus amples informations sur ce sujet peuvent être trouvées dans une récente conférence de Phil Estes sur QCon NY: «
CRI Runtimes Deep Dive: Who's Running My Kubernetes Pod!? "
PS du traducteur
Lisez aussi dans notre blog: