Les Unikernels existent depuis de nombreuses années et sont réputés pour offrir d’excellentes performances en termes de temps de démarrage, de débit et de consommation de mémoire, pour n’en nommer que quelques-uns. [1]. Malgré leur potentiel apparent, les unikernels n’ont pas encore connu un large niveau de déploiement en raison de trois inconvénients principaux:

• Difficile à construire: L’assemblage d’une image unikernel nécessite généralement un travail manuel d’expert qui doit être refait pour chaque application. De plus, de nombreux projets unikernel ne sont pas, et ne visent pas à être, conformes à POSIX, et un effort de portage important est donc nécessaire pour avoir des applications et des frameworks standard exécutés sur eux.
• Difficile à extraire haute performance: Les projets Unikernel n’exposent généralement pas d’API hautes performances; l’extraction de hautes performances nécessite souvent des connaissances d’experts et des modifications du code.
• Écosystème d’outils peu ou pas: En supposant que vous ayez une image à exécuter, la déployer et la gérer est souvent une opération manuelle. Il y a peu d’intégration avec les principaux frameworks DevOps ou d’orchestration.

Bien que tous les projets unikernel ne souffrent pas de tous ces problèmes (par exemple, certains fournissent un certain niveau de conformité POSIX mais les performances font défaut, d’autres ciblent un seul langage de programmation et sont donc relativement faciles à construire mais leur applicabilité est limitée), nous soutenons que aucun projet n’a été en mesure de les résoudre tous avec succès, ce qui a entravé tout niveau de déploiement significatif. Au cours des trois dernières années, Unikraft (www.unikraft.org), un projet de la Linux Foundation sous les auspices du projet Xen, a eu pour objectif explicite de changer cet état de fait pour amener les unikernels dans le courant dominant.

Si vous êtes intéressé, lisez la suite et assurez-vous de vérifier:

Haute performance

Pour permettre aux développeurs d’obtenir facilement des performances élevées, Unikraft expose un ensemble d’API composables et orientées performances. La figure ci-dessous montre l’architecture d’Unikraft: tous les composants sont des bibliothèques avec leurs propres Makefile et Kconfig fichiers de configuration, et peuvent donc être ajoutés à la construction unikernel indépendamment les uns des autres.

Figure 1. Architecture entièrement modulaire d’Unikraft montrant des API hautes performances

Les API sont également des micro-bibliothèques qui peuvent être facilement activées ou désactivées via un menu Kconfig; Les Unikraft Unikraft peuvent composer les API à choisir pour répondre au mieux aux besoins d’une application. Par exemple, une application de style RCP peut désactiver le uksched API (➃ dans la figure) pour implémenter une boucle d’événement d’exécution à achèvement de haute performance; de même, un développeur d’application peut facilement sélectionner un allocateur de mémoire approprié (➅) pour obtenir des performances maximales, ou pour en utiliser plusieurs dans le même unikernel (par exemple, un allocateur de mémoire simple et rapide pour le code de démarrage, et un alloueur standard pour l’application elle-même).

Figure 2. Consommation de mémoire Unikraft par rapport aux autres projets Unikernel et Linux	Figure 3. Débit Unikraft NGINX par rapport aux autres unikernels, Docker et Linux / KVM.

Ces API, associées au fait que tous les composants d’Unikraft sont entièrement modulaires, se traduisent par des performances élevées. La figure 2, par exemple, montre Unikraft ayant une consommation de mémoire inférieure à celle d’autres projets unikernel (HermiTux, Rump, OSv) et Linux (Alpine); et la figure 3 montre qu’Unikraft les surpasse en termes de requêtes NGINX par seconde, atteignant 90K sur un seul cœur de processeur.

De plus, nous travaillons sur (1) un outil de profilage de performances pour être en mesure d’identifier rapidement les goulots d’étranglement potentiels dans les images Unikraft et (2) un outil de test de performances qui peut exécuter automatiquement un grand ensemble d’expériences de performances, en variant différentes options de configuration pour comprendre configurations optimales.

Facilité d’utilisation, aucun portage requis

Forcer les utilisateurs à porter des applications vers un unikernel pour obtenir des performances élevées est un véritable coup de cœur. On peut soutenir qu’un système est aussi bon que les applications (ou langages de programmation, frameworks, etc.) peuvent fonctionner. Unikraft vise à obtenir une bonne compatibilité POSIX; une façon de le faire est de soutenir un libc (par exemple, musl), ainsi qu’un grand nombre d’appels système Linux.

Figure 4. Seul un certain pourcentage d’appels système est nécessaire pour prendre en charge un large éventail d’applications

Bien qu’il y en ait plus de 300, beaucoup d’entre eux ne sont pas nécessaires pour exécuter un grand nombre d’applications; comme le montre la figure 1 (tirée de [5]). Avoir dans la gamme de 145, par exemple, est suffisant pour prendre en charge 50% de toutes les bibliothèques et applications dans une distribution Ubuntu (dont beaucoup ne sont pas pertinentes pour les unikernels, tels que les applications de bureau). Au moment d’écrire ces lignes, Unikraft prend en charge plus de 130 appels système et un certain nombre d’applications grand public (par exemple, SQLite, Nginx, Redis), des langages de programmation et des environnements d’exécution tels que C / C ++, Go, Python, Ruby, Web Assembly et Lua, et non pour mentionner plusieurs hyperviseurs différents (KVM, Xen et Solo5) et support bare-metal ARM64.

Écosystème et DevOps

Un autre inconvénient apparent des projets unikernel est le manque presque total d’intégration avec les principaux frameworks DevOps et d’orchestration existants. En travaillant vers l’objectif d’intégration, au cours de la dernière année, nous avons créé le kraft outil, permettant aux utilisateurs de choisir simplement une application et une plate-forme cible (par exemple, KVM sur x86_64) et de prendre soin de construire l’image qui l’exécute.

Au-delà de cela, nous avons plusieurs sous-projets en cours à soutenir dans les mois à venir:

• Kubernetes: Si vous utilisez déjà Kubernetes dans vos déploiements, ce travail vous permettra de déployer des images Unikraft beaucoup plus simples et rapides de manière transparente.
• Fonderie de nuages: De même, les utilisateurs qui s’appuient sur Cloud Foundry pourront générer des images Unikraft à travers celui-ci, encore une fois de manière transparente.
• Prométhée: Les Unikernels sont également connus pour avoir des moyens très primitifs ou aucun moyen de surveiller les instances en cours d’exécution. Unikraft cible le support Prometheus pour fournir un large éventail de capacités de surveillance.

Dans l’ensemble, nous pensons qu’Unikraft se rapproche de combler le fossé entre la promesse unikernel et le déploiement réel. Nous sommes très enthousiasmés par les fonctionnalités et les développements à venir de cette année, alors n’hésitez pas à nous laisser un message si vous avez des commentaires, des questions ou des suggestions à l’adresse info@unikraft.io.

A propos de l’auteur: Dr Felipe Huici est chercheur en chef, groupe Systèmes et Machine Learning, NEC Laboratories Europe GmbH

Les références

[1] Unikernels repensant l’infrastructure cloud. http://unikernel.org/

[2] Le moment est-il venu pour les Unikernels de se généraliser avec Unikraft? Salle des développeurs Microkernel FOSDEM 2021. https://fosdem.org/2021/schedule/event/microkernel_unikraft/

[3] Images de nuages ​​gravement débloquées avec Unikraft. Virtualisation FOSDEM 2021 et salle des développeurs IaaS. https://fosdem.org/2021/schedule/event/vai_cloud_images_unikraft/

[4] Bienvenue sur le stand Unikraft! https://stands.fosdem.org/stands/unikraft/

[5] Une étude de l’utilisation et de la compatibilité des API Linux modernes: ce qu’il faut prendre en charge lorsque vous prenez en charge. Eurosys 2016. https://dl.acm.org/doi/10.1145/2901318.2901341