DevOps - Charts de despliegue de recursos de la Plataforma en alta disponibilidad
Disponible desde la versión 3.1.0-KickOff
Introducción
En esta versión se ofrecen varios Charts para desplegar diferentes componentes de la Plataforma en alta disponibilidad, tanto en Kubernetes como en Openshift.
A continuación se detallan dichos charts.
Chart de MongoDB en Replica Set
La base de datos de tiempo real podía integrarse en la Plataforma tanto contenerizada, en modo single-node, como externa al cluster de Kubernetes tanto en modo single-node como en Replica Set. Con este chart puede desplegarse dentro del cluster de Kubernetes en alta disponibilidad/Replica Set haciendo uso de un StatefulSet de Kubernetes.
Cada nodo o pod de Mongo, gracias al objeto StatefulSet, tendrá asignado su propia persistencia en forma de Persistent Volumen Claim:
Chart de Kafka/Zookeeper en alta disponibilidad
Históricamente, los despliegues de Kafka y Zookeeper en Kubernetes consistían en un pod/contenedor desplegado en un único nodo. Para infraestructuras en las que haya más de un worker, esta arquitectura no es suficiente para garantizar la alta disponibilidad de estos servicios.
Para solucionar este problema se ha creado dos charts independientes que despliegan tres pods/contenedores en nodos separados, garantizando así el servicio en alta disponibilidad.
Para Zookeeper, cada deployment tendrá asociados sus propios recursos en Kubernetes: pvc, pv y service.
En el caso de Kafka, la foto es la misma, cada deployment tiene sus propios recursos de Kubernetes asociado.
Chart de OpenDistro/Elastic Search en alta disponibilidad
En anteriores releases se incluyó el proyecto OpenDistro para utilizarlo como base de datos de auditoría, además de dar la posibilidad de utilizarla como base de datos en tiempo real (RTDB). Cuando se necesite desplegar este servicio en entornos que consten de varios nodos, surge la necesidad de alta disponibilidad.
OpenDistro necesita varios recursos únicos para cada pod, tales como certificados y archivos de configuración. Por lo que se ha creado un chart que despliega tres deployments, cada uno con sus recursos asociados.
Además del servicio asociado a cada pod, se despliega un servicio adicional en Kubernetes que hace las veces de balanceador entre los tres nodos.
Chart de despliegue de BD histórica (Presto-MinIO) en modo 'single-instance' y en alta disponibilidad
Además de liberarse en este trimestre dos funcionalidades muy importantes como son Presto y MinIO, se ofrecen para ser desplegadas con Helm en clusters de Kubernetes.
MinIO: que es un es un sistema de almacenamiento de objetos compatible con S3, que permite almacenar de forma segura y replicada grandes volúmenes de información.
PrestoDB: que es un motor de consultas SQL de tipo Big Data, que funciona en modo distribuido y que es muy eficiente.
Los Charts de estos dos componentes se ofrecen de la siguiente manera:
Chart para el despliegue de MinIO en entornos de desarrollo.
Chart para el despliegue de PrestoDB y Hive en entornos de desarrollo.
Chart para el despliegue en alta disponibilidad de MinIO en entornos de producción.
Chart para el despliegue en alta disponibilidad de PrestoDB y Hive en entornos de producción.
MinIO una vez desplegado en modo de desarrollo pueden diferenciarse dos subcomponentes: por un lado la consola administrativa y por otro lado el servidor de almacenamiento.
En el caso de Presto en entornos «mínimos» sin alta disponibilidad, también se distinguen dos subcomponentes: el servidor de metadatos de Hive con destino MariaDB y el worker/coordinador.