Copia de seguridad de Kubernetes: protección de cargas de trabajo nativas de la nube

El cliente que tenía una copia de seguridad de todos los nodos

La primera vez que vi a un cliente intentar recuperar un clúster de Kubernetes a partir de su copia de seguridad de máquinas virtuales, supe que las conversaciones del año siguiente girarían en torno a explicar por qué los contenedores no funcionan de la misma manera que las máquinas virtuales. Tuvimos que analizar qué contenía realmente la copia de seguridad, qué faltaba y qué implicaba eso para su RTO.

El cliente creía que estaba protegido. Disponía de copias de seguridad de todos los nodos del clúster. Sin embargo, no tenía forma alguna de recuperar la carga de trabajo. La copia de seguridad capturaba las máquinas virtuales subyacentes en las que se ejecutaba Kubernetes. No capturaba la configuración del espacio de nombres, los manifiestos YAML, los ConfigMaps y los Secrets, ni el estado de etcd que registraba lo que debía existir. Tenían la base. Les faltaba la aplicación. 

Esto es lo que le diría a ese equipo si pudiera rebobinar el tiempo y mantener la conversación antes del incidente.

En qué consiste realmente una copia de seguridad de Kubernetes

La copia de seguridad de Kubernetes consiste en la captura y recuperación de aplicaciones en contenedores, su estado persistente, y la configuración de Kubernetes que define cómo se ejecutan, de tal forma que permita restaurar la carga de trabajo completa en el mismo clúster, en un clúster diferente o en una nube diferente.

La distinción es importante porque la carga de trabajo en Kubernetes no se limita a los contenedores en ejecución. Incluye los volúmenes persistentes (PV) donde las aplicaciones con estado almacenan datos, el espacio de nombres donde reside la carga de trabajo, los manifiestos YAML que definen los Deployments y los StatefulSets, los ConfigMaps y los Secrets que contienen la configuración específica del entorno, las definiciones de recursos personalizados (CRD) que amplían la API y el estado de etcd que registra lo que el clúster considera que debería existir. Una copia de seguridad que solo capture los volúmenes persistentes puede restaurar los datos, pero no la aplicación en ejecución. Una copia de seguridad que solo capture los manifiestos YAML puede restaurar la estructura, pero no el estado. Ambas situaciones son habituales. Ambas son insuficientes.

La adopción de cargas de trabajo de producción en contenedores ya no es una hipótesis. Google pone en marcha miles de millones de contenedores a la semana en su propia infraestructura. Para la mayoría de los equipos de plataformas empresariales, la cuestión ya no es si las cargas de trabajo de Kubernetes necesitan una copia de seguridad, sino cómo diseñarla correctamente. 

Por qué los contenedores necesitan una copia de seguridad diferente a la de las máquinas virtuales

Las máquinas virtuales y los contenedores comparten suficientes características como para que algunos principios de copia de seguridad sean aplicables. Ambos son abstracciones virtualizadas. Ambos exponen API para operaciones de instantáneas. Los datos de copia de seguridad siguen siendo datos de copia de seguridad independientemente de su origen. Una plataforma de copia de seguridad puede almacenar razonablemente las copias de seguridad de ambos en el mismo almacén.

El modelo operativo difiere en tres aspectos que resultan importantes para el diseño de la protección de datos:

1. El almacenamiento de las máquinas virtuales persiste tras los apagados. El almacenamiento de los contenedores a menudo no lo hace. Cuando una máquina virtual se apaga, su almacenamiento asignado permanece. Cuando un pod de Kubernetes se apaga, el kubelet puede recuperar sus volúmenes «emptyDir» y cualquier almacenamiento no persistente.
2. Las máquinas virtuales son relativamente estables. Los pods son transitorios por diseño. Kubernetes está diseñado para iniciar, detener y reprogramar pods como parte de un patrón operativo normal. Las copias de seguridad que parten de la base de cargas de trabajo de larga duración con horarios predecibles no son adecuadas.
3. Las máquinas virtuales ejecutan una sola aplicación. Los pods ejecutan partes de aplicaciones. Un límite significativo de la aplicación en Kubernetes es el espacio de nombres o la versión de Helm, no el pod individual. Las copias de seguridad a nivel de pod fragmentan la aplicación. 

Los cinco retos que hacen que las copias de seguridad en Kubernetes sean arquitectónicamente diferentes

Los analistas del Data Center Intelligence Group (DCIG) han identificado cinco retos específicos que el software de copia de seguridad debe resolver para proteger los entornos de Kubernetes. Este marco resulta muy válido y aclara en qué se diferencia la protección nativa de Kubernetes de las herramientas de copia de seguridad adaptadas de la era de las máquinas virtuales.

1. Almacenamiento efímero

Cuando un pod se apaga, Kubernetes puede recuperar su almacenamiento. Los datos se pierden de forma efectiva. Esto tiene dos implicaciones para la copia de seguridad: en primer lugar, la plataforma debe saber que la aplicación en contenedor existe (detección automática, no registro manual); y, en segundo lugar, la copia de seguridad debe realizarse mientras la aplicación está en ejecución, lo que puede suponer horas, no días. Las programaciones de copia de seguridad basadas en ventanas nocturnas no se adaptan a cargas de trabajo que podrían no existir mañana por la mañana.

2. Imprevisibilidad

El kube-scheduler decide dónde se ejecutan los pods en función de la disponibilidad de recursos, las reglas de afinidad, los taints y las tolerancias. No se basa en las preferencias del operador. Un pod puede ejecutarse en cualquier nodo de cualquier clúster en cualquier momento. La plataforma de copias de seguridad debe seguir la carga de trabajo en lugar de dar por sentada una ubicación fija, y debe tomar decisiones de protección para cada carga de trabajo. No todos los contenedores necesitan una copia de seguridad. Algunos solo requieren protección en momentos concretos de su ciclo de vida, como antes del apagado.

3. Escalabilidad

Una implementación de Kubernetes en producción puede ejecutar miles de pods en cientos de espacios de nombres. Los entornos con múltiples clústeres elevan esa cifra a millones. Los contenedores se inician y se detienen a un ritmo mucho mayor que las máquinas virtuales. Una plataforma de copias de seguridad que escala linealmente con el esfuerzo del operador —registro manual, asignación manual de políticas y verificación manual— se convierte en el cuello de botella. La copia de seguridad de Kubernetes requiere una infraestructura de copia de seguridad nativa de la nube y de escalado dinámico que crezca y se reduzca en función de la carga de trabajo.

4. Alcance: aplicaciones más plano de control

Las aplicaciones en contenedores son importantes, pero resultan inútiles sin el estado del plano de control que las orquesta. etcd alberga la fuente de verdad del clúster: qué Deployments existen, qué ConfigMaps y Secrets están vinculados a qué cargas de trabajo, qué CRD amplían la API y qué reglas RBAC rigen el acceso. Las entornos de Kubernetes maduros automatizan el plano de control mediante GitOps y pueden reconstruirlo bajo demanda. Las implementaciones menos maduras dependen de la plataforma de copias de seguridad para capturar ambas capas.

5. Complejidad de la recuperación

La recuperación pone de manifiesto todos los retos anteriores a la vez. La plataforma debe identificar qué copia de seguridad se debe restaurar (fecha, clúster, espacio de nombres, contexto de la aplicación), gestionar las interdependencias entre aplicaciones en contenedores que quizá deban iniciarse conjuntamente y, cada vez con mayor frecuencia, restaurar en una implementación de Kubernetes diferente a aquella de la que se realizó la copia de seguridad. Un clúster diferente, una nube diferente, una versión de K8s diferente y, potencialmente, una distribución diferente (EKS frente a AKS frente a GKE frente a la instalación local). La plataforma de copias de seguridad debe conocer lo suficiente tanto sobre el origen como sobre el destino para realizar la conversión entre ambos. 

Qué debe proteger una copia de seguridad completa de Kubernetes

Una copia de seguridad completa de Kubernetes abarca cuatro categorías distintas. Las herramientas de copia de seguridad varían considerablemente en cuanto al número de categorías que gestionan realmente.

El papel de las etiquetas y los metadatos de los contenedores

Kubernetes proporciona el mecanismo de protección que la plataforma necesita: etiquetas y metadatos asociados a cada carga de trabajo. Cuando se inicia un contenedor, el servicio del nodo de Kubernetes lee sus metadatos existentes, añade pares clave-valor que identifican qué recursos pertenecen al mismo conjunto y expone dichas etiquetas a cualquier entidad que supervise la API.

Una plataforma de copias de seguridad bien diseñada supervisa los inicios de los contenedores y lee los metadatos en tiempo real. Las etiquetas indican a la plataforma qué debe copiar (la carga de trabajo cumple los criterios de la política), cuándo (según la política vinculada a dichas etiquetas) y cómo (qué recursos relacionados deben capturarse de forma coordinada). A continuación, la plataforma puede programar tareas de copia de seguridad mediante la integración con kube-scheduler, lo que permite que sea el propio Kubernetes quien decida dónde se ejecuta la tarea de copia de seguridad, del mismo modo que decide dónde se ejecutan los pods.

Este patrón difiere del modelo impulsado por operadores que utilizan las soluciones de copia de seguridad tradicionales. En el modelo tradicional, es una persona o un archivo de configuración quien declara qué se debe copiar. En el modelo nativo de Kubernetes, la propia carga de trabajo se declara a través de sus etiquetas y la plataforma de copias de seguridad responde. Las nuevas cargas de trabajo obtienen protección automáticamente. Las cargas de trabajo retiradas dejan de generar carga de copia de seguridad. La tarea del operador pasa a ser establecer políticas, no gestionar el inventario.

Recuperación entre clústeres y Kubernetes multicloud

La recuperación en un único clúster (restaurar la carga de trabajo en el mismo clúster del que procedía) es el caso más sencillo. La mayoría de las implementaciones empresariales de Kubernetes no permanecen en el caso sencillo durante mucho tiempo. A continuación, tres escenarios reales que las plataformas de copia de seguridad deben gestionar actualmente.

Migración de cargas de trabajo entre EKS, AKS, GKE y distribuciones locales. Las decisiones sobre el ciclo de vida de los clústeres (optimización de costes, cambios de región, preferencias de distribución) suelen requerir el traslado de cargas de trabajo. Un sistema de copias de seguridad que admita la restauración entre distribuciones convierte estas migraciones de proyectos de varias semanas en operaciones rutinarias.

Recuperación ante desastres en una región diferente. Cuando la región principal falla, la carga de trabajo de recuperación se inicia en un clúster de otra región, idealmente con los mismos datos de copia de seguridad, las mismas políticas y el mismo plano de gestión que el equipo de operaciones utiliza a diario.

Clonación de entornos de prueba y desarrollo. La restauración de cargas de trabajo de producción (con datos sintéticos o datos anonimizados) en clústeres de pruebas es un requisito habitual para realizar pruebas precisas previas a la producción. El mismo mecanismo de restauración entre proyectos y regiones que da soporte a la recuperación ante desastres también da soporte a la clonación de entornos.

Errores comunes en las copias de seguridad de Kubernetes

El mercado de la protección de datos de Kubernetes está repleto de productos que parecen adecuados en una matriz de características, pero que fallan al enfrentarse a la complejidad de la producción. Tres patrones a tener en cuenta.

Error 1: Copia de seguridad basada únicamente en almacenamiento persistente

Muchas herramientas de «copia de seguridad de Kubernetes» capturan instantáneas de PV y se consideran completas. Las instantáneas de PV son necesarias, pero no suficientes. Sin la configuración de los espacios de nombres, los manifiestos YAML, los ConfigMaps, los Secrets y los recursos personalizados definidos por los operadores, los volúmenes persistentes recuperados son datos sin contexto. La copia de seguridad basada únicamente en el almacenamiento es una función básica útil. No constituye una estrategia de copia de seguridad de Kubernetes.

Error 2: Complementos añadidos a productos de copia de seguridad heredados

Cuando los proveedores de copia de seguridad existentes añadieron la «compatibilidad con Kubernetes» entre 2019 y 2021, muchos lanzaron complementos que adaptaban su arquitectura de la era de las máquinas virtuales para llamar a las API de Kubernetes. El resultado suele consistir en tratar los contenedores como una carga de trabajo independiente que requiere una infraestructura separada, lo que crea precisamente esa protección de datos en silos que se suponía que la transición a Kubernetes debía eliminar. Tal y como ha señalado Krista Macomber, de Evaluator Group, en su guía introductoria sobre los fundamentos de la protección de datos de contenedores, tratar Kubernetes como un complemento adicional rara vez da lugar al modelo operativo que esperan los equipos de la plataforma. 

Error n.º 3: Omitir el plano de control

Las empresas que utilizan GitOps y reconstruyen su plano de control a partir del control de código fuente bajo demanda pueden omitir la copia de seguridad del plano de control de forma segura. La mayoría de las implementaciones de Kubernetes no son puramente GitOps. El clúster ha acumulado configuraciones aplicadas manualmente, operadores instalados a través de kubectl, CRD que no están en el control de código fuente y secretos que nunca se han sometido a control de versiones (como es correcto). Si se pierde etcd, el historial del clúster sobre lo que se ha desplegado desaparece. O bien la copia de seguridad del plano de control forma parte de la estrategia de protección, o bien lo hace la disciplina operativa en torno a GitOps. No puede ser ninguna de las dos cosas.

Preguntas frecuentes sobre la copia de seguridad de Kubernetes

¿Necesitan copia de seguridad las cargas de trabajo sin estado? 

Las cargas de trabajo sin estado no contienen datos de aplicación que deban respaldarse, pero sí cuentan con una configuración (Deployments, ConfigMaps, definiciones de Service, reglas de Ingress) que merece la pena capturar. Si se destruye el espacio de nombres, la restauración de las cargas de trabajo sin estado a partir de imágenes de contenedor es rápida, pero solo si dispone de los manifiestos de configuración a mano. La mayoría de los equipos se dan cuenta de ello la segunda vez que tienen que recrear un Service de memoria tras un incidente en el clúster.

¿Qué hay de las instantáneas CSI?

Las instantáneas CSI son un recurso básico útil que la plataforma de copias de seguridad debería utilizar en segundo plano. Capturan copias puntuales de volúmenes persistentes en la capa de almacenamiento. Sin embargo, las instantáneas CSI por sí solas no constituyen una estrategia de copia de seguridad. Están vinculadas al backend de almacenamiento, no capturan la configuración del espacio de nombres, no se pueden trasladar entre clústeres sin herramientas adicionales y, por lo general, comparten el destino del clúster en el que residen (si se pierde el clúster, se pierden las instantáneas). Una plataforma de copia de seguridad que coordine las instantáneas CSI y capture el resto de la carga de trabajo es el modelo adecuado. 

¿Puedo restaurar una copia de seguridad de una distribución de Kubernetes a otra?

Depende de la plataforma de copia de seguridad. Las distribuciones varían en cuanto a sus extensiones de API, controladores de entrada predeterminados, clases de almacenamiento y ajustes de seguridad predeterminados. Una plataforma que capture la carga de trabajo a nivel de objetos de Kubernetes (Deployments, Services, PVC) y traduzca las configuraciones específicas del destino durante la restauración puede trasladar cargas de trabajo entre clústeres de EKS, AKS, GKE y locales con un esfuerzo razonable. Una plataforma que capture instantáneas de almacenamiento a nivel del proveedor de la nube no puede hacerlo. Las instantáneas están vinculadas al proveedor.

Por dónde empezar

Si ya protege Kubernetes, realice un ejercicio de simulación este trimestre. Elija su aplicación en contenedores más crítica. Simule cómo la recuperaría en un clúster diferente, en una región diferente, en el caso de que el clúster de origen ya no estuviera disponible. Si alguien del equipo utiliza la palabra «manualmente» durante la simulación, habrá identificado su punto débil.