Configurar un Ingress Controller con Nginx, Helm y nip.io

Configurar un Ingress Controller con Nginx, Helm y nip.io

Cuando te hablé de utilizar un Ingress Controller para acceder a tus aplicaciones dentro de Kubernetes lo hice a través del camino fácil, con Minikube  Es el caso más sencillo porque no tienes que configurar casi nada, pero no se puede aplicar a cualquier clúster. Hoy quiero contarte cómo configurar un Ingress Controller con Nginx, Helm y nip.io.

Instalar Helm

Como te conté hace tiempo, Helm es un gestor de paquetes que te ayuda a desplegar recursos en tu clúster. Si todavía no lo tienes instalado puedes hacerlo a través de los siguientes comandos:

  
brew install helm@2
brew link --force helm@2

kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-role-binding --clusterrole cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --upgrade
 

Una vez que haya finalizado el proceso deberías de ver el pod tiller funcionando entre tus pods, en el namespace de kube-system.

Instalar el Ingress Controller a través del chart de Helm

El siguiente paso es crear el Ingress Controller. En este ejemplo también voy a utilizar Nginx y la forma de instalarlo es a través de este comando con Helm:

  
helm install --name ingress-controller --namespace ingress-controller stable/nginx-ingress
 

Para tener mi clúster organizado, le he especificado en el comando el namespace ingress-controller. Una vez finalice, podrás ver que ha creado un montón de objetos dentro de tu cluster, que de otra manera hubieras tenido que ir definiendo uno a uno.

Lo bueno es que el código del chart está disponible en GitHub, por lo que podrías revisar cada uno de los objetos e incluso utilizar el archivo values.yaml para modificar el comportamiento del chart si lo necesitaras.

Uno de los recursos que ha creado es el servicio ingress-controller-nginx-ingress-controller, que es el que nos dará acceso desde el exterior. Este se crea por defecto del tipo LoadBalancer. Esto significa que nuestro proveedor cloud nos dará una IP pública para el acceso. Para saber cuál es debes buscarla entre los servicios generados en el namespace ingress-controller:

  
➜  ~ kubectl get svc -n ingress-controller
NAME                                               TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
ingress-controller-nginx-ingress-controller        LoadBalancer   10.0.136.200   51.104.158.74   80:32376/TCP,443:32253/TCP   6m15s
ingress-controller-nginx-ingress-default-backend   ClusterIP      10.0.34.135    none          80/TCP                       6m15s
 

En mi caso se me ha asignado la IP 51.104.158.74. Si accedo a ella debería de responderme el backend por defecto con este mensaje:

Si accedes a la IP asignada al Ingress Controller te mostrará el backend por defecto

Esto significa que tu Ingress Controller está funcionando correctamente. Solo te falta crear los objetos Ingress para las aplicaciones que quieras exponer.

Creación del objeto Ingress con nip.io

Lo ideal es que cuando trabajes con Ingress y tus aplicaciones utilices diferentes dominios que hayas adquirido. Sin embargo, para entornos de prueba, tenemos una opción mucho más barata y súper util llamada nip.io. Lo que te permite es simular dominios, sin necesidad de estar tocando el archivo hosts, gracias a que nip.io redirigirá la llamada a la IP que utilices como parte del mismo, utilizando el hostname definido. Para este ejemplo voy a configurar un ingress para la API que utilicé en un post anterior, donde te explicaba cómo depurar una aplicación en Kubernetes desde local con Azure Dev Spaces.

  
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: booksapi
  namespace: bookstore
spec:
  rules:
  - host: booksapi.51.104.158.74.nip.io
    http:
      paths:
      - backend:
          serviceName: booksapi-svc
          servicePort: 80
        path: /
 

Como puedes ver, gracias a nip.io he podido crear un hostname, utilizando un nombre para identificar a mi aplicación (booksapi), la IP pública de mi Ingress Controller, al que quiero redirigirme, y por último .nip.io que es lo que hace la magia. Si intentas acceder a la API a través de http://booksapi.TU_IP.nip.io/api/books comprobarás que tienes tu aplicación disponible en Internet a través de un Ingress Controller con Nginx, gracias a Helm y nip.io.

¡Saludos!