Cómo mantener la calma cuando tu clúster de Kubernetes se cae, o por qué necesitas Velero

Imagina esto: es viernes por la noche, estás planeando relajarte, cuando de repente aparece una notificación de Slack — uno de tus clústeres de producción de Kubernetes ha muerto. Una mala configuración, una caída del proveedor de la nube, o simplemente un error humano — la causa ya no importa. Lo que importa es la velocidad con la que puedes recuperar todo. Si solo tienes archivos YAML en Git, buena suerte recuperando aplicaciones con estado y sus datos.

Aquí es donde entra Velero. Es un proyecto de VMware (originalmente creado por Heptio) que se ha convertido en el estándar de facto para backup en el mundo K8s.

Qué es y por qué GitOps por sí solo no es suficiente

Muchos desarrolladores creen que si toda su infraestructura está definida en código (IaC) y se despliega a través de ArgoCD o Flux, los backups son innecesarios. Esta es una misconception peligrosa. Git almacena manifiestos, pero no sabe nada sobre el estado de tus Volúmenes Persistentes (PV), los certificados emitidos dinámicamente, o los secrets que nunca llegaron al repositorio.

Velero hace dos cosas: guarda objetos de la API de Kubernetes (deployments, configmaps, secrets) y toma snapshots de disco con datos. Funciona en nubes públicas (AWS, GCP, Azure) así como en centros de datos on-premises en metal desnudo.

Tres escenarios donde Velero salva el día

A menudo veo que Velero se usa no solo para protección ante desastres. Aquí están los principales casos de uso:

1. Recuperación ante desastres clásica. Este es directo: el clúster está muerto, levantas uno nuevo, y restauras todo desde el almacenamiento S3 con un solo comando.
2. Migración entre nubes. Moverse de AWS a Google Cloud o de una región a otra se convierte en una tarea trivial. Velero empaqueta los recursos y los despliega en la nueva ubicación.
3. Clonación de entornos. ¿Necesitas crear rápidamente una copia exacta de producción para pruebas? Haces un backup de prod, lo restauras en el namespace staging. Los datos de la base de datos estarán actualizados, no de un dump de hace un mes.

Cómo funciona internamente

La arquitectura del proyecto es bastante transparente. Hay un componente de servidor que se ejecuta dentro del clúster como un operator, y un cliente CLI para gestionar el proceso.

Cuando disparas un backup, esto es lo que sucede:

1. El cliente envía una solicitud a la API de Velero.
2. El controlador de Backup encuentra todos los objetos que especificaste (puedes filtrar por labels o namespaces).
3. Velero hace solicitudes a la API de Kubernetes para recopilar descripciones JSON de los recursos.
4. En paralelo, se invocan plugins para gestión de discos (p. ej., EBS en AWS o drivers CSI) para crear snapshots de datos.
5. Todo esto se archiva y se envía a almacenamiento de objetos (compatible con S3).

Por cierto, Velero soporta Restic y Kopia. Esto significa que puedes hacer backups incrementales del sistema de archivos incluso donde los snapshots en la nube no están disponibles.

Ejemplo práctico

Digamos que necesitamos hacer backup de una aplicación completa en el namespace app-production. El comando en la terminal se vería algo así:

velero backup create production-backup --include-namespaces app-production

Y si alguien elimina accidentalmente ese namespace una semana después, la recuperación toma solo unos minutos:

velero restore create --from-backup production-backup

Curiosamente, Velero puede modificar parámetros de recursos sobre la marcha durante la restauración. Por ejemplo, puedes cambiar el StorageClass de los discos si la clase anterior no está disponible en el nuevo clúster.

Matices de compatibilidad

Los desarrolladores de Velero mantienen una matriz de compatibilidad bastante estricta. Actualmente, la versión 1.18 está probada contra las últimas versiones de Kubernetes (hasta la 1.35). Esto es importante porque la API de Kubernetes cambia rápidamente, y las herramientas más antiguas a menudo se rompen cuando se actualiza el clúster.

El proyecto está bajo el paraguas de la Cloud Native Computing Foundation (CNCF), lo que proporciona ciertas garantías: no desaparecerá mañana, y su seguridad está siendo monitoreada.

¿Vale la pena implementarlo?

Si estás ejecutando Kubernetes en producción y tienes algún dato en discos (bases de datos, colas, almacenes de configuración), Velero es imprescindible.

Quién definitivamente se beneficiará de él:

• Ingenieros SRE que necesitan dormir tranquilos por las noches.
• Equipos que migran frecuentemente entre clústeres.
• Desarrolladores que necesitan datos frescos de producción para depurar errores complejos.

Comienza con la documentación oficial en velero.io. Es bastante detallada, aunque puede parecer abrumadora a veces. Lo principal que debes recordar es que un backup solo existe cuando has restaurado exitosamente desde él al menos una vez. Intenta hacer esto en un clúster de prueba antes de confiar la herramienta con datos reales.