Résoudre les problèmes liés aux instantanés de pods

Ce document explique comment résoudre les problèmes courants liés aux instantanés de pod GKE et aux ressources associées.

Ces informations sont importantes pour les développeurs d'applications, les administrateurs de plate-forme et les opérateurs qui utilisent des instantanés de pod pour vérifier et restaurer des charges de travail. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le Google Cloud contenu, consultez Rôles utilisateur et tâches courantes de GKE.

Risques de mutation post-checkpoint avec les PVC

Si votre pod utilise une revendication de volume persistant (PVC), un risque important se produit lors du workflow "checkpoint and resume" (vérification et reprise) : 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 la PVC après le point de contrôle.

  • Problème d'arrêt progressif : après le cycle de vérification 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 pour supprimer ou mettre à jour des fichiers temporaires sur la PVC.
  • Échec de la restauration : si ces modifications se produisent sur la PVC après la création de l'instantané du pod, la procédure de restauration s'attend à ce que l'état de la PVC soit celui qui 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.
  • Atténuation recommandée : si l'utilisation d'une 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 point de contrôle terminée.

Points d'installation ConfigMap et masquage de répertoire

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

Si un ConfigMap est installé à l'aide d'un point d'installation de volume standard, Kubernetes traite l'intégralité du répertoire cible comme un point d'installation externe. Étant donné que les points d'installation 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 point d'installation 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 point d'installation 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 qui utilise 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 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 points d'installation externes et, comme les PVC, ne sont pas vérifiés. Vérifiez vos images de base pour vous assurer que les données critiques ne sont pas stockées dans des volumes implicites.