No cabe duda de que Jenkins es la opción
numero 1 cuando se piensa en automatizar el despliegue de aplicaciones en un clúster
Kubernetes. Existen cada vez más opciones (aparte de Jenkins) y más orientadas
a Kubernetes Jenkins (Jenkins esta para automatizar cualquier cosa). En este post particularizo en Jenkins, pero los puntos que se exponen a continuación se pueden
extrapolar a la mayoría de los mecanismos de automatización.
Cuando una empresa piensa en automatizar sus
tareas de desarrollo con Jenkins y tener una estrategia de CI/CD para
despliegue en un clúster de Kubernetes una de las primeras preguntas es ¿El
Jenkins se despliega en un pod dentro de algún namespace del clúster de
Kubernetes o fuera del cluster de kubernetes con alguna otra solución?
Vamos a analizar puntos relevantes para tomar esta decisión
Modo de instalación y mantenimiento
Para desplegar en Jenkins en el cluster de Kubernetes se deberán crear los ficheros que creen los objetos Kubernetes correspondientes (deployment, Pod, configmaps,etc..) mientras que en una maquina fuera del cluster de kubernetes se puede instalar de cualquier manera (incluso usando tecnologías de contenedores como docker que utilizan métodos parecidos a los usados por Kubernetes). Por lo que este punto las cuestiones son:
- Se va a usar imágenes para las aplicaciones de mi negocio (ya que se quieren desplegar en un cluster de kubernetes) pero ¿quiero una solución basada en imágenes para todos los elementos de TI? Recordemos que Jenkins no es para negocio, es para los técnicos.
- ¿Existe alguna normativa en la empresa que me obliga a seguir un procedimiento determinado? ¿Ese procedimiento es incompatible con el despliegue en un clúster de kubernetes?
- El equipo técnico ¿se tiene más conocimiento en algún tipo de instalación diferente al de kubernetes y se identifica como más fiable?
- Analizar el mantenimiento de Jenkins como aplicación (ampliar recursos, plugin, tolerancia a fallos, etc..). Tras analizarlo ¿se ajusta mejor desplegarlo en un clúster de kubernetes o fuera del clúster de kubernetes?
Explotación
En este punto si que estoy claramente en contra de desplegar Jenkins en el clúster de kubernetes (pero esta es mi opinión y pude no ajustarse a la realidad de la organización) por los siguiente:
- En un clúster de kubernetes, por regla general, se deben desplegar aplicaciones que sigan la filosofía de microservicios (es decir, ligeras que van a requerir escalado, etc..) y Jenkins no sigue dicha filosofía.
- En un clúster de kubernetes, los pods luchan por lo recursos y Jenkins es una aplicación que va a “dar guerra” cuanto mas se use por lo que no se puede justificar el hecho de que no funcione una aplicación en el clúster de kubernetes porque esta Jenkins.
Este punto cabria en el anterior, pero me lo
he encontrado en tantas ocasiones cuando he tenido que implantar Jenkins en una
organización que prefiero destacarlo a parte. Si se cae el clúster de
kubernetes ¿Merece la pena que siga funcionando Jenkins? La respuesta es sí por
dos grandes motivos:
- No todas las tareas que se incluyan en Jenkins tienen porque actuar sobre el clúster de kubernetes por lo que si desplegamos Jenkins en el cluster de kubernetes estamos perdiendo esa funcionalidad.
- Los clústeres de kubernetes son un sistema muy robusto y raramente he visto un cluster de kubernetes caerse. El clúster de kubernetes, antes de caerse, hace que las aplicaciones no funcionen (los famosos estados “Evicted” de los pods) por falta de recursos. Pero se puede seguir trabajando con ellos. Es decir, si Jenkins esta desplegado en un clúster de kubernetes y este cluster entra en este estado entonces Jenkins no funcionaría, pero si estuviera fuera del cluster de kubernetes podría seguir trabajando con Jenkins y Jenkins atacando al cluster de kubernetes. El gran problema sería que no veríamos las aplicaciones que Jenkins a desplegado en el clúster de kubernetes, pero estas aplicaciones están declaradas en el cluster y una vez solucionado el problema de los recursos del cluster de kubernetes todo funcionar correctamente, por lo que nunca se ha perdido la funcionalidad.
