Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

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

La herramienta de línea de comandos de bmctl te permite crear copias de seguridad y restablecer clústeres creados con el software de Distributed Cloud solo para equipos físicos con el objetivo de prepararte para la recuperación ante desastres o recuperar un clúster dañado en todos los tipos de clústeres. Restablecer desde una copia de seguridad es un último recurso que restablece el clúster y reemplaza la información existente del clúster. Restablece desde la copia de seguridad solo si un clúster falla de forma catastrófica. Comunícate con Atención al cliente de Cloud para obtener ayuda y tomar la mejor decisión.

Qué contenido se incluye en la copia de seguridad y cuál 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 datos de cargas de trabajo, 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 una copia de seguridad de los siguientes objetos:

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

Almacenamiento de cargas de trabajo y VM Runtime (sin copia de seguridad del proceso de copia de seguridad de `bmctl`)

bmctl no crea copias de seguridad de los siguientes datos:

Estado del entorno de ejecución del contenedor y del Pod en vivo. bmctl no guarda los procesos activos ni los datos de la aplicación en la memoria. Después de un restablecimiento, Kubernetes reinicia los Pods desde las especificaciones de etcd. Se pierde cualquier estado en la 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 volúmenes locales (LVP) ni controladores de almacenamiento externos.
Discos de máquina virtual. bmctl no crea copias de seguridad del contenido del disco duro virtual de la VM, como las bases de datos, los archivos o el estado del sistema operativo dentro de la VM.

Debes usar mecanismos de copia de seguridad nativos de Kubernetes o integrados en el invitado para proteger los datos de la aplicación y el estado de la máquina virtual. Si el 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 cómo configurar el almacenamiento, consulta Descripción general del almacenamiento.

Ejecuta agentes de copia de seguridad dentro del sistema operativo invitado de las máquinas virtuales del entorno de ejecución de VM 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 el restablecimiento de imágenes de SO a nivel de host. Por lo tanto, Google no admite la instalación de agentes de copia de seguridad de nivel de host de terceros directamente en el SO host ni la restauración de nodos físicos a partir de copias de seguridad de imágenes de nivel de SO o instantáneas de disco.

Si instalas agentes de copia de seguridad física 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ánea, lo que puede causar los siguientes problemas:

La base de datos 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 de kernel de terceros no compatibles entran en conflicto con las rutinas de kernel de bajo nivel y el entorno de ejecución de contenedores, lo que provoca que las actualizaciones del clúster fallen.
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 se desincroniza 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 se desincronizan con la fuente de información del servidor de la API, las direcciones IP de Dataplane V2 (Cilium) entran en conflicto y se descarta el tráfico.

Para recuperar un nodo físico que haya tenido 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 de recuperación, consulta Restablece 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, 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 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 tus nodos de destino, consulta Cambia la capacidad de almacenamiento local para los nodos de destino. Si no puedes cambiar el tamaño del directorio /tmp del nodo administrador, consulta Cambia la capacidad de almacenamiento local de un nodo administrador.

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

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

Verifica la sección Status en el resultado del comando para Conditions del 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 que se cree 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
  ...

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.

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:

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.
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.
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.
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.
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 el restablecimiento, sigue estos pasos para verificar que se haya completado correctamente:

Ejecuta los siguientes comandos para verificar la preparación de los nodos 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
```

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

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 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 restablecimiento que no sean muy claros o no expliquen 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 memoria suficiente para realizar el proceso de copia de seguridad o restablecimiento.

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, la eliminación de la configuración de arranque puede fallar 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 no se puede escribir en algunos directorios que requiere la restauración.

La versión 1.14 y posteriores de Google Distributed Cloud tienen mensajes de error más claros sobre qué directorios deben tener permisos de escritura. Asegúrate de que se pueda escribir en los directorios informados y actualiza los permisos en 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

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

Para resolver este problema, puedes volver a agregar de forma temporal la clave SSH original y, luego, realizar el restablecimiento. 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 de Node Agent

Si usas Node Agent y recibes un error que indica que la creación de la copia de seguridad no puede crear un archivo, similar a este:

  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 en el nodo administrador y en todos los nodos de destino. Si no puedes cambiar el tamaño del directorio /tmp de tus nodos de destino, consulta Aumenta 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.