Salut,

Aujourd'hui on va parler de Kubernetes, ou K8S pour les intimes

C'est un sujet qui fait peur à tout le monde, même aux plus expérimentés

En fait, c'est pas l'outil qui fait peur, mais son implémentation

Mais on va voir tout ça pour que tu puisses augmenter ta culture générale informatique sans avoir besoin de devenir expert.

K8S

K8S est un Open Source Container Orchestration Tool
À la base, développé par Google

Il aide à gérer des App composées de dizaines voir de centaines de conteneurs.

Ces conteneurs peuvent être dans plusieurs environnements de déploiement différents en même temps (serveur physique, virtuel, cloud)

C'est la raison pour laquelle ça fait peur : K8S gèrent des centaines de docker dans des infras totalement mixtes.
C'est assez vertigineux

À quoi sert K8S ?

Et qu'est ce que fait un outil d'orchestration ?

L'essor des micro services a multiplié le nombre de conteneurs à déployer.
On veut souvent avoir la possibilité de lancer plusieurs fois la même image pour avoir plus de perf, puis de les éteindre en période creuse par exemple

Tout ça fait que l'on doit gérer des centaines de conteneurs.
Certaines app et archi gèrent plusieurs milliers de conteneurs.

À la main à gérer, même pour les OPS, c'est impossible (même avec des scripts et tout)

En plus quand tu commences à mettre ces conteneurs un peu partout sur la planète, c'est l'enfer pour tout faire communiquer

D'où la nécessité d'avoir un outil pour orchestrer tout ça

Quelles sont les fonctionnalités d'un orchestrateur ?

- Il doit permettre d'avoir de la Haute Disponibilité : c'est à dire garantir que ton APP ne soit jamais arrêtée
- Il doit permettre de la Scalabilité : c'est à dire maintenir les performances les plus hautes en permanence
- Il doit permettre le Disaster recovery : c'est-à-dire qu'en cas de sinistre important, tu peux faire repartir ton APP rapidement et dans le dernier état stable

Quelle est l'architecture K8S ?

Il y a un Master node
Puis des Worker : ce sont des serveurs avec le process Kubelet qui tourne dessus
Les kubelet permettent la communication entre les noeuds et c'est eux qui vont déclencher des actions

Sur chaque worker, il y a aussi Docker d'installé et des conteneurs tournent dessus

Donc c'est sur les workers que ton app tourne réellement

Sur le master, il n'y a que les process Kubenetes importants qui servent à piloter l'ensemble des workers (qui forment un cluster) :

- Api Server

C'est le point d'entrer pour piloter le cluster dans son ensemble
K8S Dashboard l'utilise
Tu peux faire appel à l'API pour déclencher des actions automatiques (CICD par exemple )
La ligne de commande permet aussi de configurer le cluster et utilise l'API.

- Controler Manager

Il garde les traces de tout ce qu'il se passe sur le cluster

- Scheduler

Il se charge de répartir la charge des workers

- ETCD

C'est la base de données qui contient la conf et l'état complet du cluster

- Virtual Network

Sa mission est de faire en sorte que l'on voit l'ensemble des worker comme une seule et grosse machine
Dont on a additionné toutes les ressources

Généralement le master est une petite machine et les worker des bêtes de courses pour gérer toute la charge

Mais le master est plus important : sans lui, tu perds la main sur ton cluster
En production, tu peux mettre 2 masters qui se redondent mutuellement

Pods et Services

Le Pod est l'élément unitaire que tu manipules dans K8S

En simplifiant, un Pod est un emplacement pour un conteneur

Donc 1 pod = 1 app

Ex : Ta bdd est une app dans un conteneur donc ça utilise un pod

Chaque pod, grâce au virtual network possède sa propre IP sur le réseau

Un pod est donc un peu comme un serveur auto suffisant

Dans K8S, tu ne configures pas de conteneur.

Tu utilises les pods qui abstraient donc la technologie de conteneur dessous

Les pods sont par nature éphémères. Ils vivent et meurent et sont recréés dynamiquement.

Ce qui fait que leurs IPs changent toujours

Dans une APP, si l'ip de ta bdd change sans que tu saches, y'a plus rien qui marche.

Il y a un composant K8S qui s'appelle Services qui s'occupe de ça pour toi.

Au lieu d'utiliser des IPs il utilise un nom de service pour faire communiquer les pods entre eux

Quand le Pod meurt, le Service reste. Le nouveau Pod est rattaché au Service et tout continue de fonctionner.

Un mot sur la conf

La conf se fait sur le master via l'UI, l'API ou la ligne de commande

On utilise YAML ou JSON

C'est du déclaratif : je dis le résultat que je veux et K8S se débrouille pour l'atteindre

Voilà. Tu as la base pour comprendre K8S et peut-être commencer à te faire un cluster avec 3 Pods.