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 usar 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 HorizontalPodAutoscaler GKE.

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 con 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 usar 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, scripts personalizados 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 lleva 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: usa 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. Verifica la eliminación con 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 con el comando kubectl get events:

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

      Sustituye NAMESPACE 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.

Siguientes pasos