Automatización de DNS multiclúster con el controlador de ingreso NGINX

Las aplicações no pueden cumplir su propósito 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 nombres de dominio a direcciones IP. El DNS es tan omnipresente y confiable que la mayoría de los días ni siquiera pensamos en él. Pero cuando hay problemas de DNS, todo se detiene. Asegurarse de que el DNS funciona es crucial para las aplicações modernas, especialmente en arquitecturas de microservicios donde los servicios están en constante activación y desactivación.

En una publicación anterior , hablamos sobre cómo definir registros DNS para dos subdominios que corresponden a aplicações 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 ingeniería ) y se resuelven en el mismo punto de entrada del clúster, es decir, la dirección IP externa del controlador de ingreso NGINX del clúster. El enrutamiento de indicación de nombre de servidor (SNI) se configura en el controlador de ingreso NGINX para autenticar y enrutar las conexiones a la aplicação adecuada en función del nombre de dominio solicitado por los usuarios.

Pero muchas organizaciones necesitan ampliar ese caso de uso e implementar aplicações en múltiples clústeres de Kubernetes, que podrían estar distribuidos en regiones de proveedores de nube. Para que el tráfico externo llegue a nuevas regiones del clúster, debe crear zonas DNS que se resuelvan en esas regiones.

En el pasado, este proceso requería el uso de un proveedor externo (como GoDaddy o DNSExit) para crear manualmente un registro de dominio y actualizar los registros de host adecuadamente. Ahora, el proyecto ExternalDNS Kubernetes automatiza el proceso al hacer que los recursos de Kubernetes sean detectables a través de servidores DNS públicos. Eso significa que utiliza la API de Kubernetes para configurar una lista de proveedores de DNS.

Con una integración entre ExternalDNS y NGINX Ingress Controller , puede administrar registros DNS A de modo que los nombres DNS se deriven de nombres de host declarados en un recurso Ingress de Kubernetes estándar o en un recurso personalizado de NGINX VirtualServer . Los desarrolladores y los equipos de DevOps pueden aprovechar esta integración en sus pipelines de CI/CD para descubrir automáticamente aplicações en diferentes clústeres, sin involucrar al equipo de NetOps (que normalmente es el propietario del DNS).

En esta publicación, mostramos cómo usar archivos de configuración de muestra de nuestro repositorio de GitHub para integrar ExternalDNS con NGINX Ingress Controller.

La arquitectura base

Para implementar ExternalDNS con el controlador de ingreso NGINX, comenzamos con el caso base donde los desarrolladores configuran un controlador de ingreso 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.

El controlador de ingreso NGINX interactúa con el proveedor de DNS a través de la implementación intermediaria de Kubernetes ExternalDNS, lo que permite el descubrimiento automático de aplicações de Kubernetes mediante registros DNS externos. En el diagrama, las líneas negras representan la ruta de datos mediante la cual los usuarios externos acceden a las aplicações en el clúster de Kubernetes. Las líneas violetas representan la ruta de control sobre la cual los propietarios de aplicaciones administran registros DNS externos con recursos de VirtualServer en la configuración del controlador de ingreso NGINX y el DNS externo accede al proveedor de DNS.

Integración de ExternalDNS y el controlador de ingreso NGINX

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

• Requisitos previos
• Implementar el controlador de ingreso NGINX y ExternalDNS
• Configurar el controlador de ingreso NGINX

Requisitos previos

1. Crea al menos un dominio registrado. Sustituya su nombre por <mi‑dominio> en los pasos siguientes. (Hay muchos artículos disponibles sobre cómo registrar un dominio, incluida esta guía de PCMag ).

2. Implemente el controlador de ingreso NGINX mediante manifiestos o gráficos de Helm . Agregue 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 – Le indica al controlador de ingreso NGINX que anuncie su punto de entrada público para grabar en registros A administrados 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 está implementando el clúster de Kubernetes en las instalaciones, aprovisione un equilibrador de carga externo. Proporcionamos instrucciones para implementar NGINX como equilibrador de carga externo con BGP en nuestro libro electrónico gratuito Get Me to the Cluster . Alternativamente, puede utilizar F5 BIG‑IP o MetalLB .

4. Si es necesario, cree una zona DNS en un proveedor compatible con ExternalDNS . Este comando es para el proveedor utilizado en la implementación de muestra, Google Cloud DNS.

   $ gcloud dns managed-zones crea "dns externo"<mi-dominio>"--dns-name "dns-externo.<mi-dominio>." --description "Zona administrada automáticamente por ExternalDNS"
   

Implementar el controlador de ingreso NGINX y ExternalDNS

1. Clone el repositorio de GitHub para la implementación de muestra e implemente NGINX Ingress Controller.

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

2. Actualice los siguientes argumentos en la especificación de implementación de ExternalDNS (en las líneas 59 a 62 en external-dns-gcloud.yaml para la implementación de muestra):

   • --filtro de dominio – El nombre del dominio creado en Paso 4 de la sección anterior (en la implementación de muestra, dns externo.<mi-dominio>). Elimine todos los valores existentes para que solo se utilice este dominio.
   • --provider – El proveedor de DNS (en la implementación de muestra, Google para Google DNS).
   • --google-project : el nombre del proyecto de Google que estás usando para la implementación de muestra (obligatorio solo si tienes más de un proyecto de Google).
   • --txt-owner-id – El ID que elija (único para la implementación de muestra).

   Nota:  Los argumentos que debe incluir en la especificación de implementación de ExternalDNS pueden variar según el proveedor de DNS que elija. Para obtener una lista de tutoriales sobre cómo implementar ExternalDNS en el clúster con diferentes proveedores de DNS, consulte la documentación de ExternalDNS .

3. Implemente ExternalDNS en el clúster y verifique que la implementación se ejecute correctamente (la salida se distribuye en dos líneas para facilitar la legibilidad).

   $ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide NOMBRE LISTO ESTADO ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 En ejecución ... ... REINICIO EDAD... 0 1 m
   

Configurar el controlador de ingreso NGINX

A continuación, configuramos un recurso VirtualServer con una regla de equilibrio de carga de Ingress que enruta las conexiones externas a nuestras aplicações de Kubernetes.

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

    6 host: ingress.external-dns.<mi-dominio>
   

   La asignación 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 habilita la actualización automática de los registros DNS.

2. Aplique app-virtual-server.yaml y verifique que VirtualServer esté configurado correctamente.

   $ kubectl apply -f app-secret.yaml && kubectl apply -f app-virtual-server.yaml
   $ kubectl obtener vs 
   NOMBRE ESTADO HOST IP
   cafe Ingress.external-dns válido.<mi-dominio>  34.168.incógnita.Y
   

3. Verifique que se haya agregado un registro DNS tipo A a la zona DNS. En particular, la dirección IP en el campo DATOS debe coincidir con el campo IP en la salida del comando kubectl get vs en el paso anterior (la dirección IP externa del servicio de tipo LoadBalancer que expone NGINX Ingress Controller, o el equivalente en una implementación local).

   $ lista de conjuntos de registros dns de gcloud --zone external-dns-<mi-dominio> -nombre ingress.dns-externo.<mi-dominio> --tipo ANOMBRE TIPO TTL DATOS
   ingress.external-dns.<mi-dominio>.  A 300 34.168. X. Y
   

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

   $ lista de conjuntos de registros dns de gcloud --zone external-dns.<mi-dominio> --name dns externo.<mi-dominio>. --tipo NSNOMBRE TIPO TTL DATOS
   dns externo.<mi-dominio>.   NS 21600 mis dominios NS
   
   $ dig +short @mis-dominios-ns ingress.dns-externos.<mi-dominio>
   34.168.incógnita.Y
   

5. Utilice los registros DNS recuperados en el paso anterior como servidores de nombres dedicados para su dominio registrado. Esto establece su dominio registrado como la zona principal de la zona DNS creada en el Paso 4 de Requisitos previos .

6. Verifique que pueda acceder al nombre de host de VirtualServer ahora que está expuesto a Internet global.

   $ curl -i --insecure https://ingress.external-dns.<mi-dominio>/téHTTP/1.1 200 OK
   Servidor: nginx/1.23.0
   Fecha: Día , DD MM AAAA hh : mm : ss TZ Tipo de contenido: texto sin formato Longitud del contenido: 160 Conexión: keep-alive Expira: Día , DD MM AAAA hh : mm : ss TZ Control de caché: sin caché
   

Escalado horizontal de múltiples clústeres de Kubernetes

Puede escalar rápidamente la arquitectura y descubrir automáticamente múltiples clústeres al automatizar la creación de registros DNS externos y resolverlos en nuevos puntos de entrada del clúster ( Clúster de Kubernetes 1 y Clúster de Kubernetes 2 ) en el diagrama. Repita las instrucciones en Implementar el controlador de ingreso NGINX y ExternalDNS y Configurar el controlador de ingreso NGINX .

También puede utilizar herramientas de infraestructura como código en su canalización de CI/CD para generar y exponer nuevos clústeres al tráfico externo mediante ExternalDNS y el controlador de ingreso NGINX. Además, puedes administrar múltiples zonas DNS, o incluso múltiples proveedores DNS dependiendo de cómo esté habilitado el descubrimiento.

CONCLUSIÓN

Equilibrar la productividad con medidas de seguridad que mitiguen las infracciones puede ser difícil. Imponer restricciones a los equipos de DevOps a menudo genera fricción entre ellos y los equipos de NetOps/SecOps. El equilibrio ideal difiere en cada organización, y NGINX proporciona la flexibilidad para establecer un equilibrio que se ajuste a sus prioridades y requisitos.

En el pasado, los propietarios de aplicaciones confiaban en los equipos de NetOps para conectar sus aplicações a sistemas externos. Al utilizar la integración de ExternalDNS con NGINX, los desarrolladores y los equipos de DevOps pueden implementar aplicações detectables por su cuenta, lo que ayuda a acelerar el tiempo de comercialización de la innovación.

Para obtener una guía completa e integral sobre cómo comenzar a usar NGINX en Kubernetes, descargue nuestro libro electrónico gratuito Gestión del tráfico de Kubernetes con F5 NGINX: Una guía práctica .

También puede comenzar hoy mismo solicitando una prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS o contáctenos para analizar sus casos de uso .