{"id":71858,"date":"2020-02-28T21:00:08","date_gmt":"2020-02-28T18:00:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/patterny-hraneniya-dannyh-v-kubernetes"},"modified":"2020-03-03T16:14:09","modified_gmt":"2020-03-03T13:14:09","slug":"patterny-hraneniya-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Patrones de almacenamiento de datos en Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Patrones<\/a><\/noindex>
\n\u00a1Hola, Habr!<\/p>\n

Te recordamos que hemos lanzado otro libro extremadamente interesante y \u00fatil sobre patrones de Kubernetes. Todo comenz\u00f3 con \"<\/a><\/noindex> sobre los patrones de Kubernetes. Todo comenz\u00f3 con \"\" de Brendan Burns, y, de hecho, nuestro trabajo en este segmento<\/a><\/noindex>\" Brendan Burns, y, de hecho, nuestro trabajo en este segmento . Hoy te ofrecemos leer un art\u00edculo del blog de MinIO, que resume las tendencias y especificidades de los patrones de almacenamiento de datos en Kubernetes.<\/a><\/noindex>Kubernetes ha cambiado fundamentalmente los patrones tradicionales de desarrollo y despliegue de aplicaciones. Ahora, un equipo puede tardar solo unos d\u00edas en desarrollar, probar y desplegar una aplicaci\u00f3n en diferentes entornos, todo dentro de cl\u00fasteres de Kubernetes. Este trabajo con tecnolog\u00edas de generaciones anteriores sol\u00eda llevar semanas, si no meses.
\n<\/a><\/noindex><\/p>\n

Esta aceleraci\u00f3n ha sido posible gracias a la abstracci\u00f3n que proporciona Kubernetes, es decir, gracias a que Kubernetes maneja las interacciones con los detalles de bajo nivel de m\u00e1quinas f\u00edsicas o virtuales, permitiendo a los usuarios declarar entre otros par\u00e1metros el procesador necesario, la cantidad de memoria requerida y el n\u00famero de instancias de contenedores. Dado que una enorme comunidad est\u00e1 involucrada en el soporte de Kubernetes y su uso sigue expandi\u00e9ndose, se sit\u00faa con gran ventaja como la plataforma l\u00edder en orquestaci\u00f3n de contenedores.<\/p>\n

A medida que aumenta el uso de Kubernetes, tambi\u00e9n crece la confusi\u00f3n sobre los patrones de almacenamiento de datos que se aplican en \u00e9l.<\/p>\n

Con la competencia general por una porci\u00f3n del mercado de Kubernetes (es decir, por almacenamiento de datos), cuando se habla de almacenamiento, la se\u00f1al se pierde en un fuerte ruido.<\/b><\/i>.<\/p>\n

Kubernetes encarna un modelo moderno de desarrollo, despliegue y gesti\u00f3n de aplicaciones. Este modelo moderno desacopla el almacenamiento de datos de los c\u00e1lculos. Para entender completamente este desacoplamiento en el contexto de Kubernetes, tambi\u00e9n es necesario comprender qu\u00e9 son las aplicaciones con y sin estado, y c\u00f3mo se relaciona esto con el almacenamiento de datos. Aqu\u00ed es donde el enfoque API REST utilizado por S3 tiene ventajas claras sobre el enfoque POSIX\/CSI caracter\u00edstico de otras soluciones.
\nKubernetes encarna un modelo moderno de desarrollo y despliegue de aplicaciones, as\u00ed como de su gesti\u00f3n. Este modelo moderno desacopla el almacenamiento de datos de la computaci\u00f3n. Para comprender completamente este desacoplamiento en el contexto de Kubernetes, tambi\u00e9n es necesario entender qu\u00e9 son las aplicaciones con y sin estado, as\u00ed como c\u00f3mo se combina esto con el almacenamiento de datos. Aqu\u00ed es donde el enfoque de REST API utilizado por S3 tiene claras ventajas en comparaci\u00f3n con el enfoque POSIX\/CSI, t\u00edpico de otras soluciones.<\/p>\n

En este art\u00edculo hablaremos sobre los patrones de almacenamiento de datos en Kubernetes y abordaremos por separado la discusi\u00f3n sobre las aplicaciones sin estado y con estado, para entender completamente cu\u00e1l es la diferencia entre ellas y por qu\u00e9 es importante. A continuaci\u00f3n, se examinar\u00e1n las aplicaciones y los patrones de almacenamiento de datos utilizados en ellas a la luz de las mejores pr\u00e1cticas para trabajar con contenedores y Kubernetes.<\/p>\n

Contenedores sin estado<\/h4>\n

\nLos contenedores son por naturaleza livianos y ef\u00edmeros. Se pueden detener, eliminar o desplegar en otro nodo sin dificultad; todo esto lleva solo unos segundos. En un gran sistema de orquestaci\u00f3n de contenedores, estas operaciones suceden constantemente, y los usuarios ni siquiera notan esos cambios. Sin embargo, los movimientos son posibles solo si el contenedor no tiene ninguna dependencia del nodo en el que se encuentra. A estos contenedores se les dice que funcionan sin estado<\/i>.<\/p>\n

Contenedores con estado<\/h4>\n

\nSi un contenedor almacena datos en dispositivos conectados localmente (o en un dispositivo de bloques), entonces el almacenamiento de datos en el que se encuentra tendr\u00e1 que ser trasladado a un nuevo nodo junto con el propio contenedor en caso de fallo. Esto es importante, ya que de lo contrario, la aplicaci\u00f3n que se ejecuta en el contenedor no podr\u00e1 funcionar correctamente, ya que necesita acceder a los datos almacenados en los dispositivos locales. A estos contenedores se les dice que funcionan con estado<\/i>.<\/p>\n

Desde un punto de vista puramente t\u00e9cnico, los contenedores con estado tambi\u00e9n pueden trasladarse a otros nodos. Esto generalmente se logra mediante sistemas de archivos distribuidos o almacenes de datos en red de bloques conectados a todos los nodos donde funcionan los contenedores. De este modo, los contenedores acceden a vol\u00famenes para el almacenamiento persistente de datos, y la informaci\u00f3n se almacena en discos distribuidos por toda la red. Llamar\u00e9 a este m\u00e9todo elenfoque de contenedor con estado<\/i>, y en el resto del art\u00edculo lo llamar\u00e9 as\u00ed por uniformidad.<\/p>\n

\"Patrones
\n
\nEn un enfoque t\u00edpico de contenedor con estado, todos los pods de aplicaciones se adjuntan a un sistema de archivos distribuido, formando una especie de almacenamiento compartido donde residen todos los datos de las aplicaciones. Aunque pueden existir algunas variaciones, este es un enfoque de alto nivel.<\/p>\n

Ahora, examinemos por qu\u00e9 el enfoque de contenedor con estado en un mundo orientado a la nube es un antipatr\u00f3n.<\/p>\n

Dise\u00f1o de aplicaciones orientado a la nube<\/h4>\n

\nTradicionalmente, las aplicaciones utilizaban bases de datos para el almacenamiento estructurado de informaci\u00f3n y discos locales o sistemas de archivos distribuidos donde se almacenaban todos los datos no estructurados o incluso semi-estructurados. A medida que aumentaba el volumen de datos no estructurados, los desarrolladores se dieron cuenta de que POSIX era demasiado \"charlat\u00e1n\", asociado con costos significativos y, en \u00faltima instancia, perjudicaba el rendimiento de la aplicaci\u00f3n al escalar realmente a gran escala.<\/p>\n

Esto, en gran medida, contribuy\u00f3 a la aparici\u00f3n de un nuevo est\u00e1ndar de almacenamiento de datos, es decir, los almacenes orientados a la nube que operan principalmente sobre la base de REST API y liberan a la aplicaci\u00f3n del oneroso mantenimiento de un almacenamiento de datos local. En este caso, la aplicaci\u00f3n efectivamente opera en modo sin estado (ya que el estado se almacena en un almacenamiento remoto). Las aplicaciones modernas se construyen desde cero teniendo en cuenta este factor. Por lo general, cualquier aplicaci\u00f3n moderna que maneje alg\u00fan tipo de datos (registros, metadatos, blobs, etc.) se construye bajo la paradigma orientada a la nube, donde el estado se transfiere a un sistema de software espec\u00edficamente designado para su almacenamiento. <\/p>\n

El enfoque de contenedor con estado obliga a toda esta paradigma a retroceder exactamente a donde comenz\u00f3. <\/b><\/i><\/p>\n

Al utilizar interfaces POSIX para el almacenamiento de datos, las aplicaciones funcionan de la misma manera que si estuvieran guardando estado, y por ello se desv\u00edan de los postulados m\u00e1s importantes del dise\u00f1o orientado a la nube, es decir, de la capacidad de variar los tama\u00f1os de los flujos de trabajo de la aplicaci\u00f3n seg\u00fan la carga entrante, de trasladarse a un nuevo nodo tan pronto como el nodo actual falle, etc.<\/p>\n

Al observar esta situaci\u00f3n m\u00e1s de cerca, descubrimos que al elegir un almacenamiento de datos nos encontramos una y otra vez con el dilema \"POSIX vs REST API\", PERO con un agravamiento adicional de los problemas de POSIX debido a la naturaleza distribuida de los entornos de Kubernetes. En particular,<\/p>\n