Nuestra historia con kubernetes empezó a ser un poco más seria un sábado 16 de enero de 2016 en las oficinas de ShuttleCloud. Ese día Iván Pedrazas y Álex González impartían un maravilloso taller gratuito de docker y Kubernetes al que tuvimos la suerte de asistir junto a otras 30-40 personas. Varios de ellos hoy son amigos, aunque esa es otra historia.

Aún así, no sería hasta finales de 2017 cuando pusimos en marcha nuestro primer cluster productivo de kubernetes para uno de nuestros clientes. Tuvimos la suerte de tener la confianza y comprensión del mismo para que juntos aprendiéramos y evolucionásemos con esta nueva tecnología.

El uso de kubernetes por parte de nuestros clientes ha ido en aumento, así como la importancia en nuestro día a día. Esto hace que sea habitual que en las conversaciones de arquitectura con nuestros clientes surja debate alrededor de la pregunta “¿Deberíamos comenzar a usar kubernetes?”.

Claramente el uso de kubernetes nos dará unas ventajas prácticamente de manera inmediata, especialmente hablando de aplicaciones y servicios web que es dónde más trabajamos. Algunos ejemplos son:

• Grandes capacidades de orquestación
• Facilidad de despliegue con rolling update de manera nativa y automática
• Posibilidad de usar servicios gestionados como Amazon Elastic Kubernetes Service, Azure Kubernetes Service, Google Kubernetes Engine, DigitalOcean Kubernetes, etc.
• Grandes posibilidades de automatización de despliegues existentes o para nuevos servicios, etc.

Necesidades para trabajar con kubernetes

Para responder a esta pregunta vamos a exponer lo que para nosotros, de manera objetiva,  es necesario cuando se decide trabajar con kubernetes:

Cambios de paradigma, de servidores a contenedores

El uso de kubernetes conlleva el uso de contenedores y aquí hay un cambio de paradigma importante al dejar de usar servidores.

Este cambio de paradigma requiere de un cambio cultural en el equipo de desarrollo para no caer en el error de usar los contenedores como si se tratasen de máquinas virtuales.

Aplicaciones stateless

En kubernetes existe la posibilidad de usar persistencia de datos mediante el uso de volúmenes persistentes y statefulsets, sin embargo, la naturaleza de contenedores es efímera y hace que si queremos sacar partido real a esta tecnología, nuestra aplicación deba ser en general stateless, es decir, que no requiera en ningún caso de persistencia a disco o memoria en la parte servidor para poder completar sucesivas peticiones.

Esto no quiere decir que no podamos tener sesiones o datos de usuario o de aplicación, pero deben ser externos en todo momento al contenedor que ejecuta nuestra aplicación. 

Para conseguir esto podemos usar por ejemplo las siguientes soluciones comunes:

• Gestionar las sesiones con redis
• Usar configuraciones basadas en configmaps
• Utilizar almacenamiento de objetos tipo Amazon S3 o similar

Posibilidad de ejecución en paralelo

Normalmente si conseguimos que nuestra aplicación sea stateless no será problema, suele ser una consecuencia de ello.

Aún así, no está de más recalcar que si queremos disponer de alta disponibilidad real, necesitaremos al menos 2 pods de cada uno de nuestros servicios y por ello cada una de nuestras imágenes deberá permitir tener N instancias ejecutándose a la vez de manera balanceada.

Ciclo de desarrollo

Para poder usar kubernetes de manera exitosa es necesario que la imagen que usamos para lanzar nuestros contenedores sea la misma desde nuestro entorno de desarrollo local hasta nuestro entorno de producción, pasando por todos los entornos intermedios que tengamos para testing, qa, etc.

Esto hace necesario que:

• La imagen esté preparada para funcionar en todos los entornos por los que vaya ejecutándose la imagen
• Sabiendo de antemano que en la mayoría de los casos todos los entornos no serán idénticos a producción, deberían serlo al menos y en la medida de lo posible a nivel lógico
• Todo el equipo de desarrollo debe trabajar con contenedores y, para facilitar esto, debe automatizarse muy bien la gestión de creación de imágenes con respecto a los repositorios de código con un sistema de CI/CD o similar
• El despliegue entre entornos también debe estar automatizado siempre que se pueda, y debemos olvidarnos de hacer cambios en producción de manera manual

Tecnología joven

La versión 1.0 de kubernetes se lanzó el 21 de julio de 2015, esto hace que a día de hoy todavía sea una tecnología muy joven y con una evolución rapidísima.

Se lanzan nuevas versiones cada poco tiempo y, en muchos casos, la mayoría de  funcionalidades quedan obsoletas rápidamente y desaparecen poco después. Es tan agresivo esto, que incluso los 3 proveedores grandes de cloud público, obligan a subir la versión de los cluster de kubernetes cada pocos meses, pues retiran el soporte de versiones anteriores.

Todo esto conlleva:

• Disponer de nuevas funcionalidades y mejora de las actuales de manera muy rápida
• Gran posibilidad de encontrar bugs en diferentes partes del trabajo con kubernetes, quizás no tanto en el funcionamiento de éstos en sí, pero sí en componentes como controladores de balanceadores, drivers y similares que son básicos para la buena gestión del cluster
• Requisito continuo de formación en muchos componentes y adaptación rápida al cambio

Conclusión

Por tanto, volviendo a la pregunta que planteamos más arriba, nuestra recomendación objetiva es que pasar a usar kubernetes a nivel productivo será una muy buena decisión siempre que:

• Ya hayas hecho el tránsito en el desarrollo de tus aplicaciones a contenedores teniendo en cuenta que sea stateless y todo su ciclo de desarrollo
• Estés dispuesto a invertir tiempo en formar a tus equipos
• Seas capaz y estés dispuesto a gestionar cambios en infraestructura (objetos de kubernetes, cambios de versiones, etc.) de manera ágil y continua

Por supuesto hay muchas más cosas a tener en cuenta, algunas no tan objetivas, pero eso lo dejamos para comentarlas cuando quieras en otro artículo, en eventos, tomando algo o en una videoconferencia ;-).