Déploiement dans Azure de la distribution Kubernetes de Canonical (CDK) à l’aide de Juju, JAAS et Conjure-Up …

Image for post
Image for post

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).

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

J’y installe également Conjure-Up qui va donc servir au déploiement de cette distribution Kubernetes de Canonical:

Image for post
Image for post

Et je configure mes identifiants avec Juju pour effectuer le déploiement dans le cloud Azure => https://docs.jujucharms.com/2.0/en/credentials

Image for post
Image for post

et je choisi aussi la région par défaut dans Azure pour ce déploiement :

Image for post
Image for post

Conjure-Up offre une interface graphique conviviale pour faciliter l’installation de bundles avec Juju.

Image for post
Image for post

Application ici au choix de notre distribution :

Image for post
Image for post

avec des options supplémentaires comme l’installation de Helm voire de JFrog Artifactory ou KubeFlow :

Image for post
Image for post

et en selectionnant les identifiants créés précedemment :

Image for post
Image for post

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.

Image for post
Image for post

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 :

Image for post
Image for post

avec flannel :

Image for post
Image for post

et “ce modèle” est initialisé via Juju :

Image for post
Image for post
Image for post
Image for post

On voit donc ce modèle en déploiement dans JAAS :

Image for post
Image for post

et dans le dashboard Azure on voit le resource group créé automatiquement avec les différents composants déployés :

Image for post
Image for post

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 …

Image for post
Image for post

ainsi que dans JAAS :

Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

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 :

Image for post
Image for post

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 :

Image for post
Image for post

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 :

Image for post
Image for post

Je réalise également (comme maintenant une tradition) le test du déploiement du démonstrateur FranceConnect Agent avec cet Ingress Controller :

Image for post
Image for post
Image for post
Image for post

Le portail du démonstrateur apparait avec cette adresse en Wild Card DNS :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

La suppression du cluster peut également être faite en un clic via JAAS …

Image for post
Image for post

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 …

Image for post
Image for post

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 …

Image for post
Image for post
Image for post
Image for post

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” =>

Image for post
Image for post
Image for post
Image for post

A suivre !

Image for post
Image for post

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