¿Qué es la copia de seguridad de Kubernetes?

La copia de seguridad de Kubernetes protege las aplicaciones que se ejecutan en un clúster de Kubernetes capturando dos cosas a la vez: las definiciones de recursos que describen cada aplicación y los datos de sus volúmenes persistentes. El objetivo es poder recrear una aplicación, con sus datos, en el mismo clúster o en otro.

¿Qué contiene una copia de seguridad de Kubernetes?

Una aplicación en Kubernetes es un conjunto de objetos almacenados en la API del clúster, como deployments, servicios, config maps y secrets, más los datos que haya en volúmenes persistentes. Las imágenes de contenedor normalmente no se copian, porque se descargan de nuevo desde un registro.

ComponenteQué esCómo se captura
Definiciones de recursosObjetos que describen la aplicaciónExportadas desde la API de Kubernetes
Datos de volúmenes persistentesBases de datos, colas, archivos subidosInstantánea de almacenamiento exportada, o copia a nivel de archivo
Estado del clúster (etcd)Configuración de todo el clústerInstantánea de etcd aparte, para reconstruir el propio clúster
Imágenes de contenedorCódigo de la aplicaciónSe guardan en un registro, normalmente fuera de la copia

¿En qué se diferencia de la copia de seguridad de máquinas virtuales?

La copia de seguridad de máquinas virtuales captura la imagen de disco de una máquina de larga vida. Las cargas de trabajo de Kubernetes se reparten entre contenedores efímeros que se programan allí donde hay capacidad, así que no existe un único disco que represente la aplicación. Por eso las herramientas de copia trabajan a nivel de aplicación o de namespace, seleccionan qué proteger mediante etiquetas y llaman a hooks dentro de los contenedores para llevar las bases de datos a un estado coherente antes de una instantánea, el equivalente en Kubernetes de la copia de seguridad coherente con aplicaciones.

¿Por qué las copias de Kubernetes van a almacenamiento de objetos?

Casi todas las herramientas de copia de Kubernetes escriben en almacenamiento de objetos compatible con S3. Es accesible por HTTP desde cualquier clúster, escala sin volúmenes preasignados y está fuera del clúster, algo esencial, porque una copia guardada en el clúster que protege se pierde con él. El mismo almacén puede dar servicio a varios clústeres, lo que también lo convierte en el vehículo para mover aplicaciones entre ellos. Cuando el almacén admite S3 Object Lock, las copias pueden hacerse inmutables.

¿Qué influye en el dimensionamiento y la recuperación?

La capacidad depende de los datos de los volúmenes persistentes, de su tasa de cambio y del calendario de retención, no del número de contenedores. Las copias también generan muchos objetos pequeños, así que el almacén de objetos tiene que manejar grandes cantidades de objetos y listados frecuentes. En la recuperación, las preguntas son cuánto se tarda en restaurar la aplicación con estado más grande y si se ha probado una restauración completa en un clúster nuevo y vacío. El artículo Retención de copias de Kubernetes y dimensionamiento de S3 desarrolla los números.

Preguntas frecuentes

¿Basta la copia de etcd para proteger las aplicaciones de Kubernetes?

No. Una instantánea de etcd restaura la configuración del clúster. No incluye los datos de los volúmenes persistentes.

¿Merece la pena copiar las aplicaciones sin estado?

Sus definiciones sí, salvo que puedan volver a desplegarse por completo desde un repositorio de código. No guardan datos propios.

¿Se puede restaurar una copia de Kubernetes en otro clúster?

Sí. Es uno de sus usos principales, para migraciones, actualizaciones y recuperación ante desastres, siempre que las clases de almacenamiento y las versiones sean compatibles.