Me quedo en un estado de incredulidad (juego de palabras) cuando, en 2024, escucho a menudo a los operadores de plataformas hablar de que Kubernetes es solo para cargas de trabajo sin estado, o que no requieren protección de datos ya que “todas nuestras aplicaciones son sin estado”. En este artículo, hablaré de dónde hay estados en nuestras aplicaciones, el auge del mito “Kubernetes = sin estado” y analizaré las necesidades de protección de datos en todos los entornos de Kubernetes.
Con estado vs. sin estado: conceptos básicos
Sin estado se refiere a una carga de trabajo que no requiere persistencia con control de estado, de modo que reiniciar o volver a implementar la carga de trabajo significa que los datos recopilados o la configuración modificada desaparecen. En comparación con sus predecesores de máquina virtual (VM) con control de estado, los contenedores son consustancialmente sin estado. Al reiniciar un contenedor, un usuario sabe que la carga de trabajo que está ejecutando es la misma que cuando se creó inicialmente la imagen del contenedor.
Siguiendo la lógica, una carga de trabajo con control de estado es aquella que conserva los datos de modo que se pueda acceder a ellos durante los reinicios. Las cargas de trabajo con control de estado comunes incluyen bases de datos como PostgreSQL, MySQL o MongoDB.
Entonces, ¿qué es una aplicación sin estado?
Normalmente, las aplicaciones constan de varias cargas de trabajo. Incluso las aplicaciones monolíticas basadas en VM generalmente constan de cargas de trabajo de frontend, lógica empresarial y base de datos. Las aplicaciones nativas de la nube y basadas en microservicios normalmente constarán de muchas más cargas de trabajo separadas, cada una con su propia función específica, con el objetivo de permitir a las organizaciones lanzar nuevas características y servicios más rápido que nunca.
Esto significa que, en su inmensa mayoría, no existen aplicaciones sin estado.
Su aplicación favorita para pedir comida, una aplicación de “tareas pendientes” en su teléfono, un formulario que completa para reservar una cita con el médico: todo esto sería efectivamente inútil si no hubiera algunas cargas de trabajo con control de estado responsables de conservar los datos críticos asociados con cada uno de estos casos de uso.
Con Kubernetes, es fundamental comprender dónde residen los datos o el estado de su aplicación: dentro o fuera del clúster.
¿Cómo hemos llegado a Kubernetes = sin estado?
A medida que Docker se convirtió en una plataforma de contenedores de facto a principios y mediados de la década de 2010 para el software de paquetización, tener una solución para orquestar grupos de contenedores a escala era fundamental para extraer todo el valor operativo de un cambio hacia los microservicios. Y Kubernetes cumplió. Las implementaciones declarativas, la alta disponibilidad y el escalado automatizado eran beneficios significativos para las cargas de trabajo sin estado que se podían detener, reiniciar y clonar con facilidad. Estas cargas de trabajo, que a menudo proporcionan más procesamiento de front-end o servidor de aplicaciones, podrían conectarse a servicios de datos que se ejecutan fuera del clúster. La solución fue aclamada por muchos como un éxito. Kubernetes era claramente una solución diseñada para cargas de trabajo sin estado, ¿verdad?
Sin embargo, en Kubernetes v1.0, junto a todas estas excelentes capacidades para las cargas de trabajo sin estado, se encontraban los volúmenes persistentes, un mecanismo nativo de Kubernetes para adjuntar almacenamiento persistente a pods efímeros. Claramente, la intención de admitir cargas de trabajo con control de estado fue una consideración desde el principio, con varias mejoras notables en el camino:
- Dic 2017 (v1.9) Disponibilidad general de StatefulSets: proporciona persistencia de las características de identidad del pod y operaciones ordenadas
- Dic 2018 (v1.13) Disponibilidad general de Container Storage Interface (CSI): un estándar que permite a cualquier fabricante de almacenamiento crear sus propios complementos para proporcionar almacenamiento a las cargas de trabajo de Kubernetes
- mayo de 2018 Presentación de Operator Framework, un kit de desarrollo de software (SDK) para simplificar la implementación y administración de cargas de trabajo avanzadas, como bases de datos, en Kubernetes
- diciembre de 2020 (v1.20) Disponibilidad general de los snapshots de volumen dentro de la especificación CSI: proporciona una interfaz estandarizada para realizar operaciones de snapshot de almacenamiento dentro de Kubernetes
Estas mejoras, combinadas con los esfuerzos de diferentes proveedores y colaboradores del proyecto, han creado un rico ecosistema que brinda a los usuarios la libertad de elegir qué servicios de datos proporcionarán el estado de su aplicación y dónde se ejecutarán esas cargas de trabajo.
El auge de GitOps
Durante este periodo, la comunidad de Kubernetes vio surgir otra idea para mejorar la orquestación de contenedores: GitOps. El concepto es simple: usar el control de versiones como fuente de verdad, almacenando todo lo necesario para implementar una aplicación, incluido el código y los recursos de Kubernetes. Cada vez que el código se fusiona en el repositorio para realizar un cambio, un controlador actualiza la implementación para reflejar el estado deseado descrito en Git. Las implementaciones de GitOps pueden proporcionar un mecanismo para el control de cambios, la capacidad de volver a implementar un entorno completo con un solo clic y una forma de revertir cambios incorrectos, a veces.
Solo porque Kubernetes pueda ejecutar cargas de trabajo con control de estado, ¿significa que debería hacerlo usted?
Un desarrollador al que se ha encargado crear una aplicación de prueba de concepto puede optar frecuentemente por una base de datos gestionada alojada en la nube, o DBaaS, para alojar sus datos persistentes fuera del clúster de Kubernetes. Las soluciones DBaaS proporcionan API fáciles de usar para los desarrolladores y un rápido tiempo de obtención de valor para los usuarios, independientemente de su nivel de experiencia en administración de bases de datos. Sin embargo, como suele ocurrir, lo más fácil no siempre es lo mejor. Exploremos las razones para considerar la ejecución de cargas de trabajo con control de estado dentro y fuera del clúster:
- Latencia : la colocación conjunta de servicios de datos junto con otras cargas de trabajo en contenedores ayuda a garantizar una conectividad de baja latencia con sus datos para ofrecer una experiencia de usuario consistente.
- Movilidad : Kubernetes proporciona una fuerte capa de abstracción que le permite mover la misma carga de trabajo entre diferentes nubes. Esto permite a las organizaciones abordar las necesidades de soberanía de datos o simplemente aprovechar las mejores condiciones de precios. Sin embargo, si sus servicios de datos están vinculados a una DBaaS específica de la nube, la migración entre entornos se vuelve significativamente más complicada. Las automatizaciones y políticas creadas para un DBaaS tendrán que volver a crearse para la base de datos administrada equivalente en la nube de destino, suponiendo que exista y cumpla los requisitos. Se necesitarán herramientas y procesamiento separados para volver a implementar las cargas de trabajo de Kubernetes desde los servicios de datos externos.
- Gestión de copia de datos: los desarrolladores deben probar la aplicación con datos recientes y relevantes, lo que requiere procesos separados para administrar y conectar estos servicios de datos cuando se ejecuta fuera del clúster. Como parte de una solución totalmente declarativa que ejecuta cargas de trabajo con y sin estado dentro del clúster, los usuarios podrían simplemente restaurar backups de aplicaciones completas como clones utilizando una interfaz nativa de Kubernetes como ‘kubectl.’
- Persistencia políglota: una forma elegante de decir “el servicio de datos adecuado para el caso de uso adecuado”. A medida que las aplicaciones tradicionales se reconstruyen usando una arquitectura de microservicios, los desarrolladores pueden elegir en Kubernetes entre implementar el servicio de datos idóneo para cada necesidad, con una implementación simplificada y una gestión continua dirigida por los operadores. Es posible que las organizaciones que operan servicios de datos fuera de Kubernetes no puedan escalar para cumplir con los complejos requisitos operativos para admitir cada una de las selecciones ideales de servicios de datos realizadas por los desarrolladores.
- Costo: con las soluciones de DBaaS, usted paga por la comodidad. Pero partners como EnterpriseDB han demostrado cómo alojar sus propios servicios de datos en Kubernetes genera un menor costo total de la propiedad (TCO) sin sacrificar de forma significativa la experiencia del usuario.
Optar por consolidar cargas de trabajo con y sin estado en Kubernetes puede aumentar la flexibilidad de dónde pueden ejecutarse las aplicaciones. También puede brindar autoservicio adicional para DevOps, costos más bajos y optimizar herramientas y procesos. Esto permite aplicar la metodología GitOps a todas las partes de una aplicación. No debería sorprender entonces, según el informe más reciente de Datadog sobre el uso de contenedores en el mundo real, que las bases de datos continúen siendo la categoría más popular de cargas de trabajo en contenedores.
Mantenga protegidos sus datos de Kubernetes
Equipo con control de estado
Si ya está convencido de que las cargas de trabajo con control de estado en Kubernetes son el camino a seguir, probablemente ya comprenda que proporcionar backup y recuperación ante desastres para estas aplicaciones requiere una herramienta diseñada específicamente para ello. Cada aplicación se compone de muchos recursos diferentes de Kubernetes (ConfigMaps, Secrets, Deployments, etc.) junto con datos de volúmenes persistentes. Es más, todo esto necesita ser descubrirse correctamente, capturarse en un snapshot y exportarse a una ubicación segura fuera del clúster.
Presentamos Veeam Kasten for Kubernetes, una solución de protección de datos y movilidad de aplicaciones nativa de Kubernetes. Kasten proporciona a las organizaciones una forma fácil de usar, escalable y segura de crear backups inmutables y recuperar aplicaciones completas de forma rápida y fiable.
Dado que Kasten proporciona una API declarativa nativa de Kubernetes para definir políticas, ejecutar acciones y mucho más, la protección de datos puede integrarse estrechamente en cualquier implementación de GitOps. Esto es posible en una amplia gama de casos de uso, desde la implementación y configuración de Kasten en un nuevo clúster hasta la mejora de GitOps mediante la automatización de backups antes de implementar actualizaciones de código. Por sí mismo, GitOps proporciona la capacidad de revertir los cambios de configuración a un recurso de Kubernetes; Sin embargo, si uno de esos cambios erróneos altera los datos de un volumen persistente (por ejemplo, un cambio de esquema incorrecto o la eliminación de una tabla), querrá un backup reciente que pueda restaurarse rápidamente.
Equipo sin estado
¿Todavía no está listo para cambiar su DBaaS favorito por una nueva base de datos gestionada por el operador y alojada en Kubernetes? Kasten todavía te cubre las espaldas. Veamos por qué la protección de datos nativa de Kubernetes sigue siendo necesaria:
- El estado debe estar alojado en alguna parte : con independencia de dónde estén alojados los datos fuera del clúster, sigue siendo fundamental poder reproducir implementaciones de aplicaciones en un punto en el tiempo, normalmente por razones de cumplimiento o de DR. En esencia, Kasten es un motor de orquestación diseñado para operaciones de protección de datos. Las funcionalidades del modelo de Kasten permiten contar con controles sólidos para pausar los servicios de datos en el clúster, pero también pueden aprovecharse para orquestar snapshots y backups de servicios de datos externos. Esto puede incluir la orquestación de volcados lógicos de una base de datos o la integración directa con las API de DBaaS.
- GitOps no es infalible: muchos administradores e ingenieros han experimentado alguna forma de “probado en producción”. Esto significa que se realizaron cambios en una instancia de producción <insert important reason here>que sorteó el proceso de administración de cambios aceptado. Por lo tanto, la única fuente de verdad de lo que se ha implementado proviene del propio clúster en tiempo de ejecución. Disponer de backups periódicos de los manifiestos asociados a cada aplicación a medida que se implementa garantiza que se detecte cualquiera de estas discrepancias. Esto permite reproducciones fieles del entorno original para admitir DR y/o cualquier requisito normativo.
- Protección de imágenes de contenedores: Kasten se integra con muchas de las capacidades avanzadas proporcionadas por Red Hat OpenShift, incluido el soporte para proteger y restaurar imágenes de contenedores de ImageStream. Los flujos de imágenes añaden muchas funcionalidades para crear e implementar imágenes de contenedores en comparación con Kubernetes upstream. Los orígenes que pueden pasarse por alto de un estado de clúster son las imágenes de contenedor de ImageStream que, de forma predeterminada, se insertan en el registro de contenedor interno del clúster. La reconstrucción desde el origen no garantiza que las imágenes resultantes sean las mismas. Una vez más, ser capaz de reproducir un entorno por completo o recuperarse de la pérdida de un clúster requiere backups fiables.
- Máquinas virtuales en Kubernetes: gracias al proyecto KubeVirt y sus colaboradores, ahora es posible ejecutar VM en paralelo con cargas de trabajo en contenedores en Kubernetes. Esto permite a las organizaciones optimizar las herramientas y los procesos en torno a Kubernetes a la vez que proporciona una sencilla vía de acceso a las cargas de trabajo que todavía no se han transformado, o simplemente no se transformarán, en aplicaciones totalmente nativas de la nube. Incluso en Kubernetes, las máquinas virtuales son intrínsecamente con control de estado, pero no se pueden proteger con las herramientas de backup de máquinas virtuales tradicionales. Kasten V7.0 ofrece el mejor soporte de su clase para el backup y la restauración de máquinas virtuales en Kubernetes que ejecutan OpenShift Virtualization.
El equipo de protección de datos de Kubernetes
Kubernetes ha evolucionado para admitir todo tipo de cargas de trabajo, a pesar de la creencia generalizada de que Kubernetes solo es adecuado para cargas de trabajo sin estado. A medida que las organizaciones se esfuerzan por extraer el máximo valor de sus inversiones nativas de la nube, es inevitable un cambio continuo hacia la ejecución de cargas de trabajo con control de estado. El aumento del rendimiento y la movilidad, la simplificación de la gestión de datos de copias, la persistencia políglota y el ahorro de costes son ventajas que están a la espera de hacerse realidad.
Tanto si se ejecutan cargas de trabajo con o sin control de estado, la protección de datos sigue siendo crucial. Veeam Kasten para Kubernetes proporciona una solución nativa de Kubernetes para backup de aplicaciones y datos, recuperación ante desastres, movilidad de aplicaciones y protección contra ransomware. Además, las metodologías GitOps pueden mejorarse integrando la protección de datos en las implementaciones de aplicaciones. En definitiva, la adopción de cargas de trabajo con control de estado en Kubernetes no solo desbloquea oportunidades de ingresos, sino que también aporta a las organizaciones una mayor flexibilidad, autoservicio, rentabilidad y optimización de operaciones.
Pruebe nuestra solución Veeam Kasten Free o nuestra versión de prueba de Enterprise para empezar hoy mismo.