[25/02/2020] Sí, su infraestructura de contenedores necesita algún tipo de respaldo. Kubernetes y Docker no se reconstruirán mágicamente después de un desastre. No es necesario hacer una copia de seguridad del estado de ejecución de cada contenedor, pero deberá hacer backup de la configuración utilizada para ejecutar y administrar sus contenedores.
Aquí le dejamos un recordatorio rápido de las cosas a las que necesitará hacerles una copia de seguridad.
Configuración e información de estado deseado
- Los Dockerfiles utilizados para construir sus imágenes y todas las versiones de esos archivos
- Las imágenes creadas a partir del Dockerfile y utilizadas para ejecutar cada contenedor
- Kubernetes, etcd y otros: Bases de datos de K8 que informan sobre el estado del clúster
- Implementaciones: Archivos YAML que describen cada implementación
Datos persistentes creados o modificados por contenedores
- Volúmenes persistentes
- Bases de datos
Dockerfiles
Los contenedores Docker se ejecutan a partir de imágenes, y las imágenes se crean a partir de Dockerfiles. Una configuración adecuada de Docker usaría primero algún tipo de repositorio como GitHub como sistema de control de versiones para todos los Dockerfiles. No cree contenedores ad hoc utilizando imágenes ad hoc creadas a partir de Dockerfiles ad hoc. Todos los Dockerfiles deben almacenarse en un repositorio que le permita extraer versiones históricas de ese Dockerfile en caso haya un problema con la compilación actual.
También debe tener algún tipo de repositorio donde almacene los archivos YAML asociados con cada implementación de K8. Estos son archivos de texto que pueden beneficiarse de un sistema de control de versiones.
Estos repositorios deben ser respaldados. Uno de los repositorios más populares es GitHub, que ofrece varias formas de hacer una copia de seguridad del repositorio. Existe una variedad de scripts que utilizan las APIs proporcionadas para descargar una copia de seguridad actual de su repositorio. También hay herramientas comerciales de terceros que se pueden utilizar para hacer una copia de seguridad de GitHub o del repositorio que esté utilizando.
Si no ha seguido los consejos anteriores y ha ejecutado contenedores basados en imágenes para las que ya no tiene los Dockerfiles, puede usar el comando de historial de imágenes de Docker o una herramienta como dfimage para crear un Dockerfile a partir de sus imágenes actuales. ¡Coloque esos Dockerfiles en un repositorio y comience a hacer una copia de seguridad! Pero, sinceramente, no se meta en esta situación. Siempre almacene y haga una copia de seguridad de los archivos Dockerfiles y YAML utilizados para crear su entorno.
Imágenes de Docker
Las imágenes actuales utilizadas para ejecutar sus contenedores también deben almacenarse en un repositorio. (Por supuesto, si está ejecutando imágenes de Docker en Kubernetes, ya lo está haciendo). Puede usar un repositorio privado como un registro de Docker o un repositorio público como Dockerhub. Los proveedores de la nube también pueden proporcionarle un repositorio privado para almacenar sus imágenes. El contenido de ese repositorio debe ser respaldado. Una simple búsqueda en Google de "Dockerhub backup” puede ofrecer una sorprendente cantidad de opciones.
Si no cuenta con la imagen actual utilizada para ejecutar sus contenedores, puede crear una usando el comando docker commit. Luego puede crear un Dockerfile a partir de esa imagen utilizando el historial de imágenes de Docker o la herramienta dfimage.
Kubernetes etcd
La base de datos Kubernetes etcd es muy importante y debe ser respaldada con el comando etcdctl snapshot save db. Esto creará el archivo snapshot.db en el directorio actual. Luego, ese archivo debería ser respaldado en un almacenamiento externo.
Si está utilizando un software comercial de backup, puede activar fácilmente el comando etcdctl snapshot save snapshot save antes de realizar una copia de seguridad del directorio donde se creará la snapshot.db. Esa es una manera de integrar esta copia de seguridad en su entorno de backup comercial. Échele un vistazo a esta documentación de recuperación.
Volúmenes persistentes
Existe una variedad de formas en que los contenedores pueden tener acceso al almacenamiento persistente que se puede usar para almacenar o crear datos. Los volúmenes de Docker tradicionales residen en un subdirectorio de la configuración de Docker. Los montajes de enlace son simplemente cualquier directorio en un host Docker que está montado dentro de un contenedor (usando el comando de montaje de enlace). Por una variedad de razones, la comunidad Docker prefiere los volúmenes tradicionales, pero en cuanto al respaldo, los volúmenes tradicionales y los montajes de enlace son esencialmente los mismos. También puede montar un directorio de sistema de archivos de red (NFS) o un objeto de un sistema de almacenamiento de objetos como un volumen dentro de un contenedor.
El método que elija para respaldar sus volúmenes persistentes se basará en cuál de las opciones anteriores use para el contenedor. Sin embargo, todos ellos tendrán el mismo problema: si los datos están cambiando, tendrá que lidiar con eso para obtener una copia de seguridad consistente.
Una forma es cerrar cualquier contenedor que use ese volumen en particular. Esto es un poco anticuado, pero es uno de los desafíos creados por el mundo de contenedores, ya que el método típico de poner un agente de respaldo dentro del contenedor no es realmente una opción. Una vez apagado, el volumen puede ser respaldado. Si se trata de un volumen Docker tradicional, puede realizar una copia de seguridad montándolo en otro contenedor que no cambiará sus datos mientras se realiza el respaldo, y luego creando una imagen tar del volumen en un volumen montado en enlace, que luego debe respaldar usando lo que usa su sistema de backup.
Sin embargo, esto es realmente difícil de hacer en Kubernetes. Esta es una razón por la cual la información stateful se almacena mejor en una base de datos, no en un sistema de archivos. Tenga en cuenta este problema cuando diseñe su infraestructura K8.
Además, si está utilizando un directorio montado en enlace, un sistema de archivos montado en NFS o un sistema de almacenamiento de objetos como su sistema de almacenamiento persistente, puede usar cualquiera que considere la mejor manera de hacer una copia de seguridad de ese sistema de almacenamiento. Esto podría ser una captura de pantalla seguida de una duplicación, o simplemente ejecutar su software de backup comercial en el sistema. Es probable que estos métodos proporcionen una copia de seguridad mucho más consistente que un respaldo típico a nivel de archivo de ese mismo volumen.
Bases de datos
El siguiente desafío de respaldo es cuando un contenedor está utilizando una base de datos para almacenar sus datos. Estas bases de datos deben ser respaldadas de una manera que garantice su integridad. Dependiendo de la base de datos, el método mencionado anteriormente podría funcionar: cierre el contenedor que accede a la base de datos, luego haga una copia de seguridad del directorio donde están almacenados sus archivos. Sin embargo, el tiempo de inactividad requerido por este método puede no ser apropiado.
Otro método es conectarse directamente al motor de la base de datos y pedirle que ejecute una copia de seguridad en un archivo que luego puede respaldar. Si la base de datos se ejecuta dentro de un contenedor, primero deberá usar un montaje de enlace para adjuntar un volumen que pueda respaldar, de modo que su respaldo pueda existir fuera del contenedor. Luego ejecute el comando que usa la base de datos (como mysqldump) para crear una copia de seguridad. Después de eso, asegúrese de hacer una copia de seguridad del archivo que crea utilizando su sistema de copia de seguridad.
¿Qué sucede si no sabe qué contenedores utilizan qué almacenamiento o qué bases de datos? Una solución podría ser usar el comando docker ps para enumerar los contenedores en ejecución, luego utilizar el comando docker inspect para mostrar la configuración de cada contenedor. Hay una sección llamada Mounts que le dirá qué volúmenes están montados y dónde. Cualquier montaje de enlace también se especificará en los archivos YAML que envió a Kubernetes.
Soluciones comerciales de backup
Hay una variedad de soluciones de backup comerciales que pueden proteger algunos o todos los datos mencionados anteriormente. El siguiente es un resumen:
- El agente del servidor virtual de Commvault puede actuar como un proxy para respaldar los contenedores y sus imágenes.
- Cohesity ofrece protección de datos para namespaces de K8
- Heptio (ahora una compañía de VMware) ofrece Velero, copia de seguridad diseñada para K8
- Contino, Datacore y Portworx ofrecen almacenamiento diseñado para K8 y contenedores, y también admiten copias de seguridad de esa información
Dada la variedad de formas en que se pueden configurar K8s y Docker, es muy difícil cubrir todo en un solo artículo. Pero con suerte, esto le ha brindado información que lo haga reflexionar, o tal vez lo haya ayudado a darse cuenta de algo que no ha sido respaldado.
W. Curtis Preston, Network World
W. Curtis Preston es un experto en respaldo, almacenamiento y recuperación; habiendo trabajo en tal campo desde 1993. Ha sido un usuario final, consultor y analista, y recientemente se unió al equipo de Druva, una empresa de protección de datos basada en la nube.