Considero a Hashicorp una de las empresas que más están innovando actualmente: su compromiso con los entornos multi-nube (privada, pública y mixta) y su suite de herramientas están facilitando mucho la transición entre proveedores y reduciendo la curva de aprendizaje de la nube.
Cada día utilizamos más servicios online: servicios accesibles a través de Internet que podemos operar y utilizar por nuestra cuenta, pero que forman parte de un conjunto mucho más grande.
Vamos a imaginarnos que Netflix o Spotify tuvieran que desplegar una aplicación para cada uno de sus usuarios. Sería mucho más difícil mantener y operar el servicio y haría casi imposible su escalabilidad y disponibilidad general. Tanto para ofrecer un mejor servicio como para ahorrar costes, cada plataforma digital suele funcionar como si fuese una única aplicación, dentro de la cual se nos asigna una pequeña parte de la misma y que podemos utilizar de manera independiente. Este sistema de compartición de recursos es una de las bases de la computación en la nube y recibe el nombre de Multi-tenancy.
Es un sistema que inicialmente añade complejidad al conjunto, pero que bien diseñado, puede aportar mucha robustez y ahorro a futuro.
Pese a que hay compañías que deciden desplegar una aplicación por clúster de Kubernetes para evitar complicaciones, esto puede ser muy ineficiente. Además, Kubernetes ofrece multitud de mecanismos para garantizar una buena gestión del multi-tenancy.
Por ejemplo: a la izquierda tenemos dos clústers separados con una aplicación cada uno. El superior tiene demasiados recursos para la carga que tiene, mientras que el inferior ya está al máximo y no puede aprovechar los recursos sobrantes del primero. A la derecha, ambas aplicaciones comparten el clúster y cualquiera de ellas puede aprovechar los recursos sobrantes si fuese necesario.
En anteriores post hemos visto como aislar pods y aplicaciones dentro del mismo clúster tanto a nivel de seguridad y permisos como a nivel de red. Hoy vamos a aprender cómo asignar y aislar los recursos computacionales que utilizan nuestras aplicaciones sobre Kubernetes.
La digitalización de la sociedad es un proceso que ha aumentado tanto el consumo de servicios web como los ataques informáticos contra sus usuarios y los propios servicios. A mediados de 2020, alguien accedió a las herramientas de gestión internas de Twitter y pudo publicar mensajes en cuentas verificadas de gente famosa para que le enviaran Bitcoins. El ataque era un robo, pero las consecuencias del ataque podían haber sido mucho más graves.
¿Os imaginais que se hubiera publicado amenazas de muerte desde la cuenta de un presidente de un Estado hacia otro presidente? ¿O si desde la cuenta de un gran empresario se diese información errónea para manipular la Bolsa de un país?
Evidentemente, nosotros como usuarios no tenemos tanto poder, pero si alguien accediese a nuestras cuentas de AWS o GCP, podríamos tener problemas o gastos indeseados.
A lo largo de varios meses, hemos visto qué es Kubernetes y cómo realizar algunas acciones en nuestros clústers: desplegar aplicaciones, hacerlas accesibles desde fuera del clúster o almacenar datos, entre otros (I, II y III)
En el último post de la serie, comenzamos a hablar de multitenancy y la capacidad de ejecutar diferentes aplicaciones, separadas de forma lógica en el mismo clúster.
Para lograr esta separación, lo primero era entender cómo funcionan los sistemas de autorización y autenticación de Kubernetes, pero aunque tengamos una buena política de permisos definida, nada impide por defecto que una aplicación mande peticiones a otra desplegada en el mismo clúster.
Esto puede parecer lógico y no ser un gran problema, pero si puede llegar a serlo: ¿Y si alguien despliega una aplicación maliciosa o alguien explota una vulnerabilidad en alguno de nuestros contenedores? ¿Y si nuestras aplicaciones tienen distintos grados de confidencialidad?.
Para que la separación lógica entre aplicaciones sea completa, no necesitamos crear un clúster por aplicación sino aplicar Network Policies.
El uso de funciones en la nube no es una moda pasajera y ha llegado para quedarse. Pese a sus limitaciones, tienen algunos puntos fuertes que las hacen una baza imprescindible a la hora de potenciar la automatización de la administración de la nube.
Ya escribí un post sobre funciones en el que explicaba cómo utilizo las funciones para vigilar el estado de los backups de mis servicios a coste 0 y sin tener que preocuparme por su gestión.
Hoy vamos a darle una vuelta extra a dicho post, terraformando dichas funciones e integrándolas en un sistema de CICD completo.
Al comenzar este blog hace más de dos años, siempre tuve claro que me centraría en la nube en sí misma, así como en las metodologías y tecnologías que permiten su existencia.
La tecnología no ha parado de evolucionar en estos años: han aparecido constántemente nuevas ideas, que buscan solucionar los problemas ya existentes, pero que a su vez generan otros nuevos problemas.
El propio Kubernetes es un ejemplo perfecto: permite aprovechar mejor los recursos que disponemos y aporta una mayor resilencia y disponibilidad. Sin embargo, también genera mucha abstracción en sus elementos y hace que podamos perder capacidad operativa y visibilidad. Sin las herramientas adecuadas es mucho más fácil corregir un error en una máquina virtual que en una aplicación desplegada en varios microservicios.
Personalmente, siempre me he centrado en los principales proveedores de nube pública. Son mi foco a nivel profesional y permiten reducir la complejidad que supone usar estas nuevas tecnologías, acercándolas a los usuarios, clientes y administradores menos techies.
Pero… ¿Y si no queremos utilizar nube pública? ¿No existe alguna alternativa potente para gestionar nuestra nube pública?
Hoy vamos a continuar con la serie de posts relacionados con Kubernetes. Tras el contenido de los post I, II y III, ya sabemos un poco qué es Kubernetes, cómo almacenar datos en nuestro clúster y cómo acceder a nuestros servicios.
En cada post hemos visto como K8s está diseñado para ser escalable y para ello, cualquier servicio necesita ingentes cantidades de hardware (host, switchs, routers, cableado, discos duros, etc).
Si utilizamos una nube pública, nuestro proveedor se encargará de aprovisionar los recursos necesarios, pero seguirá de nuestra mano el tener que distribuir las cargas de trabajo a lo largo del clúster para lograr nuestros objetivos de servicio (alta disponibilidad, distribución en zonas o regiones, etc).
La gran necesidad de recursos nos lleva a hacernos una pregunta: ¿Cómo podemos aprovechar al máximo los recursos de nuestro clúster? La forma más completa se basa en desplegar diferentes aplicaciones que compartan hardware, pero puede no ser lo más seguro.
Así que, ¿cómo podemos aprovechar al máximo y de la manera más segura posible, los recursos de nuestro clúster?
Una de mis mayores preocupaciones informáticas es la pérdida de datos. Nunca he tenido una pérdida catastrófica pero sí algunas menores y siempre he buscado que mi sistema de respaldo fuese consistente y fiable. Como ya dije en un post anterior, hace tiempo que me monté un sistema de backups personalizado y que me permite recuperar mis datos con una pérdida máxima de datos de 24 horas.
Los backups se generan cifrados con GPG en el origen a través de Backupninja y se suben a almacenamientos en la nube gracias a rclone. Se realiza un sistema de archivado en MEGA.
Aunque generalmente funcione bien, sí he tenido algunas incidencias desde que lo implementé, todas ellas relacionadas con la imposibilidad de subir el backup al destino remoto (tokens expirados, discos remotos llenos, etc).
Tras haber aprendido algunos conceptos, ahora vamos a realizar un ejercicio similar al que podríamos tener que hacer en la vida real. La idea es coger una aplicación tradicional y ejecutarla de la mejor manera posible en un clúster de Kubernetes.
La aplicación elegida es Traccar, una aplicación rusa de seguimiento GPS que cumple muchos de los puntos que buscaba:
Es una aplicación con diferentes capas: tiene un frontal web, un backend de procesamiento y necesita una base de datos relacional para funcionar. Su frontal y su backend se encuentran acoplados en el mismo paquete.
Está bien mantenida por sus desarrolladores y ofrece imágenes Docker oficiales (para no empezar todo el proceso de 0).
Su frontend web está desarrollado actualmente en tecnologías no punteras como el gestor de componentes Sencha.
Su backend está desarrollado en Java, sin un diseño específico para adaptarse per se a un sistema como Kubernetes: gestiona cachés internas en local haciendo problemático su escalado.
¡Manos a la obra!
Tras unos pocos meses de atraso, continuamos con los posts de Kubernetes :)
En el post anterior aprendimos unos cuantos conceptos básicos (pods, namespaces, deployments, replicasets y services) de Kubernetes. Son lo mínimo que debería saber un usuario (que no un administrador) para empezar a utilizar nuestro timonel favorito con un mínimo de cabeza, pero no son los únicos y existen otros objetos importantes.
Hoy vamos a explicar algunos conceptos extra que mejorarán nuestra comprensión de la herramienta y ayudará a que desatemos todo su potencial.
De momento vamos a seguir utilizando MicroK8s para los ejemplos que hagamos, pero si algún lector tiene otro clúster instalado podrá utilizarlo también. Leña al mono.