Soluciona problemas relacionados con las instantáneas de Pods

En este documento, se muestra cómo resolver problemas comunes con las instantáneas de Pods de GKE 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 Pods para realizar puntos de control y restablecer cargas de trabajo. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el Cloud de Confiance by S3NS contenido de, consulta Roles y tareas comunes del usuario de GKE y tareas.

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

Si tu Pod usa una Persistent Volume Claim (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 mediante el envío de un SIGTERM indicador 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 la PVC.
• Falla de restablecimiento: Si estos cambios ocurren 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 generará posibles fallas de restablecimiento o incoherencia 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 o cambios de estado después de que se complete la fase de punto de control.

Montajes de ConfigMap y enmascaramiento de directorios

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

Si se monta un ConfigMap con un montaje de volumen estándar, Kubernetes trata todo el directorio de destino como un montaje externo. Debido a que los montajes externos 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 un montaje externo. Esta configuración apunta al archivo exacto, lo que permite que los archivos y la estructura restantes dentro del directorio superior sigan formando parte del sistema de archivos local del contenedor, que se captura correctamente durante el proceso de punto de control.

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

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

Volúmenes anónimos implícitos

Ciertas 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 de tu Pod no define un volumen, Kubernetes crea automáticamente un volumen anónimo para cualquier ruta de acceso definida como un 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 montajes externos y, al igual que las PVCs, no se les realiza un punto de control. Verifica tus imágenes base para asegurarte de que los datos críticos no se almacenen en volúmenes implícitos.