Una de las tareas más habituales que tenemos es la de desplegar y mantener aplicaciones para el resto de la empresa. Generalmente para poner en producción una aplicación tenemos varias opciones y herramientas disponibles. No existe una forma necesariamente mejor que otra para hacer este trabajo pero sí hay que tener en cuenta que cada opción tiene unas ventajas y unos inconvenientes.
Desde máquinas físicas a contenedores pasando por muchos niveles de virtualización y de gestionar las dependencias. No hay una forma única pero sí que conviene conocerlas todas para elegir la más adecuada en cada entorno.
Tradicionalmente en esta organización esto se ha realizado utilizando la filosofía de una máquina por aplicación. Este criterio lleva a un desperdicio de recursos y no favorece la escalabilidad ni el mantenimiento de las aplicaciones. Habitualmente un servicio desplegado así sólo se actualiza, con suerte, cada varios años. Esto choca claramente con los ciclos de desarrollo de aplicaciones de software libre que habitualmente sacan versiones nuevas cada pocas semanas. Tampoco favorece el uso de herramientas como ansible para la gestión porque pronto nos encontramos con decenas de máquinas con diferentes configuraciones y estados.
Desde hace ya un tiempo la forma más habitual de despliegue de aplicaciones es a través de contenedores siendo Docker el más común. En nuestro caso tenemos bastantes servicios funcionando de esta forma pero de forma manual, es decir, desplegados desde el terminal y con poco control sobre el ciclo de vida y estado de los contenedores.
Con la monitorización adecuada de los servicios este sistema funciona bastante bien para entornos con un volumen de usuarios acotados. No tiene la flexibilidad que ofrecen otros entornos pero a cambio resulta muy sencillo de poner en práctica y mantener.
Esta dicotomía entre potencia y simplicidad es crucial en nuestras decisiones técnicas, que algo le sirva a Google no significa que te sirva a ti.
Aún así estábamos pensando en dar el siguiente paso que sería pasar todas las cargas que ya tenemos en contenedores a Kubernetes. Esto lo haríamos para así aprovechar las ventajas en la gestión y estar más preparados para un futuro donde en nuestra organización se estandarice el uso de Kubernetes ya sea in-house o en un proveedor externo y podamos migrar los servicios ahí.
Después de realizar algunas consultas vimos que en la organización no estaba disponible ningún cluster gestionado para el uso que queríamos darle así que nos tocaba montarlo nosotros mismos.
En estos capítulos vamos a ver el proceso de cómo hemos montado este cluster. No pretende ser una guía técnica para todos porque en nuestro caso tenemos algunas limitaciones organizativas y técnicas que nos obligan a tomar decisiones que no sean las mejores en la mayoría de los casos. Aún así es posible que las ideas sean extrapolables a vuestros entornos.
Infraestructura disponible y limitaciones
Debido a limitaciones corporativas la única posibilidad que tenemos es desplegar VMs con una configuración y sistema operativo ya establecido. Esta carencia nos impide utilizar las distribuciones específicas de Linux para Kubernetes tales como Talos o Flatcar.
Como sistema operativo el único que tenemos disponible es RedHat así que lógicamente es el que utilizaremos en nuestro caso.
Al no poder desplegar un OS concreto necesitamos una distribución de Kubernetes que funcione sobre un sistema ya existente y que tenga pocas o ninguna dependencia.
Existen varias distribuciones que funcionan de esta forma pero la que hemos considerado más adecuada es k0S por su estabilidad y flexibilidad.
k0S
k0S es una distribución certificada de Kubernetes que funciona en cualquier infraestructura, desde bare-metal hasta nubes públicas y privadas.
También tiene la opción de funcionar sobre un Linux existente como un único binario con la única dependencia que tenga un kernel 3.10 o superior.
Configuración del cluster y alta disponibilidad
Nuestro cluster va a estar formado por 6 nodos, 3 en el control plane y 3 como workers. La elección de este número de nodos es para tener alta disponibilidad.
El cluster estará alojado detrás de un proxy inverso y más adelante veremos cómo será la configuración para que todo funcione correctamente.
Ceph
Como es bien conocido Kubernetes no incluye por defecto ningún sistema de almacenamiento. Es posible enlazarlo a través de CSI a muchos backend de almacenamiento pero estos tienen que estar disponibles previamente.
En un cluster gestionado como AWS o GCP esto no es ningún problema porque ya el cluster ya tiene la configuración adecuada para utilizar sus distintas opciones de almacenamiento. En nuestro caso esto no es aplicable porque no tenemos ningún backend de almacenamiento que cumpla con nuestros requisitos así que nuevamente tendremos que montarlo nosotros mismos.
En nuestro cluster vamos a utilizar Ceph, un sistema de almacenamiento distribuido open source que se integra y gestiona perfectamente dentro de un cluster Kubernetes mediante Rook.
El tener este sistema de almacenamiento nos permitirá tener una flexibilidad enorme a la hora de asignar espacio a las aplicaciones ejecutadas en Kubernetes así como a otros sistemas y aplicaciones que tenemos desplegados actualmente.
La versatilidad de Ceph que permite en la misma solución almacenamiento de objetos tipo S3, bloques y filesystem así como la escalabilidad prácticamente infinita hace que sea una tecnología en la que basar nuestra infraestructura futura.
Comentarios