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

En este documento, se describen los errores y los códigos correspondientes que puedes encontrar cuando usas la Copia de seguridad para GKE para realizar operaciones de restablecimiento. En cada sección, se incluyen aspectos que debes tener en cuenta cuando realices acciones para resolver los errores de restablecimiento, así como instrucciones para resolver los errores de la operación de restablecimiento.

Error 200010301: No se pudo completar la operación de restablecimiento debido a que el servicio de webhook de admisión no está disponible

El error 200010301 se produce cuando falla un intento de completar una operación de restablecimiento porque no está disponible un servicio de webhook de admisión, también conocido como devolución de llamada HTTP, lo que genera el siguiente mensaje de error. El mensaje de error indica que el servidor de la API de GKE intentó comunicarse con un webhook de admisión mientras intentaba restablecer un recurso, pero el servicio que respalda el webhook no estaba disponible o no se encontró:

  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 ocurre cuando un recurso de GKE ValidatingAdmissionWebhook o MutatingAdmissionWebhook está activo en el clúster de destino, pero el servidor de la API de GKE no puede acceder al extremo 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 el servidor de la API de GKE debe consultar las solicitudes.

El clientConfig del webhook especifica el backend que controla 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. Según el tipo de opción, es posible que la operación de restablecimiento haya fallado por los siguientes motivos:

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

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

Para resolver este error, sigue estas instrucciones:

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

  2. Ejecuta el comando kubectl get validatingwebhookconfigurations para inspeccionar el webhook:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Reemplaza WEBHOOK_NAME por el nombre del webhook que se identificó 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

    Reemplaza WEBHOOK_NAME por el nombre del webhook que se identificó en el mensaje de error.

  3. Realiza los siguientes pasos para solucionar problemas según el tipo de configuración:

    Basado en servicio clientConfig

    Para definir un orden de restauración personalizado, modifica el recurso RestorePlan para incluir un RestoreOrder con entradas GroupKindDependency. Esto permite que los componentes que respaldan el webhook, como Deployment, StatefulSet o Service, se restablezcan y estén listos antes de ValidatingWebhookConfiguration o MutatingWebhookConfiguration.

    Para obtener instrucciones sobre cómo definir un orden de restablecimiento personalizado, consulta Cómo especificar el orden de restablecimiento de los recursos durante el restablecimiento.

    Este enfoque puede fallar porque los Pods del servicio no entran en un estado ready completo incluso después de que se crea el objeto Service. Otro motivo de falla podría ser que otra aplicación haya creado inesperadamente la configuración del webhook. Como alternativa, puedes realizar una operación de restablecimiento en dos etapas siguiendo estos pasos:

    1. Crea un recurso Restore con la copia de seguridad. Para ello, configura la operación de restauración con un filtro de restauración detallado que incluya los recursos específicos que se requieren para que funcione el webhook, por ejemplo, Namespaces, Deployments, StatefulSets o Services.

      Para obtener más información sobre cómo configurar el restablecimiento con un filtro de restablecimiento detallado, consulta Cómo habilitar el restablecimiento detallado.

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

    clientConfig basado en URL

    1. Verifica el extremo HTTPS externo y asegúrate de que esté activo, sea 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 debas verificar las reglas de firewall, por ejemplo, si usas una nube privada virtual, una solución local o un proveedor de servicios en la nube que aloja el webhook, las políticas de red y la resolución de DNS.

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

Error 200010302: No se pudo completar la operación de restablecimiento debido a que se rechazó la solicitud de creación de recursos

El error 200010302 se produce cuando falla un intento de completar una operación de restablecimiento porque un webhook de admisión rechaza una solicitud de creación de recursos, lo que genera el siguiente mensaje de error que indica que no se pudo crear un recurso de tu copia de seguridad en el clúster de destino porque un webhook de admisión activo interceptó la solicitud y la rechazó 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 establecida en el clúster de GKE de destino, que tiene un ValidatingAdmissionWebhook o un MutatingAdmissionWebhook que aplica reglas específicas sobre 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 un recurso relacionado, pero en conflicto, en el clúster. Por ejemplo, un webhook podría rechazar la creación de una implementación si ya la administra un recurso de la API de HorizontalPodAutoscaler de GKE.

Para resolver este error, sigue estas instrucciones:

  1. Identifica el webhook que rechaza la solicitud con el mensaje de error que se produce cuando falla la operación de restablecimiento. Por ejemplo, webhook WEBHOOK_NAME denied the request. El mensaje de error contiene la siguiente información:

    • Nombre del webhook: Es el nombre del webhook que rechaza la solicitud.

    • Reason for denial: Es el motivo específico por el que se rechazó la solicitud.

  2. Ejecuta el comando kubectl get validatingwebhookconfigurations para inspeccionar el webhook:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Reemplaza WEBHOOK_NAME por el nombre del webhook que identificaste 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

    Reemplaza WEBHOOK_NAME por el nombre del webhook que identificaste 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. En el ejemplo, si hay un conflicto de HorizontalPodAutoscaler, debes borrar el HorizontalPodAutoscaler existente en el clúster de destino antes de ejecutar la restauración para permitir que se creen las cargas de trabajo de la copia de seguridad y sus recursos asociados.

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

Error 200060202: No se pudo completar la operación de restablecimiento debido a la falta de recursos 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 restablecimiento cuando no se encuentra en el clúster de destino un recurso de GKE que se espera que valide la copia de seguridad para GKE, lo que genera 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 Copia de seguridad para GKE crea o actualiza correctamente el recurso de GKE como parte del proceso de la operación de restablecimiento, pero, cuando comienza la etapa de validación, uno o más de los recursos de GKE ya no están presentes en el clúster de destino porque se borraron después de que el proceso de restablecimiento los creó o actualizó inicialmente, pero antes de que se pudiera completar la validación de la carga de trabajo para el recurso de GKE. Este error puede ocurrir por los siguientes motivos:

  • Borrado manual: Un usuario o administrador borró manualmente el recurso con kubectl o con otras herramientas de Google Cloud .

  • Automatización externa: Los controladores de GitOps, como Sincronizador de configuración, ArgoCD, Flux, secuencias de comandos personalizadas o cualquier otra herramienta de administración de clústeres, revirtieron o borraron el recurso para que coincidiera con el estado deseado en un repositorio.

  • Controladores de GKE: Un controlador de GKE borró un recurso porque entra en conflicto con otros recursos o políticas, o una cadena de OwnerReference conduce a la recolección de elementos no utilizados, o el proceso de limpieza automatizado de GKE que borra los recursos dependientes cuando se borra su recurso owner.

Para resolver este error, sigue estas instrucciones:

  1. Identifica el recurso faltante con el mensaje de error que aparece cuando no se completa la operación de restablecimiento.

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

    • Registros de auditoría de GKE: Examina 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 borrado en los recursos Kind y Name. La entrada de registro de auditoría contiene el espacio de nombres original.

    • Detalles de la copia de seguridad: Revisa el alcance de la operación de restablecimiento 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 RestorePlan contiene un TransformationRule que especifica reglas para restablecer 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

      Reemplaza KIND y NAME por los valores del mensaje de error. Si el recurso aún existe, este comando mostrará su espacio de nombres.

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

    kubectl get KIND NAME -n [NAMESPACE]

    Reemplaza KIND y NAME por los valores del mensaje de error. Deberías recibir un mensaje de error not found.

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

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

    • Revisa las automatizaciones configuradas: Si usas GitOps o cualquier otra herramienta de automatización, verifica sus registros y estado para ver si interfirieron en los recursos restablecidos.

    • Examina los eventos relacionados: Ejecuta el comando kubectl get events para verificar los eventos de GKE en el espacio de nombres determinado:

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

      Reemplaza NAMESPACE_NAME por el nombre del espacio de nombres.

  5. Aborda la causa de la eliminación del recurso según los resultados del paso anterior. Por ejemplo, pausar automatizaciones en conflicto, corregir errores de configuración o ajustar los permisos de los usuarios.

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

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

    • Realiza un restablecimiento detallado: Realiza una operación de restablecimiento detallado para restablecer de forma selectiva solo el recurso faltante de la misma copia de seguridad, lo que garantiza que especifiques el espacio de nombres correcto. Para obtener más información sobre cómo realizar una operación de restablecimiento detallado, consulta Habilita el restablecimiento detallado.

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

Error 200060201: No se pudo completar la operación de restablecimiento debido a que se agotó el tiempo de espera de la validación de la carga de trabajo

El error 200060201 se produce cuando una o más cargas de trabajo restablecidas no se convierten en ready por completo durante una operación de restablecimiento dentro del límite de tiempo esperado después de que se crearon los recursos en el clúster, lo que genera el siguiente mensaje de error:

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

Este error se produce porque la Copia de seguridad para GKE realiza un paso de validación después de restablecer la configuración de los recursos de GKE para garantizar que las cargas de trabajo críticas funcionen correctamente. Copia de seguridad para GKE espera a que ciertas cargas de trabajo alcancen un estado ready, pero al menos una carga de trabajo no cumplió con el siguiente criterio de preparación dentro del período 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, sigue estas instrucciones:

  1. Identifica las cargas de trabajo que no están en estado ready en el mensaje de error que enumera las cargas de trabajo y sus espacios de nombres que no pudieron ingresar en un estado ready.

  2. Para inspeccionar el estado de la carga de trabajo y obtener detalles y eventos de las cargas de trabajo con errores, ejecuta el comando kubectl describe:

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

    Reemplaza lo siguiente:

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

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

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

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

    En el caso de los Pods dentro de los tipos de cargas de trabajo Deployments o StatefulSets, verifica el estado de los Pods individuales ejecutando el comando kubectl describe pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Reemplaza lo siguiente:

    • POD_NAME: Es el nombre del pod específico.

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

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

    • ImagePullBackOff / ErrImagePull: Indica que hay problemas para recuperar imágenes de contenedor.

    • CrashLoopBackOff: Indica que los contenedores se inician y fallan.

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

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    Reemplaza lo siguiente:

    • POD_NAME: Es el nombre del pod específico.

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

    • CONTAINER_NAME: Es el nombre del contenedor dentro 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, incluidos los siguientes:

    • Fallas en los sondeos de preparación: Los sondeos de preparación del contenedor no se completan correctamente.

    • Problemas de recursos: No hay suficiente CPU, memoria o algún otro recurso en el clúster, o se alcanzaron los límites de cuota.

    • Problemas con los contenedores init: Fallas 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 requeridos.

  5. Verifica los recursos del clúster de GKE para asegurarte de que tenga suficiente capacidad de nodos, 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 recomendamos verificar si hay limitaciones o errores de escalamiento de nodos. Aborda los problemas subyacentes según tus hallazgos 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 garantizar que se cumplan las dependencias.

  6. Después de resolver los problemas subyacentes, espera a que las cargas de trabajo entren en un estado ready. No es necesario que vuelvas a ejecutar la operación de restablecimiento.

Si el problema persiste, comunícate con Atención al cliente de Cloud para obtener más ayuda.

Error 200060102: No se pudo completar la operación de restablecimiento debido a un error de validación del volumen

El error 200060102 se produce porque uno o más recursos VolumeRestore, que administran el proceso de restablecimiento de datos de VolumeBackup a un PersistentVolume, ingresaron en un estado failed o deleting durante la fase de validación de volumen de una operación de restablecimiento. El error en el restablecimiento del volumen genera el siguiente mensaje de error en el campo stateReason del recurso de restablecimiento:

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 enumera los nombres completos de los recursos VolumeRestore que fallaron, incluidos el nombre y el espacio de nombres del PersistentVolumeClaim de destino. El mensaje de error indica que el proceso de restablecimiento de datos para el PersistentVolumeClaim afectado no se completó correctamente cuando Copia de seguridad para GKE inició recursos de VolumeRestore para aprovisionar PersistentVolumes desde VolumeBackups, y falló la creación del Persistent Disk subyacente a partir de la instantánea. Las fallas de VolumeRestore pueden ocurrir por los siguientes motivos:

  • Cuota insuficiente: No hay suficiente cuota de Persistent Disk asignada en el proyecto o la región, por ejemplo, SSD_TOTAL_GB.

  • Problemas de permisos: La cuenta de servicio que usa Copia de seguridad para GKE no tiene los permisos necesarios para crear discos o acceder a instantáneas.

  • 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 subyacente del Persistent Disk están dañadas o no se puede acceder a ellas.

  • Restricciones de recursos: Otras restricciones de recursos del clúster dificultan el aprovisionamiento de volúmenes.

  • Errores internos: Hay problemas internos en el servicio de Persistent Disk.

Para resolver este error, sigue estas instrucciones:

  1. Identifica el PersistentVolumeClaims que falló y que se indica en el mensaje de error, el cual enumera los nombres de recursos completos de los objetos VolumeRestore que fallaron.

  2. Para obtener detalles de cada recurso VolumeRestore con errores, 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

    Reemplaza lo siguiente:

    • VOLUME_RESTORE_ID: Es el ID del recurso VolumeRestore que falló.

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

    • LOCATION: Es la Google Cloud ubicación del restablecimiento.

    • RESTORE_PLAN_ID: Es el ID del plan de restablecimiento.

    • RESTORE_ID: Es el ID de la operación de restablecimiento.

  3. Examina los campos state y stateMessage en el resultado para obtener detalles sobre la falla.

  4. Ejecuta el comando kubectl get pvc para examinar el estado del destino PersistentVolumeClaim:

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    Reemplaza lo siguiente:

    • PVC_NAME: Es el nombre del recurso PersistentVolumeClaim.

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

  5. Confirma que la sección status.phase del resultado indique una fase Pending. Esta fase significa que el PersistentVolumeClaim aún no está vinculado a un PersistentVolume, lo que se espera si falla el VolumeRestore.

  6. Inspecciona la sección Events en el resultado de YAML para ver 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 encriptación durante la creación del disco. Para proporcionar el permiso pertinente para acceder a la clave, sigue las instrucciones que se describen en la documentación de Copia de seguridad para GKE sobre cómo habilitar la encriptación con CMEK.compute service agent

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

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

    Reemplaza NAMESPACE_NAME por el espacio de nombres de PersistentVolumeClaim.

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

  9. Examina los registros de Persistent Disk. Para ello, verifica los registros de auditoría de Cloud y los registros de Persistent Disk en Cloud Logging en busca de errores relacionados con las operaciones de creación de discos en el momento de la falla.

  10. Según los mensajes de error generados, aborda los siguientes problemas subyacentes:

    • Aumenta las cuotas de Persistent Disk si se indica, como (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • Verifica y corrige los permisos de IAM.

    • Investigar y resolver problemas de red

    • Comunícate con Atención al cliente de Cloud para resolver problemas relacionados con la instantánea o el servicio de Persistent Disk.

    • El PersistentVolumeClaim permanece en estado Pending.

    • El proceso de la operación de restablecimiento no reintenta automáticamente la operación VolumeRestore. Para resolver este problema, debes activar una operación de restauración para la carga de trabajo Deployment o StatefulSet que usa el PersistentVolumeClaim afectado.

    • Usa un restablecimiento detallado para restablecer de forma selectiva la carga de trabajo Deployment o StatefulSet asociada con el PersistentVolumeClaim fallido. Este enfoque permite que los mecanismos estándar de GKE vuelvan a controlar el proceso de creación y vinculación de PersistentVolumeClaim si se corrige el problema subyacente. Para obtener más información sobre el restablecimiento detallado, consulta Habilita el restablecimiento detallado.

Si el problema persiste o no está clara la causa de la falla de VolumeRestore, comunícate con Atención al cliente de Cloud para obtener más ayuda.

Error 200060101: No se pudo completar la operación de restablecimiento debido a que se agotó el 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 restablecimiento cuando Copia de seguridad para GKE deja de esperar porque al menos un recurso VolumeRestore, que administra el restablecimiento de datos desde un VolumeBackup, no alcanzó un estado succeeded dentro del período de tiempo de espera asignado. Es posible que otros recursos VolumeRestore también estén incompletos.

El mensaje de error en el campo stateReason del recurso Restore muestra el primer recurso VolumeRestore encontrado que aún no estaba en un estado succeeded cuando se verificó el tiempo de espera. Incluye el nombre y el espacio de nombres del PersistentVolumeClaim de destino para 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)]

Copia de seguridad para GKE inicia recursos VolumeRestore para aprovisionar PersistentVolumes desde VolumeBackups. El error indica que la creación subyacente del Persistent Disk a partir de la instantánea y la vinculación posterior del PersistentVolumeClaim al PersistentVolume tardaron más que el tiempo de espera calculado para el VolumeRestore citado. Es posible que otros VolumeRestores para la misma operación de restablecimiento también se encuentren en un estado no completado.

Aunque se haya alcanzado el tiempo de espera desde la perspectiva de Copia de seguridad para GKE, es posible que el proceso subyacente de creación de discos para el recurso VolumeRestore mencionado y, posiblemente, los recursos VolumeRestore, aún esté en curso o haya fallado.

Para resolver este problema, sigue estas instrucciones:

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

  2. Ejecuta el comando gcloud beta container backup-restore volume-restores list para enumerar todos los VolumeRestores asociados con la operación de restablecimiento y ver sus estados actuales:

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

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID del proyecto Google Cloud .

    • LOCATION: Es la Google Cloud ubicación del restablecimiento.

    • RESTORE_PLAN_NAME: Es el nombre del plan de restablecimiento.

    • RESTORE_NAME: Es el nombre de la operación de restablecimiento.

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

  4. Para obtener detalles sobre el VolumeRestore mencionado en el error y cualquier otro VolumeRestores que no esté en estado succeeded, 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_NAME \
--restore=RESTORE_NAME

    Reemplaza lo siguiente:

    • VOLUME_RESTORE_ID: Es el ID del recurso VolumeRestore.

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

    • LOCATION: Es la Google Cloud ubicación del restablecimiento.

    • RESTORE_PLAN_NAME: Es el nombre del plan de restablecimiento.

    • RESTORE_NAME: Es el nombre de la operación de restablecimiento.

  5. Verifica 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 de destino.

  6. Para examinar el estado del destino identificado PersistentVolumeClaims, ejecuta el comando kubectl get pvc:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    Reemplaza lo siguiente:

    • PVC_NAME: el nombre de PersistentVolumeClaim.

    • PVC_NAMESPACE: Es el espacio de nombres de PersistentVolumeClaim.

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

    • 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 programa un Pod que usa PersistentVolumeClaim. El problema podría estar relacionado con la programación de Pod, no con el aprovisionamiento de volumen en sí. Por lo tanto, te recomendamos que confirmes 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. Revisa los eventos de GKE en los espacios de nombres pertinentes ejecutando el comando kubectl get events:

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

    Reemplaza PVC_NAMESPACE por el espacio de nombres de PersistentVolumeClaim.

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

  8. Verifica los registros de Registros de auditoría de Cloud y de Persistent Disk en Cloud Logging.

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

    Después de que se corrige el problema, el estado del VolumeRestores puede pasar a los estados succeeded o failed. Si los VolumeRestores alcanzan un estado succeeded, los PersistentVolumeClaims deberían convertirse en Bound y las cargas de trabajo deberían ser funcionales. Si algún VolumeRestore entra en un estado failed, debes seguir los pasos para solucionar problemas y resolver el error de validación del volumen. Para obtener más información, consulta Error 200060102: No se pudo completar la operación de restablecimiento debido a un error de validación del volumen

Si los VolumeRestores permanecen en los estados creating o restoring durante un período excesivo, comunícate con Atención al cliente de Cloud para obtener más ayuda.

¿Qué sigue?