Kubernetes (K8s)

Définition

Kubernetes exécute des systèmes distribués de façon résiliente en automatisant la gestion des conteneurs. Il intervient principalement dans un contexte de mise à l’échelle (scaling) et de gestion des défaillances.

---

Fonctionnalités & Philosophie

Les piliers du système

• Networking : Exposition réseau des conteneurs et Load Balancing intégré.
• Stockage : Gestion automatisée des volumes de stockage.
• Auto-remplissage (Bin Packing) : Optimisation des ressources (RAM/CPU) en plaçant les conteneurs sur les nœuds les plus adaptés.
• Self-healing : Redémarrage automatique des conteneurs en cas d’échec via des Health Checks.
• Sécurité : Gestion des secrets et des configurations (découplage des données sensibles et des images).

Philosophie : Le mode Déclaratif

Kubernetes repose sur une approche déclarative : on ne lui dit pas comment faire, mais quel état on souhaite obtenir. Le système travaille ensuite pour maintenir cet état (réconciliation).

Architecture du Cluster

Un cluster se divise en deux parties distinctes : le Control Plane (le cerveau) et les Nodes (les bras).

graph TD
    subgraph Control_Plane ["Control Plane (Master)"]
        API[API Server]
        ETCD[(etcd - Store)]
        SCHED[Scheduler]
        CM[Controller Manager]
    end

    subgraph Worker_Nodes ["Worker Nodes"]
        Node1[Node 1]
        Node2[Node 2]
    end

    API <--> ETCD
    API <--> SCHED
    API <--> CM
    Node1 <--> API
    Node2 <--> API

Rôles des Composants

Composant	Rôle
API Server	Point d’entrée central (REST/CLI). Tout passe par lui.
etcd	Base de données clé-valeur stockant l’état total du cluster.
Scheduler	Décide sur quel nœud un nouveau Pod doit être déployé.
Controller Manager	Boucle de régulation qui surveille et corrige l’état du cluster.
Kubelet	Agent tournant sur chaque nœud pour s’assurer que les conteneurs tournent.
Kube-proxy	Gère les règles réseau et l’acheminement du trafic vers les Pods.

Les Workloads (Charges de travail)

Le Pod : L’unité de base

Le Pod est le plus petit objet déployable. Il peut contenir un ou plusieurs conteneurs.

graph TD
    subgraph Pod ["Pod (IP Unique)"]
        direction TB
        C1[Conteneur A]
        C2[Conteneur B]
        Vol[(Volumes Partagés)]
        Net([Network Namespace / Localhost])
        
        C1 --- Vol
        C2 --- Vol
        C1 --- Net
        C2 --- Net
    end

Attention aux Pods Orphelins

Un Pod créé directement avec kubectl run n’est pas géré par un contrôleur. S’il s’arrête ou si le nœud tombe, il ne sera pas redémarré. Utilisez toujours un contrôleur (Deployment, etc.).

Gestionnaires de Pods (Controllers)

Le Pod Template

Les contrôleurs utilisent des Pod Templates (spécifications YAML) pour savoir comment recréer des Pods à l’identique.

1. Deployment : Pour les applications sans état (stateless). Les Pods sont interchangeables.
2. StatefulSet : Pour les applications avec état (Bases de données). Garantit l’identité du Pod et l’attachement au stockage.
3. DaemonSet : Exécute une copie du Pod sur chaque nœud du cluster (utile pour les logs ou le monitoring).

Networking & Stockage

• IP unique par Pod : Tous les conteneurs d’un même Pod partagent la même adresse IP.
• Communication Inter-Conteneur : Se fait via localhost à l’intérieur d’un Pod.
• Communication Inter-Pod : Se fait via le réseau IP du cluster (pas d’IPC direct entre Pods différents).

Persistance

Par défaut, le stockage d’un conteneur est éphémère. Il faut définir des Volumes pour que les données survivent au redémarrage des conteneurs.

Commandes utiles

• Lister les pods : kubectl get pods -A
• Lister les déploiements : kubectl get deployments -A
• Appliquer une config : kubectl apply -f manifest.yaml