DEDICATION

EPI SUP Page i

 REMERCIEMENT

EPI SUP Page ii

 TABLE DES MATIÈRES

LISTE DES FIGURES v

LISTE DES ABRÉVIATIONS vi

INTRODUCTION GÉNÉRALE 1

1 CONTEXTE GÈNÈRAL 2
1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Etude Prealeable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Analyse de l’existant : Docker Swarm . . . . . . . . . . . . . . . . . . 3
1.2.2 Critique de l’existant : les lacunes de Docker Swarm . . . . . . . . . . 4
1.2.3 Solution proposée : les outils d’orchestrateurs . . . . . . . . . . . . . . 5
1.2.3.1 Choix d’une plateforme d’orchestration . . . . . . . . . . . . 5
1.2.3.2 Comparaison des fonctionnalités des Orchestrateurs de Conteneurs 8
1.3 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 NOTIONS DE BASE 10
2.1 Vision du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Conception de l’architecture du cluster Kubernetes . . . . . . . . . . . . . . . 12
2.4.1 Mise en place du cluster Kubernetes . . . . . . . . . . . . . . . . . . . 13
2.4.2 Objets de Cluster Kuberenetes . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Le rôle du maître (Master) dans le cluster . . . . . . . . . . . . . . . . 14
2.4.4 Les nœuds (Nodes) et leur fonction . . . . . . . . . . . . . . . . . . . 15
2.4.5 Les services et leur gestion du trafic réseau . . . . . . . . . . . . . . . 16
2.4.6 Les volumes persistants et le stockage des données . . . . . . . . . . . 16
2.4.7 Les outils de monitoring et de gestion du cluster . . . . . . . . . . . . 17
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

EPI SUP Page iii

TABLE DES MATIÈRES

3 RÉALISATION 19
3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Environnements et outils de développement . . . . . . . . . . . . . . . . . . . 20
3.2.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Intégration de l’application . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Réalisation en Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Réalisation dans le Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

CONCLUSION GÉNÉRALE 35

BIBLIOGRAPHIE 35

ANNEXES 37
Présentation de l’organisme d’accueil EPI Group . . . . . . . . . . . . . . . . 37

EPI SUP Page iv

 LISTE DES FIGURES

1.1 logo docker swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 logo Mesos apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 logo kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Capture d’écran du terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Capture d’écran du terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Capture d’écran du terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Capture d’écran du terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 tableau de bord Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Création d’un nouveau pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 31
3.10 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 32
3.11 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 32
3.12 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 33
3.13 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 34
3.14 Logo de l’EPI Educationnel Group . . . . . . . . . . . . . . . . . . . . . . . . 34

EPI SUP Page v

 LISTE DES ABRÉVIATIONS

k8S Kubernetes

Azure AKS Microsoft Azure Kubernetes Service

EPI SUP Page vi

 INTRODUCTION GÉNÉRALE

Dans l’ère numérique actuelle, le Cloud et le Réseau sont devenus des éléments essentiels
de l’environnement technologique des organisations. Le Cloud, avec ses capacités de stockage,
de calcul et de services à la demande, a révolutionné la façon dont les entreprises gèrent
leurs données et leurs applications. De même, le Réseau, qui interconnecte ces infrastructures
cloud, permet une circulation fluide et sécurisée de l’information, offrant ainsi une plus grande
agilité et flexibilité aux utilisateurs. Cette évolution rapide des technologies du Cloud et du
Réseau a profondément transformé les modèles d’affaires, les processus de collaboration et les
expériences des utilisateurs finaux.

Dans ce contexte, la mise en place d’un cluster hautement performant, fiable et évolutif
devient un impératif pour les organisations souhaitant rester compétitives et s’adapter aux changements
constants de l’environnement numérique. Ce cluster permettra de tirer pleinement parti des
avantages du Cloud et du Réseau, en offrant une infrastructure solide, sécurisée et évolutive
pour héberger les applications et les données critiques de l’organisation.

Ce projet s’inscrit dans une volonté d’optimiser les ressources informatiques, de gagner en
flexibilité et en évolutivité, tout en offrant une meilleure résilience et une plus grande sécurité
des données.

Ce rapport présente la mise en place d’un cluster et la migration d’applications déployées

en mode Swarm vers d’autres orchestrateurs.

EPI SUP Page 1

Chapitre

1
CONTEXTE GÈNÈRAL

Sommaire
1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Etude Prealeable . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Analyse de l’existant : Docker Swarm . . . . . . . . . . . . . . . 3
1.2.2 Critique de l’existant : les lacunes de Docker Swarm . . . . . . 4
1.2.3 Solution proposée : les outils d’orchestrateurs . . . . . . . . . . 5
1.3 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

EPI SUP Page 2

CONTEXTE GÈNÈRAL

1.1 INTRODUCTION

Le choix d’une technologie adaptée pour la mise en place d’une outil d’orchestration des
conteneurs est une étape cruciale. De nombreuses solutions existent, chacune avec ses avantages
et ses inconvénients, et il est essentiel de bien définir les besoins afin de sélectionner la meilleure
option. Dans ce chapitre, nous nous intéresserons à une étude approfondie sur les plateformes
d’orchestration qui jouent un rôle crucial dans la gestion des applications conteneurisées.

1.2 Etude Prealeable

Avant de plonger dans la mise en place d’un cluster et le déploiement des applications en
mode Swarm, il est essentiel de mener une étude préalable approfondie. Cette analyse permettra
de comprendre le contexte actuel, d’identifier les forces et faiblesses du système existant, et de
proposer une solution optimale répondant aux besoins spécifiques de l’organisation.

1.2.1 Analyse de l’existant : Docker Swarm

Docker Swarm est une solution d’orchestration de conteneurs développée par Docker Inc.
pour permettre la gestion de clusters de conteneurs à grande échelle. C’est une technologie
native de Docker qui s’intègre parfaitement dans l’écosystème Docker et offre une alternative
intéressante aux outils tiers comme Kubernetes. Docker Swarm se caractérise par sa simplicité
de mise en place et son intégration native avec l’ensemble des outils Docker, ce qui en fait une
solution de choix pour les équipes familières avec l’univers Docker.[1]

L’illustration ci-dessous (Figure 1.1) présente le logo de Docker Swarm, symbolisant la

puissance et la cohésion de cet outil dans l’écosystème des conteneurs."

EPI SUP Page 3

CONTEXTE GÈNÈRAL

F IGURE 1.1 – logo docker swarm

Cependant, bien que Docker Swarm soit une solution puissante et performante, elle présente
certaines limites qui peuvent devenir problématiques pour des déploiements complexes ou à très
grande échelle. Par exemple, la gestion de la haute disponibilité et de la tolérance aux pannes
peut s’avérer plus complexe sur Docker Swarm que sur d’autres solutions d’orchestration plus
matures. De plus, l’écosystème d’outils et d’extensions autour de Docker Swarm est moins riche
, ce qui peut limiter les possibilités d’intégration et d’automatisation avancées.

1.2.2 Critique de l’existant : les lacunes de Docker Swarm

Bien que Docker Swarm soit une solution puissante et largement adoptée pour l’orchestration
de conteneurs, elle présente certaines lacunes qui peuvent devenir problématiques dans des
environnements de production complexes. Tout d’abord, la gestion de la haute disponibilité
et de la tolérance aux pannes peut s’avérer plus complexe sur Docker Swarm que sur d’autres
solutions d’orchestration plus matures . En effet, la mise en place de mécanismes de redondance
et de basculement automatique nécessite des configurations plus avancées sur Docker Swarm,
ce qui peut s’avérer délicat pour les équipes moins expérimentées.

De plus, l’écosystème d’outils et d’extensions autour de Docker Swarm est moins riche ,
limitant ainsi les possibilités d’intégration et d’automatisation avancées. Par exemple, la gestion
des déploiements, des mises à jour, de la surveillance et de l’évolutivité peut s’avérer plus
complexe sur Docker Swarm, nécessitant le développement de scripts et d’outils sur mesure.

Enfin, la prise en charge des fonctionnalités avancées telles que la gestion du stockage
persistent, le déploiement de workloads stateful ou encore la gestion des secrets peut être plus

EPI SUP Page 4

CONTEXTE GÈNÈRAL

limitée sur Docker Swarm, ce qui peut s’avérer problématique pour des applications complexes
ou à forte criticité. Ces limitations peuvent obliger les équipes à développer des solutions ad
hoc, augmentant ainsi la complexité de l’architecture et les coûts de maintenance.

1.2.3 Solution proposée : les outils d’orchestrateurs

Face aux lacunes identifiées dans l’utilisation de Docker Swarm, la solution proposée consiste
à se tourner vers des outils d’orchestration de conteneurs plus avancés et performants. Ces
outils, appelés orchestrateurs, offrent des fonctionnalités étendues pour la gestion de clusters de
conteneurs à grande échelle, avec une attention particulière portée à la haute disponibilité, la
tolérance aux pannes et l’automatisation des déploiements.

Plusieurs outils d’orchestration de conteneurs ont émergé ces dernières années, les plus
populaires sont Apache Mesos et Kubernetes. Chacun de ces outils possède ses propres caractéristiques,
fonctionnalités et écosystèmes, offrant ainsi une certaine flexibilité dans le choix de la solution
qui répondra le mieux aux besoins spécifiques en matière de gestion des applications conteneurisées.

1.2.3.1 Choix d’une plateforme d’orchestration

Dans cette section, nous explorerons en détail les caractéristiques de chaque outil d’orchestration,
mettant en lumière à la fois leurs points forts et leurs points faibles

Apache Mesos est un système d’exploitation distribué pour le cloud computing. Il permet
de gérer des clusters de serveurs et d’exécuter des applications de manière distribuée et tolérante
aux pannes. Mesos abstrait les ressources du cluster (CPU, mémoire, stockage, etc.) et les met à
disposition des applications de manière transparente.L’image ci-dessous (Figure 1.2) représente
le logo d’Apache Mesos, symbolisant son rôle essentiel dans la gestion efficace des ressources
et des applications dans les environnements distribués[2]

EPI SUP Page 5

CONTEXTE GÈNÈRAL

F IGURE 1.2 – logo Mesos apache

Mesos Apache : points forts

— Flexibilité et adaptabilité : Mesos Apache permet de déployer et de gérer une grande

variété d’applications, des services web aux tâches par lots, en passant par les bases de
données et les systèmes de streaming.

— Haute disponibilité et tolérance aux pannes : Grâce à son architecture distribuée et tolérante
aux pannes, le système continue de fonctionner même en cas de défaillance d’un nœud. .

— Écosystème riche et évolutif : De nombreuses bibliothèques, frameworks et outils ont été

développés pour faciliter le déploiement et la gestion des applications sur cette plateforme.[2]

Mesos Apache : points faible

— Manque d’intégration native avec les outils populaires : Mesos n’a pas d’intégration
native avec des outils comme Docker, Prometheus ou Istio. Cela peut compliquer l’intégration
avec l’écosystème existant et nécessiter plus d’efforts personnalisés.

— Moins de documentation et de support communautaire : moins de documentation, de

tutoriels et de ressources de dépannage disponibles, ce qui peut rendre plus difficile la
résolution des problèmes pour les utilisateurs .[2]

Kubernetes est un orchestrateur développé originellement par Google et basé sur une dizaine
d’années d’expérience de déploiement d’application énormes.

La première version est sortie en 2014 et K8S est devenu depuis l’un des projets open source
les plus populaires du monde.Il s’agit d’une solution robuste, structurante et open source qui se
construit autour des objectifs de :

EPI SUP Page 6

CONTEXTE GÈNÈRAL

— Rapidité.

— Scaling des logiciels et des équipes de développement.

— Abstraction et uniformisation des infrastructures.[3]

L’illustration ci-dessous (Figure 1.3) présente le logo de Kubernetes, symbole de sa popularité

croissante et de son rôle central dans l’écosystème des conteneurs.

F IGURE 1.3 – logo kubernetes

Kubernetes : points forts

— Scalabilité élastique : Grâce à son système de réplication et de mise à l’échelle automatique,

Kubernetes peut facilement ajuster le nombre de répliques d’un conteneur en fonction de
la charge de travail..

— Gestion de la haute disponibilité : En cas de défaillance d’un conteneur ou d’un nœud,

Kubernetes peut automatiquement redémarrer les instances défaillantes, garantissant ainsi
la continuité du service.

— Portabilité et interopérabilité : Kubernetes est une solution open source et portable, ce qui
permet de déployer des applications sur différentes plateformes cloud ou on-premise, tout
en conservant les mêmes outils et processus de gestion.[3]

Kubernetes : points faibles

— Manque de standardisation : Kubernetes étant un projet open source, il existe de nombreuses

distributions et intégrations différentes, ce qui peut entraîner un manque de standardisation.
Cela peut rendre la migration entre les fournisseurs de cloud et les déploiements sur site
plus difficile et nécessite des efforts d’intégration supplémentaires

EPI SUP Page 7

CONTEXTE GÈNÈRAL

— Surcharge de sécurité : Kubernetes apporte de nombreuses fonctionnalités de sécurité

intégrées, mais leur configuration et leur maintenance peuvent être complexes. Cela peut
représenter une surcharge importante pour les équipes IT.[3]

1.2.3.2 Comparaison des fonctionnalités des Orchestrateurs de Conteneurs

Cette analyse nous permettra d’établir un tableau comparatif pour visualiser de manière
concise les caractéristiques clés de chaque orchestrateur, facilitant ainsi une évaluation comparative
claire. Le tableau 1.1 ci-dessous présente cette comparaison.

Parametres Docker Swarm Apache Mesos kubernetes

Vitesse de Se basant sur des peut varier en Kubernetes a besoin
déploiement critères qui netiennent fonction de plusieurs de connaître à l’avance
pas compte de l’état facteurs, notamment l’état du cluster, ce qui
réel du cluster, la configuration du ralentit le déploiement
Swarm est capable cluster, la charge des pods ralentit le d
de déployer rapidement de travail et les
des conteneurs exigences spécifiques
de l’application.
Modularité Swarm utilise l’API Conçu avec une Kubernetes est
Docker deamon pour architecture modulaire modulaire. Il offre
gérer tout le cluster depuis le début, d’un ensemble unifié
permettant une gestion d’APIs qui collaborent
fine des ressources pour gérer le cluster
et une intégration
transparente avec
divers frameworks.
Mise en ouevre Offrant une solution La mise en place peut Offre une solution
d’orchestration de être plus complexe en d’orchestration de
conteneurs simple à raison de la flexibilité conteneurs robuste
configurer et à gérer offerte et de la nécessité et évolutive, bien
pour les déploiements de comprendre les que nécessitant une
d’applications concepts avancés de configuration initiale
distribuées Mesos. plus complexe.
Surveillance Pas de garanties solides Dispose de son Grâce à son ensemble
sur l’état du cluster propre système de unifié d’API s, le noeud
surveillance appelé maître connaît en temps
Mesos Monitoring réel l’état global du
Stack, cluster

Après avoir examiné cette comparaison on constate que :

EPI SUP Page 8

CONTEXTE GÈNÈRAL

Tolérance aux Faible tolérance aux Dispose de mécanismes Kubernetes est tolérant
fautes (pannes) pannes de détection et de aux pannes franches
gestion des pannes comme l’arrêt d’un
intégrés pour assurer nœud de travail, d’un
une reprise rapide en pod ou d’un conteneur
cas de défaillance..

TABLE 1.1 – Différences fondamentales entre Docker Swarm, Apache Meses et Kubernetes.

La principale différence entre Docker Swarm ,Kubernetes et Mesos Apache réside dans
leur philosophie de conception. Kubernetes adopte une approche plus modulaire et évolutive,
avec une architecture distribuée et une API riche, offrant une haute disponibilité, une sécurité
avancée et une gestion des ressources supérieure. Docker Swarm se veut plus simple et plus
intégré à l’écosystème Docker, tandis que Mesos Apache offre une gestion de cluster flexible et
évolutive, avec une modularité dès sa conception.

Chacune des technologies d’orchestration de conteneurs étudiées présente des forces et

des faiblesses distinctes. Kubernetes se distingue par sa flexibilité, son évolutivité et sa large
communauté de développeurs. Cependant, sa complexité peut représenter un défi pour les utilisateurs
moins expérimentées. Mesos Apache offre une grande puissance de calcul et une gestion avancée
des ressources, mais peut être plus difficile à mettre en place et à maintenir. Docker Swarm se
caractérise par sa simplicité d’utilisation et son intégration étroite avec l’écosystème Docker,
mais peut être moins performant à grande échelle.

Tous ces avantages font de Kubernetes un choix plus préférable par rapport à Swarm.

1.3 CONCLUSION

À l’issue de cette exploration des principales plateformes d’orchestration de conteneurs, il

est clair que Kubernetes s’est imposé comme le leader incontesté du marché. Avec son adoption
massive par son écosystème riche et en constante évolution, et ses capacités de gestion avancées,
Kubernetes s’affirme comme la solution de référence pour l’orchestration des conteneurs. Néanmoins,
Docker Swarm reste une alternative intéressante, notamment pour les déploiements les plus
simples ou les projets de taille plus modeste.

EPI SUP Page 9

Chapitre

2
NOTIONS DE BASE

Sommaire
2.1 Vision du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . 12
2.4 Conception de l’architecture du cluster Kubernetes . . . . . . 12
2.4.1 Mise en place du cluster Kubernetes . . . . . . . . . . . . . . . 13
2.4.2 Objets de Cluster Kuberenetes . . . . . . . . . . . . . . . . . . 13
2.4.3 Le rôle du maître (Master) dans le cluster . . . . . . . . . . . . 14
2.4.4 Les nœuds (Nodes) et leur fonction . . . . . . . . . . . . . . . . 15
2.4.5 Les services et leur gestion du trafic réseau . . . . . . . . . . . 16
2.4.6 Les volumes persistants et le stockage des données . . . . . . . 16
2.4.7 Les outils de monitoring et de gestion du cluster . . . . . . . . 17
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

EPI SUP Page 10

NOTIONS DE BASE

2.1 Vision du projet

Le projet vise à mettre en place un cluster performant et évolutif pour héberger les applications,
actuellement déployées en mode Swarm. L’objectif est de profiter des avantages de Kubernetes
en termes de scalabilité, de gestion des charges de travail et de haute disponibilité, afin d’améliorer
la fiabilité et les performances des applications critiques de l’entreprise. La migration vers
Kubernetes permettra également de standardiser les processus de déploiement et de gestion
des applications, facilitant ainsi la maintenance et l’évolutivité du système.

2.2 Exigences fonctionnelles

Les exigences fonctionnelles de ce projet sont conçues pour assurer une transition harmonieuse
du déploiement des applications vers l’architecture choisi Kubernetes. Parmi les principales
exigences, on peut citer :

— La capacité de déployer et de gérer l’ensemble des applications de manière transparente

et sans interruption de service.

— L’intégration des services essentiels tels que la gestion des bases de données, les systèmes
de messagerie, les outils de surveillance.

— La possibilité de mettre à l’échelle les ressources de calcul et de stockage de manière

dynamique en fonction des besoins de charge de travail.

— L’implémentation de mécanismes de haute disponibilité et de tolérance aux pannes pour

assurer la fiabilité et la résilience de l’infrastructure.

— La gestion centralisée et la visibilité des logs, des métriques et des événements pour
faciliter le monitoring et le diagnostic des applications.

Ces exigences fonctionnelles visent à garantir une transition en douceur vers Kubernetes,
tout en conservant les performances et la fiabilité de l’infrastructure existante.

EPI SUP Page 11

NOTIONS DE BASE

2.3 Exigences non fonctionnelles

Outre les exigences fonctionnelles du projet de migration vers Kubernetes, il est également
essentiel de prendre en compte les exigences non fonctionnelles. Celles-ci définissent les critères
de qualité et les performances attendues du nouveau système, ainsi que les contraintes techniques
et organisationnelles à respecter.

— Disponibilité et fiabilité : Le nouveau cluster Kubernetes devra garantir une disponibilité

élevée des applications, avec un temps de fonctionnement maximal et une tolérance aux
pannes. Des mécanismes de haute disponibilité et de reprise après incident devront être
mis en place.

— Évolutivité et extensibilité : Le système devra pouvoir s’adapter à l’augmentation future

des charges de travail et du nombre d’utilisateurs, en permettant une montée en charge
aisée et sans interruption de service.

— Sécurité et conformité : Le cluster Kubernetes devra répondre aux exigences de sécurité

de l’entreprise, en assurant une protection adéquate des données, des accès et des ressources.
Les normes et réglementations en vigueur devront également être respectées.

— Performances et optimisation : Les applications migrées vers Kubernetes devront offrir

des performances optimales, avec des temps de réponse rapides et une utilisation efficace
des ressources.

— La prise en compte de ces exigences non fonctionnelles permettra de s’assurer que le

nouveau système Kubernetes répondra aux attentes de les utilisateurs en termes de fiabilité,
de scalabilité, de sécurité et de facilité d’utilisation.

2.4 Conception de l’architecture du cluster Kubernetes

Dans cette section, nous explorerons en détail les différentes composantes nécessaires à la
conception et à la mise en œuvre d’un tel cluster. De la configuration initiale du cluster à la
gestion des objets, en passant par le rôle crucial des maîtres et des nœuds, nous examinerons

EPI SUP Page 12

NOTIONS DE BASE

également les aspects liés à la gestion du trafic réseau, au stockage des données, ainsi qu’aux
outils de surveillance et de gestion du cluster.

2.4.1 Mise en place du cluster Kubernetes

La première étape dans la mise en place du cluster Kubernetes consiste à définir précisément
les besoins de en termes de charges de travail, de disponibilité, de scalabilité et de sécurité. Une
fois les besoins identifiés, il est nécessaire de concevoir l’architecture du cluster Kubernetes
qui répondra à ces exigences. Cette étape implique de choisir le nombre de nœuds maîtres et
d’agents, le type d’instance à utiliser, la configuration des volumes persistants.

— Déploiement du cluster Kubernetes : Une fois l’architecture définie, le déploiement du

cluster Kubernetes peut commencer. Cette phase implique l’installation et la configuration
des différents composants Kubernetes, tels que l’API server, le scheduler, le contrôleur
de nœuds, etc. Selon la taille et la complexité du cluster, cette étape peut nécessiter des
ressources et des compétences techniques importantes. Il est important de veiller à la
bonne configuration du cluster afin d’assurer sa fiabilité et sa haute disponibilité.

— Intégration et tests : Après le déploiement du cluster, une phase d’intégration et de

tests est cruciale pour s’assurer du bon fonctionnement de l’ensemble. Cela implique de
déployer des applications de tests, de vérifier la connectivité, la performance, la mise à
l’échelle et la résilience du cluster. Des ajustements peuvent être nécessaires à cette étape
pour optimiser la configuration et répondre aux exigences demandées. Une fois les tests
concluants, le cluster Kubernetes peut être considéré comme prêt pour la production.

2.4.2 Objets de Cluster Kuberenetes

Un objet de cluster Kubernetes est une entité logique qui représente un composant essentiel
de l’infrastructure Kubernetes. Ces objets définissent les différents éléments du système, tels
que les pods, les services, les volumes et les déploiements, qui permettent de construire et de
gérer des applications conteneurisées hautement disponibles et évolutives.

EPI SUP Page 13

NOTIONS DE BASE

— Nœuds (Nodes) : Les machines physiques ou virtuelles qui composent le cluster Kubernetes
et exécutent les charges de travail.

— Pods : Les unités d’exécution les plus petites gérées par Kubernetes, contenant un ou
plusieurs conteneurs étroitement liés.

— Services : Des abstractions réseau qui exposent l’accès à un ensemble de Pods fournissant
une fonctionnalité unifiée.

— Volumes : Des mécanismes de stockage permettant de persister les données entre les
cycles de vie des Pods.

— Déploiements (Deployments) : Des contrôleurs qui gèrent le cycle de vie des applications,
assurant leur déploiement, leur mise à l’échelle et leur mise à jour.

— ConfigMaps et Secrets : Des objets permettant de stocker et de distribuer de manière

sécurisée les configurations et les informations sensibles.

2.4.3 Le rôle du maître (Master) dans le cluster

Le nœud maître (Master Node) joue un rôle essentiel dans l’orchestration et la gestion
globale d’un cluster Kubernetes. Ce composant central assume plusieurs responsabilités cruciales
pour assurer le bon fonctionnement de l’infrastructure.

— Gestion du plan de contrôle (Control Plane) : Le nœud maître est responsable du

contrôle et de la coordination de tous les composants du cluster, tels que l’ordonnanceur
(Scheduler), l’API de Kubernetes et les contrôleurs. Il veille à ce que les ressources soient
utilisées de manière optimale et que le cluster reste dans un état souhaité.

— Gestion de l’état du cluster : Le maître surveille en permanence l’état du cluster, détectant

les défaillances et prenant les mesures correctives nécessaires. Il gère les opérations de
mise à jour, de redémarrage et de redimensionnement des composants du cluster pour
maintenir sa stabilité et sa disponibilité.

En résumé, le nœud maître joue un rôle central dans l’orchestration et la gouvernance du

cluster Kubernetes, assurant la coordination des composants, l’allocation des ressources et le

EPI SUP Page 14

NOTIONS DE BASE

maintien de l’intégrité du système. C’est grâce à son fonctionnement efficace que le cluster
peut offrir une haute disponibilité et une grande scalabilité aux applications déployées.

2.4.4 Les nœuds (Nodes) et leur fonction

Les nœuds (ou nodes en anglais) sont des composants essentiels d’un cluster Kubernetes. Ils
représentent les serveurs physiques ou virtuels qui exécutent les charges de travail et services
déployés dans le cluster. Chaque nœud joue un rôle fondamental dans le fonctionnement global
du système Kubernetes.

— Capacité de calcul et de stockage : Les nœuds fournissent la puissance de calcul, la

mémoire et l’espace de stockage nécessaires à l’exécution des applications conteneurisées.
Ils peuvent être des machines physiques dans un datacenter ou des instances virtuelles
dans un environnement cloud.

— Exécution des Pods : Les nœuds sont responsables du déploiement et de l’exécution

des pods. Ils gèrent leur cycle de vie, en les démarrant, les arrêtant et les redémarrant si
nécessaire.

— Réseau et connectivité : Les nœuds assurent la connectivité réseau entre les pods, en
permettant la communication entre les applications et avec l’extérieur du cluster. Ils gèrent
également les règles de traffic et de sécurité réseau.

— Surveillance et gestion : Chaque nœud exécute des agents Kubernetes qui rapportent
l’état du nœud au maître (master). Cela permet au maître de surveiller la santé du cluster
et de prendre des décisions de placement et de scaling des charges de travail.

En résumé, les nœuds Kubernetes sont les briques de construction fondamentales qui permettent
l’exécution des applications conteneurisées de manière fiable et évolutive. Leur rôle est essentiel
pour assurer la disponibilité, la performance et la résilience du cluster dans son ensemble.

EPI SUP Page 15

NOTIONS DE BASE

2.4.5 Les services et leur gestion du trafic réseau

Dans un cluster Kubernetes, les services jouent un rôle essentiel dans la gestion du trafic
réseau. Ces composants abstraient l’accès aux pods en fournissant une adresse IP et un nom de
domaine stables, permettant ainsi aux clients d’accéder aux applications de manière fiable et
cohérente.

Les principaux types de services sont :

— Service ClusterIP : Ce service n’est accessible qu’à l’intérieur du cluster, permettant une
communication sécurisée entre les différents composants de l’application.

— Service NodePort : Ce service expose l’application sur un port spécifique de chaque

nœud du cluster, rendant l’application accessible depuis l’extérieur.

— Service LoadBalancer : Ce service utilise un équilibreur de charge externe pour distribuer

le trafic entrant vers les pods de l’application, offrant une haute disponibilité et une
évolutivité.

Kubernetes fournit également des services de découverte de service et de résolution de noms,

permettant aux pods de communiquer entre eux de manière transparente. Le contrôleur de
service gère automatiquement la création, la mise à jour et la suppression des services en
fonction des changements dans le cluster.

2.4.6 Les volumes persistants et le stockage des données

Dans un cluster Kubernetes, la gestion du stockage des données est primordiale. Les volumes
persistants (Persistent Volumes) permettent de découpler le stockage des données des conteneurs,
assurant ainsi leur persistance au-delà du cycle de vie des pods. Ces volumes peuvent être
montés dans les pods, garantissant l’accès aux données depuis les applications en cours d’exécution.

La configuration des volumes persistants s’effectue via des objets Kubernetes dédiés, permettant
de définir les caractéristiques du stockage, comme la taille, le mode d’accès ou encore les classes
de stockage.

EPI SUP Page 16

NOTIONS DE BASE

— La gestion des déploiements et des mises à jour : La gestion des déploiements et des
mises à jour est un aspect essentiel d’un cluster Kubernetes.

— Stratégies de déploiement : Kubernetes propose différentes stratégies de déploiement,

telles que le déploiement progressif, le déploiement canari ou le déploiement bleu-vert,
permettant de minimiser les risques et de garantir une expérience utilisateur fluide lors
des mises à jour.

— Gestion des versions : Kubernetes gère de manière native les versions des différentes
ressources (pods, services, configmaps, etc.). Cela facilite le suivi des changements, le
rollback en cas de problème et la mise à jour sélective de certains composants.

En maîtrisant ces différents aspects de la gestion des déploiements et des mises à jour, les
administrateurs de clusters Kubernetes peuvent assurer une haute disponibilité et une résilience
de leurs applications, tout en réduisant les risques de perturbations lors des mises à jour

2.4.7 Les outils de monitoring et de gestion du cluster

— Tableau de bord : Le tableau de bord est l’outil central pour suivre et gérer l’état de votre
cluster Kubernetes. Il offre une vue d’ensemble des ressources déployées, des charges
de travail, des événements et des métriques clés. Cet outil permet aux administrateurs
de surveiller les performances, d’identifier les problèmes et de prendre des décisions
éclairées pour optimiser le fonctionnement du cluster.

— Surveillance avancée : Au-delà du tableau de bord, des outils de surveillance plus poussés
comme Prometheus, Grafana ou Elastic Stack permettent de collecter, d’analyser et de
visualiser en détail les métriques du cluster, des applications et des ressources. Ils offrent
des capacités d’alerte, de corrélation des données et de prédiction des tendances pour une
vision approfondie de l’état du système.

— Automatisation et gestion : Pour faciliter l’administration du cluster, des solutions comme

Ansible, Terraform ou Helm permettent d’automatiser le déploiement, la configuration et
la mise à jour des ressources Kubernetes. Elles apportent une approche Infrastructure as
Code, favorisant la reproductibilité, la fiabilité et la résilience des opérations sur le cluster.

EPI SUP Page 17

NOTIONS DE BASE

— Diagnostic et dépannage : En complément, des outils comme Kubectl, Istio ou Linkerd

offrent des capacités avancées de diagnostic, de dépannage et de résolution des problèmes
au sein du cluster. Ils permettent d’analyser les journaux, les métriques et les communications
réseau pour identifier rapidement les sources de dysfonctionnements et les corriger.

2.5 Conclusion

L’architecture Kubernetes offre une plateforme puissante et flexible pour le déploiement et

la gestion d’applications conteneurisées. Ses composants clés, tels que les nœuds maîtres, les
pods, les services et les déploiements, permettent une grande agilité et une haute disponibilité.
Les fonctionnalités avancées de mise à l’échelle, de gestion du stockage et du réseau en font un
outil incontournable pour les

EPI SUP Page 18

Chapitre

3
RÉALISATION

Sommaire
3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Environnements et outils de développement . . . . . . . . . . 20
3.2.1 Environnement de développement . . . . . . . . . . . . . . . . . 20
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Intégration de l’application . . . . . . . . . . . . . . . . . . . . 23
3.3 Réalisation en Local . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Réalisation dans le Cloud . . . . . . . . . . . . . . . . . . . . . 27

EPI SUP Page 19

RÉALISATION

3.1 INTRODUCTION

La phase qui suit une etude bien détaillée est éventuellement l’implémentation. Dans ce
chapitre, nous présentons le travail que nous avons réalisé durant cette période. En effet, nous
allons commencer par la présentation de l’environnement de développement ainsi que les technologies
et les outils utilisés pour la réalisation de notre application. Ensuite, nous allons exposer les
résultats de l’implémentation à travers des captures d’écran des interfaces réalisés

3.2 Environnements et outils de développement

Dans cette partie, nous présentons les différents outils matériels et logiciels nécessaires pour
la realisation de notre projet.

3.2.1 Environnement de développement

Cette section détaille la configuration matérielle minimale requise pour déployer et gérer
efficacement un cluster Kubernetes. Pour mener à bien ce projet, les caractéristiques matérielles
essentielles sont les suivantes :

•Processeur : Le processeur revêt une importance capitale dans la mise en place d’un cluster
Kubernetes, car il est chargé de traiter les opérations de gestion et de communication entre les
nœuds du cluster, il est recommandé de disposer d’une fréquence minimale de 2.5 GHz pour
garantir des performances acceptables.

•Mémoire vive (RAM) : recommandée au minimum 8Go de RAM.

•Il est privilégié d’avoir disque dur de type SSD, plus rapide et ne perde pas en performance
dans le temps. les SSD conservent leurs performances au fil du temps, ce qui est crucial pour
maintenir la fiabilité et la disponibilité du cluster.

EPI SUP Page 20

RÉALISATION

Dans le cadre de ce projet de déploiement de cluster Kubernetes, nous avons sélectionné

un ensemble de matériels répondant à ces exigences minimales pour assurer une mise en place
efficace et stable du cluster.

3.2.2 Environnement logiciel

Pour la mise en place d’un cluster Kubernetes dans une machine virtuelle, nous avons choisi
d’utiliser Ubuntu comme système d’exploitation hôte. Sur cette machine virtuelle Ubuntu.

En plus de cette configuration locale, nous prévoyons également de mettre en place un

cluster Kubernetes sur Microsoft Azure pour le déploiement dans le cloud.

Cette approche nous permettra d’avoir une infrastructure flexible, nous permettant de déployer
notre application à la fois localement et dans le cloud. Le tableau 3.1 illustre les différents
logiciels que nous avons utilisés, ainsi que leur rôle dans notre environnement de développement
et de déploiement

EPI SUP Page 21

RÉALISATION

VSCode L’un des outils le plus important de VSCode est la capacité de déboguer les
applications directement sur l’éditeur sans même avoir recours aux navigateurs,
grâce à un système de points d’arrêt et une console de débogage intégrée qui permet
de résoudre les problèmes directement dans l’éditeur [.].

Kubernetes Assure l’orchestration et la gestion harmonieuse des conteneurs au sein du cluster,

permettant une efficacité opérationnelle accrue.

Docker Facilite la création, la distribution et l’exécution fluide des conteneurs applicatifs,

favorisant ainsi la portabilité et la cohérence des déploiements.

Kubectl Fournit une interface de ligne de commande intuitive pour une interaction directe
et précise avec le cluster Kubernetes, offrant un contrôle complet sur les ressources
déployées.

Minikube Minikube est un outil qui permet de créer et de gérer un cluster Kubernetes local
sur une seule machine, facilitant ainsi le développement, les tests et l’apprentissage
de Kubernetes dans un environnement isolé et contrôlé.[..]

GitHub Comme référentiel central pour le code source des applications à déployer sur le
cluster Kubernetes.

EPI SUP Page 22

RÉALISATION

helm Pour simplifier le processus de déploiement et de gestion des applications sur

Kubernetes en utilisant des packages préconfigurés.

Grafana Pour la visualisation des données de surveillance collectées par Prometheus,

facilitant ainsi l’analyse et l’optimisation des performances.

Rancher Rancher simplifie la gestion et l’exploitation d’un cluster Kubernetes, en offrant

une interface utilisateur intuitive et des fonctionnalités avancées pour automatiser
les tâches de gestion.

Mircorsft Azure Microsoft Azure, notre choix privilégié pour le déploiement du cluster Kubernetes,
offre une infrastructure cloud fiable et hautement évolutive. En tirant parti des
fonctionnalités avancées d’Azure, nous garantissons une gestion efficace des
ressources et une transition transparente entre les environnements de déploiement
local et cloud

TABLE 3.1 – Etude des méthodologies de développement

3.2.3 Intégration de l’application

Cette application de démonstration comprend un ensemble de microservices conteneurisés

qui peuvent être facilement déployés dans un cluster Kubernetes . Elle vise à illustrer un scénario
réaliste utilisant une architecture polyglotte, une conception orientée événements et des services
back-end open source courants (par exemple - RabbitMQ, MongoDB).

Dans la partie qui va suivre, nous allons donner un aperçu des interfaces de notre application
en essayant de présenter les fonctionnalités les plus importantes dans notre travail.

EPI SUP Page 23

RÉALISATION

3.3 Réalisation en Local

Création un cluster

Pour installer un cluster Kubernetes sur une machine Ubuntu, nous avons commencé par
installer Docker pour la gestion des conteneurs. Ensuite, nous avons installé les outils Kubernetes
tels que kubeadm, kubectl et kubelet pour configurer et gérer le cluster. En utilisant kubeadm,
nous avons initialisé le cluster, configuré le réseau et ajouté des nœuds ouvriers au cluster selon
les besoins. Enfin, nous avons vérifié l’état du cluster à l’aide de kubectl pour nous assurer que
tous les composants fonctionnent correctement.

images/c.png

F IGURE 3.1 – Capture d’écran du terminal

Déploiement de l’application

Pour déployer notre application sur le cluster Kubernetes, nous avons suivi plusieurs étapes.
Tout d’abord, nous avons cloné le référentiel GitHub contenant le code source de notre application
. Ensuite, nous avons démarré notre cluster Kubernetes local . Une fois le cluster devient
opérationnel, nous avons utilisé la commande ’kubectl get svc’ pour obtenir la liste des services
disponibles sur le cluster. . Les Figures 1.1 et 1.2 illustrent respectivement le processus de travail

EPI SUP Page 24

RÉALISATION

F IGURE 3.2 – Capture d’écran du terminal

F IGURE 3.3 – Capture d’écran du terminal

Enfin, nous avons lancé notre service front-end en utilisant la commande ’minikube service
front’. Ces étapes nous ont permis de déployer avec succès notre application sur le cluster

EPI SUP Page 25

RÉALISATION

Kubernetes. L’application est maintenant accessible à l’adresse IP externe fournie par le service
front-end

F IGURE 3.4 – Capture d’écran du terminal

Surveillance de cluster kubernetes

La Figure 1.1 illustre le tableau de bord Kubernetes, une interface Web conviviale qui offre
une vue d’ensemble de l’état de notre cluster, des pods, des déploiements, des services, et
d’autres ressources Kubernetes. Avec cet outil, nous avons pu surveiller les performances de
notre cluster, déboguer d’éventuels problèmes, déployer de nouvelles applications et ajuster la
configuration du cluster selon nos besoins

EPI SUP Page 26

RÉALISATION

F IGURE 3.5 – tableau de bord Kubernetes

3.4 Réalisation dans le Cloud

Pour notre solution cloud, nous avons choisi Microsoft Azure Kubernetes Service (AKS).
Cette plateforme offre une gestion simplifiée des clusters Kubernetes, une intégration fluide
avec l’écosystème Azure, et une scalabilité optimale.

Dans la phase de création d’un cluster Kubernetes, nous avons procédé à la configuration
en suivant plusieurs étapes essentielles. Tout d’abord, nous avons défini un nom pour notre
cluster, , comme illustré dans la figure 1.1. Ensuite, nous avons sélectionné une région pour
le déploiement du cluster AKS, . Nous avons laissé les valeurs par défaut pour la version de
Kubernetes et pour la mise à niveau automatique, qui est activée avec le correctif recommandé.
Enfin, nous avons configuré l’authentification et l’autorisation avec des comptes locaux .

EPI SUP Page 27

RÉALISATION

F IGURE 3.6 – Logo de l’EPI Educationnel Group

Après avoir cliqué sur "Suivant", sous l’onglet "Pools de nœuds", nous avons ajouté un
nouveau pool de nœuds en suivant les étapes recommandées. Nous avons nommé ce pool
"nplinux" et sélectionné le mode "Utilisateur" avec une référence SKU du système d’exploitation
définie sur "Ubuntu Linux". Nous avons choisi de ne pas utiliser de zones de disponibilité et
avons laissé la case "Activer les instances Azure Spot" décochée. Pour la taille des nœuds,
nous avons opté pour "D2s-v2" et avons maintenu la méthode de mise à l’échelle sur "Mise
à l’échelle automatique", ainsi que les valeurs par défaut pour le nombre minimal et maximal
de nœuds. En outre, nous avons laissé tous les autres paramètres des autres onglets sur leurs
valeurs par défaut, sauf pour les paramètres de l’onglet "Analyse", où nous avons désactivé les
fonctionnalités Azure Monitor Container Insights, Azure Monitor service géré pour Prometheus
et Azure Managed Grafana afin d’économiser des coûts. Pour illustrer ces étapes,

EPI SUP Page 28

RÉALISATION

F IGURE 3.7 – Création d’un nouveau pool

Une fois que tous les éléments nécessaires pour la création du cluster ont été configurés,
nous avons appuyé sur le bouton ’Create’ pour lancer le processus de création. Après cela, nous
avons attendu quelques minutes pour que la vérification soit effectuée et que le cluster soit créé
avec succès.La Figure 3.7 illustre ce processus.

EPI SUP Page 29

RÉALISATION

F IGURE 3.8 – Logo de l’EPI Educationnel Group

Se connecter au cluster

Pour gérer un cluster Kubernetes, nous avons utilisé kubectl, le client de ligne de commande
Kubernetes. Si nous utilisons Azure Cloud Shell, kubectl est déjà préinstallé. Nous avons configuré
kubectl pour nous connecter à notre cluster Kubernetes en utilisant la cmdlet Import-AzAksCredential.
Cette commande a téléchargé les informations d’identification et configuré l’interface CLI
Kubernetes pour les utiliser. Pour vérifier la connexion à notre cluster, nous avons exécuté la
commande kubectl get pour obtenir une liste des nœuds du cluster. L’exemple de sortie suivant
illustre le nœud unique créé au cours des étapes précédentes. Assurons-nous que l’état du nœud
est "Prêt".

EPI SUP Page 30

RÉALISATION

F IGURE 3.9 – Logo de l’EPI Educationnel Group

Déployer l’application

Pour déployer l’application, nous avons utilisé un fichier manifeste pour créer tous les objets
nécessaires à l’exécution de l’application AKS Store. Un fichier manifeste Kubernetes spécifie
l’état souhaité d’un cluster, y compris les images de conteneurs à exécuter.

EPI SUP Page 31

RÉALISATION

F IGURE 3.10 – Logo de l’EPI Educationnel Group

Nous avons déployé l’application en utilisant la commande kubectl apply et en spécifiant le

nom de notre manifeste YAML.

F IGURE 3.11 – Logo de l’EPI Educationnel Group

EPI SUP Page 32

RÉALISATION

F IGURE 3.12 – Logo de l’EPI Educationnel Group

Pour vérifier l’état des pods déployés, nous avons utilisé la commande kubectl get pods.
Nous avons veillé à ce que tous les pods soient en état "Running" avant de continuer. Ensuite,
nous avons recherché une adresse IP publique pour l’application de vitrine. Pour surveiller
la progression de cette recherche, nous avons utilisé la commande kubectl get service avec
l’argument –w.

Enfin, pour visualiser l’application Azure Store en action, nous avons ouvert un navigateur
web et accédé à l’adresse IP externe de notre service.

sureveillance de lapplication

EPI SUP Page 33

RÉALISATION

F IGURE 3.13 – Logo de l’EPI Educationnel Group

Test de l’application

F IGURE 3.14 – Logo de l’EPI Educationnel Group

EPI SUP Page 34

 CONCLUSION GÉNÉRALE

la mise en place d’un cluster Kubernetes a permis à notre application de relever avec succès
les défis liés à l’orchestration et à la gestion des conteneurs à grande échelle. Grâce à la puissance
et à la flexibilité offertes par cette solution, nous avons pu déployer nos applications de manière
fiable, évolutive et sécurisée, tout en bénéficiant d’un écosystème riche en outils d’intégration
et d’automatisation.

Le choix de Kubernetes s’est avéré judicieux, car il a répondu parfaitement à nos besoins
en matière de haute disponibilité, de tolérance aux pannes et de gestion avancée des charges
de travail. La planification rigoureuse de la mise en place du cluster, ainsi que le déploiement
progressif de nos applications, ont permis une transition en douceur vers cette nouvelle infrastructure,
sans perturber le fonctionnement de nos services existants.

Néanmoins, les défis ne s’arrêtent pas là. Nous envisageons d’explorer davantage les possibilités
offertes par Kubernetes, notamment en matière d’intelligence artificielle et d’apprentissage
automatique, afin de tirer parti de ces technologies émergentes pour optimiser nos processus
métier et offrir de nouvelles expériences. De plus, nous prévoyons de mettre en place des
solutions avancées de sécurité et de gouvernance pour garantir la protection de nos données
sensibles et la conformité avec les réglementations en vigueur.

En définitive, la transition vers Kubernetes a été un véritable succès pour notre notre projet,
nous permettant de relever les défis de l’ère du numérique avec agilité et innovation. Nous
sommes convaincus que cette solution d’orchestration de conteneurs continuera à être un atout
majeur pour soutenir la croissance et la transformation digitale dans les années à venir.

EPI SUP Page 35

 BIBLIOGRAPHIE

[1] Docker swarm. Disponible sur : https ://datascientest.com/docker-guide-complet

[2] Florent Lothon. Introduction aux méthodes agiles [en ligne]. Disponible sur :
agiliste.fr/introduction-methodes-agiles

[3] NUTCACHE. les methodes agiles [en ligne]. Disponible sur :

https ://www.nutcache.com/fr/blog/les-methodes-agiles/, 2010.

[4] USB-IF. USB Power Delivery Specification Revision 2.0, Version 1.3, le 12 January 2017.
Format PDF. Disponible sur :
https ://www.usb.org/document-library/usb-power-delivery-0

EPI SUP Page 36

 ANNEXES

Présentation de l’organisme d’accueil EPI Group

Le Group EPI Sup : Créé en 2011 par une équipe spécialisé dans l’enseignement supérieur
et comprend aujourd’hui 4 écoles :

• Ecole Polytechnique (EPI-Polytechnique) pour la formation d’ingénieurs.

• Ecole Digitale (EPI-Digital School) pour la formation des professionnels du monde du

digital (licences, masters, ingénieurs)

• Ecole d’Architecture (EPI-Arch) pour la formation d’ingénieurs-architectes.

• Ecole Business School (EPI-Business School) pour la formation de managers.

En fait, ces écoles sont implantées dans un Campus exceptionnel disposant d’une infrastructure
moderne et performante et offrant un cadre d’étude et de vie agréable. Aujourd’hui, elle a
l’honneur d’affirmer sa réussite, ce qui lui donne la passion et la confiance de travailler encore
plus afin de la préserver et de hisser encore notre Groupe EPI vers les plus hautes sphères de
l’excellence et pour être toujours à la hauteur des attentes [1].pharetra tempor.

EPI SUP Page 37

 Mise en place d’un cluster kubernate et migration des applications déployées en mode
SWARM SUR KUBERNETES

Mohamed Amine BEN TICHA

Hamza BAGGA

Résumé :
Notre projet de fin d’année se concentre sur la mise en place d’un environnement de développement
et de déploiement basé sur des conteneurs avec Kubernetes (K8s). En utilisant des outils tels que
Docker, Minikube et Helm, nous créerons et gérerons un cluster Kubernetes sur une machine
virtuelle Ubuntu, permettant le déploiement et la gestion efficace d’applications distribuées. En
parallèle, nous explorerons également le déploiement dans le cloud en utilisant Microsoft Azure
comme plateforme cloud pour héberger notre cluster Kubernetes, offrant ainsi une flexibilité
et une évolutivité accrues à notre infrastructure. L’objectif principal est de comprendre en
profondeur les concepts de l’orchestration de conteneurs et de maîtriser les outils nécessaires
pour gérer des environnements de déploiement modernes.
Mots clés : k8S,Swarm, orchestrateur,Minukube,Kubctl,Azure AKS.

Abstract :
Our end-of-year project focuses on setting up a container-based development and deployment
environment with Kubernetes (K8s). Using tools such as Docker, Minikube, and Helm, we will
create and manage a Kubernetes cluster on an Ubuntu virtual machine, enabling the efficient
deployment and management of distributed applications. Additionally, we will explore cloud
deployment by using Microsoft Azure as the cloud platform to host our Kubernetes cluster,
providing increased flexibility and scalability to our infrastructure. The main objective is to
gain a deep understanding of container orchestration concepts and master the tools required to
manage modern deployment environments.
Key words : k8S,Swarm, orchestrateur,Minukube,Kubctl,Azure AKS.
ANNEXES

EPI SUP Page 39