Automatización del DNS multiclúster con NGINX Ingress Controller

Amir RawdatIngeniero de soluciones

Las aplicaciones no pueden cumplir su función si los usuarios no pueden encontrarlas. El sistema de nombres de dominio (DNS) es la tecnología de Internet que «encuentra» aplicaciones y sitios web traduciendo los nombres de dominio a direcciones IP. El DNS es tan omnipresente y fiable que la mayoría de los días ni siquiera se piensa en él. Pero cuando hay problemas con el DNS, todo se detiene. Garantizar que el DNS funcione es crucial para las aplicaciones modernas, especialmente en arquitecturas de microservicios, donde los servicios se inician y se detienen constantemente.

En una publicación anterior, hablamos de definir registros DNS para dos subdominios que corresponden a aplicaciones que se ejecutan en el mismo clúster (unit-demo.marketing.net para la aplicación de Marketing y unit-demo.engineering.net para la aplicación de Engineering) y que se resuelven en el mismo punto de entrada del clúster, es decir, la dirección IP externa del controlador de entrada NGINX del clúster. El enrutamiento mediante indicación del nombre del servidor (SNI) se configura en el controlador de entrada NGINX para autenticar y dirigir las conexiones a la aplicación correspondiente en función del nombre de dominio solicitado por los usuarios.

Sin embargo, muchas organizaciones necesitan ampliar ese caso de uso e implementar aplicaciones en varios clústeres de Kubernetes, que pueden estar distribuidos entre distintas regiones del proveedor de servicios en la nube. Para que el tráfico externo llegue a las nuevas regiones de los clústeres, es necesario crear zonas DNS que resuelvan a esas regiones.

Anteriormente, este proceso requería utilizar un proveedor externo (como GoDaddy o DNSExit) para crear manualmente un registro de dominio y actualizar los registros de host según correspondiera. Ahora, el proyecto ExternalDNS de Kubernetes automatiza el proceso haciendo que los recursos de Kubernetes se puedan detectar mediante servidores DNS públicos. Esto significa que se utiliza la API de Kubernetes para configurar una lista de proveedores de DNS.

Gracias a la integración entre ExternalDNS y NGINX Ingress Controller, puede gestionar los registros A de DNS de modo que los nombres DNS se deriven de los nombres de host declarados en un recurso Ingress estándar de Kubernetes o en un recurso personalizado VirtualServer de NGINX. Los desarrolladores y los equipos de DevOps pueden aprovechar esta integración en sus canalizaciones de CI/CD para detectar automáticamente aplicaciones en distintos clústeres, sin que intervenga el equipo de NetOps (que normalmente se encarga del DNS).

En este artículo, mostramos cómo utilizar los archivos de configuración de ejemplo de nuestro repositorio de GitHub para integrar ExternalDNS con NGINX Ingress Controller.

La arquitectura base

Para implementar ExternalDNS con NGINX Ingress Controller, partimos del caso básico en el que los desarrolladores configuran un controlador Ingress para exponer externamente las aplicaciones de Kubernetes. Los clientes no pueden conectarse a las aplicaciones hasta que el nombre de dominio configurado se resuelva en el punto de entrada público del clúster de Kubernetes.

NGINX Ingress Controller interactúa con el proveedor de DNS a través del despliegue intermediario de ExternalDNS en Kubernetes, lo que permite detectar automáticamente las aplicaciones de Kubernetes mediante registros DNS externos. En el diagrama, las líneas negras representan la ruta de datos por la que los usuarios externos acceden a las aplicaciones del clúster de Kubernetes. Las líneas moradas representan la ruta de control mediante la cual los propietarios de las aplicaciones gestionan los registros DNS externos con recursos VirtualServer en la configuración de NGINX Ingress Controller y ExternalDNS accede al proveedor de DNS.

Integración de ExternalDNS y NGINX Ingress Controller

Siga los pasos de las secciones siguientes para integrar ExternalDNS y NGINX Ingress Controller.

• Requisitos previos
• Implementar NGINX Ingress Controller y ExternalDNS
• Configurar el controlador de Ingress NGINX

Requisitos previos

1. Crea al menos un dominio registrado. Sustituye su nombre por <my‑domain> en los pasos que se indican a continuación. (Hay muchos artículos disponibles sobre cómo registrar un dominio, incluida esta guía de PCMag.)
2. Implemente NGINX Ingress Controller mediante manifiestos o charts de Helm. Añada el equivalente de estos argumentos de línea de comandos en la especificación de implementación:
   • -enable-external-dns – Habilita la integración con ExternalDNS.
   • -external-service=nginx-ingress – Indica a NGINX Ingress Controller que anuncie su punto de entrada público para registrarlo en los registros A gestionados por el proveedor de DNS. El nombre de host del punto de entrada público se resuelve en el servicio externo nginx-ingress.
3. Si va a implementar el clúster de Kubernetes en sus propias instalaciones, aprovisione un balanceador de carga externo. En nuestro libro electrónico gratuito Get Me to the Cluster encontrará instrucciones para implementar NGINX como balanceador de carga externo con BGP. También puede utilizar F5 BIG‑IP o MetalLB.
4. Si es necesario, cree una zona DNS en un proveedor compatible con ExternalDNS. Este comando corresponde al proveedor utilizado en la implementación de ejemplo: Google Cloud DNS.

$ gcloud dns managed-zones create "external-dns-<my-domain>" --dns-name "external-dns.<my-domain>." --description "Zone automatically managed by ExternalDNS"

Desplegar el controlador de Ingress NGINX y ExternalDNS

1. Clona el repositorio de GitHub para el despliegue de ejemplo e instala NGINX Ingress Controller.

$ git clone https://github.com/nginxinc/NGINX-Demos.git && cd NGINX-Demos/external-dns-nginx-ingress/ 
$ kubectl apply -f nginx-ingress.yaml && kubectl apply -f loadbalancer.yaml

1. Actualice los siguientes argumentos en la especificación de despliegue de ExternalDNS (en las líneas 59–62 de external-dns-gcloud.yaml para el despliegue de ejemplo): Nota: Los argumentos que debe incluir en la especificación de despliegue de ExternalDNS pueden variar en función del proveedor de DNS que elija. Para consultar una lista de tutoriales sobre cómo desplegar ExternalDNS en el clúster con distintos proveedores de DNS, consulte la documentación de ExternalDNS.
   • --domain-filter – El nombre del dominio creado en el paso 4 de la sección anterior (en la implementación de ejemplo, external-dns.<my-domain>). Elimine cualquier valor existente para que solo se utilice este dominio.
   • --provider – El proveedor de DNS (en la implementación de ejemplo, google para Google DNS).
   • --google-project – El nombre del proyecto de Google que utiliza para la implementación de ejemplo (solo es obligatorio si tiene más de un proyecto de Google).
   • --txt-owner-id – El ID que elija (único para la implementación de ejemplo).
2. Despliegue ExternalDNS en el clúster y compruebe que el despliegue se ejecuta correctamente (el resultado se muestra en dos líneas para facilitar su lectura).

$ kubectl apply -f external-dns-gcloud.yaml$ kubectl get pods -o wide
NAME                                READY  STATUS    ...
external-dns-4hrytf7f98f-ffuffjbf7  1/1    Running   ...
    ... RESTARTS   AGE
    ... 0          1m

Configurar el controlador de Ingress NGINX

A continuación, configuramos un recurso VirtualServer con una regla de equilibrio de carga de Ingress que dirige las conexiones externas a nuestras aplicaciones de Kubernetes.

1. En app-virtual-server.yaml, establece el campo host (línea 6):

 6    host: ingress.external-dns.<my-domain>

1. La correspondencia entre este valor y el valor de domain-filter en la línea 59 de external-dns-gcloud.yaml (establecido en el paso 2 de la sección anterior) es lo que permite la actualización automática de los registros DNS.
2. Aplique app-virtual-server.yaml y compruebe que VirtualServer esté configurado correctamente.

$ kubectl apply -f app-secret.yaml && kubectl apply -f app-virtual-server.yaml
$ kubectl get vs 
NAME   STATE   HOST                              IP            
cafe   Valid   ingress.external-dns.<my-domain>  34.168.X.Y

1. Compruebe que se haya añadido un registro DNS de tipo A a la zona DNS. En concreto, la dirección IP del campo DATA debe coincidir con el campo IP de la salida del comando kubectl get vs del paso anterior (la dirección IP externa del servicio de tipo LoadBalancer que expone NGINX Ingress Controller, o su equivalente en una implementación local).

$ gcloud dns record-sets list --zone external-dns-<my-domain> -name ingress.external-dns.<my-domain> --type ANAME                               TYPE     TTL     DATA
ingress.external-dns.<my-domain>.  A        300     34.168.X.Y

1. Para validar que el nombre de host de VirtualServer se puede resolver en la máquina local, obtenga los servidores de nombres asignados a la zona DNS (en este caso, my-ns-domains).

$ gcloud dns record-sets list --zone external-dns.<my-domain> --name external-dns.<my-domain>. --type NSNAME                        TYPE      TTL     DATA
external-dns.<my-domain>.   NS        21600   my-ns-domains

$ dig +short @my-ns-domains ingress.external-dns.<my-domain>
34.168.X.Y

1. Utiliza los registros DNS obtenidos en el paso anterior como servidores de nombres dedicados para tu dominio registrado. De este modo, tu dominio registrado se establece como la zona principal de la zona DNS creada en el Paso 4 de Requisitos previos.
2. Compruebe que puede acceder al nombre de host de VirtualServer ahora que está expuesto a Internet.

$ curl -i --insecure https://ingress.external-dns.<my-domain>/teaHTTP/1.1 200 OK
Server: nginx/1.23.0
Date: Day, DD MM YYYY hh:mm:ss TZ
Content-Type: text/plain
Content-Length: 160
Connection: keep-alive
Expires: Day, DD MM YYYY hh:mm:ss TZ
Cache-Control: no-cache

Escalado horizontal de varios clústeres de Kubernetes

Puede escalar rápidamente la arquitectura y detectar automáticamente varios clústeres automatizando la creación de registros DNS externos y haciendo que apunten a los nuevos puntos de entrada de los clústeres (Clúster de Kubernetes 1 y Clúster de Kubernetes 2) del diagrama. Repita las instrucciones de Implementar NGINX Ingress Controller y ExternalDNS y Configurar NGINX Ingress Controller.

También puede utilizar herramientas de infraestructura como código en su canalización de CI/CD para crear nuevos clústeres y exponerlos al tráfico externo mediante ExternalDNS y NGINX Ingress Controller. Además, puede gestionar varias zonas DNS o incluso varios proveedores de DNS, en función de cómo esté habilitado el descubrimiento.

Conclusión

Encontrar el equilibrio entre la productividad y las medidas de seguridad que reducen el riesgo de brechas puede resultar difícil. Imponer restricciones a los equipos de DevOps suele generar fricciones con los equipos de NetOps/SecOps. El equilibrio ideal varía en cada organización, y NGINX ofrece la flexibilidad necesaria para establecer uno que se ajuste a sus prioridades y requisitos.

En el pasado, los propietarios de aplicaciones dependían de los equipos de NetOps para conectar sus aplicaciones a sistemas externos. Gracias a la integración de ExternalDNS con NGINX, los desarrolladores y los equipos de DevOps pueden implementar por sí mismos aplicaciones detectables, lo que ayuda a acelerar la comercialización de innovaciones.

Para consultar una guía completa sobre cómo empezar a utilizar NGINX en Kubernetes, descargue nuestro libro electrónico gratuito Gestión del tráfico de Kubernetes con F5 NGINX: guía práctica.

También puede empezar hoy mismo solicitando una prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y protección contra ataques DoS, o bien ponerse en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Amir RawdatIngeniero de soluciones

Más artículos de Amir Rawdat