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

En esta página, se describe cómo usar bmctl para crear copias de seguridad de clústeres y restablecer los creados con Google Distributed Cloud (solo software) en 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.

El proceso de copia de seguridad y restablecimiento de bmctl no incluye volúmenes persistentes. Los volúmenes creados por el aprovisionador de volumen local (LVP) no se modifican.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud. También puedes consultar Obtener 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 agrega la información del clúster del depósito de etcd y los certificados de PKI para el clúster especificado al clúster en un archivo tar. El almacén de etcd es el almacenamiento de copia de seguridad de Kubernetes para todos los datos del clúster y contiene todos los objetos de Kubernetes y objetos personalizados requeridos para administrar el estado del clúster. Los certificados de PKI se usan para la autenticación con TLS. Estos datos tienen copia de seguridad desde el plano de control del clúster o en uno de los planos de control para una implementación con 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 una exposición accidental 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.

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 Conditions de tipo Reconciling.

   Como se muestra en el siguiente ejemplo, un estado de 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 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 afecta 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 una exposición accidental 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 verse de la siguiente manera:

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

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

   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 restablecimiento, las siguientes secciones pueden ayudarte a solucionar el problema.

Si necesitas asistencia adicional, comunícate con el equipo de asistencia de Google.

Se agota la memoria 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 restauración.

La versión 1.13 y posteriores de Google Distributed Cloud 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 se produzca un error al borrar el bootstrap con 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 una copia de seguridad interrumpe el proceso de restablecimiento

Es posible que las operaciones relacionadas con SSH durante el proceso de restablecimiento fallen si la clave SSH se actualiza 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, puedes rotar la clave SSH.