À 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 des instantanés de pods en cours d'exécution. Un instantané de pod enregistre l'état complet du pod, y compris les modifications de la mémoire et du système de fichiers. Lorsque vous créez des instances répliqué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. Cette fonctionnalité est utile pour faire évoluer horizontalement les charges de travail, telles que les modèles d'inférence d'IA qui chargent des pondérations importantes en mémoire ou les applications qui chargent des dépendances étendues.

Ce document vous explique comment fonctionnent les instantanés de pods GKE et vous aide à déterminer si vos charges de travail peuvent en bénéficier.

Les administrateurs et opérateurs de plate-forme, ainsi que les développeurs d'applications, peuvent utiliser ce document pour évaluer la compatibilité des charges de travail, planifier des règles de stockage d'instantanés et comprendre comment GKE gère les points de contrôle et la restauration. Pour en savoir plus sur les rôles courants et les exemples de tâches référencés dans le contenuCloud de Confiance by S3NS , consultez Rôles utilisateur et tâches courantes de GKE.

Pour préparer et utiliser des instantanés de pods dans vos clusters, consultez les guides suivants :

1. Se préparer aux instantanés de pods
2. Déclencher un instantané de pod
3. Restaurer une charge de travail à 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. Il peut s'agir, par exemple, de charges de travail d'inférence d'IA qui chargent des modèles volumineux dans la mémoire du processeur ou du GPU, ou d'applications volumineuses 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éficient 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 vous créez des instances répliquées, au lieu d'initialiser le pod à partir d'un état vierge, GKE le restaure à partir d'un instantané. Cette restauration signifie que le pod reprend l'exécution à partir du point où l'instantané a été pris.

Pour configurer les instantanés de pods de manière déclarative, vous devez créer des ressources personnalisées Kubernetes afin de définir le comportement des instantanés. Un agent qui s'exécute 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 qui s'exécute 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.

Contenu de l'instantané

Le tableau suivant liste ce qu'un instantané de pod inclut et exclut :

Ressources personnalisées

Pour configurer les instantanés de pod de manière déclarative, utilisez les ressources personnalisées suivantes :

• PodSnapshotStorageConfig : spécifie l'emplacement de stockage des instantanés. Compatible uniquement avec les buckets Cloud Storage.
• PodSnapshotPolicy : définit les pods dont il faut créer un instantané en fonction des sélecteurs d'étiquettes Kubernetes. Cette ressource personnalisée contient la plupart des options de configuration de la fonctionnalité, y compris la façon dont les instantanés sont déclenchés, leur champ d'application 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.

Pour obtenir des spécifications de référence, consultez la documentation de référence sur la ressource CustomResourceDefinition PodSnapshot.

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 par 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 son aptitude.

Correspondance et compatibilité des instantanés

Pour s'assurer qu'un instantané est compatible avec une charge de travail restaurée, GKE effectue une mise en correspondance de compatibilité entre le pod d'origine ayant fait l'objet d'un point de contrôle et le pod cible.

GKE utilise les règles suivantes pour déterminer la compatibilité :

• Ordre de sélection : par défaut, GKE restaure les charges de travail à partir de la ressource personnalisée PodSnapshot la plus récente qui correspond à l'espace de noms et à la configuration du pod.
• Critères de correspondance : la vérification de compatibilité dépend du champ d'application de l'instantané configuré dans votre ressource personnalisée PodSnapshotPolicy (whole-pod ou rootfs-only).

Correspondance de champ d'application whole-pod (par défaut)

Pour les règles avec le champ d'application whole-pod par défaut, GKE vérifie les éléments suivants :

• Hachage de spécification distillé : GKE génère un hachage unique basé sur les champs d'exécution essentiels de la spécification du pod. Pour qu'une restauration réussisse, le pod cible doit générer un hachage identique à partir de sa spécification distillée. Cette vérification permet de s'assurer que les pods soumis à un point de contrôle et restaurés sont identiques dans leurs configurations d'exécution.

  Les champs suivants de l'objet Pod font partie de la spécification distillée et influencent le hachage unique :

  • metadata :
    • annotations : seules les annotations pertinentes pour GKE Sandbox (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

• Compatibilité matérielle : le pod cible doit s'exécuter sur un nœud doté de la même série de machines, du même fournisseur de processeur et du même ensemble de caractéristiques de processeur (indicateurs CPUID) que le pod de point de contrôle. Par exemple, les deux nœuds doivent utiliser la même série N2 ou G2 et les mêmes fonctionnalités de processeur Intel ou AMD. GKE Sandbox vérifie les fonctionnalités du processeur avant de restaurer la mémoire du processus et l'état du processeur. Par conséquent, un instantané avec le champ d'application whole-pod ne peut pas être restauré sur un nœud doté de fonctionnalités de processeur différentes.

• Compatibilité des versions : la version du noyau GKE Sandbox et la version du pilote de GPU doivent correspondre à la version capturée dans l'instantané d'origine.

rootfs-only correspondance de champ d'application

Lorsque vous configurez votre stratégie avec le champ d'application rootfs-only (disponible dans GKE version 1.35.3-gke.1031000 et ultérieure), les exigences de correspondance sont moins strictes :

• GKE ne calcule ni ne compare le hachage de spécification de pod distillé. Cette correspondance assouplie vous permet de restaurer un instantané sur un pod cible avec des ressources, des environnements ou d'autres champs de configuration différents. Toutefois, l'image de conteneur sous-jacente et les versions de nœud doivent être compatibles.
• Étant donné que la mémoire du processus n'est pas restaurée, vous pouvez restaurer des instantanés pris sur une famille de machines vers une autre famille de machines (y compris les types de machines E2).

Correspondance des règles de regroupement

Si la règle utilise le champ snapshotGroupingRules pour regrouper les instantanés par valeurs d'étiquette spécifiques (telles que le locataire ou l'environnement), le pod restauré doit avoir des clés et des valeurs d'étiquette correspondantes. Le contrôleur d'instantanés de pod ne sélectionne un instantané que dans le groupe correspondant. Pour en savoir plus sur la configuration des libellés de regroupement, consultez Configurer des paramètres supplémentaires pour la règle d'instantané de pod.

Aptitude à la récupération et chargement en arrière-plan

Lorsqu'un pod est restauré à partir d'un instantané, le noyau GKE Sandbox 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. 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 de lire une partie de la mémoire qui n'a pas encore été chargée, un défaut de page se produit. GKE Sandbox intercepte cette erreur, suspend le thread de l'application et récupère immédiatement la page de mémoire requise depuis l'espace de 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 subir une brève latence pendant les premières secondes suivant une restauration si l'application demande de la mémoire non 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 du 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 ne sera pas complètement restauré. En raison de ce délai, lorsque vous mesurez la vitesse de restauration, assurez-vous de mesurer le moment où le serveur de modèles est prêt à diffuser les requêtes. Vous pouvez vérifier l'état de préparation du serveur de modèles à l'aide de métriques telles que le délai avant le premier jeton (TTFT) ou les tests d'aptitude des pods.

État du GPU

Les instantanés 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. Cette étape permet de s'assurer que les données stockées sur le GPU, telles que les pondérations du modèle, sont incluses dans l'instantané. GKE met en pause le pod et prend un instantané. Lors de la restauration, GKE inverse cette opération.

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

Remarques concernant les pods restaurés

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

Tenez compte des changements d'état suivants 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 socket 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.
• Temps d'horloge : le temps d'horloge passe à l'heure actuelle.
• État de l'application : l'état de l'application doit être unique pour chaque pod, par exemple les ID de test 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 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 ni 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 celui de /proc/<pid>/environ.

Architecture mutualisée et identité

Les instantanés de pods nécessitent des liaisons IAM (Identity and Access Management) manuelles pour l'objet Kubernetes ServiceAccount de chaque pod afin d'utiliser Cloud Storage. La propagation des liaisons IAM manuelles peut prendre du temps, ce qui peut poser problème si vous devez prendre des instantanés immédiatement après la création d'un pod.

Pour résoudre les retards et simplifier la gestion de l'architecture mutualisée, au lieu de lier manuellement IAM aux objets ServiceAccount, vous pouvez utiliser un compte de service de nœud GKE pour créer des jetons de courte durée à la demande. Pour configurer des instantanés de pod avec cette approche, utilisez le champ tokenSource dans la ressource personnalisée PodSnapshotStorageConfig avec l'une des valeurs suivantes :

• podKSA (par défaut) : utilise des liaisons IAM manuelles entre l'objet ServiceAccount du pod et le bucket Cloud Storage.
• federatedP4SA : utilise un jeton spécifique au chemin d'accès créé par le compte de service du nœud.

Conditions requises

Pour utiliser les instantanés de pods GKE, assurez-vous de respecter les exigences suivantes :

• Les pods doivent s'exécuter dans GKE Sandbox, car les instantanés de pods dépendent de l'environnement isolé fourni par GKE Sandbox.
• Pour le champ d'application d'instantané whole-pod par défaut, le nœud sur lequel le pod est restauré doit avoir la même série de machines, le même fournisseur de processeur et les mêmes fonctionnalités de processeur que le nœud sur lequel l'instantané a été pris. Les charges de travail utilisant uniquement des processeurs peuvent utiliser n'importe quelle série de machines non-E2 compatible avec GKE Sandbox qui répond à ces exigences de compatibilité matérielle. Pour en savoir plus, consultez la section Limites.
• Pour utiliser des GPU avec des instantanés de pod, vous devez également remplir les conditions suivantes :
  • Les pods à GPU unique sont compatibles avec les nœuds à GPU unique et les nœuds multi-GPU.
  • Les pods multi-GPU ne sont compatibles qu'avec les GPU L4 (types de machines g2-standard-*).
  • Dans les versions 1.35.0-gke.1738000 et antérieures de GKE, un pod qui s'exécute sur un nœud multi-GPU doit utiliser tous les GPU disponibles sur ce nœud. Dans les versions 1.35.0-gke.1738000 et ultérieures, les pods peuvent utiliser un sous-ensemble des GPU d'un nœud.
  • Pour les charges de travail GPU, vous devez utiliser l'un des types de machines GPU compatibles suivants :
    • 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)

Limites

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

• Lorsque vous utilisez le champ d'application d'instantané whole-pod par défaut, un instantané ne peut pas être restauré sur une VM Compute Engine dotée de fonctionnalités de processeur (flags CPUID) différentes de celles de la VM sur laquelle l'instantané a été pris :
  • Les instantanés de pods avec le champ d'application whole-pod ne sont pas compatibles avec la série de machines E2 ni avec les autres séries de machines qui combinent de manière dynamique des processeurs Intel et AMD ou des générations de processeurs. Les instantanés de système de fichiers (champ d'application rootfs-only) sont compatibles avec la série de machines E2.
  • Même au sein d'une même série de machines non E2 et d'un même fournisseur de processeurs, Compute Engine peut provisionner des VM avec différentes plates-formes de processeurs ou différents ensembles de caractéristiques de processeur par VM. Si un pod est programmé sur un nœud dont les fonctionnalités de processeur ne correspondent pas, la restauration d'un instantané avec le champ d'application whole-pod échoue.
• Le partage de GPU avec un GPU multi-instance (MIG) n'est pas possible.
• Le conteneur side-car du pilote CSI Cloud Storage FUSE n'est pas compatible avec les instantanés de pods.
• Les instantanés de pods ne sont pas compatibles avec les TPU.

Étapes suivantes

• Découvrez comment vous préparer aux instantanés de pods.