Création de cluster Kubernetes sur la base de noeuds de faible priorité dans Azure à l’aide de Microsoft Azure Container Service Engine … Test rapide des Kata Containers

Pour rappel, il a été annoncé la disponibilité publique en preview des machines virtuelles de faible priorité (Low-priority Virtual Machines (VMs) on Virtual Machine Scale Sets). C’est un peu le pendant des machines virtuelles préemptibles dans Google Cloud pour profiter de la quantité de capacité inutilisée disponible qui peut varier en fonction de la taille, de la région, de l’heure de la journée et plus encore. Lors du déploiement de machines virtuelles de faible priorité, Azure attribuera les machines virtuelles si la capacité est disponible, mais il n’existe aucune garantie de contrat de service. À tout moment, si Azure a besoin de capacité, ces machines virtuelles de faible priorité peuvent être supprimées voire détruites (en fonction de l’option choisie). Par conséquent, l’offre de faible priorité est idéale pour les charges de travail flexibles, telles que les gros travaux de traitement, les environnements de test/développement ou les POC.

Je vais donc utiliser Microsoft Azure Container Service Engine. Le moteur de service Azure Container Service Engine (acs-engine) génère des modèles ARM (Azure Resource Manager) pour les clusters compatibles Docker sur Microsoft Azure avec au choix DC/OS, Kubernetes, Swarm Mode, ou Swarm orchestrators. L’entrée dans l’outil est une définition de cluster. La définition du cluster est très similaire à la syntaxe du modèle ARM utilisé pour déployer un cluster Microsoft Azure Container Service. Application ici à la création d’un cluster Kubernetes sur la base de noeuds de faible priorité :

Je récupère donc le binaire acs-engine depuis github :

Je prends un template kubernetes.json disponible sur les exemples du dépôt github que je personnalise :

et le moteur va me génerer les templates ARM dans un répertoire :

et je peux lancer la création du cluster Kubernetes avec des noeuds à basse priorité dans Azure :

az group deployment create \
--name K8SVMSSDeployment \
--resource-group RG-K8SVMSS \
--template-file azuredeploy.json \
--parameters azuredeploy-parameters.json

avec les scale sets :

avec les credentials, j’accède au cluster créé :

et son dashboard :

avec l’installation de Helm :

et de Kubeapps :

Je récupère le token qui va me permettre d’accéder au dashboard de kubeapps pour installer graphiquement des applications dans le cluster Kubernetes sur la base d’un catalogue de services …

voici le catalogue au complet proposé également dans https://hub.kubeapps.com/

J’y installe par exemple Weave Scope pour une visualisation graphique des composants du cluster :

après exposition du service bien évidemment :

ou tester comme d’habitude, le démonstrateur FranceConnect Agent :

J’accède au démonstrateur sur la base de l’IP publique qui m’a été attribuée dans le cluster Kubernetes :

avec les identifiants de test par défaut :

avec la visualisation dans Weave Scope :

La suppression du cluster est tout aussi rapide :

Sur la base du dépôt github d’acs-engine je peux lancer des clusters de centaines noeuds de faible priorité beaucoup plus gros (1200 dans les templates proposés) :

et comme précédemment génération des templates ARM nécessaire :

et lancement dans Azure encore une fois :

avec un premier aperçu des caractéristiques du cluster créé :

J’en profite pour déployer par exemple un cluster Hadoop via les charts publics de Helm :

helm install --name hadoop $(stable/hadoop/tools/calc_resources.sh 70) \
--set persistence.nameNode.enabled=true \
--set persistence.nameNode.storageClass=standard \
--set persistence.dataNode.enabled=true \
--set persistence.dataNode.storageClass=standard \
stable/hadoop

avec un rapide test de bench :

et je peux lancer Weave Scope pour visualiser le tout :

Au final une opération qui aura un coût réduit par rapport à des noeuds traditionnels :

autrement dit pour 100 noeuds de ce gabarit, un coût de 2,6 euros pour une heure de calcul par exemple …

Je finis par le test rapide des Kata Containers qui ont fait l’actualité du dernier OpenStack Summit à Vancouver. En effet, Intel et Hyper.sh ont décidé de réunir leurs technologies de sécurisation de containers respectives au sein d’un unique projet Open Source et d’en confier la gouvernance à la Fondation OpenStack :

Kata Containers est un nouveau projet open source construisant des machines virtuelles extrêmement légères qui se connectent de manière transparente à l’écosystème des containers :

Clear Containers, né au sein du projet Clear Linux d’Intel, visent à proposer un modèle de VM ultra-légère dans laquelle s’insèrent un container ou un pod de containers. Créant ainsi un objet bien plus étanche et isolé, et donc sécurisé — la bête noire des containers. Intel s’appuie sur sa propre technologie VT pour sécuriser l’ensemble. De son côté, Hyper.sh a conçu une offre de containers sécurisés nommée HyperContainer qui reprend le même principe de containers encapsulés dans une VM minimaliste. Il se repose quant à lui sur un runtime qui exécute un hyperviseur — qui supporte donc la VM. Dans les 2 cas, le principe est de créer une VM de type caisson étanche en intégrant le stricte minimum en matière de ressources — un micro-kernel, un OS ultra-allégé et connecté — , nécessaires pour faire tourner un container. Intel et Hyper.sh « ont prouvé qu’on pouvait obtenir une rapidité et une densité comparable à des containers classiques, tout en ayant une isolation digne des VMs :

Je pars donc d’un type de VMs autorisant la virtualisation imbriquée et donc dans Kata Containers de QEMU Lite :

incluses dans Azure via certaines propriétés d’Hyper-V :

Création du scale set avec ces noeuds à faible priorité :

et j’installe le runtime Kata Containers dans les noeuds :

et j’adapte l’exécution des containers docker via ce nouveau runtime installé dans les paramètres :

et je peux vérifier que l’exécution d’un container se fait bien au travers d’une VM minimaliste avec son propre noyau différent du noyau du noeud hôte :

avec le test rapide de la création d’un cluster Swarm Mode :

et je déploie encore une fois une stack du démonstrateur FranceConnect Agent mais avec ici les Kata Containers :

que je peux scaler ensuite :

avec l’accès public via le port par défaut (TCP 8000) :

Un nouvel écosystème en évolution et surtout à suivre ! …

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store