Despliega tus aplicaciones en Kubernetes con Helm (I)

Publicado por SSCC el

KubernetesHelm

Kubernetes es el nuevo kernel para los sistemas distribuidos. Nos permite abstraer una serie de aspectos no funcionales como son el service discovery y load balancing, el escalado y elasticidad de nuestras aplicaciones, self-healing, etc... y además define un interfaz uniforme que nos permite desplegar workloads de forma transparente al usuario.

Pero la gestión de versiones a desplegar, su empaquetado, su proceso de release (forward/rollback/upgrade), etc... genera una serie de retos a tener muy presentes cuando nos encontramos en entornos maduros de CI/CD.

En este primer artículo de la serie de Helm, vamos a aprender a instalarlo, cómo buscar charts en repositorios y cómo desplegar una aplicación de ejemplo.

¿Qué es Helm?

Helm es una herramienta que se utiliza para la gestión de paquetes Kubernetes. Estos paquetes se denominan charts.
Un chart es una colección de ficheros que describen a un conjunto de recursos del API de Kubernetes.
Lo podríamos entender como el apt/yum/homebrew de Kubernetes.

Con helm podemos:

  • Empaquetar nuestras aplicaciones como charts.
  • Interactuar con repositorios de charts (públicos o privados)
  • Instalar y desinstalar charts en nuestros clusters de Kubernetes.
  • Gestionar el ciclo de vida de despliegue de charts que han sido instaladas con Helm.

Arquitectura de Helm

Helm tiene dos componentes principales:

El cliente Helm es un CLI que es responsable de las siguientes acciones:

  • Desarrollo local de charts
  • Interactuar con Tiller server
  • Instalar charts
  • Preguntar por el estado de las releases
  • Solicitar el upgrade o uninstall de releases existentes

El segundo componente es Tiller. Tiller es la pieza que actúa como servidor de Helm y es desplegada en Kubernetes.
Tiller interactúa con el cliente Helm y a su vez con el API de Kubernetes. Tiene las siguientes responsabilidades:

  • Escuchar las peticiones del cliente Helm
  • Combinar un chart y la configuración para construir una release
  • Instalar charts en Kubernetes y ser capaz de hacer tracking de las siguientes releases
  • Hacer upgrade o desinstalar charts existentes en el cluster de Kubernetes

A modo resumen el cliente es responsable de gestionar los charts y el servidor es responsable de gestionar las releases

Instalación de Helm

Para facilitar el proceso de instalación sobre Kubernetes vamos a utilizar minikube y requiere tener instalado [VirtualBox].(https://www.virtualbox.org/wiki/Downloads)

Minikube (macOS)

Lo instalamos mediante brew:

brew cask install minikube

Comprobamos que tenemos instalado kubectl:

$ kubectl config current-context minikube

Si no lo instalamos:

brew install kubernetes-cli

Para el resto de plataformas, más información en este enlace.

Arrancamos minikube (esto puede tardar unos minutos):

minikube start

Levantamos el dashboard:

minikube dashboard

Deberíamos poder ver el dashboard:

Helm (macOS)

brew install kubernetes-helm

Para el resto de plataformas más info en este enlace.

Instalamos Tiller

helm init

Comprobamos que tiller ha sido desplegado y está running (tardará unos segundos):

kubectl get pods --namespace kube-system -w

Cuando veamos tiller-deploy-XXX-YYY ready (1/1), pulsamos Ctrl-C.

Instalación de nuestro primer Chart

Helm viene preconfigurado con el repositorio oficial de charts. Para buscar charts del repositorio:

helm search

Esto nos devuelve una lista de charts:

Como chart de ejemplo vamos a instalar Wordpress con MariaDB.

Como estamos desplegando sobre minikube y para facilitar su acceso vamos a habilitar el addon de ingress

minikube addons enable ingress

kubectl get pods --namespace kube-system -w

Cuando veamos nginx-ingress-controller-XXX-YYY ready (1/1), pulsamos Ctrl-C.

Para instalar nuestro primer helm, ejecutamos:

helm install --name enmilocalfunciona \ --set ingress.enabled=true,ingress.hosts[0].name=enmilocalfunciona-wp.local,wordpressUsername=enmilocalfunciona,wordpressBlogName=enmilocalfunciona \ stable/wordpress

¿Qué hemos hecho?

  • helm install: lanza la instalación del chart
  • --name enmilocalfunciona: es el nombre de nuestra release
  • --set ingress.enabled=true,ingress.hosts[0].name=enmilocalfunciona-wp.local,wordpressUsername=enmilocalfunciona,wordpressBlogName=enmilocalfunciona: Estamos haciendo overwrite de algunas variables que podemos consultar en este enlace

Esperamos un par de minutos para que esté disponible MariaDB y Wordpress:

kubectl get pods --all-namespaces -w

Cuando veamos enmilocalfunciona-mariadb-0 y enmilocalfunciona-wordpress-XXX-YYY ready (1/1), pulsamos Ctrl-C.

Añadimos una entrada a nuestro /etc/hosts para hacer el binding entre el nombre de host que hemos creado en ingress y la ip de minikube:

echo "$(minikube ip) enmilocalfunciona-wp.local" | sudo tee -a /etc/hosts

Accedemos a Wordpress

http://enmilocalfunciona-wp.local/

Para acceder a la consola admin:

http://enmilocalfunciona-wp.local/admin

Si queremos borrar la release, podemos:

helm delete enmilocalfunciona

Para borrar el clúster:

minikube delete

Conclusiones

En esta primera entrega de la serie de artículos acerca de Helm, hemos aprendido qué es Helm y cómo dar nuestros primeros pasos instalándolo sobre k8s (minikube) con un chart de ejemplo.

En la siguiente entrega veremos como crear un chart con un microservicio de ejemplo que almacenaremos en un repositorio de charts (chartmuseum y monocular) y que desplegaremos sobre nuestro cluster de Kubernetes.

Esperamos que os haya parecido interesante esta entrega y ... ¡stay tuned para las siguientes!