Kubernetes a menudo se aborda desde la perspectiva de los sistemas sin estado. Una aplicación sin estado es fácil de contener, distribuir y escalar porque no necesita almacenar ningún dato fuera de su entorno. No importa si el contenedor se detuvo o se movió a un host diferente: las nuevas instancias pueden reemplazar a las antiguas sin ninguna repercusión.
Sin embargo, la mayoría de las aplicaciones reales no son así. Todos los sistemas, excepto los más simples, poseen un estado que generalmente se almacena en una base de datos o en un sistema de archivos persistente. Los datos que configuran su servicio o son creados por los usuarios deben conservarse y hacerse accesibles para todos sus contenedores, independientemente de dónde se encuentren.
La mayoría de las organizaciones enfrentan el desafío de mantener el estado en entornos transitorios que usan contenedores, orquestación y prácticas de trabajo nativas de la nube. Kubernetes puede acomodar cargas de trabajo con estado, pero también existen alternativas externas. En este artículo, aprenderá algunos de los enfoques que hacen que Kubernetes funcione con aplicaciones con estado.
Los problemas con el estado
El término «estado» describe los datos asociados con una aplicación en un momento determinado. Es información de larga duración, como el contenido de la base de datos y las cuentas de usuario, que deberá recuperarse a lo largo de la vida útil del sistema. El estado cambia continuamente a medida que se crean y modifican datos mientras su servicio está en uso.
El funcionamiento correcto de la aplicación depende de que cada instancia pueda acceder al estado persistente. Si distribuye cuatro réplicas de un componente en dos hosts físicos, ambas máquinas necesitarán acceso a su almacén de datos. Esto significa que las instancias de la aplicación tienen dependencias interrelacionadas que no se pueden reemplazar automáticamente.
Las restricciones en torno a los servicios con estado entran en conflicto con el modelo de Kubernetes de contenedores efímeros que se pueden reemplazar en cualquier momento. Cuando trabaja con una aplicación con estado, debe tomar medidas especiales para que los contenedores puedan acceder de manera confiable al estado que necesitan. Esto requiere una configuración adicional para proporcionar una persistencia de datos confiable que se mantenga estable a medida que se escala su aplicación.
Ejecución de servicios con estado en Kubernetes
Soporte de Kubernetes para sistemas con estado ha crecido los últimos años, apoyado por un aumento en el interés de la comunidad. Las aplicaciones con estado se pueden ensamblar a partir de recursos admitidos oficialmente, como conjuntos con estado y volúmenes persistentes. Estos ofrecen métodos integrados para almacenar y administrar sus datos.
Los volúmenes persistentes brindan almacenamiento de datos a sus Pods. Los archivos escritos en un volumen persistente se almacenan independientemente del Pod que los crea. El contenido del volumen persiste en su clúster después de que se destruyen los pods, lo que permite que sus reemplazos accedan al estado almacenado.
StatefulSets son objetos API que representan aplicaciones con estado. Funcionan de manera similar a las implementaciones, pero asignan un identificador único a cada pod que encapsulan. Los pods conservan sus identificadores incluso si se reinician o programan en otro nodo. Esto le permite implementar procedimientos en los que el pedido y la identidad de los pods son importantes. Los identificadores confiables le permiten volver a hacer coincidir los volúmenes con los pods después de un evento de programación y lanzar actualizaciones de aplicaciones en secuencia.
Estas características significan que ahora es posible ejecutar aplicaciones con estado dentro de su clúster de Kubernetes. Puede escribir datos en volúmenes persistentes y usar StatefulSets en lugar de implementaciones cuando los pods necesitan recordar sus identidades.
Estado de gestión fuera de Kubernetes
Una ruta popular para ejecutar servicios con estado en Kubernetes es ubicar el estado fuera de tu grupo. Usted diseña su sistema para que sus componentes estén desacoplados del almacenamiento que requieren. Pueden acceder a datos persistentes en servicios separados a través de la red.
Puede mantener su propio servidor de base de datos, conectarse a recursos compartidos de archivos de red existentes o usar un servicio completamente administrado de su proveedor de nube. Las aplicaciones en su clúster de Kubernetes deben configurarse para interactuar con sus sistemas de almacenamiento mediante sus API o protocolos de acceso directo.
Esta es una buena manera de promover el desacoplamiento en sus servicios. Eliminar el acceso persistente al sistema de archivos de sus aplicaciones en contenedores las hace más portátiles entre entornos. Los contenedores se pueden lanzar utilizando modelos de implementación sin estado, ya que sus dependencias de almacenamiento se reducen a llamadas de red básicas. Puede beneficiarse de la flexibilidad de Kubernetes sin incurrir en el costo de la complejidad de usar volúmenes persistentes y conjuntos con estado para almacenar el estado en su clúster.
Evitar Kubernetes para servicios con estado
Una tercera escuela de pensamiento es evitar Kubernetes por completo para los servicios con estado. Esto suele ser una reacción exagerada: si no se siente cómodo manteniendo el estado en su clúster, aún puede usar el método descrito anteriormente para implementar sus aplicaciones usando un proveedor de almacenamiento adyacente.
No obstante, todavía hay algunos sistemas que podrían no tener sentido en Kubernetes. Las arquitecturas extremadamente dependientes del sistema de archivos que funcionan con una gran cantidad de archivos pueden ser difíciles de implementar y escalar utilizando volúmenes persistentes. Un sistema de almacenamiento externo administrado junto con Kubernetes puede agregar una latencia inaceptable cuando las interacciones de archivos son la función principal de su servicio.
En estas circunstancias, es posible que deba buscar enfoques de implementación alternativos que le brinden más control sobre el almacenamiento de datos y las operaciones de E/S. Sin embargo, se está trabajando en el ecosistema para mejorar las opciones de almacenamiento para los sistemas en contenedores. Soluciones de almacenamiento nativo en la nube están emergiendo como abstracciones de alto nivel de conceptos como volúmenes persistentes y conjuntos con estado, implementando sistemas de archivos distribuidos que siguen funcionando cuando se usan en múltiples nodos. cefalograma, Minioy Portworx son algunos de los contendientes en este espacio.
¿Debe ejecutar aplicaciones con estado en Kubernetes?
La mayoría de las aplicaciones con estado se pueden implementar sin problemas con Kubernetes. La decisión principal es si mantiene sus datos persistentes dentro de su clúster, utilizando volúmenes persistentes y conjuntos con estado, o interactuando con un almacén de datos administrado externamente.
Los volúmenes persistentes funcionan para la mayoría de los casos de uso, pero tienen algunas limitaciones. No todo el volumen modos de acceso son compatibles con todas las implementaciones, por lo que es importante verificar qué funciones admite su distribución de Kubernetes.
Relativamente pocos conductores ofrecen la ReadWriteMany modo que permite vincular el volumen a varios Nodos simultáneamente, cada uno de ellos capaz de leer y escribir datos. los ReadWriteOnce El modo es el más ampliamente admitido, lo que permite que cada nodo lea datos pero solo uno de ellos escriba. Estas restricciones pueden afectar la programación de su aplicación: un sistema con varios pods que necesitan escribir en una instancia de base de datos compartida deberá ejecutarlos todos en un solo nodo, a menos que ReadWriteMany está disponible. Esto limita su capacidad para escalar sus servicios.
Utilizar una base de datos administrada externamente o un sistema de almacenamiento de objetos es una forma efectiva de mitigar estos problemas persistentes y al mismo tiempo beneficiarse de la flexibilidad de Kubernetes. Esto requiere que su aplicación esté completamente desacoplada de su almacenamiento, por lo que podría no ser una opción si está migrando un servicio heredado.
Trabajar con aplicaciones más antiguas presenta el caso más sólido para no ejecutando una aplicación con estado en Kubernetes. Puede encontrarse con obstáculos si no puede ser intencional sobre dónde se almacena el estado y cómo se administra. En estas situaciones, generalmente es mejor refactorizar su sistema antes de intentar distribuirlo entre los nodos de implementación.
Resumen
Aunque las aplicaciones con estado y Kubernetes no son una combinación natural, es posible acomodar datos persistentes en su clúster combinando conjuntos con estado y volúmenes persistentes. Estos proporcionan métodos admitidos oficialmente para orquestar sistemas con estado utilizando Kubernetes, pero debe tener en cuenta las restricciones de programación que imponen.
Debido a que la administración del estado en el clúster agrega complejidad, mantener los datos persistentes en un servicio externo es una forma popular de optimizar sus implementaciones. Las bases de datos administradas, las plataformas de almacenamiento de objetos y las redes privadas le permiten aprovisionar almacenamiento fuera de su clúster y luego consumirlo de manera segura desde adentro. Deberá adaptar su aplicación para admitir interfaces de almacenamiento externo, pero luego podrá beneficiarse de una mayor flexibilidad de implementación.
Las aplicaciones en las que el estado consta de archivos de configuración simples pueden utilizar ConfigMaps para ejecutarse en Kubernetes sin tener que adoptar un almacenamiento de archivos persistente. Los ConfigMaps son objetos de primera clase que se proporcionan automáticamente a sus Pods cuando son necesarios, ya sea como variables de entorno o como archivos montados. Eliminan la necesidad de volúmenes persistentes cuando solo almacena un puñado de configuraciones de larga duración.
