Kubernetes : Au cœur de l’orchestration

Préambule :

Cet article ne nécessite pas d’avoir une expérience pratique avec kubernetes mais seulement de connaître les différents termes suivants ou objets de Kubernetes tels que (un Nœud, un Pod, service, déploiement, un conteneur et savoir lire un fichier de déploiement ). Si tel n’est pas le cas, nous vous recommandons vivement de consulter nos 2 précédents articles sur l’installation et le déploiement d’applications sur kubernetes ou cet article sur la conteneurisation (https://sysblog.informatique.univ-paris-diderot.fr/2019/03/08/containerisation-cgroups-namespace/)

Kubernetes (K8s) est une plateforme permettant de gérer et d’automatiser le déploiement et la scalabilité  des applications conteneurisées (voir article sur la conteneurisation). Il permet de garantir que ces applications sont tolérantes aux pannes, scalables à la demande, que les ressources sont utilisées de manière optimale. Il permet aussi la découverte et la visibilité entre les différentes applications de manière automatique et ainsi de pouvoir communiquer facilement entre elles, mais aussi de les rendre visibles pour le monde extérieur.

De ce fait, K8s est souvent défini comme un orchestrateur de conteneurs, mais ce n’est pas qu’ un simple orchestrateur de conteneurs, nous dirions  même qu’il permet d’éliminer le besoin d’orchestrer. En effet, “orchestrer”, suppose qu’on ordonne un ensemble d’actions que nous exécutons les unes à la suite des autres afin d’obtenir le résultat souhaité. L’architecture de K8s offre un ensemble de composants, dont des Schedulers et des Contrôleurs, qui vont agir continuellement de manière indépendante pour garantir que l’état courant de notre environnement (notre cluster) est bien l’état souhaité.

Le bon fonctionnement et l’automatisation de cette pseudo-orchestration sont donc garantis par 2 composants centraux, à savoir le Scheduler et le Controller Manager , dont nous évoquerons plus en détails dans la suite de cet article.

Le cœur de Kubernetes : le Scheduler et le Controller Manager

K8s est un logiciel Open Source, son code source est donc disponible et peut être étudié et modifié. Il est basé sur une architecture qui est extensible et offre donc la possibilité de personnaliser certains composants, dont certains seront abordés à la suite de cet article.

C’est un système distribué qui est basé sur un modèle client-serveur. La communication avec le serveur est assuré par l’”API Server”, qui sert d’interface de communication entre le client et le Cluster, à travers  le protocole HTTP . “L’API Server” est disponible sur un des nœuds maître, K8s permet de définir 1 à N nœuds “esclaves” et 1 à N nœuds “maître” mais un seul sera élu et les N-1 restants seront des esclaves mais restent hautement disponibles (HIGH AVAILABILITY mode)  pour être prêts à prendre le relais si jamais le nœud maître “courant” est hors service. Le Nœud maître occupe donc un rôle central .

L’API Server stockera chaque action effectuée par l’utilisateur dans l’unité de stockage, qui est le “etcd”, et qui permet de sauvegarder l’état courant du cluster (fig 2) .

Cependant, l’orchestration est automatisée grâce aux 2 composants qui interagissent continuellement avec l’API Server : Le Scheduler et le Controller Manager .

Le Scheduler (ordonnanceur)  : Qu’est ce qu’un scheduler et quel est son rôle dans le cas de kubernetes ?

Le Scheduler :

Un scheduler est un programme qui va organiser, l’exécution ou le déroulement de plusieurs processus (tâches)  en suivant une politique (algorithme) pour garantir un ordonnancement cohérent.

Dans le cas de kubernetes, il embarque un scheduler par défaut (“kube scheduler”) dont le rôle est de surveiller continuellement et passivement (grâce au pattern de l’ “Informer”) la création d’un nouveau Pod (état Pending fig. 3) par l’Api Server (fig. 2) et d’assigner un nœud pour gérer ce nouveau Pod. Le Scheduler de K8s permet donc d’allouer efficacement un nœud (= machine = host ) esclave à la création de chaque pod . On parle de relation maître esclave parce que le travail a effectué sur le pod sera pris en charge par le kublet dans le nœud esclave ( worker node ). Le Scheduler peut aussi assigner un nœud à un pod en prenant en compte des contraintes définies par l’utilisateur (affinité, anti-affinité, etc) :

Par exemple, déclarer que tel pod doit se trouver dans telle machine ou tel pod et tel pod doivent être alloués ensemble et inversement etc.

K8s permet, malgré l’efficacité de son Scheduler par défaut, de créer d’autres Schedulers pour gérer des pods et d’exécuter ces Schedulers en même temps (Multi-Scheduling).

Pour créer votre propre scheduler, nous vous conseillons cet article pour approfondir ce sujet.  https://banzaicloud.com/blog/k8s-custom-scheduler/

Le Controller Manager : gestionnaire de contrôleurs

Il permet de gérer un ensemble indépendant de contrôleurs définis par kubernetes, mais aussi la possibilité de définir ses propres contrôleurs.

Par définition, un contrôleur permet de surveiller l’état d’un environnement et d’exécuter une action si cet état a été altéré par un événement.  

Dans le cas de Kubernetes, il offre un ensemble de contrôleurs prédéfinis qui vont exécuter des boucles de contrôle pour réguler l’état du cluster . Ces contrôleurs peuvent opérer sur plusieurs objets comme  (Pods, Node, Endpoints, Services, Volume, Route, Cloud, etc). Cependant la plupart de ces contrôleurs ne sont pas utilisés par l’utilisateur directement sauf ceux qui agissent au niveau des pods, dont nous parlerons dans la suite de cet article. Chacun de ces contrôleurs connaît l’état désiré qu’il doit surveiller. Par exemple, le contrôleur “replicaSet” : permet de définir qu’un pod donné , devra exister en N exemplaires à tout instant et va donc interroger régulièrement l’ “Api Server” pour connaître l’état courant afin d’agir s’il est différent de l’état souhaité. De ce fait, si 1 pod parmi les N est hors service, ce contrôleur va donc réagir et recréer ce pod pour garder les N exemplaires attendus .

ReplicationController : son rôle est de maintenir un ensemble stable de répliques de pods à chaque instant ( sélection des pods concernés par des labels)  et de définir des templates pour la recréation de ces pods si leurs états a changé .

Replicaset : est la nouvelle version du “ReplicationController”, il offre une nouvelle manière de sélectionner les pods (sélection ensembliste) . Par exemple, labels in  [set of labels] ou labels not in [set of labels ] et il est recommandé de le coupler avec le contrôleur “Deployment” que nous verrons par la suite, pour avoir une fonctionnalité plus avancée .

Deployment : permet de faire une mise à jour déclarative des pods et des replicasets  . C’est un concept de plus haut niveau, qui offre des fonctionnalités plus évoluées comme créer un replicaset, supprimer un replicaset et adopter tout ses ressources dans le nouveau déploiement . Si on définit un état désiré dans un Deployment, il modifiera l’état actuel vers l’état le nouveau  état défini. Il permet ainsi de :

1. créer et mettre à jour un déploiement
2. revenir à un déploiement ultérieur
3. monter en charge
4. mettre pause et reprendre
5. supprimer d’anciens replicasets

StatefulSet : gère le déploiement et la montée en charge d’un ensemble de pods (avec la même spec)  et offre la garantie de maintenir un ordre dans la création ou suppression de ces pods en définissant une stratégie .Contrairement au contrôleur “Deployment”, il maintient l’identité de chacun de ses pods avec la même spec , par exemple un identifiant (adresse IP ) persistant qu’il garde après chaque ré-ordonnancement.

DaemonSet : S’assure que tous les Noeuds ou certains, exécutent une copie d’un pod donné . Dès qu’un noeud est ajouté au cluster, le pod défini dans ce contrôler est ajouté au nouveau Noeud :

• si délétion du noeud -> le pod est collecté par le Garbage Collector
• si supression d’un daemonset -> suppression des pods inhérents .

C’est un contrôleur qui pourrait être utile pour :

• avoir une collection de logs sur chaque noeud
• avoir un monitoring sur chaque noeud : Collectd, Prometheus .
• créer un stockage du cluster sur chaque noeud comme : glusterd, ceph

Garbage Collection : son rôle est de supprimer les objets qui n’ont plus de propriétaires . Dans K8s, certains objets sont les propriétaires (parents) d’autres objets,par exemple : un replicaset crée un ensemble de pods, mais qu’est ce qui se passe après une suppression de ce replicaset ?

Le GC va permettre de spécifier une stratégie( “propagationPolicy”) pour la suppression d’objets dépendants . Par défaut , K8s laissent ses objets en orphan (orphelins)

• orphan
• foreground ( objets dépendants, puis le propriétaire)
• background ( objet propriétaire, puis ses dépendances )
• cascade

curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \

-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \-H "Content-Type: application/json"

TTL Controller (for finished ressources) : Time to live : permet de limiter la durée de vie des objets ressources qui ont fini de s’exécuter ( Pour l’instant K8s ne supporte que les “jobs” ) .

Jobs : crée 1 à N pods et s’assure qu’un nombre spécifique ou la totalité de ces pods ont réussi leur exécution avant de nettoyer les pods créés (.spec.completions) :

• sa suppression entraîne aussi celle  des pods créés
• permet aussi de faire du parallélisme entre pods pour exécuter une tâche (.spec.parallelism ) .

CronJob : Tout comme “Cron” le fameux gestionnaire des tâches devant être exécutés à un moment précis (Linux), ce contrôleur permet de créer un job qui sera exécuté à un moment donné et utilise aussi le format Cron.

Kubernetes permet donc non seulement d’automatiser le déploiement, la scalabilité et la résistance aux pannes des applications conteneurisées, mais il offre aussi d’autres fonctionnalités qui facilitent l’orchestration des conteneurs . Mais cette orchestration est vraiment pousser à son paroxysme, dans le sens où K8s automatise et rend transparent, les actions de l’utilisateur (administrateur) . L ‘utilisateur spécifie l’état souhaité d’un objet et k8s fait le nécessaire pour atteindre l’état désiré et le maintenir continuellement, grâce à ses différents composants et à son architecture robuste, extensible et efficace.