Restaurer à partir d'un instantané de pod

Les instantanés de pods Google Kubernetes Engine (GKE) permettent d'améliorer la latence de démarrage des charges de travail en restaurant les instantanés des pods en cours d'exécution. Un instantané de pod enregistre l'état complet du pod, y compris la mémoire et les modifications apportées au système de fichiers racine. Lorsque de nouveaux réplicas sont créés, l'instantané est restauré au lieu d'initialiser le pod à partir d'un état vierge. Le pod reprend ensuite l'exécution à partir du point où l'instantané a été pris.

Ce document explique comment activer et configurer les snapshots de pods GKE pour vos charges de travail.

Pour en savoir plus sur le fonctionnement des instantanés de pods, consultez À propos des instantanés de pods.

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 la Google Cloud CLI pour cette tâche, installez et 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.

Activer les instantanés de pods

Pour activer les instantanés de pods, créez ou mettez à jour un cluster avec la fonctionnalité d'instantanés de pods activée. Pour les clusters Standard, vous devez également créer ou mettre à jour un pool de nœuds pour qu'il s'exécute dans GKE Sandbox. GKE Sandbox est compatible par défaut avec les clusters Autopilot.

Pour activer les instantanés de pods sur un cluster, effectuez l'une des procédures suivantes, en fonction du mode de fonctionnement GKE que vous souhaitez utiliser :

Autopilot

  • Pour activer les snapshots de pods sur un nouveau cluster, exécutez la commande suivante :

      gcloud container clusters create-auto CLUSTER_NAME \
      --enable-pod-snapshots \
      --location=CONTROL_PLANE_LOCATION \
      --cluster-version=CLUSTER_VERSION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • CONTROL_PLANE_LOCATION : emplacement du plan de contrôle de votre cluster.
    • CLUSTER_VERSION : version de votre nouveau cluster, qui doit être 1.35.3-gke.1234000 ou ultérieure.

  • Pour activer les snapshots de pods sur un cluster existant, procédez comme suit :

    1. Mettez à niveau le cluster vers la version 1.35.3-gke.1234000 ou ultérieure :

        gcloud container clusters upgrade CLUSTER_NAME \
      --cluster-version=CLUSTER_VERSION \
      --location=CONTROL_PLANE_LOCATION

      Remplacez les éléments suivants :

      • CLUSTER_NAME : nom du cluster
      • CONTROL_PLANE_LOCATION : emplacement du plan de contrôle de votre cluster.
      • CLUSTER_VERSION : version de votre nouveau cluster, qui doit être 1.35.3-gke.1234000 ou ultérieure.

    2. Activez les instantanés de pod sur votre cluster :

        gcloud container clusters update CLUSTER_NAME \
      --enable-pod-snapshots \
      --location=CONTROL_PLANE_LOCATION

Les snapshots de pods ne sont pas compatibles avec les types de machines E2. Dans Autopilot, GKE peut utiliser les nœuds E2 par défaut. Pour vous assurer que vos charges de travail s'exécutent sur du matériel compatible, vous devez utiliser une ComputeClass personnalisée pour hiérarchiser les familles de machines compatibles.

Pour créer et utiliser une ComputeClass personnalisée, procédez comme suit :

  1. Enregistrez le manifeste suivant sous le nom non-e2-class.yaml :

      apiVersion: cloud.google.com/v1
  kind: ComputeClass
  metadata:
    name: non-e2-class
  spec:
    priorities:
    - machineFamily: n2
    - machineFamily: c3
    activeMigration:
      optimizeRulePriority: false
    whenUnsatisfiable: DoNotScaleUp

  2. Appliquez le fichier manifeste :

      kubectl apply -f non-e2-class.yaml

  3. Dans la spécification de votre pod, référencez ComputeClass à l'aide du sélecteur de nœud cloud.google.com/compute-class :

      spec:
    nodeSelector:
      cloud.google.com/compute-class: non-e2-class
    ...

Standard

  • Pour activer les snapshots de pods sur un nouveau cluster, exécutez la commande suivante :

      gcloud container clusters create CLUSTER_NAME \
      --enable-pod-snapshots \
      --cluster-version=CLUSTER_VERSION \
      --workload-pool=PROJECT_ID.svc.id.goog \
      --workload-metadata=GKE_METADATA \
      --location=CONTROL_PLANE_LOCATION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • CLUSTER_VERSION : version de votre nouveau cluster, qui doit être 1.35.3-gke.1234000 ou ultérieure.
    • PROJECT_ID : ID de votre projet.
    • CONTROL_PLANE_LOCATION : emplacement du plan de contrôle de votre cluster.

  • Pour activer les snapshots de pods sur un cluster existant, procédez comme suit :

    1. Mettez à niveau le cluster vers la version 1.35.3-gke.1234000 ou ultérieure :

        gcloud container clusters upgrade CLUSTER_NAME \
      --node-pool=NODEPOOL_NAME \
      --cluster-version=CLUSTER_VERSION \
      --location=CONTROL_PLANE_LOCATION

      Remplacez les éléments suivants :

      • CLUSTER_NAME : nom du cluster
      • NODEPOOL_VERSION : nom de votre pool de nœuds.
      • CLUSTER_VERSION : version à utiliser pour mettre à jour votre nouveau cluster, qui doit être 1.35.3-gke.1234000 ou ultérieure.
      • CONTROL_PLANE_LOCATION : emplacement du plan de contrôle de votre cluster.

    2. Activez les instantanés de pod sur votre cluster :

      gcloud beta container clusters update CLUSTER_NAME \
   --enable-pod-snapshots \
   --location=CONTROL_PLANE_LOCATION

      Remplacez les éléments suivants :

      • PROJECT_ID par l'ID de votre projet.
      • CONTROL_PLANE_LOCATION : emplacement du plan de contrôle de votre cluster.

Pour exécuter des pods dans GKE Sandbox sur un cluster Standard, créez ou mettez à jour un pool de nœuds avec gVisor activé. Pour mettre à jour un pool de nœuds, utilisez l'option --sandbox type=gvisor. Pour créer un pool de nœuds avec gVisor activé, exécutez la commande suivante :

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --location=CONTROL_PLANE_LOCATION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Remplacez les variables suivantes :

  • NODE_POOL_NAME : nom de votre nouveau pool de nœuds.
  • NODE_VERSION : version à utiliser pour le pool de nœuds.
  • MACHINE_TYPE : type de machine à utiliser pour les nœuds.
  • CONTROL_PLANE_LOCATION : emplacement du plan de contrôle de votre cluster.

Pour en savoir plus sur l'utilisation de gVisor, consultez Isoler vos charges de travail à l'aide de GKE Sandbox.

Stocker des instantanés

Les instantanés de pods sont stockés dans un bucket Cloud Storage, qui contient l'état de la mémoire et (facultativement) du GPU. Les instantanés de pods nécessitent la fédération d'identité de charge de travail pour GKE afin d'activer et d'utiliser le compte de service du pod pour s'authentifier auprès de Cloud Storage.

Les instantanés de pods nécessitent la configuration suivante pour le bucket :

  • Espaces de noms hiérarchiques : ils doivent être activés pour permettre un nombre plus élevé de requêtes par seconde en lecture et en écriture. Les espaces de noms hiérarchiques nécessitent également que l'accès uniforme au niveau du bucket soit activé.
  • Suppression réversible : étant donné que les instantanés de pods utilisent les importations composites parallèles, vous devez désactiver les fonctionnalités de protection des données telles que la suppression réversible. Si vous ne la désactivez pas, la suppression des objets temporaires peut augmenter considérablement votre facture de stockage.
  • Emplacement : l'emplacement du bucket Cloud Storage doit être le même que celui du cluster GKE, car les performances peuvent être affectées si les instantanés sont transférés entre différentes régions.

Créer un bucket Cloud Storage

Pour créer le bucket et les autorisations requises, procédez comme suit :

  1. créer un bucket Cloud Storage ; La commande suivante crée un bucket avec la configuration requise :

    gcloud storage buckets create "gs://BUCKET_NAME" \
   --uniform-bucket-level-access \
   --enable-hierarchical-namespace \
   --soft-delete-duration=0d \
   --location="LOCATION"

    Remplacez les éléments suivants :

    • BUCKET_NAME : nom de votre bucket.
    • LOCATION : emplacement de votre bucket.

    Pour obtenir la liste complète des options de création de buckets, consultez les options de buckets create.

Accorder aux charges de travail l'autorisation d'accéder au bucket Cloud Storage

Par défaut, GKE n'est pas autorisé à accéder à Cloud Storage. Pour lire et écrire des fichiers instantanés, vous devez accorder des autorisations IAM au compte de service Kubernetes (KSA) utilisé par vos pods de charge de travail. Au lieu d'accorder des autorisations individuelles, vous pouvez accorder des jetons à durée de vie limitée.

  1. Obtenez des identifiants pour pouvoir communiquer avec votre cluster à l'aide des commandes kubectl :

    gcloud container clusters get-credentials "CLUSTER_NAME"

  2. Pour chaque pod, procédez comme suit :

    1. Créez un KSA pour chaque pod :

      kubectl create serviceaccount "KSA_NAME" \
    --namespace "NAMESPACE"

      Remplacez les éléments suivants :

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

    2. Accordez au KSA l'autorisation d'accéder au bucket :

      gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
    --role="roles/storage.bucketViewer"

      gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
    --role="roles/storage.objectUser"

      Remplacez les éléments suivants :

      • PROJECT_NUMBER : votre numéro de projet.
      • PROJECT_ID : ID de votre projet.

Activer l'architecture mutualisée à l'aide de jetons éphémères

Au lieu d'accorder des autorisations à des KSA individuels, vous pouvez activer le multitenancy à l'aide de jetons à durée de vie limitée et à portée restreinte. Cette approche permet d'éviter le délai de propagation associé aux liaisons IAM manuelles. Au lieu d'accorder des autorisations à chaque KSA, vous accordez une seule fois le rôle roles/storage.admin sur le bucket de stockage des instantanés au compte de service du nœud GKE. Le compte de service de nœud crée ensuite des jetons éphémères à la demande pour des chemins d'accès spécifiques.

Pour activer les jetons avec les instantanés de pod, vous devez disposer de GKE version 1.35.3-gke.1234000 ou ultérieure.

Pour activer le multitenancy, procédez comme suit :

  1. Pour autoriser le compte de service du nœud à accéder au bucket, exécutez la commande suivante :

    gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/storage.admin"

  2. Lorsque vous configurez le stockage des instantanés, définissez la valeur du champ tokenSource sur federatedP4SA.

Accorder l'autorisation de contrôleur pour accéder au bucket Cloud Storage

Pour permettre au contrôleur d'instantanés de pods de supprimer des instantanés dans un bucket Cloud Storage, l'agent de service GKE doit disposer de l'autorisation "Utilisateur d'objets Storage".

  1. Attribuez le rôle roles/storage.objectUser :

    gcloud projects add-iam-policy-binding "PROJECT_ID" \
  --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
  --role="roles/storage.objectUser" \
  --condition="expression=resource.name.startsWith(\"projects/_/buckets/BUCKET_NAME\"),title=restrict_to_bucket,description=Restricts access to one bucket only"

    Remplacez les éléments suivants :

    • PROJECT_NUMBER : votre numéro de projet.
    • PROJECT_ID : ID de votre projet.
    • BUCKET_NAME : nom de votre bucket.

(Facultatif) Créer des dossiers gérés pour le bucket Cloud Storage

La création de dossiers vous permet d'isoler les autorisations pour les instantanés des pods qui ne se font pas mutuellement confiance, ce qui est utile dans les cas d'utilisation multitenants. Pour configurer des dossiers gérés, procédez comme suit :

  1. Créez un rôle IAM personnalisé qui ne contient que les autorisations nécessaires pour les instantanés de pod :

    gcloud iam roles create podSnapshotGcsReadWriter \
    --project="PROJECT_ID" \
    --permissions="storage.objects.get,storage.objects.create,storage.objects.delete,storage.folders.create"

  2. Attribuez le rôle roles/storage.bucketViewer à tous les KSA dans l'espace de noms cible. Ce rôle permet aux ARM de lire les métadonnées des buckets, mais n'accorde pas d'autorisations de lecture ou d'écriture pour les objets du bucket.

    gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE" \
    --role="roles/storage.bucketViewer"

    Remplacez les éléments suivants :

    • PROJECT_NUMBER : votre numéro de projet.
    • PROJECT_ID : ID de votre projet.

  3. Pour chaque KSA qui doit stocker des instantanés de pod, procédez comme suit :

    1. Créez un dossier géré pour le KSA :

      gcloud storage managed-folders create "gs://BUCKET_NAME/FOLDER_PATH/"

      Remplacez FOLDER_PATH par le chemin d'accès au dossier géré, par exemple my-app-snapshots.

    2. Attribuez au compte de service géré le rôle personnalisé podSnapshotGcsReadWriter sur le dossier géré :

      gcloud storage managed-folders add-iam-policy-binding "gs://BUCKET_NAME/FOLDER_PATH/" \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
    --role="projects/PROJECT_ID/roles/podSnapshotGcsReadWriter"

      Remplacez KSA_NAME par le nom du KSA.

Configurer le stockage des instantanés

Pour spécifier où stocker les fichiers d'instantané, créez une ressource PodSnapshotStorageConfig.

  1. L'exemple suivant configure GKE pour stocker les instantanés de pods dans le chemin d'accès FOLDER_PATH/ à l'intérieur du bucket Cloud Storage BUCKET_NAME. Enregistrez le manifeste suivant sous le nom example-pod-snapshot-storage-config :

    apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotStorageConfig
metadata:
  name: example-pod-snapshot-storage-config
spec:
  snapshotStorageConfig:
    gcs:
      bucket: "BUCKET_NAME"
      path: "FOLDER_PATH"
      tokenSource: "TOKEN_SOURCE"

    Remplacez les éléments suivants :

    • BUCKET_NAME : nom du bucket Cloud Storage.
    • FOLDER_PATH : chemin d'accès au dossier géré Cloud Storage.
    • TOKEN_SOURCE : fournisseur d'identité pour l'accès. Utilisez podKSA (par défaut) ou federatedP4SA pour l'architecture mutualisée.

  2. Appliquez le fichier manifeste :

    kubectl apply -f example-pod-snapshot-storage-config.yaml

Créer une règle d'instantané

Pour activer les snapshots pour un pod, créez une ressource PodSnapshotPolicy avec un sélecteur correspondant aux libellés du pod.

  1. L'exemple suivant crée une règle qui s'applique aux pods portant le libellé app: my-app et qui 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 TRIGGER_TYPE par le 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.

    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.

  2. Appliquez le fichier manifeste :

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

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

Vous pouvez configurer d'autres règles dans votre PodSnapshotPolicy, par exemple :

  • Nettoyage automatique : pour libérer automatiquement de l'espace en supprimant les anciennes ressources de snapshots de pods, 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 de ceux qui ont été pris dans des environnements similaires, mais dans des contextes différents. Par exemple, dans un scénario multitenant où le pod de base peut être identique 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.

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

# ... other fields omitted
spec:
  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 CRD 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 :

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

La taille de l'instantané dépend de ces facteurs. Les instantanés plus volumineux mettent plus de temps à être enregistrés et restaurés. Pour optimiser les performances, avant de déclencher un instantané, vous devez nettoyer tout état ou fichier d'application qui ne sont pas nécessaires après la restauration du pod à partir de l'instantané.

L'optimisation de la taille des snapshots 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 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 pondérations du modèle sont enregistrés. Dans ce scénario, si le modèle fait 100 Go, le snapshot obtenu fera environ 200 Go (100 Go de fichiers de modèle, plus 100 Go représentant l'état du GPU). Une fois les pondérations du modèle chargées dans le GPU, les fichiers du système de fichiers ne sont souvent plus nécessaires pour l'exécution de l'application. 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 considérablement réduite.

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 le service est prêt, é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. La lecture à partir du même descripteur de fichier bloquera 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 de snapshot pour une application Python. Pour déclencher un instantané à partir de cet exemple de charge de travail, procédez comme suit :

  1. 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
          except OSError as e:
            return e
        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"

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

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

  2. Appliquez le fichier manifeste :

    kubectl apply -f example-manual-trigger.yaml --namespace NAMESPACE

Pour vérifier si l'instantané a bien été déclenché, 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 du snapshot a réussi ou échoué.

Valider des instantanés

Pour vérifier qu'un instantané a été pris, consultez 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

Remplacez POD_NAME par le nom de votre pod, par exemple my-app ou my-pod.

Le résultat se présente comme suit :

NAME                                    CREATIONTIME           REASON               MESSAGE
default/5b449f9c7c-bd7pc                2025-11-05T16:25:11Z   GKEPodSnapshotting   Successfully checkpointed the pod to PodSnapshot

Gérer les instantanés

Lorsque vous créez un instantané de pod, une ressource CRD PodSnapshot est créée pour stocker l'état du pod à ce moment-là. Le champ status de cette ressource indique si l'opération d'instantané a réussi et si l'instantané est disponible pour les restaurations.

Pour afficher toutes les ressources PodSnapshot dans un espace de noms, exécutez la commande suivante :

kubectl get podsnapshots.podsnapshot.gke.io --namespace NAMESPACE

Le résultat se présente comme suit :

NAME                                   STATUS                  POLICY           AGE
de334898-1e7a-4cdb-9f2e-7cc2181c29e4   AllSnapshotsAvailable   example-policy   47h

Restaurer une charge de travail à partir d'un instantané

Pour restaurer votre charge de travail à partir du dernier instantané, vous pouvez supprimer le pod existant après la création d'un instantané, puis redéployer le pod. Vous pouvez également déployer un nouveau pod avec une spécification identique. GKE restaure automatiquement le pod à partir de l'instantané correspondant.

Les étapes suivantes montrent comment un pod est restauré à partir d'un instantané correspondant en supprimant et en redéployant le pod :

  1. Supprimez le pod :

    kubectl delete -f POD_NAME.yaml

    Remplacez POD_NAME par le nom de votre pod, par exemple my-app.

  2. Appliquez à nouveau le pod :

    kubectl apply -f POD_NAME.yaml

  3. Consultez les journaux pour confirmer la restauration de l'instantané :

    kubectl logs my-app --namespace NAMESPACE

    Le résultat dépend de la façon dont vous avez configuré votre application. Dans l'exemple d'application, les journaux affichent GKE Pod Snapshot: restore lorsqu'une opération de restauration se produit.

Restaurer à partir d'un instantané spécifique

Par défaut, GKE restaure les charges de travail à partir de la ressource PodSnapshot la plus récente correspondant au pod. Lorsqu'un instantané est pris, GKE génère automatiquement un nom unique (UUID) pour la ressource PodSnapshot, que vous pouvez afficher en exécutant kubectl get podsnapshots.gke.io --namespace NAMESPACE.

Pour restaurer une charge de travail à partir d'une ressource PodSnapshot plus ancienne ou spécifique, ajoutez l'annotation podsnapshot.gke.io/ps-name à la spécification de pod de votre charge de travail, en spécifiant le nom de la ressource PodSnapshot à utiliser pour restaurer la charge de travail :

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
  annotations:
    podsnapshot.gke.io/ps-name: "POD_SNAPSHOT_NAME"
spec:
  serviceAccountName: KSA_NAME
  runtimeClassName: gvisor
  containers:
  ...

Remplacez POD_SNAPSHOT_NAME par le nom de l'instantané à partir duquel vous souhaitez effectuer la restauration. Vous pouvez obtenir les noms des instantanés en exécutant la commande kubectl get podsnapshots.gke.io --namespace NAMESPACE.

Pour que GKE utilise l'instantané spécifié pour la restauration, l'état de la ressource PodSnapshot doit être Ready et exister dans le même espace de noms que le pod. Si PodSnapshot n'est pas Ready ou n'existe pas dans le même espace de noms que le pod, la charge de travail effectue un démarrage à froid au lieu d'une restauration à partir d'un instantané.

Désactiver les instantanés

La suppression du CRD PodSnapshotPolicy empêche la création d'instantanés et la restauration des pods. Les pods en cours d'exécution ne sont pas affectés par la suppression des ressources. Toutefois, si vous supprimez la règle pendant qu'un pod est en cours d'enregistrement ou de restauration, il est possible qu'il passe à l'état "Échec".

Pour désactiver la création et la restauration d'instantanés pour les nouveaux pods régis par une règle, supprimez PodSnapshotPolicy en exécutant la commande suivante :

kubectl delete podsnapshotpolicies.podsnapshot.gke.io SNAPSHOT_POLICY --namespace=NAMESPACE

Remplacez SNAPSHOT_POLICY par le nom de l'PodSnapshotPolicy que vous souhaitez supprimer, par exemple example-pod-snapshot-policy.

Vous pouvez également supprimer une ressource PodSnapshot spécifique afin que les pods ne soient plus restaurés à partir de cet instantané. La suppression de la ressource PodSnapshot supprime également les fichiers stockés dans Cloud Storage.

Pour empêcher l'utilisation d'un instantané spécifique pour les restaurations futures, supprimez l'objet PodSnapshot en exécutant la commande suivante :

kubectl delete podsnapshots.podsnapshot.gke.io POD_SNAPSHOT_NAME --namespace=NAMESPACE

Remplacez POD_SNAPSHOT_NAME par le nom de l'instantané que vous souhaitez supprimer, par exemple example-podsnapshot.

Dépannage

La section suivante contient des informations pour vous aider à résoudre les problèmes courants liés aux snapshots de pods.

Risques de mutation post-point de contrôle avec les PVC

Un risque important se produit lors du workflow "checkpoint and resume" si votre pod utilise un PersistentVolumeClaim (PVC). Si vous configurez une charge de travail pour qu'elle reprenne immédiatement après un point de contrôle (à l'aide du champ postCheckpoint: resume), l'application reste active et peut modifier le PVC après le point de contrôle.

  • Problème d'arrêt progressif : après le cycle de point de contrôle et de reprise, lorsque vous supprimez un pod, Kubernetes lance une séquence d'arrêt progressif en envoyant un signal SIGTERM au processus principal du conteneur. De nombreuses applications implémentent une logique d'arrêt progressif au cours de laquelle elles peuvent déclencher des routines de nettoyage, en supprimant ou en mettant à jour des fichiers temporaires sur le PVC.
  • Échec de la restauration : si ces modifications se produisent sur le PVC après la création de l'instantané du pod, la procédure de restauration s'attend à ce que l'état du PVC soit tel qu'il existait au moment exact du point de contrôle, ce qui peut entraîner des échecs de restauration ou une incohérence des données.
  • Solution recommandée : Si l'utilisation d'un PVC est nécessaire pour la charge de travail, ne reprenez pas la charge de travail après un point de contrôle. Utilisez la configuration postCheckpoint: stop dans votre PodSnapshotPolicy. Cette configuration permet de s'assurer que le processus n'a pas la possibilité d'effectuer des écritures auxiliaires ni de modifier l'état une fois la phase de création de points de contrôle terminée.

Montages ConfigMap et masquage de répertoire

Lorsque vous intégrez des données de configuration dans un conteneur, la méthode de montage peut avoir un impact sur l'intégrité d'un instantané.

Si un ConfigMap est monté à l'aide d'un montage de volume standard, Kubernetes traite l'intégralité du répertoire cible comme un montage externe. Étant donné que les montages externes sont ignorés lors des instantanés, l'intégralité du répertoire est exclue de l'instantané.

Dans l'exemple suivant, les modifications apportées au répertoire /etc/my-app/ ne sont pas capturées dans l'instantané, car l'intégralité du répertoire est un montage externe :

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config.json: |
    {
      "mode": "local"
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: gvisor
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - mountPath: /etc/my-app
          name: config-volume
  volumes:
    - name: config-volume
      configMap:
        name: my-config

Pour résoudre ce problème, utilisez un subPath. Un subPath permet de s'assurer que seul le fichier de configuration spécifique est traité comme un montage externe. Cette configuration cible le fichier exact, ce qui permet aux fichiers et à la structure restants du répertoire parent de rester dans le système de fichiers local du conteneur, qui est correctement capturé lors du processus de point de contrôle.

L'exemple suivant montre la configuration volumeMounts à l'aide d'un subPath :

      volumeMounts:
        - mountPath: /etc/my-app/config.json
          name: config-volume
          subPath: config.json

Volumes anonymes implicites

Certaines images de conteneur définissent des volumes dans leurs métadonnées (via l'instruction VOLUME dans le fichier Dockerfile). Même si la spécification de votre pod ne définit pas de volume, Kubernetes crée automatiquement un volume anonyme pour tout chemin défini comme volume dans l'image de base. Par exemple, l'image alpine/git définit /git comme volume implicite.

Ces volumes anonymes sont traités comme des montages externes et, comme les PVC, ne sont pas mis en point de contrôle. Nous vous recommandons de vérifier vos images de base et de vous assurer qu'aucune donnée critique n'est stockée dans ces volumes implicites.

Étapes suivantes