Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard
La resolución del sistema de nombres de dominio (DNS) es un componente crítico en Azure Kubernetes Service (AKS), lo que permite que los pods y los servicios se comuniquen mediante nombres legibles en lugar de direcciones IP. AKS proporciona servicios DNS integrados para garantizar una resolución de nombres sin problemas tanto para los recursos internos del clúster como para los puntos de conexión externos. Comprender cómo funciona DNS en AKS ayuda a los operadores de clúster y a los desarrolladores a garantizar una conectividad confiable, optimizar el rendimiento y solucionar problemas de red de forma eficaz.
AKS Automatic es la opción predeterminada recomendada para producción para la mayoría de las cargas de trabajo de AKS. Los clústeres automáticos de AKS vienen preconfigurados con LocalDNS para mejorar el rendimiento de DNS, reducir la presión de conntrack y aumentar la resistencia sin necesidad de configuración adicional.
Nota:
A partir de Kubernetes 1.37, AKS Standard aplica el Preferred modo LocalDNS de forma predeterminada a los grupos de nodos aptos que no tienen un perfil LocalDNS configurado explícitamente. En Preferred modo, AKS habilita LocalDNS solo si el grupo de nodos y el clúster pasan las comprobaciones de compatibilidad necesarias. Si se produce un error en las comprobaciones, LocalDNS permanece deshabilitado. Los perfiles configurados explícitamente tienen prioridad sobre esta configuración predeterminada, por lo que un grupo de nodos configurado explícitamente como Disabled permanece deshabilitado.
Para evitar que LocalDNS se habilite, establezca explícitamente el modo LocalDNS en Deshabilitado. Para obtener instrucciones, consulte Deshabilitar LocalDNS en un grupo de nodos.
Para obtener más información sobre AKS Automatic, consulte ¿Qué es AKS Automatic?
CoreDNS en Azure Kubernetes Service
CoreDNS es el servicio DNS predeterminado en AKS. Proporciona resolución de nombres interna y descubrimiento de servicios para cargas de trabajo que se ejecutan en el clúster. Funciona como un conjunto de pods en el espacio de nombres kube-system y está estrechamente integrado con la red de Kubernetes.
Cuando un pod de AKS emite una consulta DNS, como resolver el nombre de otro servicio, la solicitud va a los pods de CoreDNS. Estos pods procesan la consulta y devuelven la dirección IP adecuada o reenvía la solicitud a un servidor DNS ascendente para dominios externos.
Esta arquitectura garantiza un equilibrio entre la flexibilidad y la seguridad operativa en un entorno administrado. Para más información sobre cómo personalizar CoreDNS en AKS, consulte la guía de personalización de CoreDNS.
Cuando LocalDNS está activo, la ruta de resolución depende del dnsPolicy del pod (Default o ClusterFirst) y de la configuración del bloque de servidor de LocalDNS. Por ejemplo, cuando un pod usa dnsPolicy: Default, las consultas DNS externas siguen la siguiente ruta:
Workload -> LocalDNS -> upstream DNS server
LocalDNS se ejecuta como una systemd unidad en el nodo, por lo que recibe la consulta antes de que CoreDNS lo haga.
cluster.local las consultas se reenvían a CoreDNS y las consultas externas se reenvían bien a CoreDNS o directamente al servidor DNS de la red virtual (VNet). Para conocer el comportamiento exacto de reenvío para cada directiva DNS y la configuración predeterminada, consulte Bloques de servidor para LocalDNS.
Los servidores DNS de red virtual personalizados deben aceptar consultas DNS UDP y TCP de nodos de AKS. Con PreferUDP, LocalDNS vuelve a intentarlo por TCP cuando una respuesta UDP se trunca.
Para obtener información sobre el proyecto CoreDNS, consulte la página de proyecto del canal de subida de CoreDNS.
LocalDNS en Azure Kubernetes Service
Nota:
En este artículo se proporciona información general sobre qué es LocalDNS y sus ventajas en AKS.
Para AKS Automatic, LocalDNS está preconfigurado.
Para AKS Standard, consulte la guía de procedimientos de LocalDNS para obtener instrucciones sobre cómo habilitar y configurar LocalDNS.
Información general
LocalDNS es una característica avanzada en Azure Kubernetes Service (AKS) que implementa un proxy del sistema de nombres de dominio (DNS) en cada nodo para proporcionar una resolución DNS de baja latencia y altamente resistente. Al controlar las consultas DNS localmente, este proxy reduce el tráfico a los pods del complemento CoreDNS, lo que mejora la confiabilidad y el rendimiento generales de DNS en el clúster. LocalDNS es especialmente beneficioso en clústeres o entornos grandes con grandes volúmenes de consultas DNS, donde la resolución DNS centralizada puede convertirse en un cuello de botella.
Cuando LocalDNS está habilitado, AKS implementa una caché DNS local como systemd servicio en cada nodo. Los pods del nodo envían sus consultas DNS a esta caché local, lo que permite una resolución más rápida al reducir los saltos de red. Este enfoque también minimiza conntrack el uso de tablas, lo que reduce el riesgo de agotamiento de tablas. Además, si dns ascendente deja de estar disponible, LocalDNS puede seguir sirviendo respuestas almacenadas en caché durante una duración configurable, lo que ayuda a mantener la conectividad del pod y la confiabilidad del servicio.
LocalDNS y AKS Automático
AKS Automatic preconfigura LocalDNS como parte de la configuración predeterminada lista para producción. No es necesario ejecutar un comando enable independiente en clústeres automáticos de AKS.
Use este artículo para comprender cómo funciona LocalDNS y por qué mejora el comportamiento de DNS para las cargas de trabajo de AKS. Si necesita pasos de habilitación y configuración para AKS Standard, use la guía de procedimientos de LocalDNS.
Funcionalidades clave
-
Latencia de resolución DNS reducida: cada nodo de AKS ejecuta un servicio LocalDNS
systemd. Las cargas de trabajo que se ejecutan en el nodo envían consultas DNS a este servicio, lo que las resuelve localmente, lo que reduce los saltos de red y acelera las búsquedas DNS. -
Comportamiento dns personalizable: use
kubeDNSOverridesyvnetDNSOverridespara controlar el comportamiento de DNS en el clúster. -
Evitar conflictos de conntrack y el agotamiento de la tabla de conntrack: Los pods envían consultas DNS al servicio LocalDNS en el mismo nodo sin crear nuevas
conntrackentradas en la tabla. Omitir el seguimiento de la conexión ayuda a reducir las carreras de seguimiento y evita que las entradas DNS del Protocolo de Datagramas de Usuario (UDP) llenen las tablasconntrack. Esta optimización evita las conexiones perdidas y rechazadas causadas por el agotamiento de la tablaconntracky las condiciones de carrera. -
Conexión actualizada a TCP: la conexión desde la
localdnsmemoria caché al servicio CoreDNS del clúster usa el Protocolo de control de transmisión (TCP). TCP permite reequilibrar la conexión y quitaconntrackentradas de tabla cuando el servidor cierra la conexión (a diferencia de las conexiones UDP, que tienen un tiempo de espera predeterminado de 30 segundos). Las aplicaciones no necesitan cambios, ya que ellocaldnsservicio sigue escuchando el tráfico UDP. -
Almacenamiento en caché: puede configurar el complemento de caché de LocalDNS con los ajustes de
serveStaley el tiempo de vida (TTL). Configure los parámetrosserveStale,serveStaleDurationInSecondsycacheDurationInSecondspara lograr resiliencia de DNS, incluso durante una interrupción del DNS upstream. -
Control de protocolo: establezca el protocolo de consulta DNS preferido, como
PreferUDPoForceTCP, para cada dominio.PreferUDPno es una instrucción para usar UDP exclusivamente. El resolvedor puede reintentar la consulta o recurrir a TCP como alternativa, por lo que los servidores DNS personalizados externos y los controles de red deben admitir el puerto 53 tanto en UDP como en TCP.
Otras ventajas y consideraciones
| Ventajas | Consideraciones |
|---|---|
| Mejor escalabilidad: reduce la carga en pods de CoreDNS centralizados | Sobrecarga mínima de recursos: usa una pequeña cantidad de CPU y memoria en cada nodo. |
| Integración sin problemas: no requiere cambios en las conexiones de aplicaciones existentes | Cambios de configuración: las actualizaciones requieren actualizaciones de imágenes de nodo, lo que puede provocar interrupciones temporales. |
| Bloquear dominios de búsqueda no válidos: impide consultas DNS no válidas en el nivel de nodo | Planeamiento de disponibilidad: Los equipos que usan AKS Estándar deben evaluar si el rendimiento y la resistencia de DNS justifican la habilitación de LocalDNS |
Comportamiento de AKS Automatic y AKS Standard
| Modo de clúster | Comportamiento de LocalDNS |
|---|---|
| AKS Automatic | Preconfigurado |
| AKS Standard, Kubernetes 1.31 a 1.36 | Configurado explícitamente por grupo de nodos |
| AKS Standard, Kubernetes 1.37 y versiones posteriores | Establece Preferred como valor predeterminado para los grupos de nodos elegibles cuando no existe ningún perfil de LocalDNS explícito. LocalDNS solo está habilitado cuando se superan las comprobaciones de compatibilidad. Se conservan los perfiles explícitos, incluidos Disabled. |
Mediante el uso de LocalDNS, se obtiene una resolución DNS más rápida y confiable para las cargas de trabajo, se reduce el riesgo de interrupciones relacionadas con DNS y se obtiene más control sobre el tráfico DNS en el entorno de AKS.
Contenido relacionado
- Para obtener más información sobre AKS Automatic, consulte ¿Qué es Azure Kubernetes Service (AKS) automático?
- Para obtener información sobre cómo crear un clúster automático de AKS, consulte Inicio rápido: Creación de un clúster automático de AKS.
- Para obtener información sobre cómo habilitar LocalDNS y configurar sus opciones en el clúster de AKS, consulte la guía de procedimientos de LocalDNS.
- Para obtener más información sobre conceptos básicos de red, consulte Conceptos de redes de aplicaciones en Azure Kubernetes Service (AKS).