La contenerización de aplicaciones proporciona escalabilidad, resiliencia, eficiencia y velocidad.
ROSARIO PRIEGO | 11/03/2019
Si me preguntaran por una tendencia a destacar en el mundo de la tecnología estos últimos años, sin duda elegiría la contenerización de aplicaciones, porque me parece que ha proporcionado un método y unas facilidades idóneas, a todos los niveles, para la investigación, desarrollo y producción del software.
Además, de manera muy transversal, es útil desde el punto de vista del desarrollo, hasta el de la ciencia de datos, pasando por operaciones y arquitectura. Si me pidieran que pusiera nombres propios de esta tecnología, sin duda elegiría Docker y Kubernetes.
Como desarrolladora, Docker me ha permitido aprender, investigar y testear a un ritmo muy rápido, y de manera limpia y ordenada, un montón de nuevas herramientas. Ha revolucionado la filosofía de DevOps y tiene una gran comunidad de desarrolladores detrás, que amplían y mejoran las imágenes sobre las que se están generando nuevas aplicaciones. Añade las características de la portabilidad, la ligereza, la agilidad, el aislamiento y la abstracción, lo que permite crear soluciones mucho más rápidamente, y con mucha más fiabilidad.
Además, Kubernetes, como herramienta de orquestación de contenedores, ha traído la escalabilidad fácil, la resiliencia, la facilidad de la comunicación entre los contenedores, la despreocupación por el balanceo de carga y la facilidad para gestionar la actualización de versiones, entre otras muchas características. También es importante resaltar que ha permitido conectar contenedores de Docker en diferentes servidores, en la nube y en entornos mixtos.
Ambas representan las bondades de la escalabilidad, de la resiliencia, de la eficiencia, de la velocidad ... ¿De qué nos suenan esas palabras? Yo siempre las he vinculado con el mundo Big Data. Por lo tanto, cabe pensar que son dos mundos que están hechos el uno para el otro, pero ¿es tan fácil adecuar las herramientas Big Data por excelencia al mundo Kubernetes?
En Treelogic hemos trabajado con herramientas Big Data para analizar cómo se podrían lograr estos objetivos con k8s. Me temo que se van a plantear más dudas que respuestas en esta entrada, pero espero que sean un punto de partida para la reflexión a la hora de elegir una arquitectura estable en proyectos Big Data.
Replicar el funcionamiento de HDFS en Kubernetes, en principio, no es complicado. HDFS tiene dos tipos de daemos: Name Nodes y Data Nodes. Las indicaciones en general apuntan a generar uno o varios StatefulSets para el Name Node y varios Stafulsets para los Data Nodes.
Tener HDFS en Kubernetes proporciona algunos beneficios como poder tener varios entornos HDFS a la vez diferenciados por su namespace, la portabilidad y el balanceo de carga entre nodos. Por otro lado, tenemos varios contras a tener en cuenta:
En Treelogic, donde apostamos fuertemente por las arquitecturas kappa, Kafka es una de las herramientas estrella más utilizadas.
Nuestro objetivo para las pruebas de esta tecnología en Kubernetes era dar de alta un clúster Kafka y uno de Zookeeper de manera que ambos pudieran escalar rápidamente hacia arriba o abajo.
Para esto hizo falta que tanto Zookeeper como Kafka fueran StatefulSets, pero nos encontramos con el problema de la persistencia puesto que Kubernetes no facilita el aprovisionamiento dinámico de los volúmenes en caso de usar un servidor NFS, como era nuestro caso.
Es cierto que existen soluciones on-premise como storageOS o glusterFS, pero lo más fácil sería utilizar el almacenamiento en la nube, y en ese caso, sería también buena idea migrar el cluster de Kubernetes íntegramente a la nube para evitar problemas de latencia de red en acceso/escritura.
Otras dudas vienen de la mano del autoescalado: en caso de querer escalar hacia arriba en número de brokers, se debería ejecutar la reasignación de particiones para que el nuevo broker pudiera aceptar escrituras y lecturas. En caso de que la carga caiga y hubiera que escalar hacia abajo, la reasignación de particiones sería muy frecuente y no parece que fuera muy productivo.
Además, cada cliente necesita conectarse en concreto con el broker donde está su partición para producir/consumir, así que no es suficiente con utilizar un LoadBalancer, ya que hay que redirigir cada mensaje al broker específico. Hay maneras de resolverlo, como explican desde Confluent aquí, pero es necesario un equipo con experiencia en redes y en almacenamiento.
Parece que la persistencia de datos distribuida en Kubernetes sigue en desarrollo y no es muy recomendable para producción.
Ha sido necesario que un grupo de empresas se hayan involucrado en el proyecto Spark on Kubernetes para reescribir el código del driver y el ejecutor de Spark para que pudiera adaptarse a Kubernetes.
En las últimas versiones de Spark (desde la versión 2.3.0) ya está disponible la información para poder lanzar spark-submit en Kubernetes.
Utilizar Kubernetes para lanzar jobs de Spark nos beneficia, como en el resto de los casos, en:
Y otros beneficios como la portabilidad o la facilidad para llevar nuestros procesos a la nube.
Por otro lado, hay otros retos pendientes como la localidad del dato (apuntado ya en la primera sección de esta entrada), las colas de jobs y la mejora de la gestión de recursos. Aunque como apuntan en la propia página de Spark, ya están trabajando sobre ello.
En cuanto a persistencia (persistencia dinámica distribuida, localidad del dato, etc.) creo que Kubernetes y las herramientas Big Data tienen todavía un largo camino que recorrer. Pero sin duda se están dando pasos para mejorar y solventar las dificultades que conllevan las aplicaciones más centradas en los datos.
Como apuntan en este artículo “el ciclo de vida del dato, es muy diferente al ciclo de vida de las aplicaciones”. Las herramientas Big Data suelen ser “datacéntricas” y complejas, no exactamente monolíticas, pero sí que darán problemas al intentar obtener escalabilidad, flexibilidad y tolerancia a fallos.
No todo son malas noticias, hay herramientas como Kafka Streams que casan perfectamente con su despliegue en Kubernetes. De hecho, desde Confluent, aconsejan empezar por ahí para ir cogiendo soltura.
Otro punto positivo es que viendo todos los esfuerzos y la gran comunidad que está trabajando detrás de proyectos como Apache Spark on Kubernetes, no cabe duda de que el camino que se ha abierto va a seguir dando sus frutos.
Aunque existe una gran variedad de herramientas para gestionar y monitorizar la multitud de microservicios desplegados en Kubernetes, cuando pensamos en un equivalente a Ambari/Cloudera Manager para gestionar todos los servicios de una distribución típica de Big Data y mantenerlos sincronizados (hablamos de HDFS, Zookeeper, Hbase, Spark, Hue, Oozie, Fume, Hive, etc), se nos presenta otro gran reto a acometer.
En Treelogic seguiremos trabajando con Kubernetes para herramientas y entornos de Big Data y de Machine Learning, pero también reconocemos la importancia y la necesidad de tener distribuciones Hadoop tradicionales como Hortonworks o Cloudera, más ahora que se han fusionado (¿quizá para hacer frente a este nuevo competidor?).
HDFS en Kubernetes:
HDFS on Kubernetes—Lessons Learned
Kubernetes, Hadoop, persistent volumes and vSAN
Understanding How to Enable Apache Hadoop on Kubernetes
Kafka en Kubernetes:
Apache Kafka on Kubernetes – Could You? Should You?
Why Is Storage On Kubernetes So Hard?
Spark en Kubernetes:
Corriendo Apache Spark sobre Kubernetes
ARQUITECTURA KAPPA
La gran mayoría de los que nos dedicamos al Big Data nos habremos iniciado en este mundo habiendo escuchado el discurso de las famosas V’s. Tres eran en sus inicios: volumen, variedad y velocidad; que pasaron a ser cuatro, valor, gracias al aprendizaje automático.
ARQUITECTURAS TREELOGIC BIG DATA
Los millones de datos que se generan actualmente en la era digital no servirían de nada sin sistemas que canalicen toda esa información. El conjunto de tecnologías que permite el tratamiento masivo de ese conjunto de datos es lo que se conoce como Big Data.
DEEP LEARNING, APRENDIZAJE PROFUNDO
Desde que en la década de los años 50 se comenzó a hablar de Inteligencia Artificial, no se ha parado de investigar, avanzar y desarrollar este tipo de tecnología. Su principal objetivo reside en poder dotar a sistemas informáticos y digitales de procesos que imiten el funcionamiento del cerebro humano.
TO DEEP, OR NOT TO DEEP, THAT IS THE QUESTION
El Deep Learning es un campo de investigación activo y está revolucionando otros ámbitos dentro del paraguas de la inteligencia artificial. Uno de estos ámbitos es la visión artificial o Computer Vision.
LA APROXIMACIÓN TREELOGIC: WE DEAL WITH DATA
Uno de los principales objetivos que tenemos en Treelogic, para cualquiera de nuestros proyectos, es ayudar al cliente a descubrir cómo los datos otorgan valor a su negocio.