Conciliación de DNS de Active Directory y Kubernetes en implementaciones de clústeres de macrodatos

En este artículo se describen algunos de los desafíos y las soluciones para dar cabida a la integración de Active Directory al implementar clústeres de macrodatos.

Overview

Cuando el clúster de macrodatos no se implementa con la integración de Active Directory, nos basamos en el servicio CoreDNS de Kubernetes para resoluciones DNS internas. Kubernetes usa un dominio interno como <namespace>.svc.cluster.local. Crea registros A (búsqueda directa) y PTR (búsqueda inversa) en el servidor DNS con nombres en este dominio.

Sin embargo, cuando el modo de Active Directory está habilitado, un nuevo dominio entra en la imagen con su propio conjunto de servidores DNS. Durante la resolución interna de nombres, esto puede causar confusión sobre a qué conjunto de servidores DNS acudir para las búsquedas directas e inversas.

Challenges

• Cuando se implementan nuevos pods de Kubernetes, es necesario agregar entradas DNS en ambos conjuntos de servidores DNS. Kubernetes se encarga de registrar las entradas en sus CoreDNS; sin embargo, el flujo de trabajo de implementación de BDC es responsable de agregar las entradas necesarias en los servidores DNS del controlador de dominio de Active Directory. Del mismo modo, cuando se elimina un clúster de macrodatos, el flujo de trabajo debe asegurarse de que se quitan estas entradas.
• Los servidores DNS de Active Directory son externos al clúster de Kubernetes. Pero BDC tiene su propio espacio ip dentro de Kubernetes y no puede crear registros para este espacio IP en un servidor DNS situado externamente, ya que este espacio IP no está visible fuera de los límites del clúster.
• Cuando se producen eventos de conmutación por error en el clúster de Kubernetes, también se deben actualizar los registros de los servidores DNS de AD.
• Además de los nombres de pod, los nombres de servicio de Kubernetes también deben ser accesibles mediante consultas de nombres de dominio de AD. Esto crea un desafío adicional en DNS de Active Directory, ya que un nombre de servicio puede asignarse a varias direcciones IP de pod.
• Los retrasos de propagación y replicación de actualizaciones de registros en los servidores DNS de Active Directory de la organización pueden ser significativos y más allá del control de los flujos de trabajo de administración de BDC. Esto puede afectar a la funcionalidad de BDC inmediatamente después de la implementación y la conmutación por error. Por el contrario, Kubernetes CoreDNS es más rápido y eficaz debido a su localidad.

Solution

Para solucionar los desafíos mencionados anteriormente, la solución implementada en BDC implica un nuevo servicio coreDNS interno que se administra dentro del espacio de nombres BDC. Este es el único servicio DNS que utilizarán los pods del espacio de nombres BDC para las resoluciones de nombres. La complejidad de varios dominios está oculta detrás del nuevo servicio CoreDNS.

Por ejemplo, en el diagrama siguiente, los pods usan el servidor BDC CoreDNS para resolver nombres. Los pods no interactúan directamente con el servidor CoreDNS de Kubernetes ni con el servidor DNS de AD.

Estos son algunos de los detalles de implementación que aclaran cómo funciona este diseño en BDC:

Administración centralizada de varios dominios

La complejidad de lo que sucede en las búsquedas de nombres permanece oculta detrás del servicio DNS interno de forma centralizada. Esto evita poner la carga de administrar varios dominios en pods individuales y simplifica el diseño.

No hay registros para pods internos en servidores DNS externos

Como resultado de este principio de diseño, BDC no tendrá que crear y administrar registros A y PTR para pods en el espacio IP de Kubernetes en servidores DNS externos.

No hay duplicación de registros

Registros DNS internos en varios lugares. El único almacenamiento de estos registros es Kubernetes CoreDNS. El coreDNS interno de BDC realizará una reescritura computacional y reenvío de consultas DNS a Kubernetes CoreDNS.

Computational rewriting

Dado que BDC no almacena ningún registro, BDC es responsable de la traducción de consultas entrantes de búsqueda directa con nombres que tienen dominio de AD a los nombres con dominio de Kubernetes y reenvía esta consulta a Kubernetes CoreDNS. Por ejemplo, una consulta entrante para compute-0-0.contoso.local se reescribiría compute-0-0.compute-0-svc.contoso.svc.cluster.local en y esta solicitud se reenviaría a Kubernetes CoreDNS. En el caso de búsquedas inversas, la solicitud se reenvía con las direcciones IP internas tal como están a Kubernetes CoreDNS, donde se reescribe la respuesta al nombre de dominio de Active Directory antes de responder al cliente.

Simplificación en las configuraciones de pod

Puesto que solo se hace referencia al BDC CoreDNS interno en /etc/resolv.conf de todos los pods de BDC, esto simplifica la vista de red de los pods. La complejidad se ocultará en el CoreDNS interno en su lugar.

Dirección IP estática y confiable para el servicio DNS

El servicio CoreDNS que implementa BDC tendrá una dirección IP interna estática registrada a la que se puede acceder desde todos los pods. Esto garantizará que los valores de /etc/resolv.conf no tengan que actualizarse.

Kubernetes conserva la administración del equilibrio de carga del servicio

Cuando se realizan consultas para servicios en lugar de pods individuales, todavía se dirigirán a Kubernetes CoreDNS, por lo que BDC no es responsable de implementar el equilibrio de carga específicamente para el dominio de Active Directory.

Por ejemplo, si se recibe una solicitud de búsqueda directa para compute-0-svc.contoso.local, se reescribirá como compute-0-svc.contoso.svc.cluster.local. Esta solicitud se reenvía a Kubernetes CoreDNS y el equilibrio de carga se producirá allí. Una respuesta será una dirección IP para una de las múltiples instancias del grupo de cómputo (réplicas de pod).

Scalability

Dado que BDC no almacena ningún registro, el BDC CoreDNS interno se puede escalar sin retención de estado y replicación de registros en varias réplicas. Si los registros DNS se almacenarán en el BDC, BDC también deberá encargarse de la replicación del estado en todos los pods.

Las entradas de servicio visibles externamente permanecen en DNS de AD

En el caso de los puntos de conexión de servicio que deben ser accesibles para los clientes fuera del clúster de Kubernetes, las entradas DNS se crearán en el servidor DNS de AD a medida que se implemente BDC. El usuario escribirá los nombres DNS para registrarse desde los perfiles de configuración de implementación.

Self-deprovisioning

Una vez eliminado el BDC, no hay ningún trabajo dinámico adicional para eliminar entradas DNS cuando se desaprovisiona el clúster. Las únicas entradas de DNS remoto de Active Directory que deben limpiarse son para los servicios externos y son estáticas en número. Las entradas DNS internas se quitarán automáticamente con el clúster.

Next steps

• Implementación de Clústeres de macrodatos de SQL Server en el modo de Active Directory
• Administración del acceso al clúster de macrodatos en el modo de Active Directory
• Implementación de varios clústeres de macrodatos de SQL Server en el mismo dominio de Active Directory