Site icon Eolya Consulting

Kubernetes – Introduction à l’architecture et aux composants

Kubernetes

Dans cet article, nous présentons l’architecture et les composants de Kubernetes (serveur Master, serveur Node, Pod, …) et plus particulièrement la mise en place de pods (containers) avec persistance des données. Il fait suite à un premier article dans lequel est décrit l’installation d’un cluster Kubernetes privé.

Architecture Kubernetes

Kubernetes ( « k8s ») est un système d’automatisation et d’orchestration du déploiement et de la montée en charge de conteneurs d’applications. Il est souvent utilisé avec Docker. Kubernetes est une solution open-source conçu à l’origine par Google. Un cluster Kubernetes est constitué de deux types de serveurs. Les serveurs « Master » qui sont en charge du pilotage du cluster et des serveurs « Worker » (ou Node) sur lesquels sont déployés des Pods (ensemble de container).

Le schéma ci-dessous synthétise l’architecture et les composants de Kubernetes. 

Les composants Kubernetes

Le pod

Le Pod est le premier des concepts Kubernetes à décrire. C’est un groupe d’un ou plusieurs conteneurs étroitement liés. Il s’agit de la plus petite unité déployable sur un node. Les containers d’un pod partagent les mêmes ressources. Les pods hébergent des containers qui fournissent des services applicatifs. Ils ont une durée de vie plus ou moins éphémère en fonction des besoins. Un pod qui héberge un service Solr fournissant la fonctionnalité de recherche pour un site ecommerce peut avoir une durée de vie longue (pour répondre aux recherches en période de fréquentation normale) ou courte (pour répondre à une augmentation ponctuelle de l’usage durant les fortes périodes de vente ou durant des campagnes publicitaires).

Les serveurs Master

Les serveurs Master sont donc en charge du pilotages du cluster. Ils sont en général au nombre de trois pour obtenir un cluster haute disponibilité. Un serveur Master unique est suffisant pour un cluster de tests. Les composantes d’un serveur Master sont les suivantes :

Les serveurs Node

Les nodes hébergent les pods et donc les containers qui vont s’exécuter. Contrairement aux serveurs Master qui ne requièrent pas une grande puissance, plus un serveur Node est puissant, plus il est en mesure d’héberger des services consommateurs de ressources (CPU, mémoire, …).

Le plugin network

Le plugin network est déployé au travers de tous les serveurs du cluster Kubernetes. Il a pour rôle la mise en œuvre du réseau entre les nodes et les pods et entre les pods eux-mêmes. Ces plugins sont des solutions tierces telles que Calico, Flannel ou Weavenet. Voici un descriptif des différents plugins.

Pods avec persistance des données 

Par défaut un container ne dispose pas d’espace de stockage persistant pour mémoriser l’état de ses données. Lorsqu’un container qui a écrit des données dans son système de fichiers redémarre, les données sont perdues. Le container se retrouve dans un état initial. Les services qui s’accommodent de ceci sont dit « stateless ». 

A contrario, des services tels que des bases de données (MySQL, Mongodb, Zookeeper, Solr, elasticsearch, …) ne peuvent pas se permettre de perdre les données qu’ils gèrent lors d’un redémarrage des pods. Ces services sont dits statefull. Les données ne peuvent pas être stockées sur le système de fichiers éphémère des containers. Il est nécessaire de disposer de volumes de données persistants.

Kubernetes permet le déploiement de service statefull grâce aux Statefulset. Un Statefulset ne permet pas uniquement d’associer des stockages persistants aux pods. Il permet également aux pods de disposer d’une identité réseau fixe même si le Pod est redéployé sur un autre node.

Un pod peut être redéployé sur un autre node ! Mais comment les données persistantes restent attachées au pod ? 

Il existe un certain nombre de solutions pour mettre en place un stockage persistant associé à un pod. Ces solutions sont soit des stockages distants dans une infrastructure privée (volumes NFS, cephfs, fc, … ) ou dans le cloud (volumes awsElasticBlockStore, azureDisk, …) soit des volumes locaux sur le node qui héberge le pod (volume local). Parmi ces solutions, le critère de choix est la performance requise en lecture/écriture. 

Conclusion

Maintenant nous disposons d’un cluster Kubernetes privé et nous en avons expliqué les concepts. Nous sommes donc en mesure de décrire le déploiement de Solrcloud avec la mise en oeuvre d’un stockage persistant local. Ce déploiement implique les éléments suivants :

La suite est ici

Quitter la version mobile