Kubernetes est le fondement de nombreux logiciels natifs du cloud contemporains. C’est une innovation pleinement développée qui est essentielle pour Azure et d’autres clouds hyperscale, Kubernetes n’est certainement pas en reste. Les mises à jour régulières incluent des fonctions, tandis qu’un environnement en pleine croissance crée des outils et des innovations qui s’intègrent à la plate-forme sous-jacente. Il n’est pas surprenant que les plateformes Kubernetes gérées comme Azure Kubernetes Service (AKS) adoptent les nouvelles technologies plus rapidement que les autres services cloud, même avec le rythme de développement rapide que le cloud traite.
Les mises à jour récentes d’AKS ont en fait amélioré l’application sécurité en incluant la prise en charge de la prévisualisation des proxys HTTP et HTTPS, en plus d’intégrer davantage le travail Krustlet dans le courant dominant avec les pools de nœuds d’interface utilisateur du système WebAssembly. Les deux sont actuellement disponibles en tant qu’aperçus opt-in, mieux pris en compte pour les modèles et les expériences. Néanmoins, cela signifie qu’ils sont prévus pour la production avec une assistance d’accord de niveau de service dans les deux prochains mois (bien que probablement plus longtemps pour WebAssembly), et cela vaut la peine de donner envie de voir s’ils répondent à vos exigences.
Y compris l’assistance proxy à Kubernetes
L’assistance pour les proxys HTTP et HTTPS est probablement la fonction la plus bénéfique à court terme, car elle vous permet d’exécuter des clusters Kubernetes derrière des proxys, ce qui permet de exécutez-les dans des réseaux isolés. Ceci est pratique si vous souhaitez utiliser un réseau virtuel Azure pour sécuriser vos services lorsque vous traitez des données sensibles ou utilisez un cloud hybride pour étendre les applications Kubernetes sur site dans Azure. C’est également une approche très probable si vous utilisez AKS dans Azure Arc par vous-même via l’infrastructure hyperconvergée (HCI) Azure Stack ou si vous utilisez une appliance Azure Stack managée à la périphérie du réseau.
La prise en charge du proxy HTTP d’AKS vous permet d’apporter les services et le trafic réseau nécessaires à votre réseau personnel, en enchaînant les connexions via des proxys. En plus des capacités de mise en réseau, il inclut des outils pour gérer les certificats afin de garantir que vos nœuds et clusters isolés font toujours partie d’une chaîne de confiance complète.
Commencer est assez simple. S’inspirant des meilleures pratiques de développement d’applications contemporaines, l’assistance proxy d’AKS est conservée derrière un indicateur de fonction. Ouvrez Azure CLI et utilisez la commande function register pour enregistrer le HTTPProxyConfigService dans le service de conteneur d’Azure. Cela prendra un certain temps, ce que vous pouvez examiner en utilisant la commande feature list. Une fois activé, réenregistrez le Container Service pour utiliser la nouvelle fonctionnalité.
Dès que la fonction a été activée, vous pouvez commencer à l’utiliser dans vos clusters Kubernetes. Cependant, vous ne pouvez pas l’activer sur les clusters existants pour le moment ; l’assistance proxy doit être ajoutée lors de la création du cluster. Ici, vous devrez utiliser la commande aksproduce, avec un fichier de configuration JSON ou YAML. Cela inclut les URL des proxys HTTP et HTTPS, avec une liste de domaines exclus du service proxy. Si vous utilisez une autorité de certification, vous devrez inclure un certificat de noms alternatifs de sujet codé en base64 au format PEM. Les mêmes informations de proxy peuvent être utilisées dans un modèle de conception ARM.
Une fois configurés, les paramètres de proxy d’un cluster ne peuvent pas être modifiés sans configurer complètement un nouveau cluster entier. La seule partie d’une configuration qui peut être modifiée est le certificat de l’autorité de certification, afin de prendre en charge le rollover (en particulier si vous utilisez des certificats temporaires d’un service tel que Let’s Encrypt).
Bien que les proxys soient faciles à configurer et à utiliser, la prise en charge d’AKS est clairement très précoce. Pour quelque chose, certaines situations importantes ne sont pas prises en charge. Actuellement, l’assistance proxy est uniquement pour les clusters basés sur Linux, où tous les pools de nœuds d’un cluster ont la même configuration de proxy et vous n’utilisez pas les ensembles de planification Virtual Maker. Néanmoins, ce sont des problèmes assez mineurs et des solutions de contournement sont possibles.
Utilisation de Krustlets dans AKS
L’autre grande nouvelle version est la prise en charge en avant-première des nœuds WebAssembly comme alternative. pour faire fonctionner des conteneurs. Cette technique est particulièrement intéressante lorsqu’elle concerne des environnements à ressources limitées exécutant des services relativement simples. Un conteneur peut paraître petit, mais il a besoin de ressources d’assistance importantes pour héberger un espace utilisateur d’application. WebAssembly (WASM), en particulier l’environnement sans navigateur WebAssembly Standard Interface (WASI), nécessite des ressources système minimales au-delà d’un environnement JavaScript pris en charge, mettant instantanément en bac à sable tout votre code.
Il y a quelque temps, j’ai écrit sur les expériences des Deis Labs de Microsoft. terminait avec Krustlets, une façon d’utiliser WASI dans les nœuds Kubernetes. C’était une option intéressante pour les conteneurs lourds, fournissant une méthode pour exécuter Kubernetes sur de petits appareils de périphérie. L’intégration de Krustlets dans AKS en tant que pools de nœuds WASM/WASI est une méthode intéressante pour l’étendre, à la fois dans le cloud Azure et dans les circonstances Azure Arc AKS sur le matériel de périphérie.
L’exécution de pools de nœuds WASM nécessite certaines conditions préalables, car ce n’est pas aussi mature que les autres aperçus AKS. Le sortir tôt est une action intrigante pour Microsoft. Il y a un intérêt substantiel pour WASM et Kubernetes, comme l’a révélé l’attrait du Cloud Native WASM Day à KubeCon aux États-Unis et au Canada 2021, il est donc bon de voir Azure prendre une longueur d’avance ici, présentant les outils dont les développeurs auront besoin pour créer et tester les applications distribuées WebAssembly à grande échelle. Il existe également un croisement intéressant avec le travail de Deis Labs sur l’interface utilisateur d’entrée WebAssembly (WAGI) et des outils tels que l’environnement de développement Hippo, qui doivent aider les concepteurs à concevoir et à créer des microservices basés sur Krustlet.
Comme traiter avec les outils proxy HTTPS, vous devez activer l’indicateur de fonctionnalité WasmNodePoolPreview dans ContainerService au moyen d’Azure CLI. Une fois que cela est possible, actualisez le service de conteneur pour vous assurer qu’il est complètement inscrit. Vous devrez ensuite configurer une version préliminaire de l’extension AKS Azure CLI. Si vous l’utilisez actuellement, assurez-vous que cela dépend de la date.
Vous pouvez désormais inclure un pool de nœuds WebAssembly dans un cluster AKS. Cela doit être exécuté sur Linux et doit être séparé de tout nœud basé sur un conteneur. Dès qu’ils sont opérationnels, vous pouvez publier des charges de travail WebAssembly dans votre pool de nœuds. Vous devrez vous assurer qu’il est établi pour exécuter uniquement les pods wasm32-wagi, afin qu’AKS n’organise pas les conteneurs sur vos nœuds WebAssembly et en même temps évite que vos pods WebAssembly ne se remplissent sur des pods de conteneur standard. C’est un domaine qui nécessitera une automatisation dans les versions futures, alors faites attention à garder les deux innovations différentes dans vos modèles.
Microsoft propose un ensemble d’exemples de modules WebAssembly que vous pouvez remplir à l’aide de kubectl, en plus d’un fichier YAML préconfiguré pour configurer votre application de test. Cela peut vous aider avec de futures applications, vous donnant une structure qui peut être adaptée pour fonctionner avec votre propre code. Vous pouvez configurer un proxy inverse pour évaluer votre application WebAssembly, en utilisant un graphique Helm pour remplir l’équilibreur de charge Nginx pour lui offrir une adresse IP externe.
Il s’agit d’une autre action qui sera probablement automatisée dans les futures versions , au fur et à mesure que Microsoft transfère la prise en charge de WebAssembly dans AKS. Cependant, il est excellent de voir une assistance expérimentale arriver ici en avant-première. WASI et WAGI sont encore des technologies très nouvelles, non préparées pour une utilisation aux heures de grande écoute, et bien que Microsoft envisage clairement un avenir durable pour elles dans Kubernetes, il est peu probable que vous les utilisiez en production avant au moins un an.
Ces aperçus montrent qu’il est temps de commencer à voir ce qu’ils peuvent faire pour vous. Les pools de nœuds WebAssembly valent la peine d’être explorés, et il existe une synergie avec l’assistance pour les proxys HTTPS en tant que méthode de passerelle des microservices basés sur WAGI au-delà des réseaux virtuels et des clouds privés. Avec AKS faisant partie d’Azure Arc, il existe de nombreuses possibilités de fournir ces services à des gadgets en dehors du cloud Azure, tout en utilisant Azure et Azure CLI comme couche de gestion.
Microsoft a en fait fait un énorme progrès. engagement envers Kubernetes, à la fois pour ses propres services et pour prendre en charge votre code. L’élimination de sa dépendance vis-à-vis des conteneurs via Krustlets devrait faciliter le démarrage de nouvelles situations de votre code selon les besoins tout en utilisant moins de ressources. Le résultat devrait être des services plus rapides, plus légers et des dépenses de calcul plus faibles. Cela ne se produira pas du jour au lendemain, mais c’est une avancée à laquelle vous devez vous préparer maintenant.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
