Esta página se ha traducido con Cloud Translation API.

Habilitar el modo permisivo en un plan de copia de seguridad

Autopilot Standard

En esta página se explica cómo habilitar el modo permisivo en un plan de copias de seguridad.

Durante la ejecución de la copia de seguridad, si Backup para GKE detecta condiciones que probablemente provoquen un error en la restauración, la propia copia de seguridad fallará. El motivo del error se indica en el campo state_reason de la copia de seguridad. En la consola de Google Cloud , este campo se denomina Motivo del estado.

Acerca del modo permisivo

Si no puedes aceptar que se produzcan fallos en las copias de seguridad y no es posible solucionar los problemas subyacentes, puedes habilitar el modo permisivo. El modo permisivo asegura que las copias de seguridad se completen correctamente, incluso si se detectan recursos de GKE que podrían provocar fallos en la restauración durante el proceso de copia de seguridad. Los detalles sobre los problemas se indican en el campo Motivo del estado de la copia de seguridad.

Te recomendamos que utilices esta opción solo si entiendes los problemas y puedes implementar soluciones alternativas durante el proceso de restauración. Para ver una lista de posibles mensajes de error en el campo Motivo del estado de la copia de seguridad con las acciones recomendadas, consulta Solucionar problemas de copias de seguridad.

Habilitar el modo permisivo

Sigue estas instrucciones para habilitar el modo permisivo:

gcloud

Para habilitar el modo permisivo, ejecuta el comando gcloud beta container backup-restore backup-plans update:

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

Haz los cambios siguientes:

BACKUP_PLAN: el nombre del plan de copia de seguridad que quieras actualizar.
PROJECT_ID: el ID de tu proyecto de Google Cloud.
LOCATION: la región de cálculo del recurso, por ejemplo, us-central1. Consulta Información sobre las ubicaciones de recursos.

Para ver una lista completa de las opciones, consulta la documentación de gcloud beta container backup-restore backup-plans update.

Consola

Sigue estas instrucciones para habilitar el modo permisivo en la consolaGoogle Cloud :

En la Google Cloud consola, ve a la página Google Kubernetes Engine.

Ir a Google Kubernetes Engine
En el menú de navegación, haga clic en Backup for GKE.
Haga clic en la pestaña Planes de copia de seguridad.
Despliega el clúster y haz clic en el nombre del plan.
Haz clic en la pestaña Detalles para editar los detalles del plan.
Haz clic en Editar para modificar la sección con el modo de copia de seguridad.
Marca la casilla Modo permisivo y haz clic en Guardar cambios.

Terraform

Actualiza el recurso google_gke_backup_backup_plan.

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

Haz los cambios siguientes:

NAME: el nombre del google_gke_backup_backup_plan que quieras actualizar.

Para obtener más información, consulta gke_backup_backup_plan.

Solucionar problemas con las copias de seguridad

En la siguiente tabla se ofrecen explicaciones y acciones recomendadas para varios mensajes de error de copia de seguridad que se muestran en el campo Motivo del estado de la copia de seguridad.

Mensaje de error de la copia de seguridad Descripción del mensaje y motivo del error Acción recomendada

Mensaje de error de la copia de seguridad	Descripción del mensaje y motivo del error	Acción recomendada
`CustomResourceDefinitions "..." have invalid schemas`	Descripción: Una definición de recurso personalizado (CRD) del clúster se aplicó originalmente como `apiextensions.k8s.io/v1beta1` y no tiene un esquema estructural necesario en `apiextensions.k8s.io/v1`. Motivo: Copia de seguridad de GKE no puede definir automáticamente el esquema estructural. Restaurar el CRD en clústeres de Kubernetes v1.22 o versiones posteriores, donde `apiextensions.k8s.io/v1beta1` no está disponible, provoca un error en la restauración. Este error se produce al restaurar recursos personalizados definidos por el CRD.	Te recomendamos que uses las siguientes opciones: Si gestionas el CRD, sigue los pasos que se indican en la documentación de Kubernetes para especificar un esquema estructural para tu CRD. Si se trata de un CRD gestionado por GKE, puedes llamar a `kubectl delete crd` si no hay recursos que sirva el CRD. Si hay recursos que sirve el CRD, puedes habilitar el modo permisivo conociendo el comportamiento de restauración. Para obtener recomendaciones sobre CRDs comunes, consulta la documentación. Si se trata de un CRD de terceros, consulta la documentación correspondiente para migrar a `apiextensions.k8s.io/v1`. Si el modo permisivo está habilitado, la CRD sin un esquema estructural no se creará en un clúster de Kubernetes v1.22 o versiones posteriores. Para restaurar correctamente una copia de seguridad de este tipo, debes excluir los recursos proporcionados por el CRD de la restauración o crear el CRD en el clúster de destino antes de iniciar la restauración.
`Failed to query API resources ...`	Descripción: un servicio de API del clúster está mal configurado. Esto provoca que las solicitudes a la ruta de la API devuelvan el mensaje "No se han podido consultar los recursos de la API". Es posible que el servicio subyacente no exista o que aún no esté listo. Motivo: Copia de seguridad de GKE no puede crear copias de seguridad de los recursos proporcionados por la API no disponible.	Comprueba el servicio subyacente en la página de estado de la API de servicio `spec.service` para asegurarte de que está listo. Cuando el modo permisivo está habilitado, no se hará una copia de seguridad de los recursos de los grupos de APIs que no se hayan podido cargar.
`Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs`	Descripción: en Kubernetes v1.23 y versiones anteriores, las cuentas de servicio generan automáticamente un token respaldado por un secreto. Sin embargo, en versiones posteriores, Kubernetes eliminó esta función de token generado automáticamente. Es posible que un pod del clúster haya montado el volumen de secretos en el sistema de archivos de sus contenedores. Motivo: Si Copia de seguridad de GKE intenta restaurar una cuenta de servicio junto con su secreto generado automáticamente y un pod que monta el volumen secreto, la restauración parece completarse correctamente. Sin embargo, Kubernetes elimina el secreto, lo que provoca que el pod se quede bloqueado en la creación del contenedor y no se inicie.	Define el campo `spec.serviceAccountName` en el pod. Esta acción asegura que el token se monte automáticamente en `/var/run/secrets/kubernetes.io/serviceaccount` en los contenedores. Para obtener más información, consulta la documentación sobre cómo configurar cuentas de servicio para pods. Cuando el modo permisivo está habilitado, se crea una copia de seguridad del secreto, pero no se puede montar en pods de clústeres de Kubernetes 1.24 o versiones posteriores.

CustomResourceDefinitions "..." have invalid schemas

Descripción: Una definición de recurso personalizado (CRD) del clúster se aplicó originalmente como apiextensions.k8s.io/v1beta1 y no tiene un esquema estructural necesario en apiextensions.k8s.io/v1.

Motivo: Copia de seguridad de GKE no puede definir automáticamente el esquema estructural. Restaurar el CRD en clústeres de Kubernetes v1.22 o versiones posteriores, donde apiextensions.k8s.io/v1beta1 no está disponible, provoca un error en la restauración. Este error se produce al restaurar recursos personalizados definidos por el CRD.

Te recomendamos que uses las siguientes opciones:

Si gestionas el CRD, sigue los pasos que se indican en la documentación de Kubernetes para especificar un esquema estructural para tu CRD.

Si se trata de un CRD gestionado por GKE, puedes llamar a kubectl delete crd si no hay recursos que sirva el CRD. Si hay recursos que sirve el CRD, puedes habilitar el modo permisivo conociendo el comportamiento de restauración. Para obtener recomendaciones sobre CRDs comunes, consulta la documentación.

Si se trata de un CRD de terceros, consulta la documentación correspondiente para migrar a apiextensions.k8s.io/v1.

Si el modo permisivo está habilitado, la CRD sin un esquema estructural no se creará en un clúster de Kubernetes v1.22 o versiones posteriores. Para restaurar correctamente una copia de seguridad de este tipo, debes excluir los recursos proporcionados por el CRD de la restauración o crear el CRD en el clúster de destino antes de iniciar la restauración.

Failed to query API resources ...

Descripción: un servicio de API del clúster está mal configurado. Esto provoca que las solicitudes a la ruta de la API devuelvan el mensaje "No se han podido consultar los recursos de la API". Es posible que el servicio subyacente no exista o que aún no esté listo.

Motivo: Copia de seguridad de GKE no puede crear copias de seguridad de los recursos proporcionados por la API no disponible.

Comprueba el servicio subyacente en la página de estado de la API de servicio spec.service para asegurarte de que está listo.

Cuando el modo permisivo está habilitado, no se hará una copia de seguridad de los recursos de los grupos de APIs que no se hayan podido cargar.

Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs

Descripción: en Kubernetes v1.23 y versiones anteriores, las cuentas de servicio generan automáticamente un token respaldado por un secreto. Sin embargo, en versiones posteriores, Kubernetes eliminó esta función de token generado automáticamente. Es posible que un pod del clúster haya montado el volumen de secretos en el sistema de archivos de sus contenedores.

Motivo: Si Copia de seguridad de GKE intenta restaurar una cuenta de servicio junto con su secreto generado automáticamente y un pod que monta el volumen secreto, la restauración parece completarse correctamente. Sin embargo, Kubernetes elimina el secreto, lo que provoca que el pod se quede bloqueado en la creación del contenedor y no se inicie.

Define el campo spec.serviceAccountName en el pod. Esta acción asegura que el token se monte automáticamente en /var/run/secrets/kubernetes.io/serviceaccount en los contenedores. Para obtener más información, consulta la documentación sobre cómo configurar cuentas de servicio para pods.

Cuando el modo permisivo está habilitado, se crea una copia de seguridad del secreto, pero no se puede montar en pods de clústeres de Kubernetes 1.24 o versiones posteriores.

Definiciones de recursos personalizadas (CRDs) habituales con problemas y acciones recomendadas

A continuación, se indican algunos CRDs habituales que tienen problemas con las copias de seguridad y las acciones que recomendamos para solucionarlos:

capacityrequests.internal.autoscaling.k8s.io: Este CRD se usó temporalmente en clústeres de la versión 1.21. Ejecuta kubectl delete crd capacityrequests.internal.autoscaling.k8s.io para quitar el CRD.
scalingpolicies.scalingpolicy.kope.io: Este CRD se usaba para controlar los recursos de fluentd, pero GKE ha migrado a fluentbit. Ejecuta kubectl delete crd scalingpolicies.scalingpolicy.kope.io para quitar el CRD.
memberships.hub.gke.io: Ejecuta kubectl delete crd memberships.hub.gke.io para eliminar el CRD si no hay recursos de membresía. Habilita el modo permisivo si hay recursos de membresía.
applications.app.k8s.io: Habilita el modo permisivo conociendo el comportamiento de restauración.