introduction à kubernetes : concepts et architecture

Objectifs

• Comprendre pourquoi on a besoin d’un “orchestrateur” après avoir maîtrisé Docker.
• Définir les concepts fondamentaux de Kubernetes : Cluster, Node, Pod et Control Plane.
• Visualiser l’architecture de base d’un cluster Kubernetes.
• Saisir la différence entre une approche impérative et l’approche déclarative de Kubernetes.

Le problème que Kubernetes résout

Docker est fantastique pour créer et lancer un conteneur sur une machine. Mais que se passe-t-il en production ?

• Comment lancer une application sur 10 serveurs différents ?
• Comment s’assurer que si un serveur tombe en panne, les conteneurs sont automatiquement redémarrés ailleurs ?
• Comment augmenter ou diminuer le nombre de conteneurs en fonction de la charge (scalabilité) ?
• Comment mettre à jour une application sans interrompre le service ?

Gérer tout cela manuellement est impossible à l’échelle. C’est le rôle d’un orchestrateur de conteneurs, et Kubernetes (souvent abrégé en k8s) est le standard de facto de l’industrie.

Concepts clés de Kubernetes

1. Cluster

Le Cluster est l’ensemble de toutes les machines que Kubernetes gère. C’est votre “ferme de serveurs”.

2. Node (Nœud)

Un Node est une seule machine, qu’elle soit physique ou virtuelle, qui fait partie du cluster.

3. Control Plane (Plan de Contrôle)

C’est le cerveau du cluster. Il est composé de plusieurs services qui prennent les décisions globales :

• Il surveille l’état du cluster.
• Il planifie sur quel Node une application doit s’exécuter.
• Il réagit aux pannes. En général, le Control Plane tourne sur des machines dédiées (les “master nodes”).

4. Worker Node (Nœud de Travail)

Ce sont les machines qui font le travail “utile” : elles exécutent vos applications.

5. Pod

C’est la plus petite unité que vous pouvez déployer dans Kubernetes.

• Un Pod représente un groupe d’un ou plusieurs conteneurs.
• Ces conteneurs partagent le même réseau et le même stockage.
• Dans 95% des cas, un Pod contient un seul conteneur principal.

Pensez à un Pod comme une “enveloppe” autour de votre conteneur Docker, qui lui donne une adresse IP et des ressources dans le cluster.

Architecture simplifiée d’un cluster

L’approche déclarative : Décrire l’état désiré

La grande force de Kubernetes est son approche déclarative.

• Vous ne dites pas : “Lance ce conteneur sur la machine X”.
• Vous dites : “Je veux que 3 répliques de mon application web tournent en permanence, avec cette version de l’image Docker”.

Vous décrivez l’état final souhaité dans des fichiers de configuration (généralement en YAML). C’est ensuite le travail du Control Plane de faire tout le nécessaire pour que la réalité corresponde à votre déclaration. Si un Node tombe en panne, le Control Plane le verra et redémarrera les Pods manquants sur un autre Node pour revenir à l’état désiré.

Bonnes pratiques pour commencer

• Utilisez un cluster managé. Les fournisseurs cloud (Google avec GKE, Amazon avec EKS, Microsoft avec AKS) proposent des services Kubernetes où ils gèrent la complexité du Control Plane pour vous. C’est la meilleure façon de commencer en production.
• Utilisez des outils locaux pour le développement. Des outils comme minikube ou k3d vous permettent de lancer un mini-cluster Kubernetes complet sur votre machine locale pour tester vos configurations.
• Apprenez kubectl. C’est l’outil en ligne de commande officiel pour interagir avec un cluster Kubernetes.

Exercices

1. Installez les outils locaux :

   • Suivez un guide pour installer kubectl, l’outil en ligne de commande.
   • Installez un cluster Kubernetes local comme minikube ou k3d.
   • Lancez votre cluster local.

2. Inspectez votre cluster :

   • Une fois votre cluster local démarré, exécutez la commande kubectl get nodes. Elle devrait vous afficher la liste des “nœuds” de votre cluster (probablement un seul).
   • Exécutez kubectl get pods -A pour voir tous les pods qui tournent sur votre cluster (principalement des composants système pour l’instant).