Fonctionnement de Kubernetes

a. Montée en charge par répartition

Aux origines de Kubernetes (ou plutôt de son ancêtre Borg, que nous évoquerons plus loin) était le besoin de gérer des montées en charge massives de ses applications par Google. La société étant un des chantres des applications web et entrant dans la phase d’adoption de masse qu’on lui connaît aujourd’hui, il lui était nécessaire de mettre en place des outils permettant de gérer efficacement des applications logicielles très largement distribuées.

En effet, il est possible de gérer avec des méthodes traditionnelles des applications déployées sur quelques dizaines, voire quelques centaines de serveurs, mais passer à des milliers de serveurs requérait une approche complètement nouvelle du déploiement et même de la façon de développer ces applications. La répartition de la charge, pour ne citer qu’une problématique, ne peut pas être simplement linéaire, car les serveurs ont toutes les chances d’être physiquement différents. De plus, sur des ensembles aussi larges, il est assez probable qu’au moins une machine aura un problème à un instant donné et cela nécessite d’avoir pensé dès le début une architecture supportant ce cas de figure sans que cela cause une défaillance de l’ensemble.

Google a de fait été un précurseur dans ces nouvelles méthodes de déploiement applicatif, poussé par ses propres besoins comme Gmail ou d’autres applications grand public. C’est ainsi par exemple que le langage Go est apparu dans les équipes Google, pour gérer de manière efficace le développement d’applications distribuées. Et pour ce qui est du déploiement, des techniques supplémentaires ont également été conçues qui ont abouti progressivement à ce qui est aujourd’hui connu sous le nom de Kubernetes.

b. Mises à jour progressives

En plus de ce besoin nouveau de passage à l’échelle massif, un besoin de progressivité des mises à jour logicielles est apparu. En effet, il était impossible sur de tels ensembles de garantir que toutes les machines allaient passer en version supérieure dans un laps de temps contraint. De plus, devant la taille du public de ces applications et son niveau d’exigence, tout arrêt du service est absolument inenvisageable. La quantité massive de serveurs est toutefois un avantage, car elle permet alors de lisser la mise à jour des applicatifs en opérant de manière progressive. Encore faut-il toutefois que les applications ainsi que l’infrastructure le permettent.

Du point de vue des applications, c’est un des avantages de l’approche stateless de faire en sorte que chaque requête soit vue comme indépendante des précédentes par défaut. De plus, les développeurs savent programmer des applications sans état. Ainsi, le fait qu’un même client soit servi par plusieurs serveurs au fur et à mesure de ses besoins est possible, pourvu que la compatibilité ascendante soit également au rendez-vous.

Pour ce qui est de l’infrastructure, il reste nécessaire de mettre au point une architecture incluant dès sa conception la capacité de mettre à jour les serveurs de façon ordonnée et progressive, tout en maîtrisant la vitesse de cette mise à jour. L’approche extrême consistant à traiter un serveur après l’autre est en effet aussi inenvisageable que l’autre extrême, à savoir basculer tous les serveurs logiques d’un seul coup sur la nouvelle version applicative. Là encore, les techniques mises en œuvre dans Kubernetes proviennent des technologies utilisées pour maîtriser la mise à jour progressive des applications distribuées.

c. Composition applicative robuste

Enfin, au-delà...

a. Principes

Avant même de parler de déploiement d’applications, Kubernetes a besoin de mettre en œuvre un cluster, c’est-à-dire de réunir des machines séparées dans un ensemble unique et de façon qu’il apparaisse alors comme une seule et unique ressource. La plupart des clusters se basent sur un principe relativement simple dit "maître/esclave", avec une machine qui pilote les autres et ces dernières qui réalisent les tâches confiées au système. Bien entendu, la gestion du cluster est beaucoup plus complexe qu’une simple délégation des tâches, et il convient en particulier de :

Pour cela, Kubernetes met en œuvre un système complexe de nœuds dans le cluster avec des "masters" et des "nodes" ; les masters hébergeant des services d’infrastructure permettant de gérer et de déployer les applications et les nodes recevant les charges applicatives, autrement dit les applications à exécuter. 

b. Les masters et leurs composants

Le master, ou plutôt les masters car il est de bon ton d’en mettre plusieurs en œuvre afin d’assurer la robustesse de la gestion du cluster, sont en charge de l’orchestration, c’est-à-dire de la répartition des tâches à effectuer par les nodes. 

C’est le master qui juge de l’équilibre du cluster et décide s’il vaut mieux déplacer une charge sur une machine faiblement occupée (avec ce que cela comporte comme inconvénients en temps de réaction ou en perte momentanée de ressources) ou s’il vaut mieux laisser l’ensemble travailler en léger déséquilibre.

Les masters ont également la charge de s’observer les uns les autres et, à l’aide d’un système de consensus, de désigner lequel a la charge du travail d’orchestration. Lorsque ce master a été élu, les autres se gardent informés de l’état du cluster et sont prêts à intervenir à la moindre défaillance du master principal. Pour effectuer toutes ces tâches, les masters s’appuient sur différents services d’infrastructure de Kubernetes, que nous allons détailler ci-dessous. 

Le premier de ces services est API-Server. Il s’agit d’un composant qui expose une API REST en SSL/TLS. Il agit comme point d’entrée pour la gestion du cluster. Cette API sera utilisée par les utilisateurs du cluster (administrateurs ou développeurs) pour visualiser, créer et supprimer...