Hola a todos, y bienvenidos nuevamente a este blog.  Es esta oportunidad hablaremos un poco de Kubernetes, y de como instalar y configurar HAProxy como Ingress Controller.

Un Ingress Controller en Kubernetes permite el uso de recursos de tipo Ingress, los cuales a su vez permiten el acceso externo a aplicaciones desplegadas en un cluster de Kubernetes.  Un Ingress Controller puede ser de mucha utilidad en entornos donde no contamos con Load Balancers soportados nativamente por Kubernetes, como los provistos por servicios de Cloud como AWS, Azure o GCP.  También pueden ser de gran ayuda cuando, a pesar de contar con Load Balancers soportados por Kubernetes, queremos limitar su uso, para de esta manera reducir los costos.

Por ejemplo, en un entorno AWS EKS, cada app con acceso externo podria utilizar su propio Load Balancer, lo cual porsupuesto tiene un costo mensual.   En cambio, con un Ingress Controller podemos publicar cada aplicacion con un recurso Ingress separado, sin pagar adicionalmente por estos, y luego tener un unico Load Balancer global con multiples VIPs para acceder a los distintos servicios publicados por dicho Ingress.

 

Lista de materiales

Para poder desplegar HAProxy, debemos contar al menos con lo siguiente:

• Un cluster de Kubernetes
• La herramienta de linea de comando HELM
• La herramienta de linea de comando kubectl

Instalación de HAProxy

Ya luego, el procedimiento de instalación es bastante sencillo:

• Añadimos el repositorio Helm de HAProxy Technologies

• Actualizamos la lista de charts

• Instalamos HAProxy Ingress Controller.  Como vemos en el comando a continuacion, es posible indicar:
  • La creación de un namespace para la instalación de HAProxy
  • Con los parámetros “–set controller.service.nodePorts.http”, “–set controller.service.nodePorts.https” y “–set controller.service.nodePorts.stats”, es posible personalizar el puerto NodePort utilizado por HAproxy para el trafico HTTP, HTTPS y estadisticas.
  • Por defecto HAProxy se despliega como un Deployment, pero es posible configurarlo también como un DaemonSet con los parametros “–set controller.kind=DaemonSet” y “–set controller.daemonset.useHostPort=true”

 

• Verificamos los pods y servicios desplegados con la instalación de HAProxy

 

Uso de HAProxy como Ingress Controller

Ahora que ya tenemos HAProxy desplegado, es la hora de comenzar a utilizarlo, y para esto desplegaremos una serie de recursos de Kubernetes:

• Deployment, que nos permite desplegar 1 o más pods para una aplicacion especifica.
• Service de tipo ClusterIP, que nos permite publicar esta aplicacion internamente en el cluster, para ser consumido por otrás aplicaciones o servicios.  Un Service de tipo ClusterIP funciona como una especie de Load Balancer para los Pods internamente en el clúster de Kubernetes.  Importante además recordar que un Service de tipo Cluster IP NO PROVEE por si mismo acceso externo a los Pods/Apps.
• Ingress, que nos permite utilizar un Ingress Controller para proveer de acceso externo a un Service.  Este Ingress además puede indicar que Ingress Controller se va a utilizar, en caso de que existan multiples Ingress Controllers en el cluster K8s.

En este caso, he desplegado 4 deployments, cada uno desplegando una app distinta, utilizando para esto algunos ejemplo provistos por KodeKloud.  Uno de estos Deployments lo podemos ver en el siguiente YAML file:

 

 

Lo siguiente entonces es crear un Service por cada applicación que queramos publicar a través del Ingress Controller.   Aqui un ejemplo de un Service para una de las apps que estoy utilizando en este ejemplo:

 

Finalmente creamos un recurso de tipo Ingress, que nos permite utilizar el Ingress Controller HAProxy para proveer acceso externo al Service que creamos en el paso anterior.

 

 

Verificar accesos

Ahora solo nos queda verificar que podamos acceder de manera externa a nuestras aplicaciones, en este caso a través de un navegador.  Verificaremos el acceso a las 2 aplicaciones que hemos configurado en el ingress utilizando una URL de tipo http://ip_cualquier_worker:puertoingresscontroller/path

• http://172.20.10.134:30000/watch
• http://172.20.10.134:30000/wear

Vemos en los siguientes screenshots que todo funciona como se espera:

 

Porsupuesto, en un entorno productivo y de cara a los usuarios, dichas URL nos son muy apropiadas al no ser suficientemente amigables.  En este caso, por encima del cluster de Kubernetes debiera haber un servicio de Load Balancer o Proxy que permita acceder a estos ingress utilizando un FQDN personalizado, y las URL antes expuestas como Target para el tráfico.

Con ese completamos este procedimiento, espero que les sea de utilidad.