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 :
- API Server
L’API server fournit l’interface interne et externe de Kubernetes au travers d’une API REST. Il gère et valide des requêtes et met à jour l’état des objets. C’est le point d’entrée des commandes d’administration du cluster. L’outil en ligne de commande « kubectl » permet d’exécuter des commandes dans les clusters par des appels à l’API. - Controller Manager
Le Controller Manager est un démon qui régule et surveille l’état du cluster. Il contrôle les nodes, les espaces de noms, les comptes de service. - Scheduler
Le scheduler est un démon qui planifie le déploiement des pods sur les nodes. Lorsqu’un pod est créé au moyen de l’API Server, le scheduler assigne un nœud au pod selon différents critères : disponibilité, ressources, contraintes d’affinité définies par l’administrateur, … - etcd
Il s’agit d’une base de données clé-valeur utilisée pour mémoriser toutes les informations sur l’état du cluster.
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, …).
- Kubelet
Kubelet est un démon qui s’assure que les conteneurs fonctionnent dans un pod. - cAdvisor
cAdvisor est un démon qui surveille et récupère les données de consommation des ressources et des performances comme le processeur, la mémoire, ainsi que l’utilisation disque et réseau des conteneurs de chaque node. - Kube-proxy
Kube-proxy qui s’exécute sur chaque node gère la connectivité entre les pods et les services Kubernetes en ajoutant et en supprimant des règles de destination NAT (DNAT) sur le sous-système iptables du node.
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.
- Si votre cluster Kubernetes est installé sur des serveurs physiques privés
- Si les performances ne sont pas critiques, une solution de stockage cloud peut être satisfaisante.
- Si les performances sont critiques, un stockage local ou fc est à privilégier. Le stockage local ne permet pas au pod l’utilisant de changer de node durant son cycle de vie.
- Si votre cluster Kubernetes est chez Google, AWS, Azure ou même OVH, l’offre inclut des stockages persistants et performants.
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 :
- Storage classe
- Persistent volume
- StatefulSet et volumeClaimTemplates
- Service
La suite est ici