Soluciona problemas de errores de almacenamiento en Copia de seguridad para GKE

En esta página, se describen los errores relacionados con el almacenamiento que puedes experimentar cuando usas Copia de seguridad para GKE, los aspectos que debes tener en cuenta cuando realizas la acción y los pasos para solucionar el problema.

Error 100010105: No se pudo crear una copia de seguridad de PersistentVolumeClaim. No existe el disco al que hace referencia PersistentVolume.

El error 100010105 se produce cuando falla un intento de crear una copia de seguridad de un PersistentVolumeClaim porque hace referencia a un disco que no existe, lo que genera un mensaje de error que indica Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist.

En Google Kubernetes Engine, PersistentVolumeClaims solicita almacenamiento de PersistentVolumes. A su vez, un PersistentVolume representa una unidad de almacenamiento, a menudo un disco persistente subyacente de Compute Engine. Se puede producir un error cuando un PersistentVolumeClaim está vinculado a un PersistentVolume y la configuración del PersistentVolume especifica un disco persistente de Compute Engine. Sin embargo, no se puede encontrar el disco real con el nombre y la ubicación especificados en la configuración de PersistentVolume en tu proyecto de Cloud de Confiance by S3NS . Por lo tanto, la copia de seguridad para GKE no puede continuar con la copia de seguridad de un disco inexistente y se produce un error.

Para resolver este error, sigue estas instrucciones:

  1. Identifica los PersistentVolumeClaim y PersistentVolume problemáticos. Los nombres del PersistentVolumeClaim problemático y su PersistentVolume asociado se enumeran en el campo state reason de la operación de Copia de seguridad para GKE fallida. Recomendamos documentar el nombre de PersistentVolumeClaim, su espacio de nombres y el nombre de PersistentVolume.

  2. Inspecciona el PersistentVolume. Para describir el PersistentVolume, usa el nombre PersistentVolume que identificaste en el campo de motivo del estado en el siguiente comando:

    kubectl describe pv PERSISTENTVOLUME_NAME

    Reemplaza PERSISTENTVOLUME_NAME por el nombre de tu PersistentVolume.

  3. En el resultado, examina la sección source, específicamente en csi. En esta sección, se describe el VolumeHandle al que intenta hacer referencia el PersistentVolume. Por ejemplo:

    Source:
  Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
PDName: my-non-existent-disk
FSType: ext4
Partition: 0
ReadOnly: false
            In this example, the PD name is my-non-existent-disk.

    Source:
  Type:       CSI (a Container Storage Interface (CSI) volume)
  Driver:     pd.csi.storage.gke.io
  VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
...

    En este ejemplo, VolumeHandle contiene la ruta de acceso completa al disco, incluidos su nombre y ubicación. Por ejemplo, projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name.

  4. Usa el VolumeHandle que obtuviste de la descripción de PersistentVolume para identificar el nombre y la zona del disco.

  5. Verifica que el disco exista en tu proyecto Cloud de Confiance by S3NS con uno de los siguientes métodos:

    Disco zonal

    Si usas un disco zonal, usa Google Cloud CLI para ejecutar el comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

    Reemplaza lo siguiente:

    • DISK_NAME: Es el nombre del disco que obtuviste de la descripción de PersistentVolume.

    • ZONE_NAME: Es la zona del disco que obtuviste de la descripción de PersistentVolume.

    • PROJECT_ID: Es el ID del proyecto de Cloud de Confiance by S3NS .

    Disco regional

    Si usas un disco regional, usa Google Cloud CLI para ejecutar el comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
    --region=REGION_NAME \
    --project=PROJECT_ID

    Reemplaza lo siguiente:

    • DISK_NAME: Es el nombre del disco que obtuviste de la descripción de PersistentVolume.

    • REGION_NAME: Es la región del disco que obtuviste de la descripción de PersistentVolume.

    • PROJECT_ID: Es el ID del proyecto de Cloud de Confiance by S3NS .

    Si recibes un mensaje de error Resource not found o The resource DISK_NAME was not found, significa que el disco no existe. Usa uno de los siguientes métodos para resolver el problema según la situación que mejor se adapte a tus necesidades:

    • Si el disco se borró o se nombró incorrectamente por accidente y quieres conservar los datos o PersistentVolumeClaim, o si el PersistentVolume se configuró con un nombre de disco incorrecto, usa uno de los siguientes métodos para resolver el problema:

      • Restablece el disco: Si tienes una copia de seguridad del disco, restablécela con el mismo nombre y ubicación a los que hace referencia PersistentVolume.

      • Crea un disco nuevo: Si no es posible restablecer el disco, crea uno nuevo con el mismo nombre y ubicación que se encuentran en la configuración de PersistentVolume.

    • Si ya no se necesitan el PersistentVolumeClaim o el PersistentVolume, sus datos o la aplicación, te recomendamos que quites la entidad innecesaria:

      • Borra el PersistentVolumeClaim: Borra el PersistentVolumeClaim con la herramienta de línea de comandos kubectl para ejecutar el comando kubectl delete pvc:
      kubectl delete pvc PVC_NAME -n NAMESPACE

      Reemplaza lo siguiente:

      • PVC_NAME: Es el nombre del PersistentVolumeClaim que deseas borrar.

      • NAMESPACE: Es el espacio de nombres del objeto PersistentVolumeClaim que deseas borrar.

    • El PersistentVolume sigue presente después de que borras el PersistentVolumeClaim: Si el PersistentVolumeReclaimPolicy del PersistentVolume está configurado como Delete, el PersistentVolume se borra automáticamente cuando se borra el PersistentVolumeClaim. Si persistentVolumeReclaimPolicy está configurado como Retain, debes borrar manualmente PersistentVolume después de que se borre PersistentVolumeClaim. Para borrar PersistentVolume, usa la herramienta de línea de comandos kubectl para ejecutar el comando kubectl delete pv:

      kubectl delete pv PV_NAME

      Reemplaza PV_NAME por el nombre del PersistentVolume que deseas borrar.

Si la operación sigue fallando, comunícate con Atención al cliente de Cloud para obtener más ayuda.

Error 100010202: No se pudo crear la instantánea del volumen

El error 100010202 se produce cuando falla la creación de la instantánea del Persistent Disk de Compute Engine, lo que genera un mensaje de error que indica Snapshotting volume failed.

Una operación de Instant Snapshot de disco persistente de Compute Engine falla si el estado de conexión del disco a una instancia de máquina virtual (VM) cambia durante el proceso de creación de la Instant Snapshot que inicia el servicio de Copia de seguridad para GKE. Algunos casos comunes que activan este mensaje son los siguientes:

  • Reparación automática de nodos: Se recrean los nodos en mal estado, lo que provoca que se vuelvan a programar los Pods y que los discos se desconecten y vuelvan a conectar.
  • Actualizaciones de nodos: Durante las actualizaciones de grupos de nodos, los nodos suelen vaciarse y reemplazarse. Los Pods se terminan de forma ordenada y se reprograman en los nodos nuevos, lo que activa ciclos de desconexión y reconexión de discos.
  • Ajuste de escala automático del clúster: Durante los eventos de reducción de escala, si el escalador automático del clúster quita un nodo, se desalojan todos los Pods de ese nodo con discos persistentes, lo que provoca la separación de los discos. Si estos Pods se reprograman en otro lugar, las conexiones se producirán en los nodos nuevos. Durante los eventos de expansión, los nodos nuevos no provocan directamente la reconexión, pero los Pods programados en ellos activarán las conexiones iniciales.

Este es un error transitorio. Por lo general, la copia de seguridad se realiza correctamente en la siguiente ejecución automática una vez que se estabiliza la conexión del disco. Para evitar que los eventos del clúster afecten tus copias de seguridad, aplica las siguientes recomendaciones:

  1. Habilita la Programación inteligente: Configura tu plan de copia de seguridad con la Programación inteligente (un programa basado en el RPO). Esto permite que el sistema vuelva a intentar automáticamente las fallas transitorias dentro del período especificado sin afectar el RPO general del plan de copias de seguridad.

  2. Configura períodos de exclusión de copias de seguridad: Si realizas operaciones de actualización de grupos de nodos o de cambio de tamaño del clúster, agrega un período de exclusión de copias de seguridad a la configuración de copias de seguridad durante esos intervalos. Esto garantiza que el servicio de Copia de seguridad para GKE se detendrá y evitará programar instantáneas mientras tu clúster modifique de forma activa las conexiones de disco.

  3. Retry Manual Backups: En el caso de las copias de seguridad manuales o a pedido, vuelve a intentar la operación de copia de seguridad una vez que finalice el evento del clúster.

Si la operación sigue fallando, comunícate con Atención al cliente de Cloud para obtener más ayuda.

¿Qué sigue?