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 pods GKE et aux ressources associées.

Ces informations sont importantes pour les développeurs d'applications, ainsi que pour les administrateurs et les opérateurs de plate-forme qui utilisent des instantanés de pods pour créer des points de contrôle 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 contenu Cloud de Confiance by S3NS , consultez Rôles utilisateur et tâches courantes de GKE.

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

Si votre pod utilise un PersistentVolumeClaim (PVC), un risque important se produit lors du workflow "checkpoint and resume" : si vous configurez une charge de travail pour qu'elle reprenne immédiatement après un point de contrôle (en utilisant le 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 mettent en œuvre 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 le PVC.
  • Échec de la restauration : si ces modifications se produisent sur le PVC après la capture de l'instantané du pod, la procédure de restauration s'attend à ce que l'état du 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.
  • 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 point 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 installé à 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 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 à l'aide de 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 un 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. Vérifiez vos images de base pour vous assurer que les données critiques ne sont pas stockées dans des volumes implicites.