Configurar nginx-ingress en k8s

Índice de contenidos

• 1. Entorno
• 2. Introducción
• 3. Vamos al lío
• 4. Conclusiones

1. Entorno

Este tutorial está escrito usando el siguiente entorno:

• Hardware: Slimbook Pro 2 13.3″ (Intel Core i7, 32GB RAM)
• Sistema Operativo: LUbuntu 18.04
• Kubernetes 11.1.1

2. Introducción

Ya sabemos que Kubernetes es el estándar de facto para el despliegue de aplicaciones y que estas aplicaciones, por lo general, necesitan una forma de acceder a ellas desde un dominio definido en una URL.

Kubernetes para esto tiene el concepto de Ingress que permite definir que una aplicación va a responder en una determinada URL y se va a encargar de gestionar el balanceo entre las distintas instancias. El Ingress puede ser implementado de diversas formas pero una de las más utilizadas es a través de nginx.

3. Vamos al lío

La forma más sencilla de conferir a Kubernetes la capacidad de hacer ingress a través de nginx es instalándolo a través de un Chart con Helm.

Helm es el gestor de paquetes instalables de Kubernetes llamados Charts y su instalación se realiza en la máquina cliente con el siguiente comando:

$> curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash

Para autoconfigurarlo solo tenemos que ejecutar:

$> helm init

Con esto ya estamos listos para instalar el Chart de nginx-ingress con el siguiente comando:

$> helm install --name nginx-ingress stable/nginx-ingress

Este comando dentro de AWS nos va a crear un "Load Balancer" el cual vamos a utilizar como punto de entrada de todas nuestras aplicaciones. Cuando éste recibe una petición comprueba en su configuración a que servicio de Kubernetes tiene que llamar. Esto nos permite poder definir los servicios de tipo ClusterIP y no LoadBalancer, lo segundo provocaría en AWS la creación de un "Load Balancer" por cada uno de los servicios desplegados, lo que puede aumentar y mucho nuestro gasto en AWS.

También podemos utilizar esta configuración para servir nuestras aplicaciones en HTTPS sin que el desarrollador se tenga que preocupar de configurar nada de HTTPS en su aplicación, actuando de proxy inverso.

Para ello tenemos que crear un secreto en Kubernetes con la información de nuestro certificado. Para el caso de certificados con Let’s Encrypt este podría ser comando para crear el secreto:

$> kubectl create secret tls secure-tls --key /etc/letsencrypt/live/tudominio.org/privkey.pem --cert /etc/letsencrypt/live/tudominio.org/fullchain.pem -n  (en cada namespace donde se vaya a utilizar)

Nota: aconsejo crear un certificado general con el wildcard *.tudominio.org y utilizarlo en todas las aplicaciones siendo éstas subdominios del principal.

De esta forma podemos crear un fichero ingress.yaml con el siguiente contenido:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: devops-demo-ci
  namespace: devops
  labels:
    app: demp-ci
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  rules:
  - host: devops-demo-ci.tudominio.org
    http:
      paths:
      - path: /
        backend:
          serviceName: devops-demo-ci
          servicePort: 80
  tls:
  -  secretName: secure-tls
     hosts:
     - devops-demo-ci.tudominio.org

Las partes importantes de este fichero de definición son: la sección de "annotations" donde establecemos que vamos a utilizar nginx como controlador del ingress y que forzamos a que la comunicación sea siempre por https; la sección "spec" donde definimos la configuración del ingress: cuál va ser su URL, a qué servicio va a llamar, que puerto va a utilizar, y la sección "tls" donde espeficamos el host y que el certificado a utilizar a través del secreto antes creado.

De esta forma solo nos quedaría configurar nuestro proveedor de DNS para añadirle el hosts apuntando al balanceador. Esto en AWS se hace en el servicio Route53 creando un "Record Set" de tipo "A – IPv4 address" con el tipo "Alias" apuntando al balanceador creado a la hora de instalar el controlador de ingress.

Nota: este último paso se puede automatizar con ExternalDNS, pero esto da para otro tutorial.

4. Conclusiones

Con esta sencilla técnica ya podemos crear todos los entornos de producción y prueba que necesiten nuestras aplicaciones desplegadas con Kubernetes, optimizando costes.

Cualquier duda o sugerencia en la zona de comentarios.

Saludos.