Créer rapidement un cluster Kubernetes avec Kontena Pharos ou MicroK8S dans Azure à l’aide de machines virtuelles basse priorité dans des groupes identiques (VMSS) …

Image for post
Image for post

Microsoft a mis en place le principe des VMs éphémères que l’on peut retrouver dans Google Cloud Preemptible VM ou AWS Spot Instances dans son dispositif de création de clusters de VMs identiques (VMSS). C’est encore officiellement en preview => https://docs.microsoft.com/fr-fr/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-use-low-priority

L’avantage avec ce type de VMs (que l’on retrouvait dans Azure Batch Service) c’est que l’on arrive à une réduction de 80% environ du tarif normal de celles-çi => https://docs.microsoft.com/fr-fr/azure/batch/batch-low-pri-vms

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

Ici je pars de la création de ce type de cluster à partir des lignes de commandes fournies avec Azure CLI :

Let’s start…

az login
az group create -l eastus -n <rgname>
az vmss create \
--resource-group <rgname> \
--name <name> \
--image UbuntuLTS \
--upgrade-policy-mode automatic \
--admin-username <myuser> \
--admin-password <mysecurepassword> \
--instance-count 3 \
--eviction-policy Delete \
--vm-sku Standard_D11_v2
--priority Low

Le cluster est à présent visualisable dans le dashboard Azure :

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

Je me connecte via un des ports définis par le load balancer attaché au cluster à l’un des noeuds :

Image for post
Image for post

et je copie en avance de phase ma clé publique sur chacun des autres noeuds :

Image for post
Image for post

Je vais utiliser le binaire Kontena Pharos pour la création d’un cluster Kubernetes très facilement :

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

J’édite un fichier de configuration cluster.yml qui va servir à la construction du cluster via Kontena Pharos :

hosts:
- address: "10.0.0.6"
user: <myuser>
role: master
- address: "10.0.0.8"
user: <myuser>
role: worker
- address: "10.0.0.9"
user: <myuser>
role: worker
network:
provider: weave
addons:
ingress-nginx:
enabled: true
kubernetes-dashboard:
enabled: true
host-upgrades:
enabled: true
interval: "7d"
kured:
enabled: true
Image for post
Image for post

Et je lance la création du cluster Kubernetes :

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

Le cluster est actif et je peux en vérifier sa composition :

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

avec le dashboard Kubernetes intégré :

Image for post
Image for post

Et je lance alors deux séries de pod avec des containers du démonstrateur FranceConnect Particulier et Agent :

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

et à partir des ports exposés dans le cluster, je règle la configuration du load balancer rattaché à ce dernier :

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

et les portails d’accès apparaissent publiquement :

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

Et Weavescope permet la visualisation de la topologie induite par ces pools de containers :

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

Autre test avec MicroK8S, alternative à Minikube toujours en utilisant ces VMs basse priorité :

Image for post
Image for post

que l’on retrouve sur Github en conjonction d’un simple script d’installation :

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

Démarrage avec un nouveau scale set dans Azure :

Image for post
Image for post

Je récupère le script d’installation de MicroK8s depuis le dépôt :

Image for post
Image for post

avec une modification de ce dernier :

Image for post
Image for post

et son exécution très simple et rapide :

Image for post
Image for post

Là encore je vérifie la composition de ce monocluster :

Image for post
Image for post

et on voit bien la partition Snap dédiée à l’installation de ce cluster :

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

avec son dashboard :

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

Je peux faire le test d’Argo pour créer ses workflows notamment de CI/CD dans Kubernetes :

Image for post
Image for post

On peut en effet arriver à ce type de scénario avec ce moteur de workflow :

Image for post
Image for post

Installation d’Argo :

Image for post
Image for post

et je peux utiliser un package npm nommé reverse-proxy dans mon noeud pour visualiser le dashboard de contrôle d’Argo :

Image for post
Image for post

Test rapide d’un workflow de CI/CD de test en exemple :

Image for post
Image for post

qui apparait dans le dashboard :

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

Je termine par le projet Multipass, autre projet de Canonical destiné à simplifier au maximum la création de VM (un peu comme s’il s’agiisait de simples containers) :

Image for post
Image for post

L’installation de multipass se fait simplement par snap :

Image for post
Image for post

et je lance en une seule ligne un groupe de VMs :

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

Le tout n’est pas très consommateur :

Image for post
Image for post

et je peux lancer un cluster Mesos avec Marathon via Rancher dans ce pool de VMs :

Image for post
Image for post

avec encore une fois Traefik :

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

Un moyen simple d’utiliser ce type de VM beaucoup moins chères et de réduire considérablement sa facture …

A suivre !

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

Get the Medium app