Kubernetes : la révolution de l'orchestration des conteneurs expliquée

Kubernetes : la révolution de l'orchestration des conteneurs expliquée

Kubernetes a été conçu pour répondre à la complexité croissante de la gestion des conteneurs sur plusieurs machines. Alors qu'un seul conteneur est facile à gérer, orchestrer une multitude de conteneurs sur un réseau de machines est un défi. Un service Python, bien que simple, peut devenir un point de défaillance unique. Les machines virtuelles, bien qu'elles offrent une meilleure isolation, souffrent de lenteurs et de dérives d'environnement. Docker a permis de rendre les applications portables et légères, mais il ne résout que le problème de l'hébergement sur une seule machine. Docker Compose coordonne les conteneurs sur une seule machine, mais pas sur un réseau entier. Kubernetes introduit des fonctionnalités avancées telles que la planification, l'auto-réparation, la découverte de services, la mise à l'échelle et les déploiements sans interruption sur plusieurs machines. Son principe fondamental est de permettre aux utilisateurs de déclarer un état souhaité, et Kubernetes s'efforce continuellement de faire correspondre le système réel à cet état.

Ce que vous comprendrez après ce chapitre

• Pourquoi l'industrie a adopté l'orchestration de conteneurs.
• Les véritables problèmes que Kubernetes résout, basés sur des principes fondamentaux plutôt que sur des discours marketing.

Le point de départ : une équipe de détection de fraude

Imaginez que vous êtes l'unique ingénieur en apprentissage automatique dans une startup fintech. L'équipe des paiements a développé un modèle XGBoost capable de détecter les transactions frauduleuses avec une précision de 94 %. Ce modèle doit fonctionner en tant que service d'inférence en temps réel, où chaque transaction par carte interroge votre API en moins de 200 ms pour obtenir un score de probabilité de fraude. Si ce score dépasse un certain seuil, la transaction est bloquée. Le modèle fonctionne bien, mais l'infrastructure devient un problème à résoudre. Ce chapitre retrace l'évolution de ce problème, depuis un simple script Python jusqu'à un déploiement Kubernetes, en expliquant à chaque étape pourquoi l'approche actuelle échoue et ce que chaque nouvelle solution apporte réellement.

ère 1 : Commencer avec un service Python

Vous débutez de la manière la plus intuitive pour un ingénieur : en optant pour la solution la plus simple qui fonctionne.

# fraud_detector.py
import numpy as np
import xgboost as xgb
from fastapi import FastAPI
from pydantic import BaseModel
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

app = FastAPI(title="Fraud Detector", version="1.0.0")

# Modèle chargé une fois au démarrage — vit dans la mémoire de ce processus
model = xgb.XGBClassifier()
model.load_model("fraud_model.json")
logger.info("Modèle chargé avec succès")

@app.get("/health")
def health():
    return {"status": "ok"}

Vous l'exécutez avec la commande : uvicorn fraud_detector:app --host 0.0.0.0 --port 8000 --workers 4

Tout fonctionne bien. L'équipe des paiements intègre le service. Les transactions affluent et tout semble parfait pendant environ six semaines.

Ce qui casse

• Point de défaillance unique. Votre processus est la seule instance en cours d'exécution. Si elle tombe en panne — à cause d'une fuite de mémoire, d'une exception inattendue ou d'une entrée mal formée — toutes les tentatives de paiement échouent. Cela peut se produire à n'importe quel moment, même à 3 heures du matin un samedi.

• Pas d'isolation. Le détecteur de fraude partage le système d'exploitation, le système de fichiers, le CPU et la mémoire avec tous les autres processus sur cette machine. Une mise à jour mal configurée peut casser votre runtime Python. Un autre service consommant trop de mémoire peut tuer votre processus. Vous n'avez aucune garantie de stabilité.

• Déploiements manuels. Pour réentraîner le modèle, il faut se connecter en SSH au serveur de production, copier un nouveau fichier fraud_model.json et redémarrer uvicorn. Chaque déploiement nécessite une intervention manuelle, ce qui augmente le risque d'erreurs. Il n'y a pas de mécanisme de retour en arrière facile.

• Pas de mise à l'échelle horizontale. Le volume de transactions augmente de 5x après une campagne marketing. Vous ne pouvez pas ajouter de capacité sans une intervention manuelle significative. L'instance unique devient un goulot d'étranglement en termes de latence.

• Pas de limites de ressources. Un bug dans le code d'extraction de caractéristiques peut provoquer une boucle infinie. Votre processus consomme alors 100 % du CPU, ce qui dégrade les performances des autres services sur le même hôte.

ère 2 : Ajouter de l'isolation avec des machines virtuelles

La première réaction est de vouloir isoler les services. Les machines virtuelles offrent des frontières strictes entre les charges de travail. L'isolation est réelle : un plantage dans une VM n'affecte pas les autres. L'hyperviseur impose des limites de CPU et de mémoire. Vous pouvez prendre des instantanés, restaurer et cloner des VMs, et vous disposez d'une piste d'audit.

Ce que les machines virtuelles n'ont pas résolu

• Gaspillage de ressources à grande échelle. Une installation minimale d'Ubuntu 22.04 consomme environ 2 Go de RAM juste pour exister. Votre modèle XGBoost avec un wrapper FastAPI nécessite environ 400 Mo de RAM pour servir le trafic. La surcharge des VMs signifie que vous payez pour 2 Go de RAM par instance juste pour exécuter une application de 400 Mo. Sur une flotte de 50 VMs de détection de fraude, cela représente 100 Go de RAM inutilisée.

• Temps de démarrage. Une VM prend 30 à 90 secondes à démarrer. Lorsqu'un pic de trafic survient — une vente flash, une attaque de bot, un événement d'actualité — vous ne pouvez pas ajouter de capacité assez rapidement. Au moment où une nouvelle VM est opérationnelle, le pic est souvent passé.

• Dérive d'environnement. Deux VMs créées à partir de la même image de machine à six mois d'intervalle seront différentes. Les correctifs de sécurité, les mises à jour de bibliothèques et les modifications de configuration s'accumulent. Vous avez déjà vécu "ça fonctionne sur la VM 2 mais pas sur la VM 3" au pire moment possible.

• Itération lente. Pour déployer une nouvelle version du modèle, vous devez construire une nouvelle image de machine (10 à 15 minutes), lancer une nouvelle instance (2 à 3 minutes), attendre les vérifications de santé (1 à 2 minutes), et déplacer le trafic. Un déploiement prend au minimum 30 minutes. Faire marche arrière n'est pas plus rapide.

• Le problème de conflit de dépendances. Le service de détection de fraude nécessite XGBoost 2.0. Un nouveau service de détection d'anomalies nécessite XGBoost 1.7 à cause d'une dépendance héritée. Sur les VMs, les deux services partagent le Python système. Vous devez soit containeriser les environnements manuellement (virtualenv, conda), soit exécuter chaque service sur sa propre VM, amplifiant ainsi le problème de gaspillage.

Les machines virtuelles ont résolu l'isolation mais ont introduit de nouveaux problèmes liés à la densité, à la vitesse et à la reproductibilité.

ère 3 : Emballer le service avec Docker

Docker et Conteneurs : Les Concepts Essentiels

Docker n'a pas inventé les conteneurs. Les technologies de base existaient déjà dans Linux, notamment les namespaces et les groupes de contrôle (cgroups). La contribution majeure de Docker a été de rendre les conteneurs faciles à construire, distribuer et exécuter de manière cohérente à travers différents environnements.

• Namespaces : Isolation des Processus
  Les namespaces Linux offrent à un processus sa propre vue des ressources système. Le conteneur peut avoir son propre nom d'hôte, système de fichiers et interface réseau, tout en partageant le noyau Linux de l'hôte.

• cgroups : Limites de Ressources
  Les namespaces fournissent l'isolation, tandis que les cgroups contrôlent l'utilisation des ressources. Avec Docker, vous pouvez restreindre combien de CPU et de mémoire un conteneur peut consommer :

  docker run \
    --memory="512m" \
    --cpus="1.0" \
    fraud-detector:v1.2.0
  

  Ce conteneur peut utiliser jusqu'à :

  • 512 Mo de mémoire
  • Un cœur de CPU

Si cela dépasse sa limite de mémoire, le noyau peut terminer le processus du conteneur sans directement...