Kubernetes

Kubernetes semble magique jusqu'au premier problème en production. Comprendre l'architecture interne vous permet de diagnostiquer rapidement — "mon pod ne démarre pas" devient "le scheduler n'a pas trouvé de nœud avec assez de mémoire" ou "le kubelet ne peut pas puller l'image".

Vue d'ensemble

┌──────────────────────────────────────────────────────────────┐
│                        CONTROL PLANE                         │
│                                                              │
│  ┌─────────────┐  ┌───────────┐  ┌──────────────────────┐  │
│  │  API Server │  │ Scheduler │  │  Controller Manager  │  │
│  │  (kube-     │  │ (kube-    │  │  (kube-controller-   │  │
│  │  apiserver) │  │ scheduler)│  │   manager)           │  │
│  └──────┬──────┘  └─────┬─────┘  └──────────────────────┘  │
│         │               │                                    │
│  ┌──────▼───────────────▼──────────────────────────────┐   │
│  │                    etcd                              │   │
│  │          (base de données distribuée)                │   │
│  └──────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────┘
 
┌───────────────────┐  ┌───────────────────┐  ┌─────────────┐
│    Worker Node 1  │  │    Worker Node 2  │  │  Worker N   │
│                   │  │                   │  │             │
│  ┌─────────────┐  │  │  ┌─────────────┐  │  │    ...      │
│  │   kubelet   │  │  │  │   kubelet   │  │  │             │
│  ├─────────────┤  │  │  ├─────────────┤  │  │             │
│  │ kube-proxy  │  │  │  │ kube-proxy  │  │  │             │
│  ├─────────────┤  │  │  ├─────────────┤  │  │             │
│  │  Container  │  │  │  │  Container  │  │  │             │
│  │   Runtime   │  │  │  │   Runtime   │  │  │             │
│  │ (containerd)│  │  │  │ (containerd)│  │  │             │
│  ├─────────────┤  │  │  ├─────────────┤  │  │             │
│  │  Pod A      │  │  │  │  Pod C      │  │  │             │
│  │  Pod B      │  │  │  │  Pod D      │  │  │             │
│  └─────────────┘  │  │  └─────────────┘  │  │             │
└───────────────────┘  └───────────────────┘  └─────────────┘

Control Plane

API Server (kube-apiserver)

Le point d'entrée unique pour toutes les interactions avec le cluster. kubectl, les autres composants, et vos applications communiquent tous via l'API Server.

Tout passe par lui : créer un pod, lire un secret, déclencher un déploiement. Il valide les requêtes, gère l'authentification/autorisation, et persiste l'état dans etcd.

# kubectl est un client de l'API Server
kubectl get pods
# équivalent à :
curl https://api-server:6443/api/v1/namespaces/default/pods \
  -H "Authorization: Bearer <token>"

En production : l'API Server tourne en haute disponibilité (3 réplicas minimum). Si l'API Server est down, les pods continuent de tourner mais vous ne pouvez plus rien changer.

etcd

Base de données clé-valeur distribuée (inspirée de Raft) qui stocke tout l'état du cluster : pods, services, deployments, secrets, configmaps.

# Voir les données etcd (depuis un nœud control plane)
ETCDCTL_API=3 etcdctl get / --prefix --keys-only | head -20
# /registry/deployments/default/mon-app
# /registry/pods/default/mon-app-abc123
# /registry/services/specs/default/mon-service

Point critique : etcd est la seule source de vérité. Si etcd est perdu sans backup — votre cluster est perdu. Sauvegardez etcd régulièrement.

# Backup etcd
etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db
 
# Restaurer
etcdctl snapshot restore /backup/etcd-2026-06-19.db

En K3s, etcd peut être remplacé par SQLite (single-node) ou par un etcd externe (cluster).

Scheduler (kube-scheduler)

Le scheduler décide sur quel nœud faire tourner chaque pod. Il prend en compte :

• Ressources disponibles : CPU et mémoire demandés par le pod vs disponibles sur chaque nœud
• Taints et tolerations : règles d'exclusion (ex : "ce nœud est réservé aux pods GPU")
• Node selectors et affinity : préférences de placement (ex : "placer ce pod sur un nœud en zone EU")
• Pod anti-affinity : éviter de mettre deux réplicas du même service sur le même nœud

Pod à placer → Filtrage des nœuds éligibles → Scoring → Nœud choisi

Si aucun nœud n'est éligible, le pod reste en état Pending jusqu'à ce qu'un nœud le devienne.

Controller Manager (kube-controller-manager)

Processus unique qui embarque des dizaines de controllers. Chaque controller surveille l'état actuel du cluster et le réconcilie avec l'état désiré.

Exemples de controllers :

• ReplicaSet controller : maintient le nombre voulu de réplicas d'un pod
• Deployment controller : gère les rolling updates et rollbacks
• Node controller : détecte les nœuds morts et marque leurs pods comme Unknown
• Service Account controller : crée les service accounts par défaut dans chaque namespace

Principe de réconciliation : K8s fonctionne en boucle continue. Vous déclarez un état désiré (3 réplicas) ; les controllers font en sorte que l'état réel corresponde. Si un pod crashe, le controller en crée un nouveau.

Worker Nodes

kubelet

Agent qui tourne sur chaque nœud worker. Il reçoit les instructions de l'API Server et pilote le container runtime pour démarrer/arrêter les conteneurs.

# Vérifier l'état du kubelet
systemctl status kubelet
 
# Logs kubelet
journalctl -u kubelet -f

Le kubelet gère aussi les probes — il vérifie périodiquement si vos conteneurs sont sains via des liveness, readiness et startup probes.

kube-proxy

Composant réseau sur chaque nœud. Il maintient les règles iptables (ou IPVS) qui permettent aux Services Kubernetes de router le trafic vers les pods appropriés.

Quand vous créez un Service, kube-proxy met à jour les règles iptables sur tous les nœuds pour que les paquets à destination de l'IP virtuelle du Service soient redirigés vers un pod healthy.

Container Runtime

Le processus qui fait réellement tourner les conteneurs. Kubernetes supporte tout runtime compatible CRI (Container Runtime Interface) :

• containerd : le standard actuel (Docker Engine l'utilise aussi en interne)
• CRI-O : runtime minimaliste spécifique K8s
• Docker : déprécié depuis K8s 1.24 (mais containerd sous le capot)

# Vérifier le runtime sur un nœud
kubectl describe node mon-node | grep "Container Runtime"
# Container Runtime Version: containerd://1.7.13

Le cycle de vie d'un pod — bout en bout

Quand vous faites kubectl apply -f deployment.yaml :

1. kubectl → API Server
   Requête HTTPS authentifiée, manifeste validé
 
2. API Server → etcd
   L'objet Deployment est persisté
 
3. Deployment Controller (dans Controller Manager)
   Détecte le nouveau Deployment, crée un ReplicaSet
 
4. ReplicaSet Controller
   Détecte que 0/3 pods existent, demande la création de 3 pods
 
5. Scheduler
   Assigne chaque pod à un nœud éligible
 
6. kubelet (sur chaque nœud choisi)
   Reçoit la spec du pod, demande au container runtime de puller l'image et démarrer le conteneur
 
7. kubelet → API Server
   Rapporte le statut du pod (Running, Failed, etc.)

Ce cycle de réconciliation s'exécute en continu. C'est pour ça que si vous supprimez un pod manuellement, il revient immédiatement — le ReplicaSet controller voit que l'état réel (2 pods) diverge de l'état désiré (3 pods) et en crée un nouveau.

L'architecture est claire. Le chapitre suivant couvre l'installation d'un cluster K3s en production et la configuration de kubectl.