REPUBLIQUE TUNISIENNE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA

RECHERCHE SCIENTIFIQUE

----------------------------------------------------

UNIVERSITE DE MONASTIR

INSTITUT SUPERIEUR D’INFORMATIQUE DE MAHDIA

Créer un cluster kubernetes multi-nœud avec Vagrant

et Ansible

Ines.Matmati
M2 EXPERT_RESEAUX
Dans ce rapport en va décrit les étapes requises pour configurer un cluster Kubernetes à nœuds
multiples à des fins de développement. Cette configuration fournit un cluster de type production
qui peut être configuré sur votre machine locale.

Introduction
Le déploiement de systèmes d'application complexes n'est pas un problème nouveau. Au cours des
dernières décennies, le besoin de configuration et de gestion automatisées, ou orchestration, des logiciels
a été identifié à plusieurs reprises. Dans l'espace des systèmes d'exploitation, des outils de gestion de la
configuration tels que Chef, Puppet, Salt et enfin Ansible orchestrent la configuration des applications
natives du système d'exploitation. Des outils comme AWS CloudFormation, OpenStack Heat et
Terraform, orchestrent le déploiement de ressources virtuelles d'infrastructure en tant que service (IaaS),
y compris des machines, des périphériques de stockage par blocs ou des réseaux définis par logiciel
(SDN). L'ordre dans lequel ces outils ont été créés illustre à quel point les solutions complexes et
orientées serveur se sont estompées, créant de l'espace pour des outils sans serveur spécialisés capables
d'exécuter un type de tâche particulièrement bien (et rapidement).

Pourquoi avons-nous besoin d'une configuration de cluster

multi-nœuds ?
Les clusters Kubernetes multi-nœuds offrent un environnement de type production qui présente
divers avantages. Même si Minikube fournit une excellente plate-forme pour démarrer, il ne
permet pas de travailler avec des clusters multi-nœuds qui peuvent aider à résoudre des
problèmes ou des bogues liés à la conception et à l'architecture des applications. Par exemple,
On peut reproduire un problème dans un environnement de cluster à plusieurs nœuds, les
testeurs peuvent déployer plusieurs versions d'une application pour exécuter des cas de test et
vérifier les modifications.

Ces avantages permettent aux équipes de résoudre les problèmes plus rapidement, ce qui les
rend plus agiles

Pourquoi utiliser Vagrant et Ansible ?

Vagrant est un outil qui va nous permettre de créer facilement un environnement virtuel et il
élimine les pièges qui provoquent le phénomène des travaux sur ma machine. Il peut être utilisé
avec plusieurs fournisseurs tels qu’Oracle VirtualBox, VMware, Docker, etc. Cela nous permet
de créer un environnement jetable en utilisant des fichiers de configuration.

p. 1
Ansible est un moteur d'automatisation d'infrastructure qui automatise la gestion de la
configuration logicielle. Il est sans agent et nous permet d'utiliser des clés SSH pour nous
connecter à des machines distantes. Les playbooks Ansible sont écrits en yaml et offrent une
gestion des stocks dans de simples fichiers texte.

Conditions préalables

 Vagrant doit être installé sur votre machine pour créer et provisionner nos
machines virtuelles à l'aide de l'hyperviseur VirtualBox

 Oracle VirtualBox peut être utilisé comme fournisseur Vagrant

 Ansible doit être installé sur votre machine qui sera utilisé pour installer et
configurer l'environnement Kubernetes

1. Structure et explication du projet

Arborescence

Voici à quoi ressemble l'arborescence du projet :

Figure 1 Arborescence du projet

p. 2
Nous avons trois rôles Ansible et un Vagrantfile dans notre projet qui mène à la création d'un
cluster kubernetes multi-nœud solide

A.Création d'un fichier Vagrant

C'est à partir du fichier Vagrantfile que toute la procédure débute. Ce fichier décrit comment nos
nouvelles machines seront configurées et provisionnées

La Vagrantfile de notre projet ressemble à ceci :

Figure 2 Vagrantfile

p. 3
Vous pouvez personnaliser votre cluster Kubernetes depuis le fichier Vagrantfile à partir des
variables de configuration, par exemple vous pouvez agrandir le nombre de nœuds en changeant
la variable WORKER_NBR, voire attribuer davantage de ressources à vos nœuds en revalorisant
les variables CPU et/ou RAM, etc.

Cependant, si on exécute le contenu actuel de notre Vagrantfile, nous obtiendrons la configuration

suivante sur nos VMs :

 Création de deux nœuds (1 Master et 1 Worker) tournant sous la distribution Ubuntu en

version 16.04 LTE avec 2 CPU et 2048 en RAM pour chaque nœud.
 Création d'un réseau VirtualBox HOST ONLY, utilisé pour accéder au master et worker
Kubernetes depuis notre machine hôte, avec notamment :
o Le master nommé master et possédant l’IP 192.168.50.10
o Le worker nommé worker-1 et possédant l’IP 192.168.50.11
 Les connexions internes entre les PODs Kubernetes se passeront depuis un réseau privé
sur la plage IP 192.168.100.0/16. Ces adresses IPs ne seront pas accessibles de l'extérieur
du cluster Kubernetes et changeront lorsque les PODs seront détruits et créés.
 Les logiciels indispensables pour le cluster Kubernetes seront installés et façonnés par le
playbook Ansible main.yml

B. Les rôles Ansible

Nous avons alors en notre disposition trois rôles Ansible, dont :

 Roles/common : installe et configure-les packages communs pour le maître et les workers

qui sont nécessaires pour le bon fonctionnement du cluster Kubernetes.
 Roles/master : spécifie la configuration spéciale au maître Kubernetes.
 Roles/node : spécifie la configuration spéciale aux workers Kubernetes.

Comme vu précédemment, le Vagrantfile fait appel au playbook main.yml, voici son contenu

p. 4
 Figure 3 main.yml

Ainsi, soit la machine est de type master, dans ce cas on lance le rôle roles/master, dans le cas
contraire on lance le rôle roles/worker.

Ces deux rôles inclus tous les deux dans leur dossier, plutôt dans les fichiers

 roles/worker/meta/main.yml
 roles/master/meta/main.yml

Le rôle roles/commun en tant que dépendance.

Figure 4 dépendances

Nous avons vu le rôle de ansible de notre projet on va passer maintenant au rôle du commun qui relier
avec les nœuds et le master

C. Le rôle commun
Au sein du rôle roles/commun, plus précisément dans le fichier roles/common/defaults/main.yml, on
peut retrouver les multiples clés gpg, dépôts et paquets qui seront ajoutés et installés sur les nœuds du
cluster, soit :

p. 5
 Figure 5 rôles/common

Dans ce fichier de configuration en trouve les package de k8s qui sont

Kubectl : permet d'exécuter des commandes sur les clusters Kubernetes afin de créer et gérer des objets
k8s et interagir avec l'API Kubernetes

Kubadm : nous permettre tout simplement d'initialiser notre cluster Kubernetes et de joindre des machines
à notre cluster k8s

Kubelet : Il s’agit d’un agent qui s'exécute dans chaque nœud chargé de relayer les informations au Master.
Il interagit avec la base de données etcd du Master pour récupérer des informations afin de connaître les
tâches à effectuer.

Nous avons vu le rôle de common de notre projet on va passer maintenant au rôle du master

D.Le rôle master

À ce stade, nous avons fini les étapes universelles des nœuds. Se suivent alors les tâches
spécifiques à chaque type de nœud.

Pour le master, les tâches sont définies dans le fichier roles/master/tasks/main.yml

p. 6
 Figure 6 main.yml du master

La première tâche exécutée kubeadm init, initialise le nœud maître Kubernetes ou il est spécifié
en tant que paramètres, l'IP du serveur API, le nom du cluster, et la plage IP des pods.

Une fois le nœud master initialisé, l'étape suivante consiste à gérer la partie réseau du cluster de
manière à connecter les divers modules sur les différents nœuds du cluster. Pour cela, nous devons
inclure un plugin CNI1 .L'objectif de ce projet est de créer une norme conçue pour faciliter la
configuration réseau des conteneurs que ça soit pendant leurs créations ou lors de leurs
destructions, le tout basée sur un plugin.

Ces plugins permettent de s'assurer que les exigences réseau de Kubernetes sont satisfaites et
fournissent les fonctionnalités réseau requises pour assurer le bon fonctionnement du cluster.
Différents plugins existent dont le plugin flannel, qui est celui utilisé dans notre rôle.

L'étape finale réside sur la génération d'un token, qui sera utilisé plus tard par les workers afin de
les autoriser à rejoindre le cluster. Ce token est par la suite copié dans un fichier qui est ensuite
transféré sur notre machine locale dans le but d'être utilisé dans la suite par le rôle roles/workers.

1
CNI signifie "Container Networking Interface" c'est un projet de la CNCF (Cloud Native Computing Foundation),
qui est une organisation qui gère également le projet Kubernetes.

p. 7
 E.Le rôle worker
Les tâches dans le rôle du worker n'ont rien de compliqué, et sont disponibles dans le
fichier roles/worker/tasks/main.yml

Figure 7 Worker/tasks

Ici, il ne fait que récupérer et exécuter le fichier généré par le master contenant le token permettant
de rejoindre notre cluster kubernetes.

2. Lancement du projet pour créer le cluster Kubernetes

Avant d'effectuer l'exécution du projet, il faut au préalable installer Vagrant et Ansible

A.Installation de Vagrant
Pour installer vagrant téléchargez-le package correspondant à notre système d'exploitation et à
notre architecture. Dans notre cas, ma machine est sous la distribution Ubuntu

Figure 8 Installation de vagrant

B. Installation d'Ansible
Configurer le PPA sur votre machine et installer Ansible, exécutez ces commandes :

p. 8
 Figure 9 Installation Ansible

C.Exécution du projet
Une fois tous les prérequis satisfaits, on peut dorénavant commencer par lancer notre projet.
Placez-vous d'abord dans la racine du projet au même niveau que le fichier Vagrantfile et lancez
ensuite la commande suivante :

Une fois que Playbook et Vagrantfile sont prêts, exécutez la commande vagrant up pour
démarrer la machine virtuelle.

p. 9
Figure 10 start Vagrant

p. 10
 Figure 11 VirtualBox

Une fois toutes les étapes ci-dessus terminées notre nœuds, master sont bien installer dans
VirtualBox, le cluster Kubernetes doit être opérationnel. Nous pouvons nous connecter aux
nœuds maître ou worker en utilisant Vagrant comme suit :

Figure 12 connecter sur master

p. 11
On va récupérer le dossier .kube de votre master, en le positionnant dans votre dossier utilisateur,
comme suit

Figure 13 déplacer fichier de configuration. kube

Dès à présent votre kubectl est configuré pour communiquer à votre API k8s, récupérerons alors
la liste des nœuds disponibles dans notre cluster :

Figure 14 Afficher le master et worker

Figure 15 affichage des nodes

Arrêtez la machine maintenant.

Figure 16 exit les nodes et stopper le vagrant

Conclusion
Les applications multi-cluster réduiront la charge de travail des équipes d'exploitation et
permettront de déployer et de mettre à niveau les applications rapidement et de manière fiable
sur tous les clusters.

p. 12
p. 13