Déploiement dans Azure de la distribution Kubernetes de Canonical (CDK) à l’aide de Juju, JAAS et Conjure-Up …
Ils existent de multiples façons d’installer et de gérer un cluster Kubernetes avec Ubuntu. Canonical, à l’origine d’Ubuntu Linux, fournit sa propre distribution Kubernetes afin de créer des déploiements sur de multiples clouds publics et privés, ainsi que sur des serveurs bare metal (avec en particulier une prise en charge des déploiements sur AWS, GCE, Azure, Joyent, OpenStack, VMware ou tout simplement en local notamment avec MicroK8S très récemment).
Canonical affirme que sa pile fonctionnera dans n’importe quel déploiement en nuage ou sur site, avec un support inclus pour les charges de travail alimentées par CPU et GPU. Les clients payant une souscription peuvent faire gérer leur cluster Kubernetes à distance par des ingénieurs de Canonical. Déploiement en exemple ici dans Azure. Pour cela je pars encore une fois d’une VM basse priorité sous Ubuntu 18.04 :
Et j’y installe Juju (en version edge) sur cette VM à l’aide de Snap. Pour rappel, Juju (anciennement Ensemble) est un gestionnaire de paquet pour le cloud computing et offre un service d’orchestration. Juju se concentre sur la notion de service, il abstrait la notion de machine ou de serveur et définit les relations entre les services qui se configurent automatiquement en fonction des liens créés. Juju permet de modéliser son architecture orientée services et de gérer le déploiement vers des clouds publics, OpenStack, du matériel local et des conteneurs. Ceci permet aux services d’agrandir ou de diminuer d’échelle à l’aide d’une seule commande :
sudo snap install juju --edge --classic
J’y installe également Conjure-Up qui va donc servir au déploiement de cette distribution Kubernetes de Canonical:
sudo snap install conjure-up --edge --classic
Et je configure mes identifiants avec Juju pour effectuer le déploiement dans le cloud Azure => https://docs.jujucharms.com/2.0/en/credentials
juju credentials
et je choisi aussi la région par défaut dans Azure pour ce déploiement :
juju set-default-region azure eastus
Conjure-Up offre une interface graphique conviviale pour faciliter l’installation de bundles avec Juju.
Application ici au choix de notre distribution :
conjure-up
avec des options supplémentaires comme l’installation de Helm voire de JFrog Artifactory ou KubeFlow :
et en selectionnant les identifiants créés précedemment :
Pour le contrôleur lié à Juju, je vais utiliser un service SaaS nommé JAAS ou Juju as a Service. En utilisant l’interface graphique, qui est installée avec chaque déploiement de Juju, on peut visualiser son modèle et configurer ses pièces. Pour gérer les déploiements, Juju nécessite un contrôleur, un nœud de gestion qui garde la trace de tous les composants du modèle déployé, gère la mise à l’échelle et toutes les autres fonctions de Juju. Lorsqu’on utilise la commande en ligne “juju bootstrap”, on créé simplement un contrôleur. Si on utilise un cloud public, ce contrôleur est une ressource que l’on doit utiliser comme toute autre machine. Un déploiement hautement disponible nécessitera donc plusieurs contrôleurs amorcés, de sorte que les dépenses pour ces nœuds seront triplées si l’on se retrouve avec trois contrôleurs HA.
Ce que JAAS introduit est un contrôleur en ligne pour passer l’étape de “juju bootstrap” et commencer simplement à l’étape suivante en utilisant juju add-model par exemple. JAAS va servir dans ce cas comme contrôleur du cluster créé via Conjure-Up :
avec flannel :
et “ce modèle” est initialisé via Juju :
On voit donc ce modèle en déploiement dans JAAS :
et dans le dashboard Azure on voit le resource group créé automatiquement avec les différents composants déployés :
Quand le déploiement est terminé on voit les adresses des différents services disponibles au sein de cette distribution Kubernetes de Canonical comprenant notamment Grafana et InfluxDB pour le monitoring …
ainsi que dans JAAS :
JAAS fournit également Juju Shell, un terminal en ligne pour exécuter ses lignes de commande avec Juju. On voit donc le statut en cours du cluster :
watch -c juju status --color
et les identifiants du cluster sont chargés dans notre VM basse priorité automatiquement avec Conjure-Up et le client kubectl pour effectuer des actions au sein de ce cluster Kubernetes :
Nginx a été installé lors du déploiement comme Ingress Controller. Je le teste via le package Microbot préconfigurée en action avec Juju :
juju expose kubernetes-worker
juju config kubernetes-worker ingress=true
juju run-action kubernetes-worker/0 microbot replicas=3
et un service en Wild Card DNS permet d’accéder à ce service Microbot sur la base de l’adresse IP d’un noeud Worker du cluster Kubernetes :
Je réalise également (comme maintenant une tradition) le test du déploiement du démonstrateur FranceConnect Agent avec cet Ingress Controller :
kubectl expose deployment fcagent --port=80 --target-port=8000 --name=fcagentservice2 --type=NodePort
kubectl apply -f ingress.yamlLe portail du démonstrateur apparait avec cette adresse en Wild Card DNS :
La suppression du cluster peut également être faite en un clic via JAAS …
Conjure-Up facilite donc le déploiement d’un cluster Kubernetes et permet de tester par exemple la fédération sur un serveur ou plusieurs clouds …
Et au travers par exemple de JAAS, ne va t’on pas s’initier à cette nouvelle démarche du DesOps ou Design-Operations (complémentaire du DevOps) amenée selon certains à se populariser à l’avenir au sein des entreprises ? Afin d’améliorer la collaboration et les pratiques entre les équipes inter-fonctionnelles, ce qui contribuerait à minimiser les éventuels gaspillages dans le processus de livraison d’un produit …
En tout cas, Microsoft a décidé de faire d’Ubuntu 18.04 un hôte de premier classe dans Azure et Hyper-V. Canonical profitant donc pour faire de sa distribution le pivot de cette tendance autour du “Cloud Native” =>
A suivre !
