Introducción
Al igual que cualquier otro entorno, los datos en un clúster de Kubernetes pueden estar en riesgo de perderse. Para prevenir problemas graves, es esencial tener un plan de recuperación de datos a mano. Una forma simple y efectiva de hacerlo es haciendo copias de seguridad, asegurando que sus datos estén seguros en caso de eventos inesperados. Las copias de seguridad pueden ejecutarse de forma única o programada. Es una buena idea tener copias de seguridad programadas para garantizar que tenga una copia de seguridad reciente a la que pueda recurrir fácilmente.
Velero: una herramienta de código abierto diseñada para ayudar en las operaciones de respaldo y restauración para clústeres de Kubernetes. Es ideal para el caso de uso de recuperación de desastres, así como para tomar instantáneas del estado de su aplicación antes de realizar operaciones del sistema en su clúster, como actualizaciones. Para obtener más detalles sobre este tema, visite la página oficial de Cómo Funciona Velero.
En este tutorial, aprenderá cómo implementar Velero en su clúster de Kubernetes, crear copias de seguridad y recuperarse de una copia de seguridad si algo sale mal. Puede hacer copias de seguridad de todo su clúster o elegir opcionalmente un espacio de nombres o un selector de etiquetas para hacer una copia de seguridad de su clúster.
Tabla de Contenidos
- Prerrequisitos
- Paso 1 – Instalación de Velero usando Helm
- Paso 2 – Ejemplo de respaldo y restauración de espacio de nombres
- Paso 3 – Ejemplo de respaldo y restauración de todo el clúster
- Paso 4 – Respaldos programados
- Paso 5 – Eliminación de respaldos
Prerrequisitos
Para completar este tutorial, necesitas lo siguiente:
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A DigitalOcean API token for Velero to use.
- A Git client, to clone the Starter Kit repository.
- Helm para gestionar las versiones y actualizaciones de Velero.
- Doctl para la interacción con la API de DigitalOcean.
- Kubectl para la interacción con Kubernetes.
- Cliente de Velero para gestionar los respaldos de Velero.
Paso 1 – Instalación de Velero usando Helm
En este paso, desplegarás Velero y todos los componentes necesarios para que pueda realizar copias de seguridad de los recursos de tu clúster de Kubernetes (incluidos los PV). Los datos de respaldo se almacenarán en el depósito de DO Spaces creado anteriormente en la sección Requisitos previos.
Primero, clona el repositorio Git del Kit de inicio y cambia al directorio de tu copia local:
A continuación, agrega el repositorio de Helm y lista los gráficos disponibles:
La salida se parece a lo siguiente:
NAME CHART VERSION APP VERSION DESCRIPTION
vmware-tanzu/velero 2.29.7 1.8.1 A Helm chart for velero
El gráfico de interés es vmware-tanzu/velero, que instalará Velero en el clúster. Visita la página velero-chart para obtener más detalles sobre este gráfico.
Luego, abre e inspecciona el archivo de valores de Helm de Velero proporcionado en el repositorio del Kit de inicio utilizando un editor de tu elección (preferiblemente con soporte para lint de YAML).
A continuación, reemplaza los marcadores <> según corresponda para tu depósito de Velero de DO Spaces (como nombre, región y secretos). Asegúrate de proporcionar también tu token de API de DigitalOcean (clave DIGITALOCEAN_TOKEN).
Por último, instala Velero usando helm:
A specific version of the Velero Helm chart is used. In this case 2.29.7 is picked, which maps to the 1.8.1 version of the application (see the output from Step 2.). It’s a good practice in general to lock on a specific version. This helps to have predictable results and allows versioning control via Git.
–create-namespace \
Ahora, verifica tu despliegue de Velero ejecutando:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
velero velero 1 2022-06-09 08:38:24.868664 +0300 EEST deployed velero-2.29.7 1.8.1
La salida se parece a lo siguiente (la columna STATUS debería mostrar deployed):
A continuación, verifica que Velero esté funcionando correctamente:
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 67s
La salida se ve similar a lo siguiente (los pods de implementación deben estar en el estado Ready):
Si estás interesado en profundizar, puedes ver los componentes del servidor de Velero:
- Explora las páginas de ayuda de la CLI de Velero para ver qué comandos y subcomandos están disponibles. Puedes obtener ayuda para cada uno usando la bandera
--help: - Lista todos los comandos disponibles para
Velero:
Lista las opciones del comando backup para Velero:
Velero utiliza varios CRDs (Definiciones de Recursos Personalizados) para representar sus recursos como copias de seguridad, programaciones de copias de seguridad, etc. Descubrirás cada uno en los próximos pasos del tutorial, junto con algunos ejemplos básicos.
Paso 2 – Ejemplo de Copia de Seguridad y Restauración de Espacio de Nombres
En este paso, aprenderás cómo realizar una copia de seguridad única para un espacio de nombres completo desde tu clúster DOKS y cómo restaurarlo posteriormente asegurándote de que todos los recursos se recrean. El espacio de nombres en cuestión es ambassador.
Creando la Copia de Seguridad del Espacio de Nombres Ambassador
Primero, inicia la copia de seguridad:
A continuación, verifica que se haya creado la copia de seguridad:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 29d default <none>
La salida se ve similar a:
Luego, después de unos momentos, puedes inspeccionarlo:
Name: ambassador-backup
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
...
- La salida se ve similar a:
- Busca la línea
Fase. Debería decirCompletado. - Verifica que tampoco se informen errores.
Se crea un nuevo objeto de copia de seguridad de Kubernetes:
~ kubectl get backup/ambassador-backup -n velero -o yaml
apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/source-cluster-k8s-gitversion: v1.21.2
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "21"
...
Por último, echa un vistazo al cubo de DO Spaces y verifica que haya una nueva carpeta llamada backups que contenga los activos creados para tu ambassador-backup:
Eliminar el Espacio de Nombres y los Recursos del Embajador
Primero, simule un desastre eliminando intencionalmente el espacio de nombres ambassador:
A continuación, verifique que el espacio de nombres haya sido eliminado (la lista de espacios de nombres no debería imprimir ambassador):
Finalmente, verifique que el punto de conexión de los servicios de backend echo y quote esté DOWN. Consulte Creación de los Servicios de Backend de la Pila de Borde del Embajador con respecto a las aplicaciones de backend utilizadas en el tutorial del Kit de Inicio. Puede usar curl para probarlo (o puede usar su navegador web):
Restaurando la Copia de Seguridad del Espacio de Nombres del Embajador
Restaure el ambassador-backup:
Importante: Cuando eliminas el espacio de nombres ambassador, el recurso del balanceador de carga asociado con el servicio de ambassador también se eliminará. Entonces, cuando restaures el servicio ambassador, el balanceador de carga será recreado por DigitalOcean. El problema aquí es que obtendrás una NUEVA dirección IP para tu balanceador de carga, por lo que necesitarás ajustar los registros A para dirigir el tráfico a tus dominios alojados en el clúster.
Verificación de la Restauración del Espacio de Nombres Ambassador
Para verificar la restauración del espacio de nombres ambassador, revisa la línea Fase en la salida del comando de restauración ambassador-backup. Debería decir Completado (también, ten en cuenta la sección de Advertencias – indica si algo salió mal):
A continuación, verifica que todos los recursos hayan sido restaurados para el espacio de nombres ambassador. Busca los pods de ambassador, los servicios y los despliegues.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-9qnz6 1/1 Running 0 18h
pod/ambassador-5bdc64f9f6-twgxb 1/1 Running 0 18h
pod/ambassador-agent-bcdd8ccc8-8pcwg 1/1 Running 0 18h
pod/ambassador-redis-64b7c668b9-jzxb5 1/1 Running 0 18h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.74.214 159.89.215.200 80:32091/TCP,443:31423/TCP 18h
service/ambassador-admin ClusterIP 10.245.204.189 <none> 8877/TCP,8005/TCP 18h
service/ambassador-redis ClusterIP 10.245.180.25 <none> 6379/TCP 18h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 18h
deployment.apps/ambassador-agent 1/1 1 1 18h
deployment.apps/ambassador-redis 1/1 1 1 18h
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 18h
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 18h
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 18h
La salida se parece a:
Obtener hosts de ambassador:
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
La salida se parece a:
ESTADO debería ser Listo y la columna NOMBRE DE HOST debería apuntar al nombre de host completamente calificado.
Obtener mapeos de ambassador:
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
La salida se parece a (nota el echo-backend que está mapeado al host echo.starter-kit.online y al prefijo de origen /echo/, lo mismo para quote-backend):
Finalmente, después de reconfigurar su equilibrador de carga y ajustes de dominio de DigitalOcean, por favor verifique que el endpoint de los servicios de backend echo y quote esté UP. Consulte Creación de los Servicios de Backend del Conjunto de Bordes de Ambassador.
En el siguiente paso, simulará un desastre eliminando intencionalmente su clúster de DOKS.
Paso 3 – Ejemplo de Respaldo y Restauración de Todo el Clúster
En este paso, simulará un escenario de recuperación ante desastres. Se eliminará todo el clúster de DOKS y luego se restaurará desde un respaldo anterior.
Creación del Respaldo del Clúster de DOKS
Primero, cree un respaldo para todo el clúster de DOKS:
A continuación, verifica que se haya creado la copia de seguridad y que no esté informando de ningún error. El siguiente comando lista todas las copias de seguridad disponibles:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
all-cluster-backup Completed 0 0 2021-08-25 19:43:03 +0300 EEST 29d default <none>
La salida se ve similar a:
Finalmente, inspecciona el estado de la copia de seguridad y los registros (verifica que no se informen errores):
Importante: Siempre que destruyas un clúster DOKS sin especificar la bandera --dangerous al comando doctl y luego lo restaures, se recreará el mismo equilibrador de carga con la misma IP. Esto significa que no necesitas actualizar los registros A de DNS de DigitalOcean.
Pero cuando se aplica la bandera --dangerous al comando doctl, el equilibrador de carga existente se destruirá y se creará un nuevo equilibrador de carga con una nueva IP externa cuando Velero restaure tu controlador de entrada. Por lo tanto, asegúrate de actualizar tus registros A de DNS de DigitalOcean en consecuencia.
Primero, elimina todo el clúster DOKS (asegúrate de reemplazar los marcadores <> en consecuencia).
Para eliminar el clúster de Kubernetes sin destruir el equilibrador de carga asociado, ejecuta:
O para eliminar el clúster de Kubernetes junto con el equilibrador de carga asociado:
A continuación, recrea el clúster, como se describe en Configurar Kubernetes de DigitalOcean. Es importante asegurarse de que el nuevo número de nodos del clúster de DOKS sea igual o mayor que el original.
Luego, instala la interfaz de línea de comandos (CLI) y el servidor de Velero, como se describe en la sección de Prerrequisitos y en el Paso 1 – Instalación de Velero usando Helm respectivamente. Es importante utilizar la misma versión del gráfico Helm.
Finalmente, restaura todo ejecutando el siguiente comando:
Comprobación del Estado de las Aplicaciones del Clúster de DOKS
Primero, verifica la línea Fase del resultado del comando restore describe all-cluster-backup. (Reemplaza los marcadores <> según corresponda). Debería decir Completado.
Ahora, verifica todos los recursos del clúster ejecutando:
Ahora, las aplicaciones del backend deberían responder a las solicitudes HTTP también. Consulta Creación de los Servicios del Backend de Ambassador Edge Stack con respecto a las aplicaciones del backend utilizadas en el tutorial del Kit de Inicio.
En el siguiente paso, aprenderás cómo realizar copias de seguridad programadas (o automáticas) para las aplicaciones de tu clúster DOKS.
Paso 4 – Copias de seguridad programadas
Realizar copias de seguridad automáticamente según un horario es una característica realmente útil. Te permite retroceder en el tiempo y restaurar el sistema a un estado de funcionamiento anterior si algo sale mal.
Crear una copia de seguridad programada es un proceso muy sencillo. Se proporciona a continuación un ejemplo para un intervalo de 1 minuto (se eligió el espacio de nombres kube-system).
Primero, crea el horario:
schedule="*/1 * * * *"
El formato cronjob de Linux también es compatible:
A continuación, verifica que se haya creado el horario:
NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR
kube-system-minute-backup Enabled 2021-08-26 12:37:44 +0300 EEST @every 1m 720h0m0s 32s ago <none>
La salida se parece a:
Luego, inspecciona todas las copias de seguridad después de un minuto aproximadamente:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
kube-system-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:20 +0300 EEST 29d default <none>
kube-system-minute-backup-20210826093744 Completed 0 0 2021-08-26 12:37:44 +0300 EEST 29d default <none>
La salida se parece a:
Verificar el estado de la copia de seguridad programada
Primero, verifica la línea Fase de una de las copias de seguridad (reemplaza los marcadores <> según corresponda). Debería decir Completado.
Por último, toma nota de posibles errores y advertencias del resultado anterior también para verificar si algo salió mal.
Restaurar la copia de seguridad programada
Para restaurar copias de seguridad de hace un minuto, por favor sigue los mismos pasos que aprendiste en los pasos anteriores de este tutorial. Esta es una buena manera de ejercitar y probar la experiencia acumulada hasta ahora.
En el siguiente paso, aprenderás cómo eliminar manual o automáticamente copias de seguridad específicas que hayas creado con el tiempo.
Paso 5 – Eliminar copias de seguridad
Si no necesitas copias de seguridad antiguas, puedes liberar recursos tanto en el clúster de Kubernetes como en el bucket de Velero DO Spaces.
Eliminar manualmente una copia de seguridad
Primero, elige una copia de seguridad de un minuto, por ejemplo, y emite el siguiente comando (por favor, reemplaza los marcadores <> según corresponda):
Ahora, verifica que haya desaparecido del resultado del comando velero backup get. También debería ser eliminado del bucket de DO Spaces.
A continuación, eliminarás múltiples backups a la vez usando un selector. El subcomando velero backup delete proporciona una bandera llamada --selector. Te permite eliminar múltiples backups a la vez basados en las etiquetas de Kubernetes. Se aplican las mismas reglas que para Selector de Etiquetas de Kubernetes.
Primero, lista los backups disponibles:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 23d default <none>
backend-minute-backup-20210826094116 Completed 0 0 2021-08-26 12:41:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826094016 Completed 0 0 2021-08-26 12:40:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093816 Completed 0 0 2021-08-26 12:38:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093716 Completed 0 0 2021-08-26 12:37:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093616 Completed 0 0 2021-08-26 12:36:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093509 Completed 0 0 2021-08-26 12:35:09 +0300 EEST 24d default <none>
La salida se parece a:
A continuación, digamos que deseas eliminar todos los activos backend-minute-backup-*. Elige un backup de la lista e inspecciona las Etiquetas:
Name: backend-minute-backup-20210826094116
Namespace: velero
Labels: velero.io/schedule-name=backend-minute-backup
velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: backend
Excluded: <none>
...
La salida se parece a (nota el valor de la etiqueta velero.io/schedule-name):
A continuación, puedes eliminar todos los backups que coincidan con el valor backend-minute-backup de la etiqueta velero.io/schedule-name:
Finalmente, verifica que todos los activos backend-minute-backup-* hayan desaparecido del resultado del comando velero backup get y también del bucket de DO Spaces.
Eliminación Automática de Backups a través de TTL
- Cuando creas una copia de seguridad, puedes especificar un TTL (Tiempo de Vida), utilizando la bandera
--ttl. Si Velero detecta que un recurso de copia de seguridad existente ha caducado, elimina: - El recurso
Backup - El archivo de copia de seguridad del objeto de almacenamiento en la nube
storage - Todas las instantáneas de
PersistentVolume
Todos los Restores asociados
La bandera TTL permite al usuario especificar el período de retención de la copia de seguridad con el valor especificado en horas, minutos y segundos en la forma --ttl 24h0m0s. Si no se especifica, se aplicará un valor TTL predeterminado de 30 días.
Primero, crea la copia de seguridad ambassador, utilizando un valor TTL de 3 minutos:
A continuación, inspecciona la copia de seguridad ambassador:
Name: ambassador-backup-3min-ttl
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
Resources:
Included: *
Excluded: <none>
Cluster-scoped: auto
Label selector: <none>
Storage Location: default
Velero-Native Snapshot PVs: auto
TTL: 3m0s
...
A new folder should be created in the DO Spaces Velero bucket as well, named ambassador-backup-3min-ttl.
La salida se ve similar a esto (nota la sección Namespaces -> Included – debería mostrar ambassador, y el campo TTL está configurado en 3ms0):
Finalmente, después de unos tres minutos, la copia de seguridad y los recursos asociados deberían eliminarse automáticamente. Puedes verificar que el objeto de copia de seguridad fue destruido usando: velero backup describe ambassador-backup-3min-ttl. Debería fallar con un error que indique que la copia de seguridad ya no existe. La carpeta correspondiente ambassador-backup-3min-ttl del bucket de Velero en DO Spaces también será eliminada.
Yendo más allá, puedes explorar todas las opciones disponibles de velero backup delete a través de:
En este tutorial, aprendiste cómo realizar copias de seguridad únicas y programadas, y cómo restaurarlo todo. Tener copias de seguridad programadas es muy importante ya que te permite revertir a un punto anterior en el tiempo si algo sale mal en el camino. También repasaste un escenario de recuperación ante desastres.
- Más información
- Copia de seguridad y restauración de datos de DOKS utilizando Velero
- Copias de seguridad de Kubernetes gestionadas por DigitalOcean con SnapShooter
Restaurar volúmenes desde instantáneas en clústeres de Kubernetes