Kubernetes

Kubernetes, souvent abrégé en K8s, est un système open source qui exécute des applications conteneurisées sur un cluster de machines. Les utilisateurs déclarent l’état souhaité d’une charge de travail — par exemple, l’image de conteneur à exécuter, le nombre de répliques à conserver et la capacité en CPU, mémoire et GPU nécessaire à chacune — et Kubernetes démarre, redémarre, déplace et met continuellement à l’échelle les conteneurs pour atteindre cet état. Google a annoncé le projet en juin 2014, en s’appuyant sur son gestionnaire de clusters interne Borg, puis l’a proposé comme projet fondateur de la nouvelle Cloud Native Computing Foundation avec la version 1.0 en juillet 2015. Le nom signifie « timonier » en grec, et K8s remplace les huit lettres entre le K et le s. Dans les opérations d’apprentissage automatique (MLOps), Kubernetes est la couche courante qui exécute les tâches d’entraînement distribué, d’inférence par lots et de mise en service de modèles sur du matériel partagé.

Architecture et boucle de contrôle#

Un cluster comprend un plan de contrôle et des nœuds de calcul. Le plan de contrôle contient le serveur API auquel chaque client s’adresse, le magasin d’état du cluster etcd, le planificateur qui affecte les nouveaux pods aux nœuds et des contrôleurs qui surveillent chacun un type d’objet. Chaque nœud de calcul, qu’il s’agisse d’un serveur sur site ou d’une machine virtuelle dans le cloud, exécute un agent kubelet et un moteur d’exécution de conteneurs tel que containerd ou CRI-O. L’unité la plus petite que Kubernetes planifie est un pod : un ou plusieurs conteneurs qui partagent une adresse réseau et des volumes de stockage.

Les charges de travail sont déclarées sous forme d’objets, généralement écrits en YAML et appliqués avec kubectl. Un Deployment maintient un nombre défini de pods identiques en cours d’exécution et les remplace progressivement lorsque l’image change ; un Service leur attribue une adresse stable et répartit les requêtes entre eux ; un Job exécute des pods jusqu’à la fin d’une tâche. Les contrôleurs comparent l’état déclaré à l’état réel et interviennent en cas de différence :

La même boucle permet à Kubernetes de s’autoréparer. Lorsqu’un nœud tombe en panne, ses pods quittent l’état actif et le contrôleur en crée de nouveaux sur des nœuds opérationnels. Un pod en attente faute de capacité signale également aux mécanismes de mise à l’échelle automatique du cluster qu’il faut ajouter des nœuds.

Kubernetes pour l’apprentissage automatique#

Les GPU sont mis à la disposition des pods par des greffons de périphériques, qui les annoncent comme une ressource dénombrable telle que nvidia.com/gpu, et par l’allocation dynamique des ressources, stable depuis Kubernetes 1.34, qui permet à un pod de demander des périphériques selon des attributs tels que le modèle ou la mémoire du GPU. L’opérateur GPU de NVIDIA installe les pilotes et les greffons sur les nœuds GPU et peut diviser un GPU en tranches Multi-Instance GPU ou le partager dans le temps entre plusieurs pods. OpenAI a rapporté en 2021 avoir mis à l’échelle des clusters Kubernetes uniques jusqu’à 7 500 nœuds pour entraîner des modèles comme GPT-3 et CLIP.

Les projets open source ajoutent des couches dédiées à l’apprentissage automatique :

• Kubeflow : Exécute sur un cluster l’entraînement distribué de PyTorch, des pipelines d’apprentissage automatique et des notebooks.
• Kueue : Met en file d’attente les tâches par lots et d’entraînement, et applique des quotas d’équipe afin que les GPU coûteux restent occupés sans qu’une équipe ne monopolise toutes les ressources.
• KServe : Met les modèles à disposition derrière des points de terminaison à mise à l’échelle automatique, y compris avec une réduction à zéro lorsque les modèles sont inactifs.
• Horizontal Pod Autoscaler : Ajoute ou supprime des répliques d’inférence selon l’utilisation du CPU ou des métriques personnalisées comme la longueur de la file d’attente, afin de stabiliser la latence malgré les variations du trafic.

Un Job est le moyen le plus simple d’exécuter une tâche GPU ponctuelle, comme l’inférence par lots. L’image Docker officielle Ultralytics contient déjà la commande yolo et les poids YOLO26 nano ; ce Job ne définit donc qu’une commande et demande un GPU :

apiVersion: batch/v1
kind: Job
metadata:
  name: yolo26-predict
spec:
  backoffLimit: 2 # retry a failed pod at most twice
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: yolo
          image: ultralytics/ultralytics:latest
          command: ["yolo", "predict", "model=yolo26n.pt", "source=https://ultralytics.com/images/bus.jpg"]
          resources:
            limits:
              nvidia.com/gpu: 1 # schedule only onto a node with a free GPU

kubectl apply -f job.yaml le soumet, le planificateur place le pod sur un nœud doté d’un GPU libre, et kubectl logs job/yolo26-predict affiche les résultats de détection d’objets du mode prédiction. Un Job d’entraînement suit le même principe et ajoute un volume persistant pour les points de contrôle, ainsi qu’un volume en mémoire à /dev/shm pour les workers de chargement de données PyTorch.

Kubernetes, Docker et l’informatique sans serveur#

• Docker : Crée des images et exécute des conteneurs sur une seule machine. Kubernetes répartit les conteneurs sur plusieurs machines et, depuis la version 1.24, exécute les images créées avec Docker via containerd ou CRI-O plutôt que Docker Engine.
• Informatique sans serveur : Des services comme Google Cloud Run et AWS Lambda masquent entièrement le cluster et facturent chaque requête ; Knative apporte le même modèle de mise à l’échelle à zéro aux clusters Kubernetes.
• Kubernetes géré : Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) et Azure Kubernetes Service (AKS) exécutent le plan de contrôle pour leurs clients ; GKE Autopilot gère également les nœuds de calcul.