Le nœud master

Un cluster Kubernetes est constamment composé d’un nœud master, les autres nœuds sont des nœuds enfants qui seront pilotés par le nœud master. Le nœud master est composé des outils Kubernetes suivants :

API Server : également appelé kube-apiserver, l’API Server est le composant central de gestion du cluster Kubernetes. Il permet en exposant des API REST de manipuler le cluster et ses nœuds via les fichiers de configuration. Il permet également de stocker l’état du cluster dans le stockage etcd ;
Controller Manager : composant de Kubernetes permettant de ‘surveiller’ le cluster, et d’agir si nécessaire. C’est lui qui permet au cluster de maintenir son état de fonctionnement, c’est-à-dire l’état décrit dans le dernier fichier de configuration. Il vérifie que les nœuds fonctionnent toujours et que le cluster respecte le bon nombre de réplica d’un service déployé au sein de celui-ci ;
Scheduler : entité qui va planifier le déploiement d’un pod sur un nœud. Le planificateur va prendre en compte beaucoup de paramètres pour décider sur quel nœud il faut déployer le pod : les ressources serveurs et logiciels, les contraintes, les spécifications d’affinités, les interférences …
etcd : stockage persistent de type NoSQL avec clé/valeur permettant à Kubernetes de connaître à tout moment l’état supposé du cluster.

Les différents types d’objets

Il est ensuite possible de communiquer avec l’API Server via une interface en ligne de commande ou via une interface graphique. Ensuite, Kubernetes manipule ce qu’on appelle des objets. Il en existe plusieurs types, et il est important de bien connaître la terminologie :

Pod : c’est l’entité la plus unitaire de Kubernetes, la plus petite et la plus simple. Un Pod représente un processus en cours d’exécution dans le cluster. Nous pouvons comparer cela à Docker : les images sont à Docker ce que les Pods sont à Kubernetes. Un Pod encapsule une application (ou plusieurs selon certains cas, mais non conseillé) et possède une ressource stockage, une adresse IP et des options qui dictent comment le Pod doit se comporter. Il représente une unité de déploiement et correspond au final à une seule instance d’une application dans Kubernetes ;
Service : un service est un ensemble de Pod regroupés sous une même enseigne logique : les labels. Les services deviennent une abstraction des Pods permettant à Kubernetes de savoir quels Pods sont concernés par quelle facette fonctionnelle de votre application ;
Volume : un Pod a une durée de vie indéterminée. S’il tombe, Kubernetes va recréer ce Pod à l’identique selon la configuration indiquée. Ainsi, tous les fichiers de l’ancien Pod sont perdus. Les volumes apportent une solution permettant de faire perdurer les fichiers, mais la durée de vie reste celle du Pod. Le volume permet cependant de conserver les fichiers même si des conteneurs sont tombés dans le Pod ;
Namespace : les namespaces permettent de diviser un cluster afin de faire fonctionner plusieurs environnements à l’intérieur (développement, production …). Cette division est une division logique, et permet par exemple de diviser les ressources à l’intérieur du cluster selon le namespace choisi.

Les modes de modification du cluster

Kubernetes permet 2 modes de modification du cluster : le mode déclaratif par opposition au mode impératif. Le mode impératif demande à l’administrateur du cluster d’écrire les commandes qui vont changer le cluster. Par exemple, les commandes ci-dessous permettent de créer un namespace, un quote, un déploiement et un service.

L’administrateur exécute lui-même les commandes, et doit ensuite lui-même s’assurer que le cluster maintient le bon état. Par exemple, si un Pod tombe, c’est à lui de relancer le pod avec les commandes appropriées. De plus, une fois le cluster dans l’état final, il est difficile de se souvenir de l’état désiré du cluster, il n’y a pas de source of truth.

Cette technique comporte bien des soucis notamment en termes de maintenabilité de l’état du cluster. C’est pourquoi il existe la méthode déclarative. Cette méthode permet d’utiliser des fichiers de configuration au format au YAML afin de piloter le cluster. Ces fichiers YAML sont établis par l’administrateur du cluster, et sont ensuite soumis à Kubernetes via la commande suivante :

C’est Kubernetes qui s’occupe de lancer les commandes en fonction des différences trouvées. L’administrateur décrit l’état du cluster au final et non plus les commandes qui amènent à cet état ;
L’état est sauvegardé et donc Kubernetes connaît constamment l’état du cluster ;
Kubernetes surveille le cluster et compare avec l’état souhaité soumis avec ses fichiers de configuration. Il va donc lancer les commandes nécessaires si une anomalie devait se produire.

Gérer un cluster Kubernetes grâce aux fichiers de configuration

Les fichiers de configuration semblent donc être la meilleure solution afin de gérer un cluster Kubernetes. Ces fichiers au format YAML doivent respecter un schéma bien particulier afin d’être compris par Kubernetes. Il est important de rappeler que YAML est une version dérivée de JSON. Cela veut dire que vous pouvez aussi très bien utiliser des fichiers au format JSON pour piloter le cluster. Pour tester Kubernetes en local sur votre machine, il est possible d’installer Minikube (disponible sur Mac, Linux et Windows). Cet outil permet de simuler des nœuds dans des machines virtuelles et ainsi tester vos déploiements : https://kubernetes.io/docs/setup/minikube/.

L’exemple ci-dessous présente la création d’un Pod via un fichier de configuration YAML :

Les fichiers Kubernetes commencent toujours par apiVersion. Ceci permet de cibler la version du schéma Kubernetes que vous souhaitez. Ensuite, on indique quel type d’objet Kubernetes on souhaite créer via l’attribut kind. Ici, nous voulons un Pod. Une bonne pratique est de constamment rajouter des métadonnées à ses objets. Dans le cas ci-dessus, on rajoute un name et un label. Dans la section spec, le fichier décrit les images docker que Kubernetes doit télécharger. Dans ce cas, on utilise une image nginx et une image personnalisée de l’application que l’on souhaite faire fonctionner dans le Pod. Une fois ce fichier bien conçu, il suffit de lancer la commande suivante :

La commande create absorbe le fichier pod.yaml et l’envoi à Kubernetes pour la création du Pod. La commande suivante permet de suivre l’avancée de la création du Pod :

Au bout d’un moment, le Pod passe en statut Running, confirmant que la création s’est bien déroulée avec succès.

Grâce aux fichiers de configuration, il est très facile de piloter et maintenir un cluster Kubernetes. Les architectures micro-services doivent se doter d’orchestrateur afin de garantir une haute disponibilité des applicatifs. Kubernetes est un excellent choix dans ce sens notamment par sa robustesse et sa flexibilité de gestion. Aujourd’hui mondialement répandu, ce projet Open Source est un parfait exemple d’outil développé par la communauté et qui sert au plus grand nombre.