Acerca de Argo Rollouts

Hoy en día, es muy común desplegar aplicaciones utilizando contenedores Docker orquestados en Kubernetes. Este hecho ha facilitado en gran medida el despliegue de todo tipo de entornos, ayudando con su administración y visualización. Sin embargo, también es cierto que, debido al gran crecimiento de la industria, las herramientas proporcionadas por esta plataforma pueden no abarcar tantas facetas como nos gustaría.

Uno de los principales problemas es conseguir despliegues eficientes y seguros. No basta con que funcione correctamente en un entorno controlado; una vez desplegada, la nueva versión trae consigo una serie de riesgos asociados. Estos riesgos pueden no solo afectar al propio programa, sino también a los clientes que la utilizan. Para resolver este problema, existe como solución el controlador Argo Rollouts, cuyas características comentamos a continuación.

Características principales

Despliegue seguro

Argo Rollouts es una herramienta que permite seguir dos técnicas de detección de errores específicas, para ayudar a los contenedores a entregar nuevas versiones de manera progresiva. Esto significa que se controlará el tráfico de datos de forma que no afecte a la aplicación, permitiendo decidir cuál es el mejor estado de esta para su uso en producción.

Técnicas de detección

Canary strategy

Esta estrategia recibe su nombre de los canarios que, en el pasado, se utilizaban en las minas para advertir a los mineros sobre la presencia de gases peligrosos. De forma similar, la estrategia "canary" permite detectar errores de manera temprana durante el despliegue.

Lo que hace esta estrategia es lanzar gradualmente la nueva versión de la aplicación con una cantidad limitada de usuarios, incrementando paulatinamente el tráfico hacia la nueva versión mientras se reduce el tráfico hacia la versión anterior, hasta lograr un 100% de tráfico funcional en la nueva versión.

La idea detrás de esto es poder detener el despliegue de la nueva versión en caso de que no soporte correctamente el tráfico. Esto se puede hacer en cualquier fase de la implementación gradual, lo que ayuda a mitigar el impacto al reducir la cantidad de usuarios y peticiones afectadas en caso de fallo.

Se incrementa el tráfico de la nueva versión a la vez que se disminuye en la primera

Ahora utilizaremos Argo Rollouts con unos contenedores de prueba para mostrar el comportamiento de esta estrategia en funcionamiento. Primero, debemos actualizar la imagen que deseamos comprobar con el siguiente comando:

kubectl argo rollouts set image <nombre_rollout> <nombre_contenedor>=<nombre_imagen> 

Donde <nombre_rollout> es el nombre del rollout que tenemos almacenado, <nombre_contenedor> es el contenedor con nuestro despliegue y <nombre_imagen> es la nueva imagen con la versión deseada.

Una vez hecho esto, podemos realizar la estrategia automáticamente con:

kubectl argo rollouts promote <nombre_rollout>
 

Los pods van recibiendo el tráfico conforme pasan a revision:2

En caso de no estar satisfechos con los resultados, se puede abortar el proceso en cualquier momento

Si la aplicación no funciona como se espera, se puede hacer:

kubectl argo rollout abort <nombre_rollout>

Y así detener el proceso de actualización.

Adicionalmente, tenemos la posibilidad de actualizar el archivo que define la estrategia a utilizar por Argo Rollouts (en el caso del ejemplo, rollout.yaml) y personalizar aún más su funcionamiento. Por ejemplo, podemos especificar una pausa indefinida a la hora de actualizar la aplicación gradualmente. Así, avanzaremos con cada comando promote tanto como hayamos especificado, no de forma automática.

Ejemplo de archivo de estrategia Canary básico

Y no solo eso, sino que también podremos configurar un recurso de Ingress en Kubernetes para especificar con facilidad cómo debe enrutarse el tráfico de nuestra aplicación, exponiéndola sin tener que preocuparnos por el proceso. A partir de esta configuración, Argo Rollouts se encargará de realizar las mismas tareas de gestión de despliegue, con solo especificarle el Ingress que pensamos utilizar, a partir del parámetro stableIngress en la especificación del rollout.
 

Blue-green strategy

Esta estrategia tiene la misma función que la ya mencionada Canary, pero realizando la puesta en marcha con algunas diferencias. En este caso, en lugar de ir llevando el tráfico de la aplicación desde la versión antigua hasta la nueva, se crean dos entornos: uno en el que se encuentra la aplicación estable en su versión ya en producción (azul) y otro con la nueva que se quiere implementar (verde).
 
Una vez existen ambos, se testea la capacidad del entorno verde para comprobar si es tolerante a errores. Una vez testeado, se lleva todo el tráfico hacia el verde y el azul queda obsoleto. Esto la convierte en una estrategia más inmediata, pero también con mayor consumo de recursos, al necesitar el doble de infraestructura para funcionar.

Se generan dos entornos, uno en producción (azul) y otro en pruebas (verde)

Una vez tenemos levantado el entorno de producción, el nuevo se levantará automáticamente por Argo Rollouts al ejecutar la estrategia cuando se añada una nueva imagen:

Así se verían ambos entornos en Argo Rollouts

Podemos abortar el proceso con el mismo comando que en Canary

Los procesos de actualización y de cancelación del proceso serán los mismos que en Canary, además de que también podremos editar el archivo donde se almacena la estrategia para poder personalizarla.

¿Cómo funciona Argo Rollouts?

Argo Rollouts vs Pod Disruption Budgets

Los Pod Disruption Budgets (o PDB) de Kubernetes son un recurso utilizado para limitar el número de pods de una aplicación replicada que pueden ser interrumpidos de forma voluntaria, garantizando así una determinada cantidad de pods corriendo en la aplicación.
 
Esta funcionalidad, si bien se parece a lo que realiza Argo Rollouts, tiene objetivos y limitaciones diferentes. Para empezar, PDB no está enfocado a lanzar una nueva versión de la aplicación, sino a garantizar la estabilidad de esta durante su funcionamiento. Además, aunque permita el control básico respecto a la creación y eliminación de pods, no es suficiente como para replicar las estrategias de despliegue avanzadas para las que sí está capacitado Argo Rollouts.
 
Esto convierte a PDB en una opción complementaria a Argo Rollouts, otra manera de proteger el entorno de producción desde un ángulo distinto. Se pueden implementar ambas herramientas para garantizar la mayor estabilidad y seguridad posible.

Conclusiones

Hemos visto la utilidad de implementar esta herramienta junto a los despliegues con Kubernetes, y también hemos comprobado la facilidad con la que podemos adaptarla a nuestro proyecto. 
 
Argo Rollouts se presenta de manera sencilla y fuertemente personalizable, permitiendo, con un solo archivo yaml, introducir comprobaciones y analíticas que simplifican y facilitan los nuevos despliegues de nuestras aplicaciones en la nube. Esto convierte a Argo Rollouts en una herramienta clave para la gestión de despliegues eficientes y seguros.

¿Quieres saber más sobre Hunters?

Ser un hunter es aceptar el reto de probar nuevas soluciones que aporten resultados diferenciales. Únete al programa Hunters y forma parte de un grupo transversal con capacidad de generar y transferir conocimiento.

Anticípate a las soluciones digitales que nos harán crecer. Consulta más información sobre Hunters en la web.

Rubén Gadea
Técnico de Software
Altia