Publication de Kata Containers 3.4 avec isolation basée sur la virtualisation.

La version 3.4 du projet Kata Containers a été publiée, développant une pile pour l'exécution de conteneurs en utilisant l'isolement basé sur des mécanismes de virtualisation complets. Le projet a été créé par Intel et Hyper par la fusion des technologies Clear Containers et runV. Le code du projet est écrit en Go et Rust, et est distribué sous la licence Apache 2.0. Le projet est supervisé par un groupe de travail créé sous l'égide de l'organisation indépendante OpenInfra Foundation, qui inclut des entreprises telles que Canonical, China Mobile, Dell/EMC, EasyStack, Google, Huawei, NetApp, Red Hat, SUSE et ZTE.

La base de Kata est un runtime permettant de créer des machines virtuelles compactes, exécutées en utilisant un hyperviseur complet, au lieu d'utiliser des conteneurs traditionnels qui partagent le noyau Linux et sont isolés par des espaces de noms et des cgroups. L'utilisation de machines virtuelles permet d'atteindre un niveau de sécurité plus élevé, protégeant contre les attaques résultant de l'exploitation de vulnérabilités dans le noyau Linux.

Kata Containers est orienté vers l'intégration dans les infrastructures d'isolement de conteneurs existantes, avec la possibilité d'utiliser des machines virtuelles similaires pour renforcer la protection des conteneurs traditionnels. Le projet fournit des mécanismes pour assurer la compatibilité des machines virtuelles légères avec diverses infrastructures d'isolement de conteneurs, plates-formes d'orchestration de conteneurs et spécifications telles que OCI (Open Container Initiative), CRI (Container Runtime Interface) et CNI (Container Networking Interface). Des outils d'intégration avec Docker, Kubernetes, QEMU et OpenStack sont disponibles.

L'intégration avec les systèmes de gestion de conteneurs est réalisée par une couche qui simule la gestion d'un conteneur, qui, via une interface gRPC et un proxy spécial, communique avec l'agent de gestion dans la machine virtuelle. À l'intérieur de l'environnement virtuel, qui est lancé par l'hyperviseur, un noyau Linux spécialement optimisé est utilisé, contenant seulement l'ensemble minimal de fonctionnalités nécessaires.

Dragonball Sandbox (édition KVM optimisée pour les conteneurs) est pris en charge comme hyperviseur, avec des outils QEMU, ainsi que Firecracker et Cloud Hypervisor. L'environnement système comprend un démon d'initialisation et un agent (Agent). L'Agent permet l'exécution d'images de conteneur spécifiées par l'utilisateur au format OCI pour Docker et CRI pour Kubernetes. Lorsqu'il est utilisé avec Docker, un conteneur distinct est créé pour chaque conteneur. machine virtuelle, c'est-à-dire qu'un environnement exécuté au-dessus de l'hyperviseur est appliqué pour le lancement imbriqué des conteneurs.

Pour réduire la consommation de mémoire, un mécanisme DAX (accès direct au système de fichiers contournant le cache de pages sans utiliser le niveau de dispositifs de blocs) est utilisé, et la technologie KSM (Kernel Samepage Merging) est appliquée pour la déduplication des zones de mémoire identiques, ce qui permet de partager les ressources du système hôte et de connecter à différents systèmes invités un modèle d'environnement système commun.

Un système de fichiers Nydus est utilisé pour organiser l'accès aux images de conteneurs, utilisant un adressage basé sur le contenu pour une collaboration efficace avec les images standard. Nydus prend en charge le chargement à la volée des images (ne les charge que lorsque cela est nécessaire), fournit la déduplication des données répétées et peut utiliser différents backend pour le stockage réel. La compatibilité avec POSIX est assurée (à l'instar de Composefs, l'implémentation de Nydus combine les capacités d'OverlayFS avec EROFS ou un module FUSE).

Dans la nouvelle version :

• Le gestionnaire de machines virtuelles Dragonball a ajouté la prise en charge de la connexion à chaud des GPU et la possibilité d'utiliser les registres MTRR (Memory-Type Range Registers) pour accéder aux zones de mémoire physique.
• Dans runtime-rs, l'implémentation du runtime en Rust, une gestion complète des threads, pid et tid est fournie, et le driver qemu a été révisé, ce qui est essentiel sur les systèmes avec une architecture s390 (IBM Z).
• Le service de création de snapshots a été mis à jour pour utiliser le système de fichiers Nydus.
• L'efficacité de la gestion de la mémoire a été améliorée dans le service de gestion des images de conteneurs.
• Le montage de la hiérarchie cgroups-v2 est activé par défaut au démarrage par le biais de systemd.
• La possibilité de définir un délai d'attente a été ajoutée pour limiter le temps de réception d'images très volumineuses dans les systèmes invités.
• Ajout du support de la construction de l'agent OPA (Open Policy Agent) pour les architectures ppc64le et s390x.

Source : opennet.ru