Soluciona problemas relacionados con las instantáneas de Pods

En este documento, se muestra cómo resolver problemas habituales con las instantáneas de GKE Pod y sus recursos asociados.

Esta información es importante para los desarrolladores de aplicaciones y los administradores y operadores de plataformas que usan instantáneas de Pod para crear puntos de control y restablecer cargas de trabajo. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que hacemos referencia en el contenido de Cloud de Confiance by S3NS , consulta Roles y tareas comunes del usuario de GKE.

Riesgos de mutación posteriores al punto de control con PVC

Si tu Pod usa una PersistentVolumeClaim (PVC), se produce un riesgo significativo durante el flujo de trabajo de "punto de control y reanudación": Si configuras una carga de trabajo para que se reanude inmediatamente después de un punto de control (con el campo postCheckpoint: resume), la aplicación permanece activa y puede modificar la PVC después del punto de control.

  • Problema de cierre ordenado: Después del ciclo de punto de control y reanudación, cuando borras un Pod, Kubernetes inicia una secuencia de cierre ordenado enviando un indicador SIGTERM al proceso principal del contenedor. Muchas aplicaciones implementan una lógica de cierre ordenado durante la cual pueden activar rutinas de limpieza para borrar o actualizar archivos temporales en el PVC.
  • Falla de restablecimiento: Si estos cambios se producen en la PVC después de que se toma la instantánea del Pod, el procedimiento de restablecimiento esperará el estado de la PVC tal como existía en el momento exacto del punto de control, lo que podría provocar fallas de restablecimiento o inconsistencia de datos.
  • Mitigación recomendada: Si es necesario usar una PVC para la carga de trabajo, no la reanudes después de un punto de control. Usa la configuración postCheckpoint: stop en tu PodSnapshotPolicy. Esta configuración ayuda a garantizar que el proceso no tenga la oportunidad de realizar escrituras auxiliares ni cambios de estado después de que se complete la fase de creación de puntos de control.

Activaciones de ConfigMap y enmascaramiento de directorios

Cuando se integran datos de configuración en un contenedor, el método de activación puede afectar la integridad de una instantánea.

Si un ConfigMap se activa con un activador de volumen estándar, Kubernetes trata todo el directorio de destino como un activador externo. Debido a que las activaciones externas se omiten durante las instantáneas, todo el directorio se excluye de la instantánea.

En el siguiente ejemplo, no se capturan los cambios en el directorio /etc/my-app/ en la instantánea porque todo el directorio es un montaje externo:

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

Para resolver este problema, usa un subPath. Un subPath ayuda a garantizar que solo el archivo de configuración específico se trate como una activación externa. Esta configuración apunta al archivo exacto, lo que permite que los archivos y la estructura restantes dentro del directorio superior sigan siendo parte del sistema de archivos local del contenedor, que se captura correctamente durante el proceso de creación de puntos de control.

En el siguiente ejemplo, se muestra la configuración de volumeMounts que usa un subPath:

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

Volúmenes anónimos implícitos

Algunas imágenes de contenedor definen volúmenes dentro de sus metadatos a través de la instrucción VOLUME en el Dockerfile. Incluso si la especificación del Pod no define un volumen, Kubernetes crea automáticamente un volumen anónimo para cualquier ruta de acceso definida como volumen en la imagen base. Por ejemplo, la imagen alpine/git define /git como un volumen implícito.

Estos volúmenes anónimos se tratan como puntos de montaje externos y, al igual que los PVC, no se guardan en puntos de control. Verifica tus imágenes base para asegurarte de que los datos críticos no se almacenen en volúmenes implícitos.