Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

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

Pour réduire la latence de démarrage des charges de travail Google Kubernetes Engine (GKE), vous pouvez prendre un instantané d'un pod en cours d'exécution et restaurer de nouveaux pods à partir de celui-ci. Ce document explique comment créer une règle d'instantané de pod et déclencher un instantané, soit à partir de votre charge de travail, soit manuellement. Pour en savoir plus sur le fonctionnement des instantanés de pods, consultez À propos des instantanés de pods GKE.

Les administrateurs et opérateurs de plate-forme, ainsi que les développeurs d'applications, peuvent utiliser ce document pour configurer des règles d'instantanés et déclencher des instantanés. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Cloud de Confiance by S3NS, consultez Rôles utilisateur et tâches courantes de GKE.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Pour utiliser la 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 commande gcloud components update. 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.

Remplissez les conditions préalables et activez les instantanés de pods sur votre cluster. Pour en savoir plus sur la préparation de votre cluster et de votre stockage, consultez Se préparer aux instantanés de pods.

Créer une stratégie d'instantanés

Pour activer les instantanés pour un pod, créez une ressource personnalisée PodSnapshotPolicy avec un sélecteur correspondant aux étiquettes du pod :

Enregistrez le fichier manifeste suivant sous le nom example-pod-snapshot-policy.yaml. Cet exemple crée une règle qui s'applique aux pods portant l'étiquette app: my-app. La règle utilise la ressource personnalisée example-pod-snapshot-storage-config PodSnapshotStorageConfig, que vous avez créée dans Préparer les instantanés de pods, pour définir l'emplacement de stockage des instantanés :
```
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 :
- NAMESPACE : espace de noms de vos pods. Utilisez le même espace de noms que celui auquel vous avez accordé l'accès à Cloud Storage dans Préparer les instantanés de pods.
- 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.
Dans cet exemple, le paramètre postCheckpoint: resume permet de maintenir le pod en cours d'exécution après que GKE a pris l'instantané.

Pour obtenir la liste complète des champs que vous pouvez configurer, consultez la spécification PodSnapshotPolicy.

Appliquez le fichier manifeste :

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

Configurer des paramètres supplémentaires pour la règle d'instantané de pod

Votre ressource personnalisée PodSnapshotPolicy accepte également des paramètres facultatifs en plus du sélecteur, de la configuration de stockage et du déclencheur requis. Ces paramètres supplémentaires contrôlent ce que chaque instantané capture, la durée pendant laquelle GKE conserve les instantanés et la manière dont GKE regroupe les instantanés pour les restaurations :

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) et rootfs-only. Le champ d'application whole-pod capture l'intégralité du pod, y compris l'état de l'application, la mémoire et les systèmes de fichiers. Le champ d'application rootfs-only ne capture que 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 personnalisées PodSnapshot, 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). Une fois ce délai écoulé, GKE supprime l'instantané.
Regroupement d'instantanés : pour isoler les instantanés pris dans des environnements similaires, mais dans des contextes différents, spécifiez des étiquettes de regroupement dans le champ spec.snapshotGroupingRules. Par exemple, dans un scénario mutualisé où le pod de base est le même pour tous les utilisateurs, vous pouvez isoler les instantanés par utilisateur ou par groupe. Lors d'une restauration, GKE ne sélectionne un instantané que dans le même groupe d'étiquettes. Pour en savoir plus sur l'impact de ce regroupement sur la correspondance de compatibilité lors de la restauration, consultez Correspondance des règles de regroupement.

Vous pouvez configurer indépendamment les paramètres de portée, de conservation et de regroupement des instantanés. L'exemple suivant montre les trois paramètres d'une ressource personnalisée PodSnapshotPolicy :

# Multiple lines are omitted here
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

Pour obtenir la liste complète des champs que vous pouvez configurer, consultez la spécification PodSnapshotPolicy.

Optimiser la taille des instantanés

Les instantanés plus volumineux prennent plus de temps à enregistrer et à restaurer. Avant de déclencher un instantané, réduisez sa taille en supprimant les fichiers temporaires ou l'état de l'application dont votre application n'a pas besoin après que GKE a restauré le pod à partir de l'instantané.

Avec le champ d'application d'instantané whole-pod par défaut, GKE Sandbox capture l'état complet de tous les conteneurs, y compris les éléments suivants :

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

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 pondérations du modèle dans un espace de stockage local (rootfs ou tmpfs) avant de les charger dans le GPU. Lorsque vous prenez un instantané, GKE Sandbox enregistre à la fois l'état du GPU et les fichiers de pondérations du modèle. Dans ce scénario, si le modèle fait 100 Go, l'instantané obtenu fait environ 200 Go (100 Go de fichiers de modèle, plus 100 Go représentant l'état du GPU). Une fois que l'application a chargé les pondérations du modèle dans le GPU, elle n'a souvent pas besoin des fichiers du système de fichiers pour s'exécuter. 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é

Choisissez l'une des méthodes suivantes pour déclencher un instantané :

Déclencheur de charge de travail : utilisez cette méthode lorsque vous pouvez modifier votre application pour signaler qu'elle est prête pour un instantané, par exemple une fois l'initialisation terminée. Cette méthode est idéale pour améliorer la latence de démarrage des charges de travail à scaling horizontal. Un déclencheur de charge de travail ne s'exécute qu'une seule fois dans un cycle de charge de travail.
Déclencheur manuel : utilisez cette méthode lorsque vous ne pouvez pas modifier votre application pour signaler son aptitude ou lorsque vous souhaitez obtenir des instantanés à la demande d'un pod spécifique. Vous pouvez créer un déclencheur manuel autant de fois que nécessaire.

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 l'aptitude, écrivez la valeur 1 dans le fichier /proc/gvisor/checkpoint, par exemple en exécutant la commande 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'opération d'instantané ou de restauration soit terminée et que la charge de travail soit prête à reprendre.

Avant de déclencher un instantané à partir d'une charge de travail, assurez-vous qu'une règle d'instantané sélectionne le pod. La valeur du champ triggerConfig.type de cette règle doit être définie sur workload.

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 fichier manifeste suivant sous le nom my-app.yaml. Dans cet exemple, l'étiquette app: my-app correspond au sélecteur de l'exemple de règle d'instantané, et le paramètre runtimeClassName: gvisor exécute le pod dans GKE Sandbox :

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: SERVICEACCOUNT_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 readiness at the 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.
SERVICEACCOUNT_NAME : nom de l'objet ServiceAccount auquel vous avez accordé l'accès à Cloud Storage dans Se préparer aux instantanés de pods.

Pour déployer l'application, procédez comme suit :
```
kubectl apply -f my-app.yaml
```
Une fois que l'application démarre et signale qu'elle est prête, GKE Sandbox prend l'instantané. Pour vérifier que l'instantané a bien été créé, consultez Vérifier les instantanés.

Déclencher un instantané manuellement

Avant de déclencher manuellement un instantané, assurez-vous que le pod cible est en cours d'exécution et qu'une règle d'instantané sélectionne le pod. La valeur du champ triggerConfig.type de cette règle doit être définie sur manual.

Pour déclencher manuellement un instantané à la demande pour un pod spécifique, créez une ressource personnalisée PodSnapshotManualTrigger en procédant comme suit :

Enregistrez le fichier manifeste suivant sous le nom example-manual-trigger.yaml. Cet exemple déclenche un instantané pour un pod nommé my-pod :
```
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 vos pods.

Appliquez le fichier manifeste :

kubectl apply -f example-manual-trigger.yaml

Pour vérifier que l'instantané a bien été déclenché, consultez la section status de la ressource personnalisée PodSnapshotManualTrigger :
```
kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io \
    example-manual-trigger \
    --namespace NAMESPACE -o yaml
```
Remplacez NAMESPACE par l'espace de noms de vos pods.

Si le déclencheur a réussi, le champ status.conditions indique que le point de contrôle est terminé et le champ status.snapshotCreated affiche le nom de la ressource personnalisée PodSnapshot créée.

Vérifier les instantanés

Pour confirmer que GKE a pris un instantané, vérifiez 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