En colaboración con: Santiago Yepes.

Saludos amigos Kubernetes aficionados, este artículo se basa en  el capítulo #45 de la serie La Hora de Kubernetes, donde aprenderemos a realizar un Continuous Delivery en Kubernetes con Flux.

Flux es un conjunto de herramientas que nos permite mantener sincronizados nuestros clústers de Kubernetes o las aplicaciones de nuestro clúster y automatizar actualizaciones cuando exista un nuevo código para desplegar.

En este capítulo estaremos revisando la versión #2, que fue construida para integrarse con Prometheus y otros componentes nucleares del ecosistema de Kubernetes. Esta versión se encontrará disponible para todos dentro de muy poco.

¿Para qué y para quién sirve Flux?

Sus tres potenciales usuarios son los operadores de clústers, que se encargan de proveer, configurar y actualizar los clústers en la medida que sean necesarias estas actualizaciones; los ingenieros de plataforma también utilizan esta herramienta para construir sistemas de “Continuous Delivery” para las herramientas de los programas que utilizan los desarrolladores y así estos trabajen de forma actualizada y segura; los desarrolladores también mantienen la última versión de los desarrollos en producción.

Características

Repositorios Git, Helm y bucket S3 – Compatibles como fuente de la verdad (o fuente de configuración); dependiendo del tipo de fuente que escojamos, nos veremos en la tarea de configurarlos.

Soporte de Kustomize y Helm para generar y soportar los manifiestos.

Reconciliación periódica, donde definiremos cada cuánto y de qué forma queremos que se reinicien nuestras fuentes y se actualicen nuestros clústers o aplicaciones dentro de nuestros clústers.

Usa RBAC (Role-Based Access Control) para integrarse con Kubernetes, esto es un mecanismo para conceder permisos o acceso a recursos de cómputo o de redes dentro del clúster.

Webhooks (senders and receivers). Los senders nos servirán para comunicarnos con herramientas externas y de esta manera, enviar notificaciones a las aplicaciones y los receivers, en donde podemos recibir información de sistemas externos para nosotros hacer alguna operación.

Compatible con los Git providers más conocidos (GitHub, GitLab, BitBucket). Incluso, si deseáramos configurar otra implementación diferente, podríamos establecer una configuración sin ningún problema.

Actualización autómatica de imágenes. Podemos ver si una imagen que nosotros marcamos como objetivo ha cambiado (escaneo y parcheo de imágenes).

Compatibilidad con herramientas de integración continua, tales como GitHub Actions, Tekton o Argo.

Conceptos básicos

GitOps. Esta es una forma de mantener actualizado nuestro clúster. Digamos que es un reinicio periódico que trata de eliminar “malas interpretaciones”. Podemos fácilmente ver la historia de todos los estados pasados que nosotros deseemos y la comunicación que nos guía a estos estados (es decir, quién lo hizo, qué hizo y por qué lo hizo).

⦁ Sources (Git Repositories, Helm Repository, Helm Chart, Bucket). O fuentes, definen el origen de un repositorio conteniendo el estado deseado del sistema y los requerimientos para obtenerlo.

Sources produce un artefacto (artifact) que es consumido por otros componentes de Flux para ejecutar acciones, como aplicar contenidos del artefacto en un clúster. Una fuente (source) puede ser compartida por múltiples consumidores para deduplicar la configuración y/o almacenamiento.

⦁ Reconciliation (Helm Release, Bucket reconciliation, Kustomization). Esto se refiere a asegurar que un estado dado (como una aplicación corriendo en un clúster, infraestructura) conecte un estado deseado definido declarativamente en algún lugar, como por ejemplo, un repositorio Git:

  1. HelmRelease reconciliation: asegura que el estado del lanzamiento de Helm conecte con lo que se define en el resource, ejecuta un lanzamiento si este no es el caso.
  2. Bucket reconciliation: descarga y archiva los contenidos del bucket declarado en un intérvalo dado y lo almacena como un artefacto, guarda la revisión observada del artefacto y el mismo artefacto en el estado del recurso.
  3. Kustomization reconciliation: asegura el estado de la aplicación desplegada en un clúster conecte con los recursos definidos en un repositorio Git o S3 bucket.

⦁ Kustomization. El recurso personalizado de kustomization representa una localidad de recursos de K8s que Flux es supuesto a reconciliar en el clúster. La reconciación corre cada minuto por defecto, sin embargo puede ser modificado.

⦁ Bootstrap. Es el proceso de instalar los componentes de Flux en una forma de GitOps. Estos manifiestos son aplicados al clúster, un GitRepository y Kustomization son creados por los componentes de Flux, luego los manifiestos son llevados o empujados a un repositorio Git existente o nuevo en caso de que no exista uno o se desee crear otro.

Demo

En el siguiente vídeo que hemos preparado para ti, aprenderás cómo realizar un Continuous Delivery en Kubernetes con Flux, ¡No te lo pierdas!

Conclusiones

Flux es una herramienta basada en un set de Kubernetes API extensiones (“recursos personalizados”), que controlan cómo los repositorios git y otras fuentes de configuración son aplicadas en el clúster (sincronizadas).

Recordemos que esta herramienta puede ser empleada por operadores de clúster, ingenieros de plataforma y desarrolladores de aplicaciones. Tiene compatibilidad con los Git providers más conocidos (GitHub, GitLab, BitBucket) pero también puedes emplear la configuración de tu gusto.

En este artículo también aprendimos sobre los conceptos principales para comprender mejor el manejo de esta herramienta, como GitOps, Sources, Reconciliation, Kustomization y Bootstrap.

Si deseas sumergirte en el tema y obtener más información, te puedes dirigir a nuestro Canal Cuemby en YouTube, nuestra comunidad está creciendo y nuestro equipo está dispuesto a ayudarte. ¡No dudes en enviarnos un mensaje en cualquier momento con tus preguntas y nos aseguraremos de responder!

¡Gracias por visitar nuestro blog! Si te gusta lo que lees, suscríbete.