Architecture Kubernetes

DevOps

Il fut un temps, les applications fonctionnaient comme un seul processus pouvant être appelés monolithiques pour faire l’analogie entre l’application et un grand bloc de pierre. L’équipe de développement « dev » transmettait l’application à l’équipe opérationnelle « ops » qui se chargeait de la déployer sur les machines. Celles-ci étaient de grandes tailles, ce qui rendait le cycle de release très lent et très peu fréquent. Avec les méthodologies de gestion de projet de type « waterfall », il fallait attendre 1 an ou plus avant de pouvoir déployer l’application sur une infrastructure. La séparation entre ces deux équipes posait quelques problèmes. Les développeurs ne pensaient qu’à développer et ne se souciaient guère de comment fonctionnait leurs codes sur l’environnement de production. Tant que tout fonctionnait sur leurs machines, ils avaient fait leur part du boulot. Aujourd’hui, on voit les choses autrement: They care not just about implementing user features, but also actively ensure their work flows smoothly and frequently through the entire value stream without causing chaos and disruption to IT Operations or any other internal or external customer.[1]

L’équipe opérationnelle a pour but d’assurer la stabilité et la qualité de l’infrastructure. Elle préparait les machines à accueillir l’application avec toutes les dépendances nécessaires. Puis, une fois en production, elle assure que l’application ne tombe pas en panne et qu’elle respecte un certain niveau de performance. Leurs objectifs respectifs créent alors un fossé entre les deux équipes et génèrent un conflit majeur. Les devs veulent coder le plus de fonctionnalités possibles dans un temps restreint, alors que les ops veulent un code stable qui respecte plusieurs critères de qualité qui ne concernent pas les fonctionnalités métier. DevOps met en place une série d’étapes au développement du logiciel formant un cycle qui intègre les développeurs et les équipes opérationnelles. Des tâches sont automatisées : les tests unitaires, la gestion de la configuration des machines et le déploiement. La mise en production de nouvelles fonctionnalités est plus fréquente. Ce nouveau système permet d’améliorer la collaboration, la productivité de chaque équipe et permet d’être plus compétitif vis-à-vis de la concurrence.

Kubernetes

Les microservices peuvent être déployés de manière très rapide grâce à docker et peuvent être répliqués puisqu’ils sont tous indépendants. Toutefois, comment gérer tout cela manuellement si des containers sont dispersés dans un grand nombre de machines ? Dans le cas où il y a un container qui pose un problème, comment le détecter ? Lequel aurait besoin de plus de réplications pour subvenir à une subite augmentation de la charge ? L’équipe opérationnelle monitore les serveurs et si un de ces derniers tombe en panne, il devra créer de nouveaux containers avec les services déchus dans un autre serveur. Kubernetes permet justement d’automatiser le déploiement, la gestion de demande de puissance et la gestion des applications containerisées.[6] Ainsi, l’équipe ops pourra déléguer la responsabilité de gérer les applications déployées à l’équipe dev et le système peut être programmé pour pouvoir s’autogérer sans la supervision d’un humain. Kubernetes s’occupera de déployer un container avec l’application qui était présente dans la machine qui est tombée en panne, dans une machine qui a la capacité de l’accueillir. Dans le cas où une machine est très fortement sollicitée et ne parvient plus à suivre à la sollicitation d’un ou plusieurs services, Kubernetes pourra être programmé pour réagir et déployer des containers offrant les services nécessaires sur d’autres machines et via un LoadBalancing, dispatcher les requêtes pour répondre à cette demande.

Puis bien évidemment, enlever des containers quand ils ne seront plus nécessaires et utilisent inutilement du temps computationnel. Ce travail de Bachelor va décrire comment Kubernetes met en place cette fonctionnalité de gestion de la charge et en faire un case study. Pour résumer, tous ces changements tant au niveau du développement d’une application que de son maintien, ont engendré de nouveaux concepts avec leurs nouvelles problématiques. Les premières architectures d’applications étaient monolitques et leurs composants étaient fortement couplés. Dorénavant, celles-ci sont distribuées et basées sur des microservices indépendants, dispatchés sur plusieurs machines et gérés par un orchestrateur de conteneurs, Kubernetes.

Worker Node

Un worker node (WN) est une machine physique ou une VM qui détient toutes les ressources nécessaires afin de garantir l’exécution d’un ou plusieurs pods. [15] Cette entité va héberger tous les services qu’un développeur aura décidé de déployer (Figure 4). Chaque WN est composé d’un Kubelet, d’un kube-proxy et d’un Container runtime. Le Kubelet a comme responsabilité de gérer tous les pods ainsi que leurs containers contenus dans le WN. Lui-même contient un composant appelé « cAdvisor » qui lui s’occupe de récupérer des métriques sur chaque container de chaque pods. Le Kube-proxy a comme responsabilité de rediriger le trafic réseau vers les pods contenant les services requis. Pour cela, il contient une table « IPTable » qui détient les adresses des pods. Le Container runtime est extérieur à Kubernetes. C’est le composant qui gère les containers dans un WN, Docker dans le cadre de notre mémoire. Pour créer un container, le Kubelet inspecte le descriptor d’un pod du WN et communique les images qui y sont mentionnées au Container runtime via le protocole REST. Ce dernier télécharge l’image à partir de DockerHub si l’image n’est pas disponible localement et instancie un container avec cette image. Si un pod est supprimé ou dysfonctionne, le Kubelet a la responsabilité d’arrêter le ou les containers qui y étaient hébergés via le container runtime.

ReplicationController, ReplicaSet

Le Replication Controller (RC) a la charge de créer, supprimer et de maintenir une ou plusieurs instances d’un pod selon le nombre de réplicas mentionné dans le descriptor du RC. Il est situé au sein du master node (voir chapitre 3.7 Master Node) Un RC s’occupe uniquement des pods qui contiennent un certain type d’image à qui on va assigner un label dans son descriptor. Si le descriptor mentionne uniquement le label A, il ne se préoccupera pas des pods ayant un label B. [16] Dans la Figure 5 : Schéma du rôle du Replication Controller, nous pouvons voir que le descriptor du RC ne mentionne que le label « A » avec une image « A ». Un pod ayant le label « A » à gauche de la Figure 5 : Schéma du rôle du Replication Controller ne fonctionne plus. Le descriptor mentionne qu’il faut trois réplicas actifs alors qu’il n’y en a plus que deux. Par conséquent, le RC en crée un nouveau pour s’ajuster au descriptor. Mais ce n’est pas lui qui les assigne aux WN. L’assignation du pod à un WN est effectuée par le Scheduler, cette étape sera expliquée dans un prochain chapitre. Le pod ayant le label « B » est supprimé lui aussi. Cependant, aucun RC ne s’en occupe. Il n’y aura plus aucun pod ayant le label B. Répliquer un pod veut dire en créer un nouveau avec les mêmes caractéristiques.

Dans le schéma de la figure 5 à droite, le pod lié au trait-tillé vert est un pod ayant les mêmes caractéristiques que les pods contenant le label « A ». Le descriptor du RC indique combien de pods d’un certain type il doit maintenir en permanence. Ainsi, en augmentant manuellement ce nombre, le RC crée immédiatement de nouveaux pods de ce type. C’est une manière d’augmenter manuellement la disponibilité d’un service. Chaque type de pod étant géré par des RC distincts, il faudrait changer chacun de leurs descriptors respectifs pour les « scaler » ensemble. Par exemple, admettons que le nombre de pod de type « FrontEnd » a été augmenté. Sachant qu’il communique toujours avec un pod « Backend », il pourrait être judicieux d’augmenter le nombre de ce dernier aussi. Kubernetes utilise un autre concept pour gérer plusieurs types de pods simultanément : le ReplicaSet. Ce dernier fonctionne de la même manière qu’un RC, mais il est possible de sélectionner plusieurs types de pods avec des labels différents dans son descriptor.1

Conclusion

En conclusion, la solution proposée par Kubernetes répond parfaitement à la problématique de manière simple et efficace. On constate que l’accès de type Nodeport offre une solution simple de loadbalancer. De plus, en cas de forte fluctuation du trafic, le système s’ajuste pour répondre au besoin automatiquement grâce à l’HPA. De ce fait, les développeurs peuvent se concentrer sur les aspects métiers de leurs applications. La phase d’étude de cette technologie était assez complexe car cette technologie est en constante évolution et m’était inconnue. J’ai dû passer par une étude de l’architecture de Kubernetes : ses composants et leurs interactions, afin de comprendre le fonctionnement du système global. Cependant, la partie pratique de ce manuscrit est académique, le déploiement de services plus complexes sur des machines de production nécessiterait un approfondissement car la technologie est plus vaste que l’échantillon qui a été décrit. Heureusement, Kubernetes possède une grande communauté d’utilisateurs, très active et une excellente documentation. Si le temps nécessaire à maitriser Kubernetes semble long, plusieurs alternatives payantes existent comme : Azure Kubernetes Service [36], Amazon EKS [37], etc. qui facilitent son usage. Pour conclure, je suis très satisfait par les connaissances et compétences acquises lors de la rédaction de ce mémoire. J’espère pouvoir les approfondir lors de mon arrivée chez mon prochain employeur qui s’avère utiliser Kubernetes.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Montée en puissance des microservices avec Kubernetes
Déclaration
Remerciements
Résumé
Liste des tableaux
Liste des figures
1. Introduction
1.1 DevOps
1.2 Microservices
1.3 Docker
1.4 Kubernetes
2. Problématique
2.1 CQRS
2.2 Publish and Subscribe
3. Architecture Kubernetes
3.1 Introduction
3.2 Docker
3.2.1 Docker deamon & docker-cli
3.2.2 Docker Image
3.2.3 Dockerfile
3.2.4 DockerHub
3.3 Pods
3.4 Worker Node
3.5 ReplicationController, ReplicaSet
3.6 HorizontalPodAutoscalling
3.7 Master Node
3.8 Service
3.8.1 NodePort :
3.8.2 LoadBalancer :
3.8.3 Ingress :
4. Accès aux services par une requête externe
4.1 Introduction
4.2 Networking
4.3.1 Ajustement du nombre de pods vis-à-vis du trafic
4.3.2 Création des pods suite à une mise-à-jour de l’etcd
4.3.3 Sélection du worker node
5. Installation
5.1 Docker
5.2 Minikube
5.2.1 Introduction
5.2.2 Prérequis
5.2.3 Virtualisation VT-x ou AMD-v
5.2.4 Hyperviseur
5.2.5 Kubectl
5.2.6 Minikube
6. Case study
6.1 Introduction
6.2 Création de l’image NBA avec Docker
6.2.1 Dockerfile
6.2.2 Docker CLI
6.3 Publier l’image sur DockerHub
6.4 Créer un container avec l’image NBA
6.5 Essai de montée en puissance
6.5.1 Introduction
6.5.2 Création minikube
6.5.3 Création ReplicaSet
6.5.4 Diminution manuelle du nombre de pods « nba »
6.5.5 NodePort Service
6.5.6 HPA
7. Conclusion
Bibliographie