Azure Kubernetes double sur WebAssembly

Il est intéressant de voir comment les environnements d’exécution natifs du cloud évoluent. Bien que les conteneurs permettent aux applications d’apporter facilement leurs propres environnements d’exécution dans les clouds et offrent une isolation efficace des autres applications, ils n’offrent pas tout ce que nous attendons d’un sandbox d’application sécurisé. Apporter votre propre userland résout beaucoup de problèmes, mais c’est une isolation horizontale et non verticale. Les applications de conteneur ont toujours accès aux ressources de l’hôte.

C’est pourquoi WebAssembly (souvent abrégé en Wasm) est devenu de plus en plus important. WebAssembly s’appuie sur le runtime JavaScript familier pour fournir un bac à sable pour le code côté serveur et côté utilisateur. Les binaires écrits dans des langages familiers, y compris Go et Rust sécurisés pour la mémoire et le type, peuvent s’exécuter sur Wasm dans le navigateur et utiliser WASI (WebAssembly System Interface) en tant qu’applications natives qui n’ont pas besoin d’un hôte de navigateur.

Il existe certaines similitudes entre WASI et Node.js, mais la plus grande différence est peut-être la plus importante : vous n’êtes pas limité à travailler en JavaScript. WASI ne vous donne pas toutes les API que vous pourriez attendre d’un environnement d’exécution comme .NET ou Java, mais il évolue rapidement, vous donnant un moyen d’exécuter le même code sur tout, des appareils de type Raspberry Pi à la périphérie, sur des nuages ​​hyperscale , et sur le matériel x64 et Arm. Avec un seul compilateur et une seule plate-forme de développement, vous pouvez utiliser des outils familiers de manière familière.

WebAssembly dans Kubernetes

Wasm et WASI présentent des avantages par rapport au travail avec des conteneurs : les applications peuvent être petites et rapides et peuvent s’exécuter à des vitesses quasi natives. Le bac à sable Wasm est également plus sécurisé, car vous devez activer explicitement l’accès aux ressources en dehors du bac à sable WebAssembly.

Chaque année, au KubeCon de la Cloud Native Computing Foundation, la pré-conférence Wasm Day prend de plus en plus d’ampleur, avec un contenu qui commence à se retrouver dans les sessions principales de la conférence. En effet, WebAssembly est considéré comme une charge utile pour les conteneurs, un moyen de programmer des services annexes tels que des maillages de services et un autre moyen de fournir et d’orchestrer des charges de travail sur des périphériques périphériques. En fournissant un environnement d’exécution commun pour Kubernetes basé sur son propre bac à sable, il est capable d’ajouter une couche supplémentaire d’isolation et de sécurité pour votre code, un peu comme courir dans Environnement de conteneur sécurisé d’Hyper-V qui exécute des conteneurs dans leurs propres machines virtuelles sur des hôtes légers Windows ou Linux.

En orchestrant le code Wasm via des technologies Kubernetes telles que Krustlets et WAGI, vous pouvez commencer à utiliser le code WebAssembly dans vos environnements cloud natifs. Bien que ces expériences exécutent Wasm directement, une approche alternative basée sur les modules WASI utilisant containerd est désormais disponible dans Azure Kubernetes Service.

Containerd facilite l’exécution de WASI

Cette nouvelle approche profite fonctionnement de l’environnement d’exécution conteneur sous-jacent de Kubernetes. Lorsque vous utilisez Kubernetes pour orchestrer des nœuds de conteneur, containerd utilise normalement un shim pour lancer runc et exécuter un conteneur. Avec cette approche de haut niveau, containerd peut prendre en charge d’autres runtimes avec leurs propres shims. Rendre containerd flexible lui permet de prendre en charge plusieurs runtimes de conteneurs, et des alternatives aux conteneurs peuvent être contrôlées via les mêmes API.

L’API de shim de conteneur dans containerd est assez simple. Lorsque vous créez un conteneur à utiliser avec containerd, vous spécifiez le runtime que vous prévoyez d’utiliser en utilisant son nom et sa version. Cela peut également être configuré à l’aide d’un chemin d’accès à un environnement d’exécution. Containerd fonctionnera alors avec un containerd-shim- préfixe afin que vous puissiez voir quels shims sont en cours d’exécution et les contrôler avec des outils de ligne de commande standard.

L’architecture adaptative de Containerd explique pourquoi supprimer Dockershim de Kubernetes était important, car avoir plusieurs couches de cale aurait ajouté de la complexité. Un seul processus de shim auto-descriptif facilite l’identification des runtimes actuellement utilisés, ce qui vous permet de mettre à jour les runtimes et les bibliothèques si nécessaire.

Runwasi : un shim conteneurisé pour WebAssembly

Il est relativement facile d’écrire un shim pour containerd, permettant à Kubernetes de contrôler une sélection beaucoup plus large de runtimes et d’environnements d’exécution au-delà du conteneur familier. La cale runwasi utilisé par Azure en profite, se comportant comme un simple hôte WASI utilisant une bibliothèque Rust pour gérer l’intégration avec containerd ou l’outil Kubernetes CRI (Container Runtime Interface).

Bien que runwasi soit toujours un code de qualité alpha, c’est une alternative intéressante aux autres façons d’exécuter WebAssembly dans Kubernetes, car il traite le code WASI comme n’importe quel autre pod dans un nœud. Runwasi propose actuellement deux cales différentes, une qui s’exécute par pod et une qui s’exécute par nœud. Ce dernier partage un seul environnement d’exécution WASI sur tous les pods d’un nœud, hébergeant plusieurs bacs à sable Wasm.

Microsoft utilise runwasi pour remplacer Krustlets dans son service Azure Kubernetes. Bien que Le support Krustlet fonctionne toujours, il est recommandé de passer au nouvel outil de gestion de la charge de travail en déplaçant les charges de travail WASI vers un nouveau pool de nœuds Kubernetes. Pour l’instant, runwasi est un aperçu, ce qui signifie qu’il s’agit d’une fonctionnalité opt-in et qu’il n’est pas recommandé de l’utiliser en production.

Utilisation de runwasi pour les nœuds WebAssembly dans AKS

Le service utilise des indicateurs de fonctionnalité pour contrôler ce que vous pouvez utiliser, vous aurez donc besoin d’Azure CLI pour activer l’accès. Commencez par installer le aks-preview extension à la CLI, puis utilisez le az feature register commande pour activer le WasmNodePoolPreview.

az feature register —namespace “Microsoft.ContainerService” —name “WasmNodePoolPreview”

Le service prend actuellement en charge les frameworks d’application Spin et légers. Spin est le framework de microservices piloté par les événements de Fermyon avec les outils Go et Rust, et léger (abréviation de SpiderLightning) provient des Deis Labs de Microsoft, avec la prise en charge de Rust et C pour les modèles de conception et les API courants natifs du cloud. Les deux sont construits au-dessus du temps d’exécution WASI de la Bytecode Alliance. La prise en charge de Wasmtime garantit qu’il est possible de travailler avec des outils tels que le sous-système Windows pour Linux pour créer et tester des applications Rust sur un PC de développement de bureau, prêt pour l’environnement Linux d’AKS.

Une fois que vous avez configuré AKS pour prendre en charge runwasi, vous pouvez ajouter un pool de nœuds WASI à un cluster AKS, vous y connecter avec kubectl et configurer la classe d’exécution pour wasmtime et le framework de votre choix. Vous pouvez maintenant configurer une charge de travail conçue pour wasm32-wasi et l’exécuter. Il s’agit toujours d’un code de prévisualisation, vous devez donc faire beaucoup de choses à partir de la ligne de commande. À mesure que runwasi évolue, attendez-vous à voir les outils du portail Azure et l’intégration avec les services de déploiement de packages, garantissant que les applications peuvent se déployer et s’exécuter rapidement.

Cela devrait être un environnement idéal pour des outils tels que Bindle, garantissant que les versions de charge de travail et les artefacts appropriés sont déployés sur les clusters appropriés. Le code peut s’exécuter en périphérie de Kubernetes et sur des instances hyperscale comme AKS, avec les bonnes ressources pour chaque instance de la même application.

Des aperçus comme celui-ci sont bons pour l’outil Kubernetes d’Azure. Ils vous permettent d’expérimenter de nouvelles façons de fournir des services ainsi que de nouvelles options d’exécution. Vous avez la possibilité de créer des chaînes d’outils et des pipelines CI/CD, en vous préparant pour le moment où WASI deviendra une technologie mature prête pour les charges de travail d’entreprise.

Il ne s’agit pas uniquement de technologie. L’utilisation de WASI comme alternative aux conteneurs présente des avantages intéressants à long terme. Alors que les fournisseurs de cloud tels qu’Azure passent à l’offre de serveurs physiques Arm denses, un environnement d’exécution relativement léger comme WASI peut mettre plus de nœuds sur un serveur, ce qui permet de réduire la quantité d’énergie nécessaire pour héberger une application à grande échelle et de maintenir les coûts de calcul au minimum. Un code plus rapide et plus écologique pourrait aider votre entreprise à atteindre ses objectifs de développement durable.