Crea copias de seguridad de los clústeres y restablécelos con bmctl

En este documento, se describe cómo usar bmctl para crear copias de seguridad y restablecer clústeres creados con software de Distributed Cloud solo para Bare Metal. Estas instrucciones se aplican a todos los tipos de clústeres.

Advertencia: El uso de un archivo de copia de seguridad para restablecer el clúster es el último recurso. El proceso de restablecimiento restablece el clúster existente y reemplaza la información del clúster. No recomendamos restablecer desde un archivo de copia de seguridad, a menos que el clúster haya fallado de forma catastrófica. Comunícate con Atención al cliente de Cloud para obtener ayuda a fin de tomar la mejor decisión.

Qué elementos tienen una copia de seguridad y cuáles no

El proceso de copia de seguridad y restablecimiento de bmctl opera en la capa del plano de control de Kubernetes y es diferente de otras soluciones de copia de seguridad. Las soluciones de copia de seguridad que no son de Kubernetes capturan los datos de la carga de trabajo, el almacenamiento persistente y los sistemas operativos host de las máquinas físicas. El proceso de copia de seguridad y restablecimiento de bmctl restablece tus clústeres de Kubernetes sin crear copias de seguridad de ninguno de estos otros componentes.

Estado del plano de control (respaldado por el proceso de copia de seguridad de bmctl)

bmctl crea copias de seguridad de los siguientes objetos:

• Almacén de etcd. Todos los recursos de Kubernetes y los objetos personalizados que definen la configuración y el estado elegido del clúster (por ejemplo, especificaciones de Pod, implementaciones, ConfigMaps y Secrets)
• Certificados de PKI Certificados que se usan para la comunicación segura dentro del clúster.
• Archivos de configuración y manifiestos de nodos Son configuraciones relacionadas con los nodos del clúster.

Almacenamiento de la carga de trabajo y de VM Runtime (no se realiza una copia de seguridad con el proceso de bmctl)

bmctl no crea copias de seguridad de los siguientes datos:

• Estado activo del Pod y del entorno de ejecución del contenedor. bmctl no guarda los procesos activos ni los datos de las aplicaciones en la memoria. Después de un restablecimiento, Kubernetes reinicia los Pods a partir de las especificaciones de etcd. Se perderá el estado en memoria que no se haya guardado.
• Almacenamiento de volúmenes persistentes. bmctl no crea copias de seguridad de los datos almacenados en volúmenes persistentes, volúmenes creados por el aprovisionador de volumen local (LVP) ni controladores de almacenamiento externo.
• Son discos de máquinas virtuales. bmctl no crea copias de seguridad del contenido del disco duro virtual de la VM, como bases de datos, archivos o el estado del sistema operativo dentro de la VM.

Debes usar mecanismos de copia de seguridad nativos de Kubernetes o en el huésped para proteger los datos de la aplicación y el estado de la máquina virtual. Si tu controlador de almacenamiento subyacente admite instantáneas de volumen de CSI, usa las instantáneas de volumen estándar de Kubernetes para crear copias de volúmenes persistentes en un momento determinado. Para obtener más información sobre la configuración del almacenamiento, consulta Descripción general del almacenamiento.

Ejecuta agentes de copia de seguridad dentro del sistema operativo invitado de las máquinas virtuales de VM Runtime o implementa herramientas de copia de seguridad nativas de la aplicación dentro de las cargas de trabajo de Kubernetes.

Sistemas operativos de host físico (no compatibles)

Trata los sistemas operativos Linux físicos en los nodos de Google Distributed Cloud como infraestructura desechable. La arquitectura de redes de Kubernetes no admite la restauración de imágenes del SO a nivel del host. Por lo tanto, Google no admite la instalación de agentes de copia de seguridad de terceros a nivel del host directamente en el SO del host ni la restauración de nodos físicos a partir de copias de seguridad de imágenes a nivel del SO o instantáneas de disco.

Si instalas agentes de copias de seguridad físicas de terceros directamente en el SO Linux del host, puedes generar riesgos graves.

Muchos agentes de copia de seguridad instalan módulos de kernel propietarios o controladores de filtro a nivel de bloque para hacer un seguimiento de los cambios y bloquear los bloques de disco locales durante las operaciones de instantáneas, lo que puede causar los siguientes problemas:

• La base de datos de etcd no puede agregar datos a sus registros de escritura anticipada, se agota el tiempo de espera de los latidos de los nodos, falla el consenso de Raft y los clústeres se vuelven inestables.
• Los controladores del kernel de terceros no admitidos entran en conflicto con las rutinas del kernel de bajo nivel y el tiempo de ejecución del contenedor, lo que provoca que fallen las actualizaciones del clúster.
• Restablecer un nodo físico a partir de una copia de seguridad de imagen o una instantánea de disco infringe el protocolo de consenso de Raft. La base de datos de etcd deja de estar sincronizada con los registros de los nodos del plano de control y se produce una corrupción grave del estado del clúster.
• Los nodos trabajadores dejan de estar sincronizados con la fuente de información del servidor de la API, las direcciones IP del plano de datos V2 (Cilium) entran en conflicto y se descarta el tráfico.

Para recuperar un nodo físico que experimentó una falla de hardware o del sistema operativo, no restablezcas una imagen de SO. En su lugar, quita el nodo del clúster de forma limpia, reinstala un sistema operativo base limpio y vuelve a agregar el nodo al grupo de nodos. Para obtener instrucciones detalladas sobre la recuperación, consulta Cómo restablecer un nodo con errores.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud. También puedes consultar Obtén asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

• Requisitos para abrir un caso de asistencia
• Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
• Componentes compatibles

Crea una copia de seguridad de un clúster

El comando bmctl backup cluster empaqueta los datos de etcd y los certificados de PKI del clúster en un archivo tar. La base de datos de etcd es el almacén de datos central para todos los datos del clúster, ya que contiene todos los objetos de Kubernetes y los recursos personalizados necesarios para administrar el estado del clúster. Los certificados de PKI se autentican a través de TLS. Se crea una copia de seguridad de estos datos desde el plano de control del clúster o desde uno de los planos de control para una implementación de alta disponibilidad (HA).

El archivo tar de copia de seguridad contiene credenciales sensibles, incluidas las claves de tu cuenta de servicio y la clave SSH. Almacena los archivos de copia de seguridad en una ubicación segura. Para evitar la exposición no deseada de archivos, el proceso de copia de seguridad de Google Distributed Cloud solo usa archivos en la memoria.

Realiza una copia de seguridad de tus clústeres con regularidad para asegurarte de que tus datos de instantáneas sean relativamente actuales. Ajusta la velocidad de las copias de seguridad para reflejar la frecuencia de los cambios significativos en los clústeres.

La versión de bmctl que usas para crear una copia de seguridad de un clúster debe coincidir con la versión del clúster de administración.

Si instalaste Node Agent en tus clústeres, el directorio /tmp en el nodo de administrador y todos los nodos de destino deben tener 12 GB de espacio libre. Si no puedes cambiar el tamaño del directorio /tmp para los nodos de destino, consulta Cómo cambiar la capacidad de almacenamiento local para los nodos de destino. Si no puedes cambiar el tamaño del directorio /tmp para el nodo administrador, consulta Cómo cambiar la capacidad de almacenamiento local de un nodo administrador.

Para crear una copia de seguridad de un clúster, haz lo siguiente:

1. Asegúrate de que tu clúster funcione correctamente, con credenciales de trabajo y conectividad SSH a todos los nodos.

   El intent del proceso de copia de seguridad es capturar el clúster en un buen estado conocido para que puedas restablecer la operación si ocurre una falla catastrófica.

   Usa el siguiente comando para verificar tu clúster:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: Es el nombre del clúster del que planeas crear una copia de seguridad.
   • ADMIN_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

2. Ejecuta el siguiente comando para asegurarte de que el clúster de destino no esté en un estado de conciliación:

   kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: el nombre del clúster del que se creará una copia de seguridad.
   • CLUSTER_NAMESPACE: es el espacio de nombres para el clúster. De forma predeterminada, los espacios de nombres de los clústeres de Google Distributed Cloud son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres tiene un nombre como cluster-test.
   • ADMIN_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

3. Verifica la sección Status en el resultado del comando para ver Conditions del tipo Reconciling.

   Como se muestra en el siguiente ejemplo, el estado False para estos Conditions significa que el clúster es estable y está listo para crear una copia de seguridad.

   ...
   Status:
     ...
     Cluster State:  Running
     ...
     Control Plane Node Pool Status:
       ...
       Conditions:
         Last Transition Time:  2023-11-03T16:37:15Z
         Observed Generation:   1
         Reason:                ReconciliationCompleted
         Status:                False
         Type:                  Reconciling
     ...
   

4. Ejecuta el siguiente comando para crear una copia de seguridad del clúster:

   bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: el nombre del clúster del que se creará una copia de seguridad.
   • ADMIN_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador.

   De forma predeterminada, el archivo tar de copia de seguridad guardado en el directorio del lugar de trabajo (bmctl-workspace) de forma predeterminada en tu estación de trabajo de administrador. El archivo tar se llama CLUSTER_NAME_backup_TIMESTAMP.tar.gz, en el que CLUSTER_NAME es el nombre del clúster en el que se crea una copia de seguridad y TIMESTAMP es la fecha y hora en que se realizó la copia de seguridad. Por ejemplo, si el nombre del clúster es testuser, el archivo de copia de seguridad tiene un nombre como testuser_backup_2006-01-02T150405Z0700.tar.gz.

   A fin de especificar un nombre y una ubicación diferentes para el archivo de copia de seguridad, usa la marca --backup-file.

El archivo de copia de seguridad se vence después de un año y el proceso de restablecimiento del clúster no funciona con los archivos de copia de seguridad vencidos.

Restablece un clúster

Restablecer un clúster desde una copia de seguridad es el último recurso y se debe usar cuando un clúster falla de manera catastrófica y no puede regresar al servicio de ninguna otra manera. Por ejemplo, los datos de etcd están dañados o el Pod de etcd está en un bucle de falla.

Nota: Para mejorar el rendimiento del clúster, Google Distributed Cloud usa una instancia de etcd separada para almacenar objetos de Event. Estos objetos Event tienen un tiempo de actividad (TTL) de una hora. La operación de restablecimiento del clúster crea una instancia de etcd-events nueva y vacía, por lo que pierdes los objetos Event existentes. Sin embargo, la pérdida de objetos Event no tiene impacto en el funcionamiento del clúster. Los eventos deben tratarse solo como datos informativos, complementarios y de mejor esfuerzo.

El archivo tar de copia de seguridad contiene credenciales sensibles, incluidas las claves de tu cuenta de servicio y la clave SSH. Para evitar la exposición no deseada de archivos, el proceso de restablecimiento de Google Distributed Cloud solo usa archivos en la memoria.

La versión de bmctl que usas para restablecer un clúster debe coincidir con la versión del clúster de administración.

Para restablecer un clúster, haz lo siguiente:

1. Asegúrate de que todas las máquinas de nodo que estaban disponibles para el clúster en el momento de la copia de seguridad funcionen de forma correcta y se pueda acceder a ellas.

2. Asegúrate de que la conectividad SSH entre nodos funcione con las claves SSH que se usaron en el momento de la copia de seguridad.

   Estas claves SSH se restablecen como parte del proceso de restablecimiento.

3. Asegúrate de que las claves de la cuenta de servicio que se usaron en el momento de la copia de seguridad aún estén activas.

   Estas claves de cuenta de servicio se restablecen para el clúster restablecido.

4. Para restablecer un clúster de administrador, híbrido o independiente, ejecuta el siguiente comando:

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: el nombre del clúster que deseas restablecer.
   • BACKUP_FILE: la ruta de acceso y el nombre del archivo de copia de seguridad que usas.

5. Para restablecer un clúster de usuario, ejecuta el siguiente comando:

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
       --kubeconfig ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: el nombre del clúster que deseas restablecer.
   • BACKUP_FILE: la ruta de acceso y el nombre del archivo de copia de seguridad que usas.
   • ADMIN_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador.

Al final del proceso de restablecimiento, se genera un archivo kubeconfig nuevo para el clúster restablecido.

Cuando finalice la restauración, sigue estos pasos para verificar que se haya realizado correctamente:

1. Ejecuta los siguientes comandos para verificar la preparación del nodo y los Pods del sistema que se ejecutan con el archivo kubeconfig generado:

   Existen dos tipos de pods de etcd:

   • etcd-HOST_NAME, que corresponde al Pod etcd principal
   • etcd-events-HOST_NAME, que corresponde al Pod etcd-events

   kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
   kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
   

2. Para cada pod de etcd, ejecuta lo siguiente para verificar el estado de etcd:

   kubectl exec ETCD_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Para un miembro de etcd en buen estado, la respuesta debería ser similar a la siguiente:

   https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms
   

3. Para cada Pod etcd-events, ejecuta el siguiente comando para verificar su etcd-events estado:

   kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Para un miembro de etcd-events en buen estado, la respuesta debería ser similar a la siguiente:

   https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms
   

Solucionar problemas

Si tienes problemas con el proceso de copia de seguridad o restauración, las siguientes secciones pueden ayudarte a solucionar el problema.

Si necesitas asistencia adicional, comunícate con Atención al Cliente de Google.

Memoria insuficiente durante una copia de seguridad o un restablecimiento

Es posible que recibas mensajes de error durante el proceso de copia de seguridad o restauración que no sean muy autoexplicativos ni claros sobre los próximos pasos. Si la estación de trabajo en la que ejecutas el comando bmctl no tiene mucha RAM, es posible que no tengas suficiente memoria para realizar el proceso de copia de seguridad o restablecimiento.

Google Distributed Cloud versión 1.13 y posteriores pueden usar el parámetro --use-disk en el comando de copia de seguridad. Para conservar los permisos de archivo, este parámetro modifica los permisos de los archivos, por lo que requiere que el usuario que ejecuta el comando sea un usuario raíz (o use sudo).

Faltan permisos para los archivos durante el restablecimiento

Después de una tarea de restablecimiento exitosa, es posible que la eliminación del bootstrap falle y se muestre un mensaje de error similar al siguiente ejemplo:

  Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

Este error podría significar que algunos directorios necesarios para la restauración no son grabables.

Las versiones 1.14 y posteriores de Google Distributed Cloud tienen mensajes de error más claros sobre qué directorios deben tener permiso de escritura. Asegúrate de que los directorios informados se puedan escribir y actualiza los permisos de los directorios según sea necesario.

La actualización de la clave SSH después de que se crea una copia de seguridad interrumpe el proceso de restablecimiento

Es posible que fallen las operaciones relacionadas con SSH durante el proceso de restablecimiento si se actualiza la clave SSH después de que se realizó la copia de seguridad. En este caso, la nueva clave SSH deja de ser válida para el proceso de restablecimiento.

Para resolver este problema, puedes volver a agregar temporalmente la clave SSH original y, luego, realizar la restauración. Una vez que se complete el proceso de restablecimiento, podrás rotar la clave SSH.

No se puede crear una copia de seguridad para un nodo del agente de nodo

Si usas el agente de nodo y recibes un error que indica que la creación de la copia de seguridad no pudo crear un archivo, similar al siguiente:

  I0508 15:29:36.831790  657351 backup_cluster.go:255] Retrying backup node: 128.187.102.133, due to error: failed receive chunk data: rpc error: code = Unknown desc = archiver.CreateArchiveWithList
  failed: failed to create archive file: failed to copy data from file: var/lib/etcd-events/member/snap/db, file size: 26136576, copy bytes: 12478464,
  error: write /tmp/uploadFileTemp1561164777: no space left on device

Verifica que haya 12 GB de espacio libre en el directorio /tmp del nodo administrador y de todos los nodos de destino. Si no puedes cambiar el tamaño del directorio /tmp para tus nodos de destino, consulta Cómo aumentar la capacidad de almacenamiento local para las copias de seguridad del agente de nodo.

Después de confirmar que hay 12 GB de espacio libre en el directorio /tmp para el nodo administrador y todos los nodos de destino, vuelve a intentar la copia de seguridad.