Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Déclencher un instantané de pod

Autopilot Standard

Découvrez comment créer des règles d'instantanés et déclencher un instantané de pod de vos charges de travail en cours d'exécution sur Google Kubernetes Engine (GKE).

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la gcloud components update commande. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Assurez-vous d'avoir rempli les prérequis et activé les instantanés de pod sur votre cluster. Pour en savoir plus, consultez Préparer les instantanés de pod.

Créer une règle d'instantanés

Pour activer les instantanés d'un pod, créez une ressource PodSnapshotPolicy avec un sélecteur qui correspond aux libellés du pod.

L'exemple suivant crée une règle qui s'applique aux pods portant le libellé app: my-app et utilise la configuration de stockage example-pod-snapshot-storage-config. Enregistrez le manifeste suivant sous le nom example-pod-snapshot-policy.yaml :
```
apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotPolicy
metadata:
  name: example-pod-snapshot-policy
  namespace: NAMESPACE
spec:
  storageConfigName: example-pod-snapshot-storage-config
  selector:
    matchLabels:
      app: my-app
  triggerConfig:
    type: TRIGGER_TYPE
    postCheckpoint: resume
```
Remplacez les éléments suivants :
- TRIGGER_TYPE : type de déclencheur. Les valeurs acceptées sont workload pour les déclencheurs basés sur la charge de travail ou manual pour les instantanés à la demande.
- NAMESPACE : espace de noms de vos pods.
Pour obtenir la liste complète de tous les champs que vous pouvez configurer, consultez la documentation sur la définition de ressource personnalisée (CRD) PodSnapshotPolicy.

Appliquez le fichier manifeste :

kubectl apply -f example-pod-snapshot-policy.yaml

Configurer des règles d'instantanés de pod supplémentaires

Vous pouvez configurer des règles supplémentaires dans votre PodSnapshotPolicy, telles que les suivantes :

Champ d'application de l'instantané : pour spécifier les parties de l'état du pod à capturer dans l'instantané, configurez le champ spec.snapshotScope. Les valeurs acceptées sont whole-pod (par défaut) pour enregistrer l'intégralité du pod, y compris l'état de l'application, la mémoire et les systèmes de fichiers, ou rootfs-only pour enregistrer uniquement le système de fichiers racine du conteneur. Le champ d'application rootfs-only nécessite GKE version 1.35.3-gke.1031000 ou ultérieure.
Nettoyage automatique : pour nettoyer automatiquement les anciennes ressources d'instantanés de pod, configurez une règle de conservation à l'aide du champ spec.retentionConfig. Vous pouvez spécifier une durée à l'aide du champ lastAccessTimeout (par exemple, 7d), après laquelle l'instantané est supprimé.
Organiser les instantanés : vous pouvez regrouper les instantanés de manière logique pour les différencier lorsqu'ils ont été pris dans des environnements similaires, mais dans des contextes différents. Par exemple, dans un scénario multilocataire où le pod de base est le même pour tous les utilisateurs, vous pouvez isoler les instantanés par utilisateur ou par groupe. Pour isoler les instantanés, spécifiez des libellés de regroupement dans la règle à l'aide du champ snapshotGroupingRules. Lorsqu'un pod est restauré, il ne correspond qu'aux instantanés du même groupe de libellés. Pour en savoir plus sur l'incidence de ce regroupement sur la correspondance de compatibilité lors de la restauration, consultez Correspondance des règles de regroupement.

L'exemple suivant montre comment configurer les paramètres de conservation et de regroupement dans votre PodSnapshotPolicy. Ces paramètres peuvent être définis indépendamment :

# ... other fields omitted
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

Pour obtenir la liste complète de tous les champs que vous pouvez configurer, consultez la documentation de référence sur PodSnapshotPolicy.

Optimiser la taille des instantanés

Lorsqu'un instantané de pod est déclenché, gVisor capture l'état complet de tous les conteneurs, y compris :

L'état de l'application, tel que la mémoire et les registres
Les modifications apportées au système de fichiers racine et à tmpfs (y compris les volumes emptyDir)
L'état du noyau, tel que les descripteurs de fichiers ouverts, les threads et les sockets

La taille de l'instantané est déterminée par ces facteurs. Plus les instantanés sont volumineux, plus ils prennent de temps à enregistrer et à restaurer. Pour optimiser les performances, avant de déclencher un instantané, vous devez nettoyer tout état ou fichier d'application qui n'est pas requis après la restauration du pod à partir de l'instantané.

L'optimisation de la taille des instantanés est particulièrement importante pour les charges de travail telles que les grands modèles de langage (LLM). Les serveurs LLM téléchargent souvent les poids du modèle dans le stockage local (rootfs ou tmpfs) avant de les charger dans le GPU. Lorsqu'un instantané est pris, l'état du GPU et les fichiers de poids du modèle sont enregistrés. Dans ce scénario, si le modèle est de 100 Go, l'instantané obtenu est d'environ 200 Go (100 Go de fichiers de modèle, plus 100 Go représentant l'état du GPU). Une fois les poids du modèle chargés dans le GPU, les fichiers du système de fichiers ne sont souvent pas nécessaires pour que l'application s'exécute. En supprimant ces fichiers de modèle avant de déclencher l'instantané, vous pouvez réduire de moitié la taille de l'instantané et restaurer l'application avec une latence nettement inférieure.

Déclencher un instantané

Vous pouvez déclencher un instantané à partir d'une charge de travail lorsque l'application est prête, ou vous pouvez déclencher manuellement un instantané à la demande pour un pod spécifique.

Déclencher un instantané à partir d'une charge de travail

Pour déclencher un instantané à partir du code de votre application, configurez votre application pour qu'elle envoie un signal lorsqu'elle est prête pour un instantané. Pour signaler que l'application est prête, écrivez 1 dans le fichier /proc/gvisor/checkpoint, par exemple echo 1 > /proc/gvisor/checkpoint. L'opération d'écriture démarre le processus d'instantané de manière asynchrone et renvoie immédiatement un résultat. La lecture à partir du même descripteur de fichier bloque le processus de lecture jusqu'à ce que l'instantané et la restauration soient terminés et que la charge de travail soit prête à reprendre.

L'utilisation exacte varie en fonction de votre application, mais l'exemple suivant montre un déclencheur d'instantané pour une application Python. Pour déclencher un instantané à partir de cet exemple de charge de travail, procédez comme suit :

Enregistrez le manifeste suivant sous le nom my-app.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: KSA_NAME
  runtimeClassName: gvisor
  containers:
  - name: my-container
    image: python:3.10-slim
    command: ["python3", "-c"]
    args:
      - |
        import time
        def trigger_snapshot():
          try:
            with open("/proc/gvisor/checkpoint", "r+") as f:
              f.write("1")
              res = f.read().rstrip()
              print(f"GKE Pod Snapshot: {res}")
          except FileNotFoundError:
            print("GKE Pod Snapshot file does not exist -- Pod Snapshots is disabled")
            return
        i = 0
        while True:
          print(f"Count: {i}", flush=True)
          if (i == 20): #simulate the application being ready to snapshot at 20th count
            trigger_snapshot()
          i += 1
          time.sleep(1)
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "250m"
        memory: "256Mi"

Remplacez les éléments suivants :

NAMESPACE : espace de noms de vos pods.
KSA_NAME : nom de votre KSA.

Pour déployer l'application, procédez comme suit :
```
kubectl apply -f my-app.yaml
```

Déclencher manuellement un instantané

Pour déclencher manuellement un instantané à la demande pour un pod spécifique, créez une ressource PodSnapshotManualTrigger.

L'exemple suivant déclenche un instantané pour un pod nommé my-pod. Enregistrez le manifeste suivant sous le nom example-manual-trigger.yaml :
```
apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotManualTrigger
metadata:
  name: example-manual-trigger
  namespace: NAMESPACE
spec:
  targetPod: my-pod
```
Remplacez NAMESPACE par l'espace de noms de votre pod.

Remarque : Le type de déclencheur de la règle d'instantanés qui sélectionne ce pod doit être défini sur manual.

Appliquez le fichier manifeste :

kubectl apply -f example-manual-trigger.yaml

Pour vérifier si l'instantané a été déclenché correctement, consultez le champ status de la ressource PodSnapshotManualTrigger :

kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io example-manual-trigger -n NAMESPACE -o yaml

Le champ status indique si le déclenchement de l'instantané a réussi ou échoué.

Vérifier les instantanés

Vous pouvez vérifier qu'un instantané a été pris en consultant l'historique des événements pour les événements GKEPodSnapshotting :

kubectl get events -o \
custom-columns=NAME:involvedObject.name,CREATIONTIME:.metadata.creationTimestamp,REASON:.reason,MESSAGE:.message \
--namespace NAMESPACE \
--field-selector involvedObject.name=POD_NAME,reason=GKEPodSnapshotting