[NSX ALB] AUTOREGISTRANDO SERVICIOS DE KUBERNETES USANDO AKO (LICENCIA ENTERPRISE)

[NSX ALB] AUTOREGISTRANDO SERVICIOS DE KUBERNETES USANDO AKO (LICENCIA ENTERPRISE)

¡Hola a todos!

Volvemos con las pilas cargadas después de un pequeño y merecido parón por verano.

Una de las grandes ventajas de usar AKO (AVI Kubernetes Operator) como ingress controller en nuestro entorno, es que proporciona al balanceador una visibilidad completa a nivel de capa 7 de lo que tenemos desplegado dentro de Kubernetes, incluyendo el hostname que hemos dado a nuestros microservicios.

En este post, me gustaría mostraros cómo utilizar AVI como proveedor de DNS para poder autoregistrar tanto los servicios de capa 4 (LoadBalancer) como los servicios de capa 7 (Ingress) que decidamos exponer desde nuestro cluster de Kubernetes, adicionalmente iremos un paso más allá y crearemos una delegación en nuestro DNS principal para aquellos servicios que queramos exponer a usuarios finales.

Prerequisitos:

  • Un entorno Kubernetes (Standalone, Tanzu, Openshift…)
  • NSX Advanced Load Balancer (AVI) con licencia enterprise
  • Enrutamiento entre el ALB y el DNS corporativo
  • AVI Kubernetes Operator (AKO) Instalado en nuestro cluster
Paso 1: Creando un servicio de DNS interno en el balanceador:

El primer paso será crear un servicio de DNS interno en el NSX ALB, este servicio responderá a las peticiones DNS que se hagan hacia la VIP del mismo.

1.1 Creando un perfil de IPAM

En primer lugar, nos dirigiremos a la sección de Templates – IPAM/DNS Profiles y escogeremos DNS Profile

Este perfil contendrá todos los dominios donde AVI responderá a peticiones DNS, en nuestro caso registraremos dos:

  • sd-juan.es – Accesible por todos aquellos clientes que apunten al DNS interno.
  • prod.sd-juan.es – Haremos una delegación de este dominio en el DNS externo corporativo de manera que los usuarios finales puedan llegar a él.

Una vez realizado pulsaremos «Save», iremos a Infraestructure – Clouds y editaremos la configuración de nuestra nube, añadiendo el perfil que acabamos de crear:

1.2 Creando un servicio virtual de DNS

El siguiente paso será crear un servicio virtual de DNS, para ello iremos a Applications – Virtual Services – Create Virtual Service – Advanced Setup

En el wizard escogeremos:

  • VS VIP: La VIP que queremos designar para el servicio de DNS, podremos escoger que se auto-asigne desde uno de nuestros pools de VIPs o bien crearla de manera estática.
  • Application Profile: Escogeremos System-DNS (Esto cambiará automáticamente el TCP/UDP Profile)
  • Pool: Tenemos la posibilidad de crear un pool con nuestros servidores DNS externos de manera que se utilicen como DNS-Relay (AVI hará un forward hacia estos DNS con todos los dominios que no conozca de manera nativa)

Acto seguido procederemos a pulsar «Next» hasta el final (podemos customizar muchas más opciones en el wizard, pero sale fuera del objetivo de este tutorial)

Nuestro servicio de DNS estará creado:

1.3 Habilitando AVI como DNS Provider

El último paso de esta sección será configurar AVI como DNS Provider, haciendo referencia al servicio recién creado. Para ello iremos a Administration – DNS Service – DNS Virtual Services y escogeremos nuestro servicio:

Una vez realizados estos pasos, ya tendremos nuestro balanceador preparado para dar servicios de DNS.

Paso 2: Exponiendo servicios desde kubernetes y probando el DNS Interno

En este paso, expondremos un ingress (capa 7) desde kubernetes y verificaremos que éste auto-registra en el DNS interno, para esta prueba he desplegado un pod de nginx llamado nginx-dev y expuesto su correspondiente servicio, por lo que procederemos a la creación de un ingress apuntando hacia nginx-dev.sd-juan.es como muestro a continuación:

Aplicaremos el yaml y verificaremos la correcta creación del ingress:

En el ALB podremos verificar como se ha creado el VS correspondiente y que este recibe correctamente el «APP Domain Name»

Por último, probaremos a lanzar un nslookup desde nuestra máquina utilizando como servidor DNS la VIP del servicio DNS configurado en AVI:

La resolución es correcta, de manera que en aquellos equipos en los que configuremos esta VIP como servidor DNS, podremos resolver automáticamente todos aquellos servicios e ingress que expongamos desde kubernetes.

Paso 3: Creando una delegación en el DNS corporativo para exponer servicios productivos

En los pasos anteriores, configuramos AVI como DNS Interno y verificamos como los servicios expuestos se registraban de manera automática en el. Pero, ¿y si queremos exponer servicios sin tener que modificar la configuración de DNS de todos los usuarios finales?, ¿y si además no queremos que puedan resolver direcciones correspondientes a entornos de desarrollo o preproducción?

En ese caso, delegaremos en nuestro DNS principal el dominio *.prod.sd-juan.es hacia AVI.

3.1 Creando la delegación en el DNS principal

En mi caso, el DNS que utilizo como «DNS Corporativo» está basado en Windows Server, por lo que los pasos a seguir son los siguientes:

  • En la consola de administración del servidor abrimos DNS
  • En «Zonas de búsqueda directa» escogemos nuestra zona, hacemos click derecho y escogemos «Nueva delegación»
  • El wizard se abrirá e introduciremos el nombre del dominio a delegar.
  • Pulsaremos siguiente, y posteriormente «Agregar…», en la ventana que se abrirá introduciremos la VIP del servicio DNS creada en el paso 1 y pulsaremos «Resolver» Ignoraremos el error de validación y pulsaremos aceptar
  • Por ultimo pulsamos en finalizar y nuestra delegación estará lista.
3.2 Exponiendo servicios y alcanzándolos con el DNS principal 

Para la siguiente prueba, mantendremos el ingress creado en el paso 2 «nginx-dev.sd-juan.es» y crearemos un nuevo pod de nginx, llamado nginx-prod.

Expondremos este pod y crearemos un ingress apuntando hacia nginx-prod.prod.sd-juan.es

Posteriormente trataremos de resolver ambos hosts desde el DNS Corporativo.

Una vez creado el nuevo ingress, abrimos un CMD desde el equipo de un usuario.

En primer lugar trataremos de llegar a nginx-dev.sd-juan.es sin éxito

Sin embargo, si tratamos de llegar al nginx de producción…

Eureka! Nuestro servicio productivo será alcanzable mediante el DNS corporativo, mientras que nuestro servicio de desarrollo sólo será alcanzable desde el DNS Interno.

Como siempre, ¡Mil gracias por leerme y espero que este contenido os resulte de utilidad! No dudéis en dejar un comentario o contactar conmigo para cualquier duda o sugerencia.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.