Las implementaciones de Kubernetes ofrecen muchas ventajas a las empresas que desean actualizar su infraestructura y pasar a una arquitectura nativa de la nube.
Pero mucho de lo que hace que Kubernetes sea atractivo para los desarrolladores y CIO también crea problemas potenciales cuando se trata de respaldo y recuperación ante desastres (DR).
Las aplicaciones monolíticas convencionales e incluso las máquinas virtuales (VM) son relativamente fáciles de respaldar e incorporar a un plan de recuperación ante desastres, siempre que se haga con cuidado. Pero Kubernetes y los contenedores (con sus microservicios interconectados, aplicaciones sin estado y almacenamiento persistente) funcionan de manera diferente. La recuperación ante desastres debe permitir esto.
¿Por qué necesitamos DR para Kubernetes?
En la producción se utilizan cada vez más contenedores y Kubernetes. Como resultado, es más probable que Kubernetes maneje datos vitales y procesos comerciales clave.
Las organizaciones deben proteger los datos y los diversos microservicios que componen una aplicación basada en Kubernetes y asegurarse de que puedan recuperarlos de manera precisa y oportuna.
Y los equipos de TI deben garantizar que todas las partes críticas de una implementación basada en Kubernetes estén cubiertas por el plan de recuperación ante desastres. No se trata solo de proteger el almacenamiento persistente con copias de seguridad estándar e inmutables, las organizaciones deben proteger todo el clúster y sus componentes y datos para poder restaurarlo sin problemas. Todo esto también necesita ser probado.
¿Cuáles son los desafíos de la recuperación ante desastres para Kubernetes?
DR para clústeres de Kubernetes significa identificación y protección de los componentes del clúster y su configuración.
Luego están los volúmenes de datos. Cada vez más, los datos de Kubernetes se encuentran en almacenamiento persistente, lo que facilita un poco la tarea del equipo de recuperación ante desastres. Pero los especialistas en recuperación ante desastres deben saber dónde almacenan los datos las aplicaciones basadas en Kubernetes, ya que pueden ejecutarse en almacenamiento local, en la nube e híbrido.
La buena noticia, según Tony Iams, analista de Gartner, es que las aplicaciones de contenedor tienen características que se prestan a la recuperación ante desastres y a la continuidad del negocio, incluso si el respaldo granular es más complicado.
“La portabilidad e inmutabilidad inherentes de los contenedores facilitan la replicación consistente de una pila de aplicaciones completa en múltiples ubicaciones”, afirma. “Uso de integración continua/implementación continua [CI/CD] procesos, las aplicaciones en contenedores se pueden reconstruir y entregar fácilmente donde y cuando se necesiten, ya sea en un sitio secundario o para reconstruir un sitio primario después de que ocurre una falla”.
¿Cuáles son los riesgos para los entornos de Kubernetes que la recuperación ante desastres debe mitigar?
Los riesgos para Kubernetes son los mismos que los que enfrenta cualquier otro entorno operativo de tecnología empresarial: fallas de hardware, problemas de software (incluso en el sistema operativo Linux subyacente), fallas de energía o de red, desastres físicos y, por supuesto, ataques cibernéticos, incluido el ransomware.
Sin embargo, la flexibilidad y la naturaleza distribuida de los contenedores pueden hacer que las aplicaciones sean vulnerables a puntos únicos de falla; Las arquitecturas distribuidas pueden magnificar el impacto de las interrupciones del hardware.
Una empresa podría, por ejemplo, replicar una máquina virtual completa o crear una instantánea inmutable y estar razonablemente segura de haber capturado todo lo necesario para ejecutar una aplicación o proceso empresarial. Con Kubernetes, existen más dependencias.
Iams identifica la forma en que las aplicaciones en contenedores manejan el almacenamiento como un riesgo específico. A diferencia de las aplicaciones convencionales, que utilizan el sistema de archivos del sistema operativo anfitrión, “los contenedores conservan los datos utilizando volúmenes que escriben datos en un almacenamiento fuera del propio sistema de archivos local del contenedor”, afirma.
Si los contenedores están en clústeres de Kubernetes, los equipos de TI deben asegurarse de que se realice una copia de seguridad de los manifiestos y otras configuraciones de políticas, y de que los contenedores puedan volver a conectarse a su almacenamiento después de una restauración.
¿Qué puntos clave contendría un plan de recuperación ante desastres para un entorno de Kubernetes?
La recuperación ante desastres exitosa para un entorno de Kubernetes normalmente será más granular que un plan de recuperación para aplicaciones convencionales.
Las empresas pueden reducir el tiempo de inactividad y la pérdida de datos, siempre que puedan recuperar partes específicas del sistema Kubernetes en lugar de clústeres completos. Cada parte de un entorno de Kubernetes podría tener su propio punto de recuperación y objetivos de tiempo de recuperación (RPO/RTO).
Sin embargo, esto requiere que los equipos de TI tengan una imagen completa y actualizada de sus componentes de Kubernetes y los procesos comerciales que respaldan.
En cuanto a un plan de recuperación ante desastres para entornos convencionales, un enfoque es priorizar los servicios que deben restaurarse primero.
Aquí es útil hacer dos preguntas vinculadas:
- ¿Qué aplicaciones basadas en Kubernetes son más críticas para las operaciones comerciales y, por lo tanto, deben volver a estar en línea primero?
- ¿Qué servicios y dependencias (de Kubernetes) recuperarán esos contenedores más rápidamente?
Bien hecho, esto podría permitir a una organización poner sus aplicaciones en línea, quizás con una funcionalidad reducida, más rápidamente que si dependieran de restaurar un clúster completo.
El enfoque exacto probablemente dependerá de la madurez de la organización y de su enfoque ante el riesgo.
“En esta etapa, los ingenieros de infraestructura tradicionales y nativos de la nube tienen diferentes puntos de vista sobre cómo abordar mejor el problema”, dice Iams.
“Los ingenieros nativos de la nube priorizan los métodos de redistribución a través de flujos de trabajo de CI/CD, mientras que los enfoques tradicionales dependen de herramientas de respaldo y recuperación para las aplicaciones de Kubernetes y la protección de datos”. La firma de analistas recomienda un enfoque centrado en las aplicaciones si la organización es lo suficientemente madura.
¿Cuáles son los requisitos de infraestructura de DR para Kubernetes?
Cuando se trata de infraestructura física, la flexibilidad de Kubernetes debería facilitar la recuperación de una aplicación. Esto podría ser desde el hardware local hasta la nube, o incluso pasando de un proveedor a otro de la nube.
Los especialistas en recuperación ante desastres deben garantizar que los recursos necesarios estén disponibles. Esto incluye los requisitos informáticos para ejecutar los clústeres de Kubernetes y el espacio de almacenamiento para recuperar volúmenes persistentes. Los recursos de red adecuados también son esenciales.
Para la recuperación de aplicaciones, si los equipos de TI han utilizado un enfoque GitOps centrado en aplicaciones, pueden usar ArgoCD o Flux CD para la recuperación.
De lo contrario, el mejor enfoque probablemente sea una herramienta de un proveedor que se especialice en Kubernetes, como Kasten, Trilio, CloudCasa o Cohesity (que ahora también posee el negocio de protección de datos de Veritas). Proveedores como Commvault y Rubrik también admiten contenedores y aplicaciones nativas de la nube.
Estas son herramientas “compatibles con Kubernetes” que se implementan en clústeres y comprenden cómo los clústeres componen una aplicación y cómo restaurarlas si hay una interrupción.