À propos des instantanés de pods GKE

Les instantanés de pods Google Kubernetes Engine (GKE) permettent d'améliorer la latence de démarrage des charges de travail en restaurant les instantanés des pods en cours d'exécution. Un instantané de pod enregistre l'intégralité de l'état du pod, y compris les modifications apportées à la mémoire et au système de fichiers. Lorsque vous créez des réplicas, ils sont restaurés à partir de l'instantané, ce qui permet à la charge de travail de reprendre au lieu de démarrer à partir d'un nouvel état.

Ce document présente les concepts liés aux instantanés de pods GKE. Pour savoir comment activer et utiliser cette fonctionnalité, consultez Restaurer à partir d'un instantané de pod.

Quand utiliser les instantanés de pod ?

Utilisez des instantanés de pods pour les charges de travail dont les temps d'initialisation sont longs, par exemple les charges de travail d'inférence d'IA qui chargent de grands modèles dans la mémoire du processeur ou du GPU, ou les grandes applications qui chargent de nombreuses bibliothèques et dépendances. Les charges de travail qui ont déjà des temps de démarrage rapides ne bénéficieront généralement pas des instantanés de pods.

Fonctionnement des instantanés de pod

Les instantanés de pods GKE stockent une copie exacte de l'état du processus d'un pod à un moment précis. Lorsque de nouveaux réplicas sont créés, au lieu d'initialiser le pod à partir d'un état vierge, le pod est restauré à partir d'un instantané, et l'exécution reprend à partir du point où l'instantané a été pris.

Pour utiliser les instantanés de pods, vous devez créer des définitions de ressources personnalisées (CRD) Kubernetes afin de configurer de manière déclarative le comportement des instantanés. Un agent s'exécutant sur chaque nœud GKE gère le cycle de vie des instantanés. En fonction des règles que vous définissez, l'agent détermine quand créer des instantanés et quand utiliser des instantanés existants pour restaurer de nouveaux pods. Un contrôleur s'exécutant sur le plan de contrôle GKE nettoie les instantanés obsolètes et résout les problèmes. Cloud Storage stocke les instantanés de vos pods.

Définitions des ressources personnalisées

Les instantanés de pods sont configurés de manière déclarative avec les CRD suivants :

  • PodSnapshotStorageConfig : spécifie l'emplacement de stockage des instantanés. Seuls les buckets Cloud Storage sont acceptés.
  • PodSnapshotPolicy : définit les pods à inclure dans le snapshot en fonction des sélecteurs de libellés Kubernetes. Cette ressource contient la majorité des options de configuration de la fonctionnalité, y compris la façon dont les instantanés sont déclenchés et les règles de conservation.
  • PodSnapshotManualTrigger : (facultatif) si vous n'utilisez pas de déclencheur de charge de travail, définit un déclencheur manuel pour créer un instantané pour un pod spécifique.

Déclencheurs d'instantanés

Vous pouvez déclencher un instantané de pod de différentes manières :

  • Déclencheur de charge de travail : l'application à l'intérieur du pod signale à l'agent GKE qu'elle est prête pour un instantané. Ce type de déclencheur s'exécute une fois dans un cycle de charge de travail, par exemple lorsque la charge de travail est prête. Cette approche est idéale pour améliorer la latence de démarrage des charges de travail à scaling horizontal.
  • Déclencheur manuel : vous pouvez déclencher un instantané à la demande pour un pod spécifique en créant une ressource personnalisée PodSnapshotManualTrigger. Ce type de déclencheur peut s'exécuter autant de fois que nécessaire. Cette approche est idéale lorsque vous ne pouvez pas modifier votre application pour signaler qu'elle est prête.

Correspondance des instantanés

La correspondance des pods détermine si un instantané de pod est compatible avec un pod spécifique. Cette correspondance est obtenue en créant un hachage unique à partir des spécifications d'exécution essentielles du pod, également appelées spécifications de pod condensées. Ce hachage est ensuite intégré dans l'instantané du pod. Pour qu'un pod ultérieur puisse être restauré à partir de cet instantané de pod, il doit générer un hachage identique à partir de sa propre spécification de pod condensée. Ce processus permet de s'assurer que les pods mis en point de contrôle et restaurés sont identiques dans leurs configurations d'exécution.

La distillation simplifie la spécification du pod en ne conservant que les champs d'exécution critiques, tels que image, tout en supprimant les champs non essentiels tels que nodeName ou nodeSelector. Vous devez vous assurer que les valeurs de ces champs essentiels sont cohérentes entre le pod utilisé pour la création de points de contrôle et celui destiné à la restauration.

Les champs suivants de l'objet Pod influencent le hachage unique :

  • metadata :
    • annotations : seules les annotations pertinentes pour l'exécution gVisor, telles que celles qui commencent par le préfixe dev.gvisor.*.
    • labels : batch.kubernetes.io/job-completion-index
  • spec :
    • volumes : name, volumeSource, hostPath, persistentVolumeClaim, configMap
    • containers :
      • name
      • image
      • command
      • args
      • workingDir
      • ports : name, containerPort, protocol
      • volumeMounts : name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
      • volumeDevices : name
      • lifecycle : postStart, preStop
      • terminationMessagePath
      • terminationMessagePolicy
      • securityContext (et tous les sous-champs)
      • stdin
      • stdinOnce
      • tty
    • initContainers : mêmes sous-champs que containers.
    • dnsPolicy
    • automountServiceAccountToken
    • hostNetwork
    • hostPID
    • hostIPC
    • shareProcessNamespace
    • securityContext
    • dnsConfig
    • runtimeClassName
    • os
    • hostUsers

Les critères supplémentaires suivants doivent correspondre pour qu'un instantané soit considéré comme compatible :

  • Matériel : le nouveau pod doit s'exécuter sur un nœud dont la série de machines et l'architecture sont identiques à celles du pod d'origine. La série et l'architecture de la machine doivent être identiques. Le nombre de processeurs et la quantité de mémoire peuvent changer. Les types de machines E2 ne sont pas acceptés en raison de leur architecture sous-jacente dynamique.
  • Gestion des versions : la version du noyau gVisor et celle du pilote GPU doivent correspondre.

GKE gère la compatibilité des instantanés. Si GKE trouve un instantané compatible, il restaure le nouveau pod à partir de l'instantané. Si aucun instantané compatible n'existe, le pod démarre normalement.

Restauration de l'état de préparation et du chargement en arrière-plan

Lorsqu'un pod est restauré à partir d'un instantané, le noyau gVisor est restauré en premier, ce qui prend généralement quelques secondes. Pour minimiser la latence au démarrage, l'application reprend immédiatement après la restauration du noyau. Il n'attend pas que la mémoire de l'application soit entièrement chargée. La mémoire de l'application est restaurée à l'aide d'un mécanisme de streaming en arrière-plan.

Si l'application tente d'accéder à une partie de la mémoire qui n'a pas encore été chargée, un défaut de page se produit. gVisor intercepte ce défaut, met en pause le thread de l'application et récupère immédiatement la page de mémoire requise à partir du stockage. Cette récupération à la demande est prioritaire par rapport au flux en arrière-plan.

En raison de ce chargement en arrière-plan, l'accès à la mémoire peut présenter une légère latence pendant les premières secondes après une restauration si l'application a besoin de mémoire qui n'a pas encore été diffusée. Cette latence disparaît lorsque l'état de la mémoire est entièrement synchronisé.

Ce comportement de chargement en arrière-plan s'applique également à l'état du GPU. Par exemple, un pod de grand modèle linguistique (LLM) peut sembler être à l'état Running et répondre aux vérifications réseau même si sa mémoire GPU est toujours en cours de remplissage. Le modèle ne sera pas entièrement réactif pour l'inférence tant que l'état du GPU n'aura pas été complètement restauré. Par conséquent, lorsque vous mesurez la vitesse de restauration, assurez-vous de capturer le moment où le serveur de modèle a démarré. Vous pouvez vérifier quand le serveur de modèle démarre à l'aide de métriques telles que le délai avant le premier jeton (TTFT) ou les vérifications de la préparation des pods.

État du GPU

Les snapshots de pods permettent de capturer l'état des GPU. Lorsque vous déclenchez un instantané pour un pod qui utilise des GPU, l'outil NVIDIA cuda-checkpoint enregistre l'état du GPU dans la mémoire du processus. Cela signifie que toutes les données stockées sur le GPU, par exemple les pondérations du modèle, sont incluses dans l'instantané. Le pod est alors mis en veille et un instantané est créé. Lors de la restauration, le processus est inversé.

Étant donné que l'état du GPU est écrit dans la mémoire du processus, l'utilisation de la mémoire du pod augmente lors des opérations d'instantané et de restauration. Vous devez tenir compte de cette exigence de mémoire supplémentaire lorsque vous définissez des limites de mémoire pour vos pods.

Éléments à prendre en compte pour les pods restaurés

Du point de vue de l'API Kubernetes, un nouveau pod est créé. Lorsque le pod démarre, s'il existe un instantané correspondant, il est restauré à partir de cet instantané, y compris l'état de la mémoire et du processus d'origine. Toutefois, certains aspects de l'état du pod doivent changer pour qu'il fonctionne comme une nouvelle instance unique.

Voici les changements d'état à prendre en compte après une restauration :

  • Interfaces réseau : le pod restauré reçoit une nouvelle adresse IP. Toutes les interfaces réseau et les routes sont reconfigurées. Les connexions réseau actives qui existaient au moment de l'instantané sont fermées lors de la restauration. Les sockets d'écoute continuent de fonctionner.
  • Nom d'hôte : le pod restauré assume une nouvelle identité et reçoit un nouveau nom d'hôte.
  • État de l'application : l'état de l'application qui doit être unique pour chaque pod, tel que les ID d'expériences ou les seeds de nombres aléatoires, doit être réinitialisé après une restauration.
  • Secrets : les clés de chiffrement et les certificats créés avant la prise de l'instantané doivent être recréés.
  • Variables d'environnement : vous pouvez modifier les variables d'environnement entre un instantané et une restauration. Toutefois, comme les variables d'environnement sont stockées dans la mémoire de l'application, GKE Sandbox ne peut pas les trouver et les remplacer de manière fiable. Si votre charge de travail repose sur de nouvelles variables d'environnement après une restauration, le pod doit les actualiser manuellement. Les nouvelles variables d'environnement sont disponibles dans le fichier /proc/gvisor/spec_environ. Le format du fichier est identique à /proc/<pid>/environ.

État qui change après la restauration

Tous les états ne sont pas conservés lors de la restauration. Les parties suivantes de l'état du pod changent pour que le pod puisse assumer une nouvelle identité :

  • Interfaces réseau : le pod restauré reçoit une nouvelle adresse IP. Toutes les interfaces et routes sont reconfigurées. Les connexions réseau actives qui existaient au moment de l'instantané sont fermées lors de la restauration. Les sockets d'écoute, les connexions de bouclage et les connexions de socket de domaine Unix continuent de fonctionner.
  • Nom d'hôte : le pod restauré assume une nouvelle identité et reçoit un nouveau nom d'hôte.
  • Durée d'exécution : la durée d'exécution passe à l'heure actuelle.

Limites et exigences

Les instantanés de pods GKE présentent les limites suivantes :

  • Les pods doivent s'exécuter dans GKE Sandbox, car les instantanés de pods dépendent de l'environnement d'exécution de conteneur gVisor fourni par GKE Sandbox.
  • Les snapshots de pods ne sont pas compatibles avec les types de machines E2.
  • Les instantanés de pods fonctionnent avec les pods à GPU unique. Seules les configurations multi-GPU suivantes sont acceptées :
    • g2-standard-4 (1 x L4)
    • g2-standard-8 (1 x L4)
    • g2-standard-12 (1 x L4)
    • g2-standard-16 (1 x L4)
    • g2-standard-32 (1 x L4)
    • g2-standard-48 (4 x L4)
    • g2-standard-96 (8 x L4)
    • a2-highgpu-1g (1 x A100-40 Go)
    • a2-ultragpu-1g (1 x A100-80 Go)
    • a3-highgpu-1g (1 x H100-80 Go)
  • L'utilisation partielle du GPU n'est pas prise en charge. Si un nœud possède plusieurs GPU, un pod doit tous les utiliser. Par exemple, vous ne pouvez pas utiliser d'instantanés de pods avec quatre pods qui utilisent chacun un GPU sur une machine à quatre GPU.
  • L'utilisation du conteneur side-car du pilote CSI Cloud Storage FUSE avec les instantanés de pod n'est pas prise en charge.

Étapes suivantes