À propos des instantanés de pods GKE

Standard

Aperçu

Ce produit est soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits en pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Les instantanés de pods Google Kubernetes Engine (GKE) permettent d'améliorer la latence de démarrage des charges de travail en restaurant des instantanés de pods en cours d'exécution. Un instantané de pod enregistre l'état complet du pod, y compris les modifications apportées à la mémoire et au système de fichiers. Lorsque vous créez des instances dupliquées, elles sont restaurées à 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 des instantanés de pods

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 des modèles volumineux dans la mémoire du processeur ou du GPU, ou les applications volumineuses qui chargent de nombreuses bibliothèques et dépendances. Les charges de travail dont les temps de démarrage sont déjà rapides ne bénéficieront généralement pas des instantanés de pods.

Fonctionnement des instantanés de pods

Les instantanés de pods GKE stockent une copie exacte de l'état du processus d'un pod à un moment précis. Lorsque de nouvelles instances dupliquées sont créées, au lieu d'initialiser le pod à partir d'un état vierge, le pod est restauré à partir d'un instantané, ce qui permet de reprendre l'exécution à partir du moment où l'instantané a été pris.

Pour utiliser des 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 vos instantanés de pods.

Contenu des instantanés

Le tableau suivant décrit ce qui est inclus ou non dans un instantané de pod :

Catégorie	Inclus dans un instantané	Non inclus dans un instantané
État de l'application	L'intégralité de l'état de l'application : tous les descripteurs de fichiers ouverts, les threads, les registres de processeur et la mémoire.
Systèmes de fichiers	Le système de fichiers racine du conteneur (rootfs), les volumes EmptyDir et les points de montage tmpfs.	Tout ce qui n'est pas couvert par la colonne précédente. Plus précisément, les volumes persistants ne sont pas mis en point de contrôle.
Mise en réseau	Les connexions de bouclage, les sockets d'écoute et les sockets de domaine Unix.	Les connexions externes ne sont pas restaurées (elles sont arrêtées lors de la restauration). Les règles ajoutées par l'utilisateur, telles que iptables ou nftables, et les routes ne sont pas restaurées.

Définitions des ressources personnalisées

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

• PodSnapshotStorageConfig: spécifie l'emplacement de stockage des instantanés. Seuls les buckets Cloud Storage sont compatibles.
• PodSnapshotPolicy: définit les pods à instantané en fonction des sélecteurs d'étiquettes 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 dans un état prêt de la charge de travail. 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 dans les situations où 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écification de pod distillée. Ce hachage est ensuite intégré à l'instantané du pod. Pour qu'un pod ultérieur soit restauré à partir de cet instantané de pod, il doit générer un hachage identique à partir de sa propre spécification de pod distillé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 mise en point de contrôle et le pod 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 les annotations commençant 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 être considérés comme un instantané 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 de machines et l'architecture doivent être identiques. Le nombre de processeurs et la quantité de mémoire peuvent changer. Les types de machines E2 ne sont pas compatibles en raison de leur architecture sous-jacente dynamique.
• Gestion des versions : la version du noyau gVisor et la version 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 cet instantané. Si aucun instantané compatible n'existe, le pod démarre normalement.

Préparation de la restauration et 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 de démarrage, l'application reprend immédiatement après la restauration du noyau. Elle n'attend pas que la mémoire de l'application soit complètement 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, une erreur de page se produit. gVisor intercepte cette erreur, 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 faible 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 de langage (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 entièrement réactif pour l'inférence que lorsque l'état du GPU sera complètement restauré. Par conséquent, lorsque vous mesurez la vitesse de restauration, assurez-vous de capturer le moment où le serveur de modèles a démarré. Vous pouvez vérifier le démarrage du serveur de modèles à l'aide de métriques telles que le délai avant le premier jeton (TTFT) ou les sondes de préparation des pods.

État du GPU

Les instantanés de pods sont compatibles avec la capture de 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 ensuite mis en pause et instantané. 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 la mémoire et l'état du processus d'origine. Toutefois, certains aspects de l'état du pod doivent changer pour qu'il fonctionne comme une instance nouvelle et unique.

Tenez compte des modifications d'état suivantes après une restauration :

• 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 sockets de domaine Unix continuent de fonctionner.
• Nom d'hôte : le pod restauré prend une nouvelle identité et reçoit un nouveau nom d'hôte.
• Heure de l'horloge murale : l'heure de l'horloge murale passe à l'heure actuelle.
• État de l'application : l'état de l'application doit être unique pour chaque pod, comme les ID d'expérience ou les valeurs de départ des nombres aléatoires, et 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 de fichier est le même que /proc/<pid>/environ.

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 instantanés 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 compatibles :
  • 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-40GB)
  • a2-ultragpu-1g (1 x A100-80GB)
  • a3-highgpu-1g (1 x H100-80GB)
• L'utilisation partielle du GPU n'est pas compatible. Si un nœud comporte 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 des instantanés de pods n'est pas compatible.

Étape suivante

• Pour savoir comment utiliser des instantanés de pods, consultez Restaurer à partir d'un instantané de pod.