Solucionar errores de permisos en Backup for GKE

En este documento se describen los errores y los códigos correspondientes que pueden producirse al usar la función de copia de seguridad de GKE para realizar operaciones de restauración. En cada sección se incluyen aspectos que debes tener en cuenta al realizar acciones para resolver los errores de restauración, así como instrucciones sobre cómo resolverlos.

Error 200010301: no se ha podido completar la operación de restauración debido a que el servicio de webhook de admisión no está disponible

El error 200010301 se produce cuando no se puede completar una operación de restauración porque no está disponible un servicio de webhook de admisión, también denominado retrollamada HTTP, lo que provoca el siguiente mensaje de error. El mensaje de error indica que el servidor de la API de GKE ha intentado ponerse en contacto con un webhook de admisión al intentar restaurar un recurso, pero el servicio que admite el webhook no estaba disponible o no se ha encontrado:

  resource [/example-group/ClusterSecretStore/example-store] restore failed:

  Internal error occurred: failed calling webhook "example-webhook.io":
  failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.

Este error se produce cuando un recurso de ValidatingAdmissionWebhook o MutatingAdmissionWebhook de GKE está activo en el clúster de destino, pero el servidor de la API de GKE no puede acceder al endpoint configurado en el webhook. Los webhooks de admisión interceptan las solicitudes al servidor de la API de GKE, y su configuración especifica cómo debe consultar el servidor de la API de GKE las solicitudes.

El webhook clientConfig especifica el backend que gestiona las solicitudes de admisión, que puede ser un servicio de clúster interno o una URL externa. La elección entre estas dos opciones depende de los requisitos operativos y de arquitectura específicos de tu webhook. En función del tipo de opción, es posible que la operación de restauración haya fallado por los siguientes motivos:

  • Servicios en el clúster: el servicio de GKE y sus pods de respaldo no se restauran ni están listos cuando el servidor de la API de GKE intenta llamar al webhook. Esto ocurre durante las operaciones de restauración en las que se aplican configuraciones de webhook con ámbito de clúster antes de que los servicios con ámbito de espacio de nombres estén completamente en estado ready.

  • URLs externas: el endpoint externo no está disponible temporalmente debido a problemas de conectividad de red entre el clúster de GKE y el endpoint externo, o bien a problemas de resolución de DNS o reglas de cortafuegos.

Para resolver este error, siga estas instrucciones:

  1. Identifica el webhook que falla y que se menciona en el mensaje de error. Por ejemplo, failed calling webhook "...".

  2. Inspecciona el webhook ejecutando el comando kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sustituye WEBHOOK_NAME por el nombre del webhook que se ha identificado en el mensaje de error.

    También puedes ejecutar el comando kubectl get mutatingwebhookconfigurations para inspeccionar el webhook:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sustituye WEBHOOK_NAME por el nombre del webhook que se ha identificado en el mensaje de error.

  3. Sigue los pasos que se indican a continuación para solucionar el problema en función del tipo de configuración:

    Basado en servicios clientConfig

    Define un orden de restauración personalizado modificando el recurso RestorePlan para incluir un RestoreOrder con entradas GroupKindDependency. De esta forma, los componentes que respaldan el webhook, como Deployment, StatefulSet o Service, se pueden restaurar y estar listos antes de ValidatingWebhookConfiguration o MutatingWebhookConfiguration.

    Para obtener instrucciones sobre cómo definir un orden de restauración personalizado, consulta Especificar el orden de restauración de los recursos durante la restauración.

    Este enfoque puede fallar porque los pods del servicio no entran en un estado ready completo, incluso después de crear el objeto Service. Otro motivo por el que se puede producir un error es que otra aplicación haya creado la configuración del webhook de forma inesperada. También puede realizar una operación de restauración en dos fases siguiendo estos pasos:

    1. Crea un recurso Restore a partir de la copia de seguridad configurando la operación de restauración con un filtro de restauración detallado que incluya los recursos específicos que necesita el webhook para funcionar. Por ejemplo, Namespaces, Deployments, StatefulSets o Services.

      Para obtener más información sobre cómo configurar la restauración con un filtro de restauración detallado, consulta Habilitar la restauración detallada.

    2. Crea otro recurso Restore para la operación de copia de seguridad y configura el resto de los recursos que elijas.

    Basado en URLs clientConfig

    1. Verifica el endpoint HTTPS externo y asegúrate de que esté activo, accesible y funcione correctamente.

    2. Confirma que haya conectividad de red desde los nodos y el plano de control de tu clúster de GKE a la URL externa. También es posible que tengas que comprobar las reglas del cortafuegos, por ejemplo, si utilizas Virtual Private Cloud, un entorno local o un proveedor de servicios en la nube que aloje el webhook, las políticas de red y la resolución de DNS.

  4. Vuelve a intentar la operación de restauración. Si la operación sigue fallando, ponte en contacto con Cloud Customer Care para obtener más ayuda.

Error 200010302: no se ha podido completar la operación de restauración porque se ha denegado la solicitud de creación de recursos

El error 200010302 se produce cuando no se puede completar una operación de restauración porque un webhook de admisión deniega una solicitud de creación de recursos, lo que provoca el siguiente mensaje de error, que indica que no se ha podido crear un recurso de tu copia de seguridad en el clúster de destino porque un webhook de admisión activo ha interceptado la solicitud y la ha rechazado según una política personalizada:

  [KubeError]; e.g. resource

  [/example-namespace/example-api/ExampleResource/example-name]

  restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}

Este error se debe a la configuración definida en el clúster de GKE de destino, que tiene un ValidatingAdmissionWebhook o un MutatingAdmissionWebhook que aplica reglas específicas a la creación y modificación de recursos, lo que bloquea la solicitud de creación de recursos. Por ejemplo, un webhook impide la creación de un recurso porque ya existe en el clúster un recurso relacionado, pero conflictivo. Por ejemplo, un webhook puede denegar la creación de una implementación si ya la gestiona un recurso de la API de GKE.HorizontalPodAutoscaler

Para resolver este error, siga estas instrucciones:

  1. Identifica el webhook que está denegando la solicitud mediante el mensaje de error que se produce cuando falla la operación de restauración. Por ejemplo, webhook WEBHOOK_NAME denied the request El mensaje de error contiene la siguiente información:

    • Nombre del webhook: el nombre del webhook que deniega la solicitud.

    • Motivo del rechazo: el motivo específico por el que se ha rechazado la solicitud.

  2. Inspecciona el webhook ejecutando el comando kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sustituye WEBHOOK_NAME por el nombre del webhook que has identificado en el mensaje de error.

    También puedes ejecutar el comando kubectl get mutatingwebhookconfigurations para inspeccionar el webhook:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sustituye WEBHOOK_NAME por el nombre del webhook que has identificado en el mensaje de error.

  3. Resuelve el problema subyacente en el clúster de destino. La acción correcta depende del error específico. Por ejemplo, si hay un conflicto de HorizontalPodAutoscaler, debes eliminar el HorizontalPodAutoscaler del clúster de destino antes de ejecutar la restauración para permitir que se creen las cargas de trabajo de las que se ha creado una copia de seguridad y sus recursos asociados.

  4. Vuelve a intentar la operación de restauración. Si la operación de restauración sigue fallando, ponte en contacto con el equipo de Asistencia de Google Cloud para obtener más ayuda.

Error 200060202: no se ha podido completar la operación de restauración porque falta un recurso de GKE durante la validación de la carga de trabajo

El error 200060202 se produce durante la fase de validación de la carga de trabajo de una operación de restauración cuando no se encuentra en el clúster de destino un recurso de GKE que Copia de seguridad de GKE espera validar. Como resultado, se muestra el siguiente mensaje de error:

  Workload Validation Error: [KIND] "[NAME]" not found

Por ejemplo, Example: Workload Validation Error: pods "jenkins-0" not found

Este error se produce cuando Backup for GKE crea o actualiza correctamente el recurso de GKE como parte del proceso de la operación de restauración, pero, cuando comienza la fase de validación, uno o varios de los recursos de GKE ya no están presentes en el clúster de destino porque se eliminaron después de que el proceso de restauración los creara o actualizara inicialmente, pero antes de que se pudiera completar la validación de la carga de trabajo del recurso de GKE. Este error puede producirse por los siguientes motivos:

  • Eliminación manual: un usuario o administrador ha eliminado manualmente el recurso con kubectl u otras Google Cloud herramientas.

  • Automatización externa: los controladores GitOps, como Config Sync, ArgoCD, Flux, las secuencias de comandos personalizadas u otras herramientas de gestión de clústeres, han revertido o eliminado el recurso para que coincida con el estado deseado en un repositorio.

  • Controladores de GKE: un controlador de GKE ha eliminado un recurso porque entra en conflicto con otros recursos o políticas, o bien una cadena OwnerReference ha llevado a la recogida de elementos no utilizados o al proceso de limpieza automatizado de GKE que elimina los recursos dependientes cuando se elimina su recurso owner.

Para resolver este error, siga estas instrucciones:

  1. Identifica el recurso que falta mediante el mensaje de error que aparece cuando no se completa la operación de restauración.

  2. Busca el espacio de nombres al que pertenece el recurso con uno de los siguientes métodos:

    • Registros de auditoría de GKE: consulta los registros de auditoría de GKE que se generaron cuando intentaste realizar la operación de restauración. Puedes filtrar los registros de las operaciones de eliminación de los recursos Kind y Name. La entrada del registro de auditoría contiene el espacio de nombres original.

    • Detalles de la copia de seguridad: revisa el alcance de la operación de restauración y el contenido de la copia de seguridad. El índice de la copia de seguridad muestra el espacio de nombres original del recurso. También puedes verificar si el RestorePlan contiene un TransformationRule que especifique reglas para restaurar el recurso en el espacio de nombres que elijas.

    • Buscar en todos los espacios de nombres: ejecuta el comando kubectl get para buscar el recurso en todos los espacios de nombres:

      kubectl get KIND --all-namespaces | grep NAME

      Sustituye KIND y NAME por los valores del mensaje de error. Si el recurso sigue existiendo, este comando mostrará su espacio de nombres.

  3. Para verificar la eliminación, ejecuta el comando kubectl get:

    kubectl get KIND NAME -n [NAMESPACE]

    Sustituye KIND y NAME por los valores del mensaje de error. Debería aparecer un not found mensaje de error.

  4. Investiga la causa de la eliminación con uno de los siguientes métodos:

    • Registros de auditoría de GKE: identifican qué entidad ha emitido la solicitud de eliminación. Por ejemplo, el usuario, la cuenta de servicio o el controlador.

    • Revisa las automatizaciones configuradas: si usas GitOps u otras herramientas de automatización, consulta sus registros y su estado para ver si han interferido en los recursos restaurados.

    • Examina los eventos relacionados: comprueba los eventos de GKE en el espacio de nombres determinado ejecutando el comando kubectl get events:

      kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

      Sustituye NAMESPACE_NAME por el nombre del espacio de nombres.

  5. Soluciona la causa de la eliminación del recurso en función de los resultados del paso anterior. Por ejemplo, pausar automatizaciones conflictivas, corregir errores de configuración o ajustar los permisos de los usuarios.

  6. Recupera el recurso que falta con uno de los siguientes métodos:

    • Vuelve a aplicar los archivos de manifiesto: si tienes el manifiesto del recurso que falta, puedes volver a aplicarlo al espacio de nombres correcto.

    • Realiza una restauración granular: lleva a cabo una operación de restauración granular para restaurar de forma selectiva solo el recurso que falta de la misma copia de seguridad, lo que te asegura que especificas el espacio de nombres correcto. Para obtener más información sobre cómo realizar una operación de restauración granular, consulta Habilitar la restauración granular.

  7. Vuelve a intentar la operación de restauración. Si la operación de restauración sigue fallando, ponte en contacto con el equipo de Asistencia de Google Cloud para obtener más ayuda.

Error 200060201: No se ha podido completar la operación de restauración debido al tiempo de espera de la validación de la carga de trabajo

El error 200060201 se produce cuando una o varias cargas de trabajo restauradas no se convierten en ready por completo durante una operación de restauración dentro del plazo previsto después de que se hayan creado los recursos en el clúster. Esto provoca el siguiente mensaje de error:

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

Este error se produce porque Backup for GKE realiza un paso de validación después de restaurar las configuraciones de recursos de GKE para asegurarse de que las cargas de trabajo críticas funcionen correctamente. Copia de seguridad de GKE espera a que determinadas cargas de trabajo alcancen el estado ready, pero al menos una de ellas no ha cumplido el siguiente criterio de preparación en el periodo de tiempo de espera asignado:

  • Para Pods: status.Phase es Running

  • Para Deployments: status.ReadyReplicas es igual a spec.Replicas

  • Para StatefulSets: status.ReadyReplicas es igual a spec.Replicas

  • Para DaemonSets: status.NumberReady es igual a status.DesiredNumberScheduled

Para resolver este error, siga estas instrucciones:

  1. Identifica las cargas de trabajo que no están en estado ready en el mensaje de error que muestra las cargas de trabajo y sus espacios de nombres que no han podido pasar al estado ready.

  2. Inspecciona el estado de las cargas de trabajo y consulta los detalles y los eventos de las cargas de trabajo que han fallado ejecutando el comando kubectl describe:

    kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD

    Haz los cambios siguientes:

    • WORKLOAD_TYPE: el tipo de carga de trabajo. Por ejemplo, Deployment, StatefulSet o DaemonSet.

    • WORKLOAD_NAME: el nombre de la instancia de carga de trabajo específica.

    • NAMESPACE_NAME: el espacio de nombres en el que se encuentra la carga de trabajo.

    • SELECTOR_FOR_WORKLOAD: el selector de etiquetas para buscar Pods asociado a la carga de trabajo. Por ejemplo, app=my-app.

    En el caso de los pods de los tipos de carga de trabajo Deployments o StatefulSets, comprueba el estado de los pods individuales ejecutando el comando kubectl describe pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Haz los cambios siguientes:

    • POD_NAME: el nombre del pod específico.

    • NAMESPACE_NAME: el espacio de nombres en el que se encuentra el pod.

  3. En la sección Events, analiza los eventos y los registros de la salida describe y busca la siguiente información:

    • ImagePullBackOff / ErrImagePull: indica que hay problemas al obtener imágenes de contenedor.

    • CrashLoopBackOff: indica que los contenedores se están iniciando y fallando.

  4. En la sección Containers, analiza los registros de contenedores en la salida describe para encontrar el nombre del contenedor ejecutando el comando kubectl logs:

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    Haz los cambios siguientes:

    • POD_NAME: el nombre del pod específico.

    • NAMESPACE_NAME: el espacio de nombres en el que se encuentra el pod.

    • CONTAINER_NAME: el nombre del contenedor del pod.

    Según el resultado de describe, hay varios motivos por los que es posible que el pod no aparezca en el resultado del recurso, entre los que se incluyen los siguientes:

    • Errores en la comprobación de preparación: las comprobaciones de preparación del contenedor no se realizan correctamente.

    • Problemas con los recursos: no hay suficiente CPU, memoria u otros recursos en el clúster o se han alcanzado los límites de cuota.

    • Problemas con los contenedores init: errores en los contenedores init que impiden que se inicien los contenedores principales.

    • Errores de configuración: errores en ConfigMaps, Secrets o variables de entorno.

    • Problemas de red: Pods no puede comunicarse con los servicios necesarios.

  5. Comprueba los recursos del clúster de GKE para asegurarte de que tiene suficiente capacidad de nodo, CPU y memoria para ejecutar las cargas de trabajo restauradas. En los clústeres de Autopilot, el aprovisionamiento automático de nodos puede tardar más tiempo, por lo que te recomendamos que compruebes si hay limitaciones o errores de escalado de nodos. Aborda los problemas subyacentes en función de tus conclusiones y resuelve los problemas que impiden que las cargas de trabajo entren en un estado ready. Este enfoque puede implicar corregir manifiestos, ajustar solicitudes o límites de recursos, corregir políticas de red o asegurarse de que se cumplen las dependencias.

  6. Una vez que se hayan resuelto los problemas subyacentes, espera a que las cargas de trabajo pasen al estado ready. No es necesario que vuelvas a ejecutar la operación de restauración.

Si el problema persiste, ponte en contacto con Cloud Customer Care para obtener más ayuda.

Error 200060102: no se ha podido completar la operación de restauración debido a un error de validación del volumen

El error 200060102 se produce porque uno o varios recursos VolumeRestore, que gestionan el proceso de restauración de datos de VolumeBackup a PersistentVolume, han entrado en el estado failed o deleting durante la fase de validación de volúmenes de una operación de restauración. Si no se puede restaurar el volumen, se mostrará el siguiente mensaje de error en el campo stateReason del recurso de restauración:

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

El mensaje de error indica los nombres de recursos completos de los VolumeRestore que han fallado, incluido el nombre y el espacio de nombres del PersistentVolumeClaim de destino. El mensaje de error indica que el proceso de restauración de datos de PersistentVolumeClaim no se ha completado correctamente cuando la función de copia de seguridad de GKE ha iniciado los recursos de VolumeRestore para aprovisionar PersistentVolumes desde VolumeBackups y se ha producido un error al crear el disco persistente subyacente a partir de la instantánea. Los errores de VolumeRestore pueden producirse por los siguientes motivos:

  • Cuota insuficiente: no hay suficiente cuota de disco persistente asignada en el proyecto o la región (por ejemplo, SSD_TOTAL_GB).

  • Problemas de permisos: la cuenta de servicio que usa Backup for GKE no tiene los permisos necesarios para crear discos o acceder a las copias de seguridad.

  • Problemas de red: hay problemas de red transitorios o persistentes que interrumpen el proceso de creación del disco.

  • Instantánea no válida: la fuente VolumeBackup o la instantánea del disco persistente subyacente están dañadas o no se puede acceder a ellas.

  • Restricciones de recursos: otras restricciones de recursos del clúster impiden el aprovisionamiento de volúmenes.

  • Errores internos: hay problemas internos en el servicio Persistent Disk.

Para resolver este error, siga estas instrucciones:

  1. Identifica el PersistentVolumeClaims que aparece en el mensaje de error, que muestra los nombres de recursos completos de los objetos VolumeRestore que han fallado.

  2. Para obtener los detalles de cada recurso VolumeRestore que no se haya podido crear, ejecuta el comando gcloud beta container backup-restore volume-restores describe:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_ID \
--restore=RESTORE_ID

    Haz los cambios siguientes:

    • VOLUME_RESTORE_ID: el ID del recurso VolumeRestoreque ha fallado.

    • PROJECT_ID: el ID de tu proyecto de Google Cloud .

    • LOCATION: la Google Cloud ubicación de la restauración.

    • RESTORE_PLAN_ID: el ID del plan de restauración.

    • RESTORE_ID: el ID de la operación de restauración.

  3. Consulta los campos state y stateMessage de la salida para obtener más información sobre el fallo.

    .

  4. Consulta el estado del PersistentVolumeClaim de destino ejecutando el comando kubectl get pvc:

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    Haz los cambios siguientes:

    • PVC_NAME: el nombre del PersistentVolumeClaim recurso.

    • NAMESPACE_NAME: el espacio de nombres donde se encuentra PersistentVolumeClaim.

  5. Confirma que la sección status.phase del resultado indica una Pending fase. En esta fase, PersistentVolumeClaim aún no está vinculado a PersistentVolume, lo cual es normal si VolumeRestore falla.

  6. Consulta la sección Events de la salida de YAML para ver los mensajes relacionados con errores de aprovisionamiento, como ProvisioningFailed. Por ejemplo:

    Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).

    El resultado indica que hay un problema de permisos al acceder a la clave de cifrado durante la creación del disco. Para proporcionar compute service agent permisos relevantes para acceder a la clave, sigue las instrucciones que se describen en la documentación de Copia de seguridad de GKE sobre cómo habilitar el cifrado con CMEK.

  7. Revisa los eventos de GKE en el espacio de nombres PersistentVolumeClaim, que proporcionan mensajes de error detallados del controlador PersistentVolume o del controlador CSI, ejecutando el comando kubectl get events:

    kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

    Sustituye NAMESPACE_NAME por el espacio de nombres de PersistentVolumeClaim.

  8. Identifica los eventos relacionados con el nombre PersistentVolumeClaim, que contiene palabras clave como FailedProvisioning o ExternalProvisioning. Los eventos también pueden contener errores del proveedor de almacenamiento, como pd.csi.storage.gke.io.

  9. Examina los registros de Persistent Disk consultando los registros de auditoría de Cloud y los registros de Persistent Disk en Cloud Logging para comprobar si hay errores relacionados con las operaciones de creación de discos en el momento del fallo.

  10. En función de los mensajes de error generados, soluciona los siguientes problemas subyacentes:

    • Aumenta las cuotas de discos persistentes si es necesario, como en el caso de (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • Verifica y corrige los permisos de gestión de identidades y accesos.

    • Investiga y resuelve problemas de red.

    • Ponte en contacto con el equipo de atención al cliente de Cloud para resolver los problemas con la instantánea o el servicio de disco persistente.

    • El PersistentVolumeClaim sigue en estado Pending.

    • El proceso de restauración no vuelve a intentar automáticamente la operación VolumeRestore. Para solucionar este problema, debes activar una operación de restauración para la carga de trabajo Deployment o StatefulSet que utilice el PersistentVolumeClaim afectado.

    • Usa una restauración granular para restaurar de forma selectiva la carga de trabajo de Deployment o StatefulSet asociada al PersistentVolumeClaim que ha fallado. De esta forma, los mecanismos estándar de GKE pueden volver a gestionar el proceso de creación y vinculación de PersistentVolumeClaim si se soluciona el problema subyacente. Para obtener más información sobre la restauración granular, consulta Habilitar la restauración granular.

Si el problema persiste o no está claro el motivo del fallo de VolumeRestore, ponte en contacto con el equipo de Asistencia de Google Cloud para obtener más ayuda.

Error 200060101: no se ha podido completar la operación de restauración debido al tiempo de espera de la validación del volumen

El error 200060101 se produce durante la fase de validación del volumen de una operación de restauración cuando Backup for GKE deja de esperar porque al menos un recurso VolumeRestore, que gestiona la restauración de datos de un VolumeBackup, no ha alcanzado el estado succeeded en el periodo de tiempo de espera asignado. Es posible que otros recursos VolumeRestoretambién estén incompletos.

El mensaje de error del campo stateReason del recurso Restore muestra el primer recurso VolumeRestore que aún no estaba en el estado succeeded cuando se comprobó el tiempo de espera. Incluye el nombre y el espacio de nombres de PersistentVolumeClaim de destino de ese VolumeRestore específico. Por ejemplo:

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]

La función de copia de seguridad de GKE inicia los recursos VolumeRestore para aprovisionar PersistentVolumes desde VolumeBackups. El error indica que la creación del disco persistente subyacente a partir de la instantánea y la vinculación posterior del PersistentVolumeClaim al PersistentVolume han tardado más que el tiempo de espera calculado para el VolumeRestore citado. Es posible que otros VolumeRestores de la misma operación de restauración también estén en un estado no completado.

Aunque se haya alcanzado el tiempo de espera desde la perspectiva de Backup for GKE, es posible que el proceso de creación del disco subyacente del recurso VolumeRestore mencionado, y posiblemente de otros recursos VolumeRestore, siga en curso o haya fallado.

Para solucionar este problema, sigue estas instrucciones:

  1. Identifica el nombre y el espacio de nombres de PersistentVolumeClaim que ha agotado el tiempo de espera en el mensaje de error. Por ejemplo, (PVC: PVC_NAMESPACE/PVC_NAME).

  2. Lista todos los VolumeRestores asociados a la operación de restauración para ver sus estados actuales ejecutando el comando gcloud beta container backup-restore volume-restores list:

    gcloud beta container backup-restore volume-restores list \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del Google Cloud proyecto.

    • LOCATION: la Google Cloud ubicación de la restauración.

    • RESTORE_PLAN_NAME: el nombre del plan de restauración.

    • RESTORE_NAME: el nombre de la operación de restauración.

  3. Busca los VolumeRestores que no estén en estado succeeded.

  4. Obtén información sobre el VolumeRestore mencionado en el error y cualquier otro VolumeRestores que no esté en estado succeeded ejecutando el comando gcloud beta container backup-restore volume-restores describe:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Haz los cambios siguientes:

    • VOLUME_RESTORE_ID: el ID del recurso VolumeRestore.

    • PROJECT_ID: el ID de tu proyecto de Google Cloud .

    • LOCATION: la Google Cloud ubicación de la restauración.

    • RESTORE_PLAN_NAME: el nombre del plan de restauración.

    • RESTORE_NAME: el nombre de la operación de restauración.

  5. Comprueba los campos state y stateMessage. Es probable que el valor del campo state sea creating o restoring. El campo stateMessage puede proporcionar más contexto y contener los detalles del PersistentVolumeClaim objetivo.

  6. Examina el estado del objetivo identificado PersistentVolumeClaims ejecutando el comando kubectl get pvc:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    Haz los cambios siguientes:

    • PVC_NAME: el nombre del PersistentVolumeClaim.

    • PVC_NAMESPACE: el espacio de nombres de PersistentVolumeClaim.

    Es probable que el valor de PersistentVolumeClaim's status.phase sea Pending. Consulte la sección Events para ver si hay alguno de los siguientes errores:

    • Waiting for first consumer to be created before binding: indica que el StorageClass tiene volumeBindingMode: WaitForFirstConsumer.

      El aprovisionamiento de PersistentVolume se retrasa hasta que se crea y se programa un Pod que use PersistentVolumeClaim. El problema puede estar relacionado con la Pod, no con el aprovisionamiento del volumen en sí. Por lo tanto, le recomendamos que confirme por qué no se programan o no se inician los Pods que consumen los PersistentVolumeClaim.

    • FailedProvisioning o errores del aprovisionador de almacenamiento: por ejemplo, pd.csi.storage.gke.io.

  7. Para revisar los eventos de GKE en los espacios de nombres correspondientes, ejecuta el comando kubectl get events:

    kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'

    Sustituye PVC_NAMESPACE por el espacio de nombres de PersistentVolumeClaim.

    Busca eventos relacionados con los nombres de PersistentVolumeClaim, como mensajes o errores de aprovisionamiento.

  8. Consulta los registros de auditoría de Cloud y los registros de discos persistentes en Cloud Logging.

  9. Monitoriza el estado de todos los VolumeRestores en los estados creating y restoring.

    Una vez que se haya solucionado el problema, el estado de la VolumeRestores puede cambiar a succeeded o failed. Si los VolumeRestores alcanzan el estado succeeded, los PersistentVolumeClaims deben convertirse en Bound y las cargas de trabajo deben funcionar. Si algún VolumeRestore entra en el estado failed, debes seguir los pasos para solucionar el error de validación del volumen. Para obtener más información, consulta Error 200060102: no se ha podido completar la operación de restauración debido a un error de validación del volumen.

Si VolumeRestores permanecen en los estados creating o restoring durante un periodo excesivo, ponte en contacto con el equipo de Asistencia de Cloud para obtener más ayuda.

Siguientes pasos