Habilita el modo permisivo en un plan de copia de seguridad

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 Copia de seguridad para GKE detecta condiciones que probablemente provoquen una falla en el restablecimiento, la copia de seguridad en sí falla. El motivo del error se proporciona 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

Cuando las fallas en las copias de seguridad no son aceptables y no es posible solucionar los problemas subyacentes, puedes habilitar el modo permisivo. El modo permisivo garantiza que las copias de seguridad se completen correctamente, incluso si se detectan recursos de GKE que podrían causar fallas en el restablecimiento durante el proceso de copia de seguridad. Los detalles sobre los problemas se proporcionan en el campo Motivo del estado de la copia de seguridad.

Te recomendamos que uses esta opción solo si comprendes los problemas y puedes implementar soluciones alternativas durante el proceso de restablecimiento. Para obtener una lista de los posibles mensajes de error en el campo Motivo del estado de la copia de seguridad con las acciones recomendadas, consulta Cómo solucionar problemas relacionados con las copias de seguridad.

Habilita 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

Reemplaza lo siguiente:

Console

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

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

    Ir a Google Kubernetes Engine

  2. En el menú de navegación, haz clic en Copia de seguridad para GKE.

  3. Haz clic en la pestaña Planes de copia de seguridad.

  4. Expande el clúster y haz clic en el nombre del plan.

  5. Haz clic en la pestaña Detalles para editar los detalles del plan.

  6. Haz clic en Editar para editar la sección con el Modo de copia de seguridad.

  7. 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 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 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, la CRD sin un esquema estructural no se incluirá en la copia de seguridad en un clúster de Kubernetes v1.22 o versiones posteriores. Para restablecer correctamente una copia de seguridad de este tipo, debes excluir los recursos que proporciona la CRD del restablecimiento o crear la CRD en el clúster de destino antes de iniciar el restablecimiento.

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 crearán copias de seguridad de los recursos de los grupos de APIs que no se cargaron.

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 se habilita el modo permisivo, se crea una copia de seguridad del secreto, pero no se puede activar en Pods en clústeres de Kubernetes v1.24 y versiones posteriores.

Definiciones de recursos personalizados (CRD) comunes con problemas y acciones recomendadas

Estos son algunos CRDs comunes que tienen problemas de copias de seguridad y las acciones que recomendamos para abordar los problemas:

  • 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.