Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Kubernetes
  3. Fonctionnement de Kubernetes
Extrait - Kubernetes Mise en œuvre d'un cluster et déploiement de microservices (2e édition)
Extraits du livre
Kubernetes Mise en œuvre d'un cluster et déploiement de microservices (2e édition) Revenir à la page d'achat du livre

Fonctionnement de Kubernetes

Contenu du livre

1. Objectifs

L’objectif principal de ce livre est de démontrer le fonctionnement de Kubernetes. Le lecteur - typiquement un développeur ou un administrateur système ou applicatif - découvrira dans la suite une façon moderne de déployer des applications informatiques sur une architecture distribuée, c’est-à-dire en utilisant plusieurs serveurs pour s’affranchir des limites de capacité d’une machine seule. Limiter Kubernetes à une couche d’indirection avec le matériel serait toutefois très réducteur et les nombreuses autres fonctionnalités d’exposition, de gestion de la robustesse et de la charge seront également montrées, car c’est l’ensemble de ces capacités qui font que Kubernetes est aujourd’hui en train de devenir le produit standard dans sa catégorie, éliminant pratiquement toute concurrence de par son étendue fonctionnelle et sa qualité.

Bien que le sujet d’étude soit principalement la technologie Kubernetes, son lien avec Docker et d’autres outils majeurs du monde open source est tel que ces autres outils seront également étudiés partiellement dans les exemples utilisés.

Le livre a comme objectif secondaire de faire découvrir également au lecteur le support par Microsoft de Kubernetes et ses particularités. Enfin, il a pour ambition de partager des retours d’expérience et des bonnes pratiques industrielles sur Kubernetes.

2. Prérequis de lecture

Le présent ouvrage est à réserver aux lecteurs ayant déjà une expérience d’utilisation courante de Docker. Ainsi, il ne comportera pas d’explications sur la grammaire Dockerfile ni sur les commandes standards de Docker. De même, les concepts soutenant le fonctionnement de Docker ne seront pas abordés, car considérés comme connus.

Si le lecteur ne connaît pas, par exemple, la différence entre un conteneur ou une image...

À quoi sert Kubernetes ?

1. Les besoins en déploiement applicatif

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à...

Historique de Kubernetes

1. Aux origines : Google Borg

Nous avons abondamment décrit plus haut les besoins auxquels Google a dû faire face pour mettre en œuvre ses applications web grand public et donc massivement distribuées. La solution mise en œuvre a commencé en interne avec des outils "cousus main" qui se sont progressivement agrégés sous le nom de Borg.

Borg servait à gérer l’énorme cluster de machines possédées par Google et mises en œuvre pour supporter ses services web. Pendant longtemps, le secret a été gardé sur son fonctionnement et même sur son existence et ce n’est qu’en 2015 qu’un article de recherche a été publié sur le sujet. Cet article s’intitule Large-scale cluster management at Google with Borg et peut être téléchargé gratuitement depuis la page https://ai.google/research/pubs/pub43438.

Borg est resté un projet interne de Google, qui n’a pas été diffusé tel quel. Toutefois, Kubernetes a tiré les enseignements de Borg et hérite de toute l’expérience acquise par Google sur le sujet de la gestion d’applications massives en ligne. Le projet Kubernetes est d’ailleurs maintenu par de nombreuses personnes qui ont présidé initialement à la mise en œuvre de Borg. L’article explique en particulier qu’une des difficultés de Borg était le fait de ne disposer que de l’adresse IP de la machine hôte, ce qui obligeait à gérer le provisionnement de ports multiples pour les différentes charges de travail dont la répartition est l’objectif principal du système. Ceci explique par exemple que dans Kubernetes, une adresse IP soit affectée à chaque pod (nous reviendrons plus loin sur ce concept), permettant de lever cette difficulté en rendant plus simple la gestion des ports.

Kubernetes lui-même est apparu en 2014...

Principes d’architecture de Kubernetes

1. Mise en cluster

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 :

  • distribuer les tâches de manière efficace ;

  • pouvoir adresser des tâches à une autre machine si l’une d’entre elles ne répond pas ou n’est pas en mesure de réaliser ladite tâche ;

  • être en mesure de savoir dynamiquement quelles sont les machines sur lesquelles le système peut compter, ce qui nécessite de pouvoir en ajouter et en retirer simplement ;

  • garder une certaine robustesse du maître (qui, s’il n’est pas correctement secondé, peut constituer un point central d’échec), par exemple en laissant une autre machine prendre le rôle de maître si le précédent est défaillant ;

  • stocker les données de l’état du cluster ;

  • définir les règles de sécurité des déploiements ;

  • gérer les autorisations dans le cluster et pour les utilisateurs ;

  • etc.

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. 

Il est à noter que par défaut, les masters ne participent pas aux tâches (dites "jobs") et ne réalisent donc pas de travail applicatif à proprement parler. Toutefois, il est possible de paramétrer un cluster de petite taille pour que les masters exécutent également des charges applicatives, de façon à mieux utiliser les ressources. C’est bien sûr le cas dans la situation particulière (mais fréquente pour les tests) d’un cluster composé d’une seule machine.

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...