Crear y restaurar una copia de seguridad de los clústeres con bmctl

En esta página se describe cómo usar bmctl para crear copias de seguridad y restaurar clústeres creados con Google Distributed Cloud (solo software) en hardware desnudo. Estas instrucciones se aplican a todos los tipos de clústeres.

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

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud. También puedes consultar la sección 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 admitidos.

Crear una copia de seguridad de un clúster

El comando bmctl backup cluster añade la información del clúster del almacén etcd y los certificados de PKI del clúster especificado a un archivo tar. El almacén etcd es el almacén de respaldo de Kubernetes para todos los datos del clúster y contiene todos los objetos de Kubernetes y los objetos personalizados necesarios para gestionar el estado del clúster. Los certificados de PKI se usan para la autenticación a través de TLS. Estos datos se almacenan en el plano de control del clúster o en uno de los planos de control de 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. Guarda los archivos de copia de seguridad en una ubicación segura. Para evitar que los archivos se expongan de forma accidental, el proceso de copia de seguridad de Google Distributed Cloud solo usa archivos en memoria.

Crea copias de seguridad de tus clústeres con regularidad para asegurarte de que los datos de las capturas estén relativamente actualizados. Ajusta la frecuencia de las copias de seguridad para reflejar la frecuencia de los cambios significativos en tus clústeres.

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

Para crear una copia de seguridad de un clúster, sigue estos pasos:

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

    El objetivo del proceso de copia de seguridad es capturar el clúster en un estado correcto conocido para que puedas restaurar el funcionamiento si se produce un fallo catastrófico.

    Usa el siguiente comando para comprobar tu clúster:

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

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

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

    kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster del que se va a crear una copia de seguridad.
    • CLUSTER_NAMESPACE: el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de clúster de Google Distributed Cloud tienen el nombre del clúster con el prefijo cluster-. Por ejemplo, si le das el nombre test a tu clúster, el espacio de nombres tendrá un nombre como cluster-test.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

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

    Como se muestra en el siguiente ejemplo, el estado False de 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

    Haz los cambios siguientes:

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

    De forma predeterminada, el archivo tar de copia de seguridad se guarda en el directorio del espacio de trabajo (bmctl-workspace de forma predeterminada) de tu estación de trabajo de administrador. El archivo tar se llama CLUSTER_NAME_backup_TIMESTAMP.tar.gz, donde CLUSTER_NAME es el nombre del clúster del que se está haciendo la copia de seguridad y TIMESTAMP es la fecha y la hora en que se hizo la copia de seguridad. Por ejemplo, si el nombre del clúster es testuser, el archivo de copia de seguridad tendrá un nombre como testuser_backup_2006-01-02T150405Z0700.tar.gz.

    Para especificar otro nombre y otra ubicación para el archivo de copia de seguridad, usa la marca --backup-file.

El archivo de copia de seguridad caduca al cabo de un año y el proceso de restauración del clúster no funciona con archivos de copia de seguridad caducados.

Restaurar un clúster

Restaurar un clúster a partir de una copia de seguridad es el último recurso y debe usarse cuando un clúster haya fallado de forma catastrófica y no se pueda volver a poner en funcionamiento de ninguna otra forma. Por ejemplo, los datos de etcd están dañados o el pod etcd está en un bucle de fallos.

El archivo tar de copia de seguridad contiene credenciales sensibles, incluidas las claves de tu cuenta de servicio y la clave SSH. Para evitar que los archivos se expongan de forma accidental, el proceso de restauración de Google Distributed Cloud solo utiliza archivos en memoria.

La versión de bmctl que uses para restaurar un clúster debe coincidir con la versión del clúster de gestión.

Para restaurar un clúster, sigue estos pasos:

  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 correctamente y se pueda acceder a ellas.

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

    Estas claves SSH se restauran como parte del proceso de restauración.

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

    Estas claves de cuenta de servicio se restauran en el clúster restaurado.

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

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

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que vas a restaurar.
    • BACKUP_FILE: la ruta y el nombre del archivo de copia de seguridad que estás usando.

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

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

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que vas a restaurar.
    • BACKUP_FILE: la ruta y el nombre del archivo de copia de seguridad que estás usando.
    • ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.

Al final del proceso de restauración, se genera un archivo kubeconfig para el clúster restaurado.

Cuando finalice la restauración, sigue estos pasos para comprobar que se ha completado correctamente:

  1. Ejecuta los siguientes comandos para verificar que el nodo esté listo y que los pods del sistema se estén ejecutando con el archivo kubeconfig generado:

    Hay dos tipos de pods de etcd:

    • etcd-HOST_NAME, que corresponde al pod principal etcd
    • 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. En 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'

    En el caso de un miembro de etcd correcto, la respuesta debería tener el siguiente aspecto:

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

  3. En cada etcd-events Pod, 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'

    En el caso de un miembro de etcd-events correcto, 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 creación o restauración de copias de seguridad, las siguientes secciones pueden ayudarte a solucionarlos.

Si necesitas más ayuda, ponte en contacto con el equipo de Asistencia de Google.

Quedarse sin memoria durante una copia de seguridad o una restauración

Es posible que recibas mensajes de error durante el proceso de creación o restauración de copias de seguridad que no sean muy explícitos o que no indiquen claramente los pasos siguientes. 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.

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 los archivos, 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 que use sudo).

Faltan permisos para los archivos durante la restauración

Después de completar una tarea de restauración, puede que no se pueda eliminar el bootstrap y se muestre un mensaje de error similar al siguiente:

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

Este error puede significar que algunos directorios necesarios para la restauración no tienen permiso de escritura.

Google Distributed Cloud versión 1.14 y posteriores tienen mensajes de error más claros sobre qué directorios deben tener permisos de escritura. Asegúrate de que los directorios denunciados tengan permiso de escritura y actualiza los permisos de los directorios según sea necesario.

La actualización de la clave SSH después de que una copia de seguridad interrumpa el proceso de restauración

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

Para solucionar este problema, puedes volver a añadir temporalmente la clave SSH original y, a continuación, realizar la restauración. Una vez que se haya completado el proceso de restauración, podrás rotar la clave SSH.