Configuración de LocalDNS en Azure Kubernetes Service (AKS)

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

Para la mayoría de las cargas de trabajo de producción, AKS Automatic es la configuración predeterminada recomendada y lista para producción en AKS. LocalDNS está preconfigurado en clústeres automáticos de AKS. En AKS Estándar, el comportamiento de LocalDNS depende de la versión de Kubernetes y del perfil localDNS existente del grupo de nodos.

LocalDNS es una característica de AKS que mejora el rendimiento y la resistencia de la resolución DNS para las cargas de trabajo que se ejecutan en el clúster. Al ejecutar un proxy DNS en cada nodo, LocalDNS reduce la latencia de las consultas DNS, mejora la confiabilidad durante las interrupciones transitorias de la red y proporciona controles avanzados de almacenamiento en caché y reenvío cuando se necesita personalización.

Para obtener información sobre lo que es LocalDNS, incluidos los detalles de la arquitectura y las funcionalidades clave, consulte Resolución de DNS en Azure Kubernetes Service (AKS).

Comportamiento de AKS Automatic y AKS Standard LocalDNS

Comprobaciones de compatibilidad para el modo Preferred

A partir de Kubernetes 1.37, AKS Standard asigna el modo Preferred a los grupos de nodos elegibles sin un perfil de LocalDNS explícito cuando se crean o actualizan. AKS conserva perfiles configurados explícitamente.

Antes de habilitar LocalDNS por primera vez en modo Preferred, AKS comprueba los siguientes requisitos de compatibilidad. Si no se cumple un requisito, LocalDNS permanece deshabilitado.

Una vez que AKS habilita LocalDNS en el modo Preferred, permanece habilitado durante las actualizaciones posteriores no relacionadas del grupo de nodos. Para deshabilitarlo, establezca explícitamente LocalDNS mode en Disabled.

Procedimientos recomendados para la configuración de LocalDNS

Al implementar LocalDNS en los clústeres de AKS, tenga en cuenta los procedimientos recomendados siguientes:

• Empiece con una configuración mínima: comience con una configuración sencilla que use el modo primero para validar la sintaxis de configuración de LocalDNS antes de pasar al modo Preferred. El Preferred modo valida la configuración sin habilitar LocalDNS, lo que le permite detectar los errores de configuración al principio sin afectar al clúster.
• Implementar estrategias de almacenamiento en caché adecuadas: configure las opciones de caché en función de las características de la carga de trabajo:
  • Para los registros que cambian con frecuencia, use valores más cortos cacheDurationInSeconds . Al hacerlo, es importante tener en cuenta que cacheDurationInSeconds actúa como un límite en el TTL del registro DNS, pero no lo aumenta. El TTL resultante es el menor de lo que se devuelve de la cadena ascendente o de lo que se establece en el complemento de caché.
  • Para registros estables, use duraciones de caché más largas para reducir las consultas DNS.
  • Habilite serveStale con la configuración adecuada para mantener el servicio durante las interrupciones de DNS.
  • El almacenamiento en caché con LocalDNS funciona con el mejor esfuerzo y no garantiza respuestas obsoletas. La memoria caché se divide en 256 comparticiones y con un máximo predeterminado de 10 000 entradas, lo que permite que cada compartición contenga aproximadamente 39 entradas. Cuando una compartición está llena y se debe agregar una nueva entrada, se elige una de las entradas existentes de manera aleatoria para expulsarse. No hay ninguna preferencia para las entradas anteriores o expiradas. Como resultado, es posible que un registro obsoleto no siempre esté disponible, especialmente en un volumen de consultas elevado.
• Supervisión del rendimiento de DNS: después de habilitar LocalDNS, supervise el rendimiento de DNS de la aplicación mediante:
  • Métricas de rendimiento de la aplicación.
  • Métricas de nodo para detectar una presión de red reducida.
  • Entradas de registro cuando queryLogging se establece en Log.
• Siga el principio de privilegios mínimos: al configurar reglas de reenvío de DNS, solo permita el acceso a los dominios y servidores DNS necesarios.
• Prueba antes de la implementación de producción: pruebe siempre la configuración de LocalDNS en un entorno que no sea de producción antes de implementarla en clústeres de producción.
• Usar Infraestructura como código (IaC): almacene el archivo localdnsconfig.json en el repositorio de infraestructura e inclúyalo en las plantillas de implementación de AKS.
• Configuración de red para el reenvío tcp: al usar TCP para el reenvío de DNS a VnetDNS, asegúrese de que los grupos de seguridad de red (NSG), los firewalls o las aplicaciones virtuales de red (NVA) no bloquean el tráfico TCP entre los servidores CoreDNS/LocalDNS y VnetDNS.
• Evite habilitar NodeLocal DNSCache y LocalDNS: no se recomienda habilitar tanto NodeLocal DNSCache de Kubernetes ascendente como LocalDNS en el grupo de nodos. Aunque AKS no bloquea esta configuración, todo el tráfico DNS se enruta a través de LocalDNS, lo que podría dar lugar a un comportamiento inesperado o a ventajas reducidas de DNSCache nodocal.
• No impone un límite de conexión TCP en el servidor DNS personalizado ascendente antes de habilitar LocalDNS: al habilitar LocalDNS en un grupo de nodos, cada nodo abre conexiones TCP de larga duración desde su proxy DNS local a la resolución ascendente, en lugar de los intercambios UDP cortos usados anteriormente. Si el servidor DNS personalizado (como BIND, Unbound, Windows DNS o un dispositivo de terceros) se configura con un límite fijo en las conexiones de cliente TCP simultáneas o si ajusta ese límite en función del tráfico localDNS anterior, se pueden rechazar las nuevas conexiones TCP desde LocalDNS, lo que provoca errores de resolución DNS en todo el clúster. Deje cualquier límite de conexiones TCP en un valor predeterminado holgado antes de activar LocalDNS, valide el número estable de conexiones TCP de sus nodos de AKS después de habilitarlo y ajuste el límite solo después, dejando margen para el escalado horizontal de nodos, las actualizaciones y las reimágenes.

Prerrequisitos

Los clústeres automáticos de AKS incluyen LocalDNS preconfigurado. Los requisitos previos de esta sección se aplican principalmente al habilitar o personalizar el comportamiento de LocalDNS, que es más común en escenarios de personalización estándar y avanzada de AKS.

• Debe tener un clúster de AKS existente con las versiones 1.31 y posteriores de Kubernetes para usar LocalDNS. Si necesita un clúster de AKS, puede crear uno mediante CLI de Azure, Azure PowerShell o Azure portal.
• Este artículo requiere CLI de Azure versión 2.80.0 y posteriores. Si usa Azure Cloud Shell, la versión más reciente ya está instalada.
• LocalDNS solo se admite en grupos de nodos que ejecutan Azure Linux o Ubuntu 22.04 y versiones posteriores.
• La SKU de máquina virtual (VM) usada para el grupo de nodos debe tener al menos 4 vCPU (núcleos) para admitir LocalDNS.

Habilitación o personalización de LocalDNS en un clúster de AKS

Puede configurar LocalDNS a nivel de grupo de nodos en AKS, para poder adaptar el comportamiento según las cargas de trabajo y el entorno.

En AKS Automatic, LocalDNS ya está preconfigurado, por lo que esta sección es principalmente para la personalización.

En AKS Standard, use esta sección para habilitar y configurar LocalDNS.

Validación de DNS personalizado antes de habilitar LocalDNS

Si la red virtual usa servidores DNS personalizados, pruebe ambos transportes DNS desde un nodo de AKS antes de habilitar LocalDNS:

dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>

Ambos comandos deben devolver una respuesta válida. Si UDP se realiza correctamente pero se agota el tiempo de espera de TCP, no habilite LocalDNS hasta que se permita el puerto TCP 53 a través de la ruta de acceso de red completa y el servidor DNS personalizado esté configurado para aceptar consultas TCP.

Habilitación de LocalDNS en un grupo de nodos

Este paso se aplica normalmente a AKS Standard. AKS Automatic ya incluye localDNS preconfigurado.

Para habilitar LocalDNS durante la creación del grupo de nodos, use el siguiente comando con el archivo de configuración personalizado:

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Para habilitar LocalDNS en un grupo de nodos existente, use el siguiente comando con el archivo de configuración personalizado:

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Deshabilitar LocalDNS en un grupo de nodos

Deshabilitar LocalDNS es una operación avanzada y, por lo general, no se recomienda para los valores predeterminados de producción automática de AKS a menos que tenga una excepción validada.

Para deshabilitar LocalDNS para un grupo de nodos, debe actualizar el archivo localdnsconfig.json estableciendo la propiedad mode en Disabled. Este cambio indica a AKS que desactive el proxy DNS local en todos los nodos del grupo especificado y revierta la resolución DNS al comportamiento predeterminado del clúster. Después de actualizar el archivo de configuración, aplíquelo al grupo de nodos mediante el CLI de Azure para asegurarse de que el cambio surte efecto.

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Verificar el funcionamiento de LocalDNS

En AKS Automatic, la comprobación confirma que la línea base localDNS preconfigurada está activa para las cargas de trabajo. En AKS Standard, la comprobación confirma la implementación de LocalDNS.

Una vez habilitado LocalDNS, puede comprobar su operación ejecutando consultas DNS desde pods en el grupo de nodos especificado e inspeccionando el SERVER campo en las respuestas para confirmar que se devuelven direcciones LocalDNS (169.254.10.10 o 169.254.10.11).

Antes de ejecutar los pasos de validación, asegúrese de que se cumplen las condiciones siguientes:

1. Tienes kubectl instalado y configurado para acceder al clúster de AKS.
2. La cuenta de usuario tiene permisos suficientes para crear y ejecutar en pods.
3. El grupo de nodos donde desea validar LocalDNS está en estado Listo .
4. La imagen busyBox (busybox:1.28) es accesible desde los nodos del clúster.

Ejemplo de validación:

1. Cree un pod de depuración en el grupo de nodos donde está habilitado LocalDNS:

   kubectl run dnstest --image=busybox:1.28 -- sleep 3600
   

2. Una vez que se esté ejecutando el pod, ejecute el siguiente comando para comprobar la resolución dns:

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   Compruebe los resultados. Si localDNS funciona correctamente, debería ver una respuesta con la dirección del servidor de 169.254.10.10 o 169.254.10.11:

   Server:    169.254.10.10
   Address 1: 169.254.10.10
   
   Name:      kubernetes.default
   Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
   

Configuración de LocalDNS

LocalDNS usa un archivo de configuración basado en JSON localdnsconfig.json para definir el comportamiento de resolución DNS para cada grupo de nodos. Este archivo le permite especificar modos operativos, bloques de servidor para distintos dominios DNS y la configuración del complemento, como el almacenamiento en caché, el reenvío y el registro.

Configuración predeterminada de LocalDNS

En AKS Automatic, LocalDNS está preconfigurado. Use la personalización solo cuando tenga un requisito específico.

En AKS Standard, esta configuración predeterminada es un buen punto de partida.

Al personalizar LocalDNS, use el siguiente formato de configuración como plantilla. Puede definir bloques de servidor adicionales según sea necesario, pero agregar propiedades de nivel superior no admitidas o no estándar a la configuración produce errores de validación.

{
  "mode": "Required",
  "vnetDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "VnetDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  },
  "kubeDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  }
}

Configuración de mode para LocalDNS

LocalDNS se puede habilitar en tres modos posibles que definen el alcance de la aplicación de LocalDNS para el flujo de trabajo.

• Required: LocalDNS se aplica en el grupo de nodos si se cumplen todos los requisitos previos. Si no se cumplen los requisitos, se produce un error en la implementación.
• Disabled: deshabilita la característica DNS local, por lo que las consultas DNS no se resuelven localmente en el nodo.
• Preferred: AKS valida que la configuración de LocalDNS es sintácticamente correcta, pero no habilita LocalDNS en los nodos. Sin embargo, al aplicar este modo se sigue activando una operación de reaprovisionamiento del nodo, por lo que puedes comprobar si hay errores en tu configuración sin afectar a la resolución DNS de tu clúster.

En el caso de las cargas de trabajo de producción en AKS Automatic, mantenga el comportamiento localDNS preconfigurado a menos que tenga una necesidad validada de personalizar.

En la tabla siguiente se resume el comportamiento de LocalDNS para cada modo y versión de Kubernetes:

Bloques de servidor para LocalDNS

La configuración predeterminada se aplica a las consultas de pods mediante dnsPolicy:default (en vnetDNSOverrides) y pods mediante dnsPolicy:ClusterFirst (en kubeDNSOverrides). Dentro de cada uno, hay dos bloques de servidor predeterminados definidos: . y cluster.local.

• . representa todas las consultas DNS externas de pods que intentan resolver dominios públicos o no de clúster (por ejemplo, microsoft.com).
• cluster.local representa todas las consultas internas de descubrimiento de servicios de Kubernetes procedentes de pods que intentan resolver nombres de servicios de Kubernetes o recursos internos del clúster. Estas consultas se enrutan a través de CoreDNS para la resolución dentro del clúster.

Complementos admitidos para la configuración de LocalDNS

Reglas de validación de configuración

Al crear la configuración de LocalDNS, tenga en cuenta estas reglas de validación para evitar errores de implementación:

• Restricciones de zona raíz (.): en vnetDNSOverrides, el forwardDestination para la zona raíz no puede ser ClusterCoreDNS.
• Restricciones de zona para cluster.local: en vnetDNSOverrides y kubeDNSOverrides, el forwardDestination para cluster.local no puede ser VnetDNS.
• Compatibilidad de protocolo y serveStale: cuando protocol se establece en ForceTCP, serveStale no se puede establecer en Verify. En su lugar, use Immediate.

Creación de un bloque de servidor personalizado en LocalDNS

CoreDNS empareja consultas de dominio con un bloque de servidor específico en función de una coincidencia exacta del dominio consultado y no en coincidencias parciales. Si tiene la necesidad de bloques de servidor personalizados, puede agregarlos a la configuración localDNS mediante la creación de un archivo denominado localdnsconfig.json con las configuraciones agregadas.

Por ejemplo, si tiene necesidades de DNS específicas al acceder a microsoft.com, puede usar el siguiente bloque de servidor:

"microsoft.com": {
  "queryLogging": "Error",
  "protocol": "ForceTCP",
  "forwardDestination": "ClusterCoreDNS",
  "forwardPolicy": "Sequential",
  "maxConcurrent": 1000,
  "cacheDurationInSeconds": 3600,
  "serveStaleDurationInSeconds": 3600,
  "serveStale": "Immediate"
}

Supervisión de localDNS

En AKS Automatic, LocalDNS está preconfigurado, así que comience con la validación de línea base y supervise el comportamiento antes de aplicar el ajuste personalizado.

LocalDNS expone las métricas de Prometheus que puede usar para la supervisión y las alertas. Las métricas se exponen en el puerto 9253 de la dirección IP del nodo.

Ejemplo de configuración de recopilación de datos para el complemento Azure Managed Prometheus como un DaemonSet:

kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config-node
  namespace: kube-system
data:
  prometheus-config: |-
    global:
      scrape_interval: 1m
    scrape_configs:
    - job_name: localdns-metrics
      scrape_interval: 1m
      scheme: http
      metrics_path: /metrics
      relabel_configs:
      - source_labels: [__metrics_path__]
        regex: (.*)
        target_label: metrics_path
      - source_labels: [__address__]
        replacement: '$NODE_NAME'
        target_label: instance
      static_configs:
      - targets: ['$NODE_IP:9253']

Solución de problemas de LocalDNS

Se producen errores en las consultas DNS en dominios específicos

Si se producen errores en las consultas DNS en dominios específicos después de habilitar LocalDNS:

1. Compruebe si tiene invalidaciones específicas del dominio en el archivo localdnsconfig.json que pudieran estar mal configuradas.

2. Intente quitar temporalmente las invalidaciones específicas del dominio y use solo la configuración predeterminada ..

3. Compruebe si el problema se produce con el Protocolo de datagramas de usuario (UDP) y el Protocolo de control de transmisión (TCP) ajustando la protocol configuración.

4. Compruebe los registros de CoreDNS para ver si hay tiempos de espera en las direcciones 169.254.10.10:53 LocalDNS o 169.254.10.11:53. Desde un nodo afectado, pruebe el servidor DNS personalizado ascendente por separado a través de UDP y TCP:

   dig +udp @<custom-dns-ip> <fqdn>
   dig +tcp @<custom-dns-ip> <fqdn>
   

   Si UDP se ejecuta correctamente, pero se produce un error en TCP, compruebe que:

   • El servidor DNS personalizado escucha en el puerto TCP 53.
   • Los NSG y los firewalls permiten el tráfico por el puerto TCP 53 desde la subred de nodos de AKS.
   • Las NVA y las rutas no descartan ni enrutan de forma asimétrica el tráfico TCP de DNS.

   Para deshabilitar LocalDNS en un grupo de nodos afectado, actualice su modo LocalDNS a Disabled. Cambiar un grupo habilitado a Disabled desencadena el restablecimiento de la imagen inicial de un nodo como parte de la actualización. Para una corrección permanente, asegúrese de que el servidor DNS personalizado y la ruta de acceso de red admiten DNS a través de UDP y TCP en el puerto 53.

Actualización de servidores DNS de red virtual para LocalDNS

Al actualizar servidores DNS personalizados directamente en la configuración de red virtual (mediante el portal de Azure o la CLI), los nodos de clúster de AKS no aplican automáticamente estos cambios. La actualización de la configuración de DNS en el nivel de red virtual solo informa al proveedor de recursos de red (NRP), pero no notifica al proveedor de recursos de AKS. Como resultado, los nodos de AKS siguen usando la configuración anterior del servidor DNS hasta que realice más acciones.

Para asegurarse de que los nodos de AKS seleccionan la nueva configuración del servidor DNS de red virtual:

1. Actualice la configuración de DNS de red virtual mediante Azure Portal o las API según sea necesario.

2. Use el proveedor de recursos de AKS para volver a crear la imagen del grupo de nodos, asegurándose de que se aplique y conserve la configuración de DNS actualizada:

   az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
   

Este proceso garantiza que el proveedor de recursos de AKS tenga en cuenta los cambios de DNS y los aplica a todos los nodos del grupo de nodos.

Actualizar directivas de red de Cilium para permitir la resolución DNS con LocalDNS

Si implementa directivas de red de Cilium en el clúster, debe permitir explícitamente la salida del pod a las direcciones IP de LocalDNS.

Las directivas de red aplican un modelo de denegación predeterminada para destinos que no se especifican, por lo que el tráfico DNS a LocalDNS se bloquea a menos que se permita explícitamente.

• En Azure CNI Powered by Cilium <=v1.16 con k8s <=1.31, esto se puede lograr mediante una política basada en CIDR.
• En Azure CNI con tecnología Cilium >=v1.17 con K8s >=1.32, se puede utilizar una política de red de Cilium que permita la salida a entidades de host.

Para consultar una directiva de red de Cilium que permita el tráfico en todas las versiones, consulte ¿Se admite el DNS local de AKS con Azure CNI con tecnología de Cilium?

Contenido relacionado

• ¿Qué es AKS Automatic?
• Creación de un clúster automático de AKS
• LocalDNS en Azure Kubernetes Service (conceptual)
• Solución de problemas de LocalDNS en AKS
• Guía de personalización de CoreDNS
• Página del proyecto original de CoreDNS
• Conceptos de red para aplicaciones en AKS