Sommaire
Update : RKT c’est fini
Le runtime abordé dans cet article RKT est abandonné depuis le mai 2020, nous vous déconseillons donc son utilisation.
Si vous souhaitez trouver une alternative à RKT, nous avons abordé ce sujet au Paris Container Day 2021 ! Donc n’hésitez pas à aller voir la conférence “Pour quelques runtimes de plus” de Thomas Gerardin, qui présente les principaux runtimes disponible actuellement. Elle est disponible en replay par ici :
RKT, mais qu’est ce que c’est ?
RKT, à prononcer “rock-it”, est un container runtime créé par les équipes de CoreOS, avec une première release fin novembre 2014 et qui est en constante évolution depuis (au rythme d’une release toutes les 2 semaines en moyenne).
Pourquoi un autre container runtime ?
La définition d’un standard autour de ce que doit être un container ayant été mise en place aux débuts de Docker, le manifeste se trouve ici, les équipes de Container Linux ont fortement participé à son développement.
Toutefois, l’évolution de Docker ne correspondait pas à ce que les développeurs de CoreOS envisageaient à la base :
- Docker tourne avec un daemon qui gère l’ensemble des composants. Si ce processus disparait, les containers ont disparu (la situation a changé en Juin 2016 avec la sortie de la version 1.11 de Docker, avec le Docker Engine séparé du daemon gérant les containers).
- De “simple” container, Docker est devenu tout un écosystème packagé dans un seul binaire (là encore, la situation a changé depuis ce constat) : création d’images, orchestrateur de containers.
De ce constat est né le projet RKT.
Mais plus précisément, c'est quoi ?
Le développement de RKT s’est concentré sur les points suivants:
La sécurité : la signature ainsi que l’intégrité des images est vérifiée par défaut au téléchargement ou au lancement d'un container. De plus, l'architecture a elle aussi gagné en sécurité. En effet, aucun daemon nécessitant des privilèges élevés n'est nécessaire au bon fonctionnement de RKT et en fonction de l'opération à réaliser, il n'est pas forcément nécessaire d'avoir des privilèges administrateurs. La récupération d'une image en est un exemple.
Afin d'assurer l'isolation entre l'host et les containers, RKT n'a pas réinventé la roue et utilise les mécanismes existants tels que les Cgroups v1 et v2 ou encore Selinux. L'isolation matérielle est, elle, assurée par le support des hyperviseurs. Cerise sur le gâteau, le support de Trusted Platform Module va permettre l'audit des containers ainsi que de leur configuration.
Composabilité : elle est à la fois externe et interne. En externe, RKT est compatible avec les systèmes d'init existants que sont OpenRC et Systemd. La compatibilité avec les orchestrateurs tels que Kubernetes et Nomad est aussi assurée.
En interne, celle-ci est assurée par un fonctionement en couches et le support de plusieurs moteurs d'exécution pour les containers. Les différentes couches sont les suivantes:
en stage0, RKT lui même, le binaire n'étant qu'une UX/API pour le moteur d'exécution du container
en stage1 se trouve le moteur d'exécution du container. Comme évoqué précédemment, plusieurs sont disponibles. Par défaut, un container est lancé via systemd-nspawn. Le container peut aussi démarrer via un simple chroot, nommé fly par les développeurs de RKT. Enfin, l'isolation matérielle peut aussi être réalisée sur cette couche par l'intermédiaire de LKVM (une version allégée de KVM) ou en core Qemu
et enfin, le stage2 comprend la ou les applications qui doivent fonctionner dans le container lancé.
La notion de Pod par RKT regroupe à la fois le moteur d'exécution et les applications containerisées, ce qui est au final démarré par le binaire rkt. Illustrée, cette composabilité interne peut être vue de la façon suivante:
Une intégration aux standards : RKT a été la première implémentation du standard APPC, qui définit ce que doit être un container runtime, le format d'image, le protocole de découverte d'images. Ce standard a eu son petit succès mais est désormais en perte de vitesse. L'Open Container Initiative, promue par la Linux Foundation, et avec la participation des grands acteurs du secteur, propose un nouveau standard qui définit lui aussi ce que doit être un container ainsi que le format de l'image, pour le moment seulement considéré comme un "filesystem bundle" décompressable sur disque. À terme, les fonctionnalités d'APPC seront disponibles avec OCI. Enfin, le projet Container Runtime Interface (CRI) développé principalement par Google et Redhat, qui permet la définition d'une API permettant de lancer tout container runtime avec les mêmes instructions, a été pris en compte récemment dans RKT.
La compatibilité : les images Docker sont supportées nativement.
Une API gRPC est disponible afin de réaliser de l'introspection sur les containers et les images.
Ça évolue ?
Parmi les évolutions présentes dans les dernières releases (au moment de l'écriture de cet article, la dernière version est la 1.23.0), nous pouvons noter:
- le support des cgroups version 2,
- l'ajout du support de qemu en stage1,
- la possibilité de réaliser de l'app sandboxing grâce à l'inclusion de CRI qui permet l'ajout/suppression d'applications à chaud dans un container. De ce fait, les tests de container sont facilités,
- support de qemu en stage 1,
- l'introduction du support du format OCI,
- la détection d'attaques sur les containers utilisant KVM. Cette fonctionnalité est pour le moment au stade de pull request et devrait être disponible dans une prochaine release. Plus de détails ici,
et bien évidemment une documentation agrémentée et des corrections de bug.
Les containers, c'est bon, mangez-en !
Si cette introduction vous a donné envie d’essayer RKT, rendez-vous prochainement pour un tutoriel qui vous permettra d'appréhender l’utilisation de RKT.
