Kata Containers 1.5 pour Firecracker

中文 版 – Firecracker a été annoncé lors de la conférence re:Invent 2018. Il fournit la sécurité et l’isolation des machines virtuelles ainsi que des temps de démarrage rapides et le support de la densité pour les conteneurs. Il fournit un hyperviseur « Cloud Native » permettant d’exécuter des conteneurs de manière sûre et efficace. Dans ce post, Eric Ernst, du projet Kata Containers, présente comment Firecracker répond au besoin d’un hyperviseur minimal dans sa communauté et comment il est maintenant directement et facilement intégré à Kata Containers.

Kata Containers est un projet open source avec une communauté partout dans le monde dont l’objectif est de créer une implémentation standard de machines virtuelles légères, fonctionnant comme des conteneurs, mais offrant une isolation renforcée des applications en utilisant une machine virtuelle comme seconde couche de défense.

Initialement basé sur QEMU, le projet Kata Containers a été conçu pour prendre en charge plusieurs solutions d’hyperviseur.

À la fin du mois de novembre 2018, Amazon Web Services a annoncé la release en open source de son hyperviseur Firecracker. Extrait du fichier Lisez-moi de Firecracker GitHub :  » Firecracker a un design minimaliste. Il exclut les périphériques inutiles et les fonctionnalités orientées sur les guests afin de réduire l’encombrement de la mémoire et la surface d’attaque de chaque microVM. Cela améliore la sécurité, réduit le temps de démarrage et augmente le taux d’utilisation du matériel  »

Il s’agit une annonce importante pour la communauté Kata, car cela répond aux demandes des utilisateurs finaux d’avoir une solution d’hyperviseur plus minimale pour des cas d’utilisation plus simples. La communauté Kata a immédiatement commencé à travailler avec Firecracker et a eu d’excellentes opportunités de collaborer avec les équipes Firecracker d’AWS.

https://twitter.com/nmeyerhans/status/1072361001792749568?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1072361001792749568&ref_url=https%3A%2F%2Faws.amazon.com%2Fblogs%2Fopensource%2Fkata-containers-1-5-firecracker-support%2F

Depuis la version 1.5 de Kata Containers, un support préliminaire de l’ hyperviseur Firecracker a été ajouté. Celui-ci est complémentaire au support existant du projet QEMU. Etant donné le compromis sur les fonctionnalités disponibles dans Firecracker, nous nous attendons à ce que les utilisateurs utilisent Firecracker pour des applications soumises à des contraintes de fonctionnalité et utilisent QEMU pour l’utilisation sur des applications plus avancées (par exemple, si une affectation de périphérique est nécessaire, QEMU doit être utilisé).

Nous prévoyons qu’il serait typique d’utiliser runc, Kata + QEMU et Kata + Firecracker dans un seul cluster Kubernetes, comme indiqué dans le diagramme ci-dessous:

Pour réaliser cette configuration, le cluster doit être configuré pour utiliser CRI-O ou containerd, ainsi que pour utiliser la fonctionnalité runtimeClass de Kubernetes. Avec runtimeClass configuré dans Kubernetes ainsi que dans CRI-O / containerd, les utilisateurs finaux peuvent sélectionner le type d’isolation souhaité pour chaque charge de travail. Dans cet exemple, deux classes d’exécution sont enregistrées: kata-qemu et kata-fc . La sélection de l’isolation basée sur Firecracker est aussi simple que de patcher les workloads existants avec l’extrait de code YAML suivant :

spec:
    template:
        spec:
            runtimeClassName: kata-fc

Pour utiliser QEMU, la balise runtimeClassName serait modifiée en kata-qemu.

Une démonstration de cette configuration, utilisant CRI-O, Kata Containers et Firecracker VMM, peut être visionnée dans le screencast Kata configuré dans CRIO + K8S, utilisant QEMU et Firecracker.

runtimeClass est une fonctionnalité alpha à partir de Kubernetes 1.13. Il est donc toujours fastidieux de combler les gaps de fonctionnalités et de créer un cluster avec runtimeClass correctement configuré. Pour faciliter la mise en route rapide avec Kata, Firecracker et runtimeClass, nous avons fourni une image vagrant, ainsi que des instructions sur la manière de faire fonctionner et d’utiliser le cluster configuré.

Comme mentionné précédemment, l’hyperviseur Firecracker est minimal par conception. En conséquence, il y aura toujours des gaps dans les fonctionnalités de Kubernetes lors de l’utilisation de Kata + Firecracker. L’une de ces lacunes est l’incapacité à ajuster de manière dynamique les configurations de mémoire et de CPU pour un pod. De même, Firecracker ne pouvant prendre en charge que des pilotes de stockage et des volumes basés sur des blocs, devicemapper est aujourd’hui indispensable. Ceci est disponible dans Kubernetes + CRI-O et Docker version 18.06. Des travaux sont en cours pour ajouter d’autres options de pilote de stockage. Voir la requête sous GitHub pour connaître les limitations actuelles de Kata + Firecracker.

Pour les conteneurs Kata version 1.5, Firecracker est inclu dans le cadre de nos releases de conteneurs statiques katas, ce qui inclut toutes les configurations et les binaires nécessaires pour l’ exécution de Kata + Firecracker. Nous travaillons pour que cela soit disponible dans des packages dans un proche avenir. Pour tester cela avec Docker CLI, il est nécessaire de se reporter au guide de démarrage, qui explique en détail comment créer des applications avec Firecracker ou QEMU pour une isolation renforcée.

Au-delà de la version 1.5, nous prévoyons de nombreuses améliorations pour améliorer la prise en charge de Firecracker:

• Prise en charge améliorée du pilote de stockage basé sur des blocs
• Utilisez le jailer Firecracker pour renforcer l’isolation de l’hôte
• Optimisations autour du démarrage
• Le contrôleur d’admission de référence aide à sélectionner l’isolation appropriée de l’hyperviseur lors de l’utilisation de Kata Containers

Nous sommes ravis de travailler avec l’équipe Firecracker et de continuer à améliorer notre assistance pour Firecracker VMM et son intégration dans Kubernetes.

La communauté Kata Containers est gérée par la OpenStack Foundation (OSF), qui soutient le développement et l’adoption d’une infrastructure ouverte à l’échelle mondiale en hébergeant des projets open source et des communautés d’experts. La communauté Open Source de Kata produit du code sous la licence Apache 2. Toute personne est la bienvenue pour rejoindre et contribuer au code, à la documentation et aux cas d’utilisation.

Vous pouvez explorer Kata sur GitHub et KataContainers.io et vous impliquer dans la communauté via ces canaux:

• Slack ou IRC Freenode: # kata-dev
• Liste de diffusion
• Réunions hebdomadaires
• Twitter

A propos des auteurs

Eric Ernst est membre du commité d’architecture de Kata Containers et un développeur senior au sein de l’Open Source Technology Center chez Intel, basé à Portland, Oreon. Eric a travaillé de nombreuses année sur le développement de firmwares embarquées et le kernel Linux. Il est également en charge des travaux sur les runtime containeur pour Intel.

Le contenu et les opinions contenus dans ce message sont ceux de l’auteur tiers et AWS n’est pas responsable du contenu ou de l’exactitude de ce message.

Traduit en francais par Guillaume Fediere, Solutions Architect chez AWS, LinkedIn.

Source