Las implementaciones de Kubernetes ofrecen muchas ventajas a las empresas que desean actualizar su infraestructura y migrar a una arquitectura nativa de la nube. Pero mucho de lo que hace que Kubernetes sea atractivo para los desarrolladores y los CIO también crea problemas potenciales cuando se trata de copias de seguridad 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 integrar en 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 una manera diferente. La recuperación ante desastres debe permitir esto. ¿Por qué necesitamos DR para Kubernetes? Cada vez más, los contenedores y Kubernetes se utilizan en producción. Como resultado, es más probable que Kubernetes gestione 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 pueden recuperarlos de manera precisa y oportuna. Los equipos de TI deben asegurarse de 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 que puedan restaurarlo sin problemas. Todo esto también necesita pruebas. ¿Cuáles son los desafíos de la recuperación ante desastres para Kubernetes? La recuperación ante desastres para clústeres de Kubernetes significa la 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 hace que la tarea del equipo de recuperación ante desastres sea algo más fácil. 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 el analista de Gartner Tony Iams, es que las aplicaciones de contenedores tienen características que se prestan a la recuperación ante desastres y la continuidad comercial, incluso si la copia de seguridad granular es más complicada. «La portabilidad e inmutabilidad inherentes de los contenedores facilitan la replicación de una pila de aplicaciones completa de manera consistente en múltiples ubicaciones», dice. “Uso de la integración continua/implementación continua [CI/CD] ¿Cuáles son los riesgos para los entornos de Kubernetes que deben mitigarse mediante DR? 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 (incluido el sistema operativo Linux subyacente), fallas de energía o 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 que ha capturado todo lo necesario para ejecutar una aplicación o un proceso comercial. Con Kubernetes, hay 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 el 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 realicen copias 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 debería contener 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 de 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 plantear dos preguntas relacionadas: ¿Qué aplicaciones basadas en Kubernetes son las 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) harán que esos contenedores vuelvan a estar en línea más rápidamente? Si se hace bien, esto podría permitir que una organización ponga sus aplicaciones en línea, tal vez 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 su enfoque del riesgo. «En esta etapa, los ingenieros de infraestructura nativos de la nube y tradicionales 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 reimplementación a través de flujos de trabajo de CI/CD, mientras que los enfoques tradicionales se basan en herramientas de respaldo y recuperación para aplicaciones de Kubernetes y protección de datos». La firma de analistas recomienda un enfoque centrado en la aplicación 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 hardware local a la nube, o incluso moviéndose entre proveedores de la nube. Los especialistas en recuperación ante desastres deben asegurarse de que los recursos necesarios estén disponibles. Esto incluye los requisitos de cómputo 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 de GitOps centrado en aplicaciones, pueden utilizar ArgoCD o Flux CD para la recuperación. De lo contrario, es probable que el mejor enfoque 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). Los 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 conforman una aplicación y cómo restaurarlos si hay una interrupción.