Habilita el modo permisivo en un plan de copia de seguridad

Autopilot Estándar

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

Durante la ejecución de la copia de seguridad, si la copia de seguridad para GKE detecta condiciones que pueden hacer que el restablecimiento falle, la copia de seguridad en sí falla. El motivo de la falla se proporciona en el campo state_reason de la copia de seguridad. En la consola de Google Cloud, este campo se denomina Motivo de estado.

Si habilitas el modo permisivo, la descripción del problema se proporciona en el campo Motivo del estado, pero la copia de seguridad no fallará. Puedes habilitar este comportamiento si estás al tanto del problema y estás preparado para emplear una solución alternativa en el momento del restablecimiento.

El siguiente es un ejemplo de un mensaje de error que puedes ver en el campo Motivo del estado de la copia de seguridad que sugiere habilitar el modo permisivo: If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

Habilita el modo permisivo:

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

Reemplaza lo siguiente:

BACKUP_PLAN: el nombre del plan de copia de seguridad que deseas actualizar.
PROJECT_ID es el ID de tu proyecto de Google Cloud.
LOCATION: Es la región de procesamiento del recurso, por ejemplo, us-central1. Consulta Acerca de las ubicaciones de los recursos.

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

Console

Usa las siguientes instrucciones para habilitar el modo permisivo en la consola de Google Cloud:

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

Ir a Google Kubernetes Engine
En el menú de navegación, haz clic en Copia de seguridad para GKE.
Haz clic en la pestaña Planes de copia de seguridad.
Expande 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 editar la sección con el Modo de copia de seguridad.
Haz clic en la casilla de verificación Modo permisivo y, luego, en Guardar cambios.

Terraform

Actualiza el recurso google_gke_backup_backup_plan existente.

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

Reemplaza lo siguiente:

NAME: el nombre de google_gke_backup_backup_plan que deseas actualizar.

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

Soluciona problemas relacionados con las copias de seguridad

En la siguiente tabla, se proporcionan explicaciones y acciones recomendadas para varios Mensajes de problemas relacionados con las copias de seguridad que se muestran en el campo Motivo del estado de la copia de seguridad.

Mensaje de problemas relacionados con las copias de seguridad	Descripción del mensaje y motivo del problema	Acción recomendada
`CustomResourceDefinitions "..." have invalid schemas`	Descripción: Originalmente, se aplicó una definición de recurso personalizado (CRD) en el clúster como `apiextensions.k8s.io/v1beta1` y no tiene un esquema estructural requerido en `apiextensions.k8s.io/v1`. Motivo: La copia de seguridad para GKE no puede definir automáticamente el esquema estructural. Restablecer la CRD en los clústeres de Kubernetes v1.22+, en los que `apiextensions.k8s.io/v1beta1` no está disponible, hace que el restablecimiento falle. Este problema ocurre cuando se restablecen los recursos personalizados definidos por la CRD.	Te recomendamos que uses las siguientes opciones: Si administras la CRD, sigue los pasos en la documentación de Kubernetes para especificar un esquema estructural para tu CRD. Si es una CRD administrada por GKE, puedes llamar a `kubectl delete crd` si no hay recursos existentes que entrega la CRD. Si hay recursos existentes que entrega la CRD, puedes habilitar el modo permisivo si comprendes el comportamiento del restablecimiento. Para obtener recomendaciones sobre las CRD comunes, consulta la documentación. Si se trata de una CRD de terceros, consulta la documentación relevante para migrar a `apiextensions.k8s.io/v1`. Cuando el modo permisivo está habilitado, no se crea una copia de seguridad de la CRD sin un esquema estructural en un clúster de Kubernetes v1.22 o superior. Para restablecer correctamente esa copia de seguridad, debes excluir los recursos que entrega el CRD del restablecimiento o crear el CRD en el clúster de destino antes de iniciar el restablecimiento.
`PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up`	Descripción: En el clúster de origen, un PVC está vinculado a un PV que no es un volumen de disco persistente. Motivo: La copia de seguridad para GKE solo admite copias de seguridad de datos de volúmenes de discos persistentes. A los PVC de discos no persistentes que se restablezcan con la política Aprovisionar volúmenes nuevos y restablecer los datos del volumen desde la copia de seguridad, no se restablecerán los datos de volumen. Sin embargo, la política Reutilizar volúmenes existentes que contienen tus datos permite que los PVC se vuelvan a conectar al controlador de volumen original. Esto es útil para los tipos de volúmenes que respalda un servidor externo, como NFS.	Habilita el modo permisivo teniendo en cuenta las opciones de restablecimiento disponibles para los volúmenes de discos no persistentes en el clúster de origen. Para crear una copia de seguridad de los volúmenes de Filestore, consulta Administra volúmenes de Filestore con Copia de seguridad para GKE. Cuando se habilita el modo permisivo, se crea una copia de seguridad de la configuración de PVC, pero no los datos del volumen.
`PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up`	Descripción: Un PVC en el clúster no está vinculado a un PV. Motivo: La copia de seguridad para GKE puede crear una copia de seguridad del PVC, pero no hay datos de volumen para crear una copia de seguridad. Esta situación puede indicar una configuración incorrecta o una discrepancia entre el almacenamiento solicitado y el disponible.	Verifica si el PVC no vinculado se encuentra en una condición aceptable. De ser así, habilita el modo permisivo. Ten en cuenta las implicaciones del comportamiento de las copias de seguridad. Cuando se habilita el modo permisivo, se crea una copia de seguridad de la configuración de PVC, pero no hay datos de volumen para crear una copia de seguridad.
`Failed to query API resources ...`	Descripción: Un servicio de API en el clúster está mal configurado. Esto hace que las solicitudes a la ruta de acceso a la API devuelvan el mensaje “No se pudieron consultar los recursos de la API”. Es posible que el servicio subyacente no exista o que aún no esté listo. Motivo: La copia de seguridad para GKE no puede crear una copia de seguridad de los recursos que entrega la API no disponible.	Verifica el servicio subyacente en el `spec.service` del servicio de la API para asegurarte de que esté listo. Cuando se habilita el modo permisivo, no se crea una copia de seguridad de los recursos de los grupos de APIs que no se pudieron cargar.
`Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs`	Descripción: En las versiones de Kubernetes v1.23 y anteriores, las cuentas de servicio generan automáticamente un token respaldado por un secreto. Sin embargo, en versiones posteriores, Kubernetes quitó esta función de token generado automáticamente. Es posible que un Pod del clúster haya activado el volumen del Secret en las capacidades un sistema de archivos. Motivo: Si la Copia de seguridad para GKE intenta restablecer una cuenta de servicio junto con su secreto generado automáticamente y un Pod que activa el volumen de secretos, el restablecimiento parece haberse realizado correctamente. Sin embargo, Kubernetes quita el secreto, lo que hace que el Pod se detenga durante la creación del contenedor y no se inicie.	Define el campo `spec.serviceAccountName` en el Pod. Esta acción garantiza que el token se active automáticamente en `/var/run/secrets/kubernetes.io/serviceaccount`, en los contenedores. Si necesitas 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 Secret, pero no se puede activar en Pods en clústeres de Kubernetes v1.24+.

CRDs comunes con problemas y acciones recomendadas

Estas son algunas CRD comunes que tienen problemas de copia de seguridad y las acciones que recomendamos para abordarlos:

capacityrequests.internal.autoscaling.k8s.io: Esta CRD se usó de forma temporal en los clústeres v1.21. Ejecuta kubectl delete crd capacityrequests.internal.autoscaling.k8s.io para quitar la CRD.
scalingpolicies.scalingpolicy.kope.io: Esta CRD se usó para controlar los recursos de fluentd, pero GKE migró al uso de fluentbit. Ejecuta kubectl delete crd scalingpolicies.scalingpolicy.kope.io para quitar la CRD.
memberships.hub.gke.io: Ejecuta kubectl delete crd memberships.hub.gke.io para quitar la 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 si comprendes el comportamiento de restablecimiento.