Archives par mot-clé : kubelet

Kubernetes pour les débutants

Kubernetes et les conteneurs

Pour comprendre ce qu’est Kubernetes, il faut d’abord savoir ce qu’est un conteneur :

  • En gros, la virtualisation par conteneur est une méthode de cloisonnement au niveau de l’OS basé sur la technologie de virtualisation Linux LXC, pour Linux Containers.
  • Le principe est de faire tourner des environnements Linux isolés les uns des autres dans des conteneurs tout en se partageant le même noyau Linux, le Kernel donc.

Le conteneur virtualise seulement l’environnement d’exécution (comme le processeur, la mémoire vive ou le système de fichier…) et ne virtualise donc pas la machine entière comme pour une VM (Pas de virtualisation d’OS inviténotamment dans un conteneur par rapport à une VM).

Le conteneur est donc plus léger que la VM, ce qui permet de créer beaucoup plus de conteneurs que de VM sur un même serveur. Docker est un exemple de technologie de virtualisation par container.

A noter que pour le reste de la vidéo, je vais prendre l’exemple des conteneurs Docker pour illustrer les fonctionnalités de kubernetes.

Et justement comme un conteneur est fortement relié au kernel, le conteneur n’a pas “conscience” de ce qui se passe en dehors de ce kernel et de la machine hôte.

Et c’est là que Kubernetes intervient :

  • c’est Kubernetes qui va apporter l’orchestration et la gestion des conteneurs sur des clusters de serveurs
  • Dis autrement, Kubernetes permet ainsi de prendre en charge plusieurs kernel et pouvoir gérer les conteneurs sur ces différents serveur hôtes Linux (qu’ils soient physique ou virtuel d’ailleurs). Ces clusters peuvent couvrir des hôtes situés dans des clouds publics, privés ou hybrides.
Les fonctionnalités de Kubernetes

Les fonctionnalités d’orchestration de Kubernetes vous permettent de :

  • créer des services applicatifs ( que ce soir front end ou backend) et ceci sur plusieurs conteneurs,
  • planifier l’exécution de ces conteneurs dans un cluster,
  • garantir leur intégrité au fil du temps.
  • assurer leur monitoring

Avec Kubernetes, le développeur n’ a plus à s’occuper de la gestion des VM, il à disposition directement son environnement d’exécution (qui est le conteneur) pour y déployer son code, et c’est kubernetes qui s’occupe des couches d’infrastructures sous-jacentes.

Avec Kubernetes, le développeur n’a plu à s’occuper de la partie infrastructure, il n’a pas besoin de savoir où tournent leur applications, l’infra sous-jacente est masquée pour le développeur

Architecture de Kubernetes

Il y a d’abord le Kubernetes Master qui est le serveur contrôlant les nodes : ce sont des noeuds esclaves et ce sont des machines hébergeant les hôtes Docker qui exécutent les tâches qui leur sont assignées. Au sein d’un node tourne un pod. Le pod est un environnement d’exécution d’un ou plusieurs conteneur(s) Docker.

C’est le master qui va dire quel node va faire tourner un pod non ordonnancé en se basant sur la disponibilité des ressources. Le master gère l’utilisation des ressources sur chaque node afin de s’assurer que la charge de travail n’est pas en excès par rapport aux ressources disponibles.

Pour accomplir cet objectif, l’ordonnanceur doit connaître les ressources disponibles et celles actuellement assignées sur les serveurs. Et c’est ces information qui sont apporté par les kubelets. Kubelet est un composant exécuté sur des nœuds et qui s’assure que les conteneurs définis ont démarré et fonctionnent comme comme prévus lors de leur conception. Si un noeud tombe par exemple, c’est Kubelet qui va le signaler au master.

Et c’est le master qui vérifie le nombre de copies identiques demandée d’un pod qui doivent s’exécuter dans le cluster. Le master gère la résilience des pod.

 

Voyons de plus près la notion de  pod :

  • Cet environnement d’exécution peut contenir un ou plusieurs conteneur(s) Docker (on va déployer deux containers sur un même POD s’il est nécessaire de partager des ressources locales).
  • En effet Tous les conteneurs d’un pod partagent une même adresse IP, un même nom d’hôte et les même ports réseau et d’autres ressources.
  • La scalabilité horizontale sera réalisée en instanciant l’application dans de multiples pods,

Un volume c’est un espace de stockage accessible à tous les conteneurs sur un pod.

Il repond à 2 besoins :

  • le premier c’est le besoin de préserver les données au delà du cycle de vie d’un conteneur : les données et fichiers dans un conteneur sont éphémères, donc si des données utilisées par les conteneurs doivent être conservés au dela du cycle de vie d’un contneeur, ces données seront stocké dans le volume.
  • Ensuite, le volume est necessaire pour Le partage des données entre 2 conteneurs : quand plusieurs conteneurs s’exécutent dans un même pod, il est souvent nécessaire de partager les fichiers (et données) entre eux. Et c’est réalisé via le volume.

Passons maintenant à la notion de service :

  • Le « Service » est un point d’entrée permettant un accès « load-balancé » à un groupe de containers identiques, autrement dit c’est une VIP ou Virtual IP.
  • Kubernetes fournit un service de routage en assignant une adresse IP et un nom de domaine à un service, et équilibre la charge du trafic vers les différents pods.
  • Les requêtes de service sont alors transférés par Kubernetes vers un des pods.

 

Fonctionnement de Kubernetes

Kubernetes s’exécute au-dessus de l’OS et interagit avec les pods de conteneurs qui s’exécutent sur les nœuds.

Le master Kubernetes reçoit les commandes de la part d’un administrateur (ou d’une équipe DevOps) et relaie ces instructions aux nodes. Comme on l’a vu tout à l’heure, ce système de transfert fonctionne avec une multitude de services et choisit automatiquement le nœud le plus adapté pour chaque tâche. Il alloue ensuite les ressources aux pods désignés dans ce nœud pour qu’ils effectuent la tâche requise.

Lorsque le Kubernetes master planifie un pod dans un nœud, le kubelet de ce nœud ordonne à Docker de lancer les conteneurs spécifiés. Docker démarre/arrête les conteneurs, comme d’habitude.

Le kubelet collecte ensuite en continu le statut de ces conteneurs via Docker et rassemble ces informations sur le serveur master.

On voit donc qu’avec Kubernetes, les ordres proviennent d’un système automatisé et non plus d’un administrateur qui assigne manuellement des tâches à tous les nœuds pour chaque conteneur.