Crear y restaurar una copia de seguridad de clústeres avanzados con gkectl

En este documento se describe cómo hacer copias de seguridad y restaurar clústeres de administradores y de usuarios de Google Distributed Cloud con la versión 1.32 o posterior que tengan habilitada la opción clúster avanzado. La función de copia de seguridad y restauración está en versión preliminar en la versión 1.32 y en versión GA en la versión 1.33 y posteriores.

Advertencia: Usar un archivo de copia de seguridad para restaurar el clúster es el último recurso. El proceso de restauración restablece el clúster y sobrescribe la información del clúster. No recomendamos restaurar a partir de un archivo de copia de seguridad a menos que el clúster haya fallado de forma catastrófica. Ponte en contacto con el equipo de Atención al Cliente de Cloud para que te ayude a decidir cuál es la mejor opción.

El proceso de gkectl 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.

Crear una copia de seguridad de un clúster

El comando gkectl 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 Seguridad en la capa de transporte (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 por error, el proceso de copia de seguridad solo utiliza 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.

Antes de empezar, asegúrate de que tu clúster funciona 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.

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

1. Ejecuta el siguiente comando para comprobar tu clúster:

   gkectl diagnose cluster --cluster-name CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

   Haz los cambios siguientes:

   • CLUSTER_NAME: el nombre del clúster del que quieres crear una copia de seguridad.

   • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

2. Ejecuta el comando correspondiente para crear una copia de seguridad del clúster:

   Clúster de administradores

   gkectl backup admin --kubeconfig ADMIN_KUBECONFIG
   

   Clúster de usuarios

   gkectl backup cluster --cluster-name CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

De forma predeterminada, el archivo tar de la copia de seguridad se guarda en el directorio gkectl-workspace/backups 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 ha creado la copia de seguridad y TIMESTAMP es la fecha y la hora en que se creó 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_2025-08-23T150405Z0700.tar.gz.

Si quieres, puedes especificar otro nombre y otra ubicación para el archivo de copia de seguridad con la marca --backup-file. Por ejemplo:

gkectl backup cluster testuser \
    --kubeconfig admin-cluster/kubeconfig \
    --backup-file cluster-backups/testuser-backup-aug-23-2025.tar.gz

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.

Crear una copia de seguridad en vSphere

Para configurar las copias de seguridad de forma que el archivo de copia de seguridad de los clústeres de administrador y de usuario se suba a vSphere, además de guardarse en tu estación de trabajo de administrador, haz lo siguiente:

1. Añade el campo clusterBackup.datastore al archivo de configuración del clúster de administrador:

   clusterBackup:
       datastore: DATASTORE
   

   Sustituye DATASTORE por el almacén de datos en el que quieras guardar la copia de seguridad. El almacén de datos debe estar en el mismo centro de datos que el clúster de administrador. Las copias de seguridad se encuentran en el directorio anthos/CLUSTER_NAME/backup del almacén de datos especificado.

2. Actualiza el clúster de administrador:

   gkectl update admin --kubeconfig ADMIN_KUBECONFIG \
       --config ADMIN_CONFIG
   

   Haz los cambios siguientes:

   • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

   • ADMIN_CONFIG: la ruta del archivo de configuración del clúster de administrador.

De forma predeterminada, el comando gkectl backup guarda los tres archivos de copia de seguridad más recientes en vSphere y elimina los archivos de copia de seguridad más antiguos. Si quieres conservar los archivos de copia de seguridad antiguos, añade la marca --keep-all-backups, que está disponible en la versión 1.32.100 y posteriores.

Restaurar un clúster

Restaurar un clúster a partir de una copia de seguridad es el último recurso y solo 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 de etcd está en un bucle de fallos.

Usa el comando gkectl restore solo si han fallado los tres nodos del plano de control.

• Si solo ha fallado un nodo y autoRepair.enabled tiene el valor true en el archivo de configuración del clúster de administrador, el nodo que ha fallado se reparará automáticamente. Si autoRepair.enabled no está configurado, añádelo al archivo de configuración del clúster de administrador y ejecuta gkectl update admin. Después de la actualización, el nodo se vuelve a crear automáticamente.

• Si se han producido errores en dos nodos del plano de control, consulta la sección Restaurar el quórum de esta página.

Nota: Para mejorar el rendimiento del clúster, Google Distributed Cloud usa una instancia de etcd independiente para almacenar objetos Event. Estos objetos Event tienen un tiempo de vida (TTL) de una hora. La operación de restauración del clúster crea una instancia de etcd-events nueva y vacía, por lo que se pierden los objetos Event. Sin embargo, la pérdida de objetos Event no afecta al funcionamiento del clúster. Los eventos deben considerarse 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 que los archivos se expongan de forma accidental, el proceso de restauración de Google Distributed Cloud solo utiliza archivos en memoria.

Antes de restaurar un clúster, asegúrate de que se cumplen las siguientes condiciones:

• Todas las máquinas de nodos del plano de control que estaban disponibles para el clúster en el momento de la copia de seguridad funcionan correctamente y se puede acceder a ellas.
• La conectividad SSH entre nodos funciona 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.
• Las claves de cuenta de servicio que se usaron en el momento de la copia de seguridad siguen activas. Estas claves de cuenta de servicio se restauran en el clúster restaurado.

Para restaurar un clúster, sigue estos pasos:

1. Ejecuta el comando correspondiente para restaurar el clúster:

   Clúster de administradores

   gkectl restore admin --backup-file BACKUP_FILE \
       --config ADMIN_CONFIG
   

   Haz los cambios siguientes:

   • BACKUP_FILE: la ruta y el nombre del archivo de copia de seguridad que estás usando.

   • ADMIN_CONFIG: la ruta al archivo de configuración del clúster de administrador.

   Clúster de usuarios

   gkectl restore cluster --cluster-name 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 nuevo archivo kubeconfig para el clúster restaurado en el directorio del espacio de trabajo gkectl-workspace.

2. Cuando finalice la restauración, ejecuta el siguiente comando para verificar que se ha completado correctamente:

   gkectl diagnose cluster --cluster-name CLUSTER_NAME \
       --kubeconfig GENERATED_KUBECONFIG
   

   Sustituye GENERATED_KUBECONFIG por el archivo kubeconfig generado.

Restaurar el quórum

Si se produce un error en dos nodos del plano de control de un clúster, puedes usar el comando gkectl restore para restaurar el quórum. Al restaurar el quórum, en lugar de especificar el archivo de copia de seguridad en el comando gkectl restore, especifica la dirección IP del nodo del plano de control que funciona.

Antes de ejecutar el comando, asegúrate de que se cumplen las siguientes condiciones:

• Hay un nodo de plano de control (y solo uno) que funciona.
• Se puede acceder al nodo del plano de control operativo con la clave SSH. Para obtener más información, consulta el artículo Conectarse a un nodo de clúster mediante SSH.

Para restaurar el quórum, ejecuta el comando correspondiente a tu tipo de clúster:

Clúster de administradores

gkectl restore admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG \
    --control-plane-node WORKING_NODE_IP \
    --ssh-key ADMIN_SSH_KEY_PATH

Haz los cambios siguientes:

• ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

• ADMIN_CONFIG: la ruta del archivo de configuración del clúster de administrador.

• WORKING_NODE_IP: la dirección IP del nodo del plano de control de trabajo.

• ADMIN_SSH_KEY_PATH: la ruta de la clave SSH del clúster de administrador.

Clúster de usuarios

gkectl restore cluster --cluster-name CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --control-plane-node WORKING_NODE_IP \
    --ssh-key USER_SSH_KEY_PATH

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster que vas a restaurar.

• ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.

• WORKING_NODE_IP: la dirección IP del nodo del plano de control de trabajo.

• USER_SSH_KEY_PATH: la ruta de la clave SSH del clúster de usuario.

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 Atención al cliente de Cloud.

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

Si la estación de trabajo en la que ejecutas el comando gkectl no tiene mucha RAM, es posible que no tengas suficiente memoria para realizar el proceso de copia de seguridad o restauración. Si es necesario, crea y usa un disco de trabajo temporal para procesar las operaciones de copia de seguridad o restauración mediante 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 debes ejecutar el comando como usuario root (o usar sudo).

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 haber realizado una 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.