Aplicaciones estadísticas vs apátridas en Kubernetes
Comencemos con una definición ingenua de "estatuto" y luego avanzamos lentamente a una visión más rigurosa y del mundo real.
Una aplicación sin estado es aquella que no depende de un almacenamiento persistente. Lo único de lo que su clúster es responsable es el código y otro contenido estático, que se aloja en él. Eso es todo, no hay bases de datos cambiantes, no escribe y no hay archivos sobrantes cuando se elimina el POD.
Una aplicación con estado, por otro lado, tiene varios otros parámetros que se supone que debe atender en el clúster. Hay bases de datos dinámicas que, incluso cuando la aplicación está fuera de línea o eliminada, persisten en el disco. En un sistema distribuido, como Kubernetes, esto plantea varios problemas. Los miraremos en detalle, pero primero aclaremos algunos conceptos erróneos.
Los servicios sin estado no son en realidad 'apátrate'
¿Qué significa cuando decimos el estado de un sistema?? Bueno, consideremos el siguiente ejemplo simple de una puerta automática.
La puerta se abre cuando el sensor detecta a alguien que se acerca, y se cierra una vez que el sensor no recibe información relevante.
En la práctica, su aplicación sin estado es similar a este mecanismo anterior. Puede tener muchos más estados que solo cerrados o abiertos, y muchos tipos diferentes de entrada, lo que lo hacen más complejo pero esencialmente lo mismo.
Puede resolver problemas complicados simplemente recibiendo una entrada y realización de acciones que dependen tanto de la entrada, como de 'estado', está en. El número de estados posibles está predefinido.
Entonces la apatridia es un nombre inapropiado.
Las aplicaciones sin estado, en la práctica, también pueden hacer trampa un poco guardando detalles sobre, por ejemplo, las sesiones del cliente en el cliente en sí (las cookies HTTP son un gran ejemplo) y aún así tener una buena apatridia que las haría funcionar sin problemas en el clúster.
Por ejemplo, los detalles de la sesión de un cliente, como qué productos se guardaron en el carrito y no se revisaron, se pueden almacenar en el cliente y la próxima vez que comience una sesión también se recordan estos detalles relevantes.
En un clúster de Kubernetes, una aplicación sin estado no tiene almacenamiento o volumen persistente asociado con él. Desde una perspectiva de operaciones, esta es una gran noticia. Diferentes vainas en todo el clúster pueden funcionar de forma independiente con múltiples solicitudes que les llegan simultáneamente. Si algo sale mal, puede reiniciar la aplicación y volverá al estado inicial con poco tiempo de inactividad.
Servicios con estado y el teorema de CAP
Los servicios con estado, por otro lado, tendrán que preocuparse por lotes y lotes de casos y problemas extraños. Una cápsula está acompañada con al menos un volumen y si los datos en ese volumen están dañados, entonces eso persiste incluso si se reinicia todo el clúster.
Por ejemplo, si está ejecutando una base de datos en un clúster Kubernetes, todas las cápsulas deben tener un volumen local para almacenar la base de datos. Todos los datos deben estar en perfecta sincronización.
Entonces, si alguien modifica una entrada a la base de datos, y eso se hizo en Pod A, y una solicitud de lectura viene en Pod B para ver esos datos modificados, entonces POD B debe mostrar que los últimos datos o darle un mensaje de error. Esto se conoce como consistencia.
Consistencia, En el contexto de un clúster de Kubernetes, significa Cada lectura recibe la escritura más reciente o un mensaje de error.
Pero esto corta contra disponibilidad, Una de las razones más importantes para tener un sistema distribuido. La disponibilidad implica que su aplicación funciona lo más cerca de la perfección como Possbile, durante todo el día, con la menor cantidad de error posible.
Uno puede argumentar que puede evitar todo esto si solo tiene una base de datos centralizada que es responsable de manejar todas las necesidades de almacenamiento persistentes. Ahora volvemos a tener un solo punto de falla, que es otro problema que se supone que los grupos de Kubernetes se resuelven en primer lugar.
Debe tener una forma descentralizada de almacenar datos persistentes en un clúster. Comúnmente conocido como partición de red. Además, su clúster debe poder sobrevivir a la falla de los nodos que ejecutan la aplicación con estado. Esto se conoce como tolerancia a la partición.
Cualquier servicio (o aplicación) con estado, ejecutarse en un clúster de Kubernetes, debe equilibrar entre estos tres parámetros. En la industria, se conoce como el teorema de CAP donde las compensaciones entre consistencia y disponibilidad se consideran en presencia de partición de red.
Más referencias
Para obtener más información sobre el teorema de CAP, es posible que desee ver esta excelente charla dada por Bryan Cantrill, que analiza mucho más de cerca a la ejecución de sistemas distribuidos en producción.