À 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 apportées à la mémoire et au 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.

Ce document présente les concepts liés aux instantanés de pods GKE. Pour activer et utiliser cette fonctionnalité, consultez les documents suivants :

  1. Préparer les 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 pods

Utilisez les 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 répliqué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 les instantanés de pods, vous créez 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 d'installation 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.

CustomResourceDefinitions

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 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, 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.

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 de préparation 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 lorsque vous ne pouvez pas modifier votre application pour signaler qu'elle est prête.

Correspondance et compatibilité des instantanés

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

La compatibilité est déterminée par les règles suivantes :

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

Correspondance du 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 :

  1. Hachage de spécification distillée : 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 garantit que les pods mis en 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 l'environnement d'exécution gVisor (par exemple, 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

  2. Compatibilité matérielle : le pod cible doit s'exécuter sur un nœud avec une série de machines et une architecture de processeur identiques à celles du pod d'origine mis en point de contrôle (par exemple, N2 à N2 ou G2 à G2).

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

Correspondance du champ d'application rootfs-only

Lorsque vous configurez votre règle 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 distillée du pod. Cette correspondance assouplie vous permet de restaurer un instantané sur un pod cible qui possède des ressources, des environnements ou d'autres champs de configuration différents de ceux du pod d'origine mis en point de contrôle, à condition que l'image de conteneur sous-jacente et les versions de nœud soient compatibles.
  • Comme la mémoire du processus n'est pas restaurée, vous pouvez restaurer des instantanés pris sur une famille de machines sur 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'étiquettes spécifiques (par exemple, par locataire ou par environnement), le pod restauré doit avoir exactement les mêmes clés et valeurs d'étiquettes. Le contrôleur d'instantanés de pods ne sélectionne qu'un instantané du groupe correspondant. Pour en savoir plus sur la configuration des étiquettes de regroupement, consultez Configurer des règles d'instantanés de pods supplémentaires.

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é. En raison de ce délai, 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é.

Comme 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, le pod 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 graines de 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.

Architecture mutualisée et identité

Les instantanés de pods nécessitent des liaisons IAM manuelles pour que le compte de service Kubernetes (KSA) de chaque pod puisse accéder à 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 problèmes de délai et simplifier la gestion mutualisée, au lieu de lier manuellement IAM aux KSA, vous pouvez éventuellement utiliser un compte de service de nœud GKE pour créer des jetons éphémères à la demande. Pour configurer les instantanés de pods avec cette approche, utilisez le champ tokenSource dans l'objet PodSnapshotStorageConfig avec l'une des valeurs suivantes :

  • podKSA (par défaut) : liaison IAM manuelle du KSA du pod au bucket Cloud Storage.
  • federatedP4SA : utilisez un jeton spécifique au chemin d'accès généré par le compte de service du nœud.

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 lorsque vous utilisez le champ d'application whole-pod par défaut. Les instantanés de système de fichiers (rootfs-only) sont compatibles avec les types de machines E2.
  • La compatibilité avec les GPU pour les instantanés de pods présente les exigences et limites suivantes :
    • Les pods à GPU unique sont compatibles avec les nœuds à GPU unique et à GPU multiples.
    • Les pods à GPU multiples ne sont compatibles qu'avec les GPU L4 (types de machines g2-standard-*).
    • Le partage de GPU avec le GPU multi-instance (MIG) n'est pas compatible.
    • Dans les versions de GKE 1.35.0-gke.1738000 et antérieures, un pod s'exécutant sur un nœud à GPU multiples 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.
    • Les instantanés de pods sont compatibles avec les types de machines 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)
  • 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 types de machines TPU.

Étape suivante