Présentation de Kubernetes

Kubernetes orchestre des Pods – unités de travail composées d’images Docker – sur un ensemble de Nodes exécutant le composant kubelet. Le groupe logique de ces nœuds forme un Cluster, auquel s’ajoute un Control Plane responsable de la coordination. Le modèle inclut également les Services, qui offrent une adresse IP virtuelle et un nom DNS stable, ainsi que les Namespaces pour isoler les ressources. Cette architecture de base apparaît simple, mais chaque couche repose sur des mécanismes d’observation et d’action continus.

Boucles de contrôle et automatisation

Le cœur de Kubernetes réside dans ses contrôleurs, implémentations de boucles de contrôle. Chaque boucle observe un état cible (par ex. file d’attente vide, latence P90 < X ms, noeuds sains) via des capteurs (metrics, état de la file, santé du nœud) et ajuste le système à l’aide d’un élément de contrôle (nombre de pods, création de nœuds). Cette séparation entre capteur et action permet d’ajuster la charge sans intervention humaine, tout en conservant la possibilité de modifier les critères d’observation indépendamment des actions exécutées.

Service et kube-proxy

Un Service crée une identité réseau stable et répartit le trafic entre les pods correspondants. Lors de sa création, Kubernetes attribue une IP virtuelle et met à jour, sur chaque nœud, les règles netfilter via le composant kube-proxy. Ainsi, chaque nœud agit comme un équilibreur de charge, éliminant un point de défaillance unique et faisant évoluer la capacité de routage proportionnellement à la taille du cluster. Cette approche entraîne toutefois une multiplication des règles iptables, ce qui peut ralentir le traitement linéaire des paquets sur des clusters très larges.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Gestion des charges via contrôleurs

Déployer un pod directement ne garantit ni résilience ni évolutivité : la perte du nœud hôte entraîne la disparition du pod, et aucune réplication n’est possible. En encapsulant le pod dans un ReplicaSet, le contrôleur veille à ce que le nombre de répliques spécifié reste constant, même après une éviction ou une panne. Le Deployment ajoute une couche de gestion d’image et de mise à jour progressive, assurant que les nouvelles versions sont déployées de façon contrôlée tout en conservant le nombre cible de pods.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2