Compartir a través de

Personalización de CoreDNS con Azure Kubernetes Service

Azure Kubernetes Service (AKS) usa el proyecto CoreDNS para la administración y la resolución DNS del clúster con todos los clústeres 1.12.x y versiones superiores. Para obtener más información sobre la personalización de CoreDNS y Kubernetes, consulte la documentación oficial de ascendente.

AKS es un servicio administrado, así que no puede modificar la configuración principal para CoreDNS (un archivo CoreFile). En su lugar, se usa una ConfigMapde Kubernetes para invalidar la configuración predeterminada. Para ver los archivos ConfigMap de CoreDNS predeterminados de AKS, use el comando kubectl get configmaps --namespace=kube-system coredns -o yaml.

En este artículo se muestra cómo usar ConfigMaps para las opciones básicas de personalización de CoreDNS en AKS. Este enfoque difiere de la configuración de CoreDNS en otros contextos, como CoreFile.

Nota

Anteriormente, kube-dns se usaba para la administración y resolución de DNS del clúster, pero ahora está en desuso. kube-dns Ofrece diferentes opciones de personalización diferentes a través de una asignación de configuración de Kubernetes. CoreDNS no es compatible con kube-dns. Las personalizaciones que usó anteriormente deben actualizarse para CoreDNS.

Antes de empezar

  • En este artículo se supone que tiene un clúster de AKS existente. Si necesita un clúster de AKS, puede crear uno mediante la CLI de Azure, Azure PowerShell o Azure Portal.
  • Compruebe la versión de CoreDNS que está ejecutando. Los valores de configuración pueden cambiar entre una versión y otra.
  • Al crear una configuración como en los ejemplos siguientes, los nombres de la sección data deben finalizar en .server u .override. Esta convención de nomenclatura se define en el ConfigMap predeterminado de CoreDNS de AKS, que se puede ver con el comando kubectl get configmaps --namespace=kube-system coredns -o yaml.

Soporte con complementos

Se admiten todos los complementos CoreDNS integrados. No se admite ningún complemento o complemento de terceros.

Reescritura de DNS

Puede personalizar CoreDNS con AKS para realizar reescrituras de nombres DNS sobre la marcha.

  1. Cree un archivo denominado corednsms.yaml y pegue la siguiente configuración de ejemplo. Asegúrese de reemplazar <domain to be rewritten> por su propio nombre de dominio completo.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: |
    <domain to be rewritten>.com:53 {
    log
    errors
    rewrite stop {
      name regex (.*)\.<domain to be rewritten>\.com {1}.default.svc.cluster.local
      answer name (.*)\.default\.svc\.cluster\.local {1}.<domain to be rewritten>.com
    }
    forward . /etc/resolv.conf # you can redirect this to a specific DNS server such as 10.0.0.10, but that server must be able to resolve the rewritten domain name
    }

    Importante

    Si redirige a un servidor DNS, como la dirección IP del servicio CoreDNS, ese servidor DNS debe poder resolver el nombre de dominio reescrito.

  2. Cree ConfigMap con el comando kubectl apply configmap y especifique el nombre del manifiesto DE YAML.

    kubectl apply -f corednsms.yaml

  3. Compruebe que las personalizaciones se han aplicado mediante el kubectl get configmaps y especifique el coredns-custom ConfigMap.

    kubectl get configmaps --namespace=kube-system coredns-custom -o yaml

  4. Para volver a cargar ConfigMap y habilitar el programador de Kubernetes para reiniciar CoreDNS sin tiempo de inactividad, realice un reinicio gradual mediante kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Servidor de reenvío personalizado

Si necesita especificar un servidor de reenvío para el tráfico de red, puede crear un objeto ConfigMap para personalizar DNS.

  1. Cree un archivo denominado corednsms.yaml y pegue la siguiente configuración de ejemplo. Asegúrese de reemplazar el nombre y la dirección de forward por los valores de su propio entorno.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    <domain to be rewritten>.com:53 {
        forward foo.com 1.1.1.1
    }

  2. Cree ConfigMap con el comando kubectl apply configmap y especifique el nombre del manifiesto DE YAML.

    kubectl apply -f corednsms.yaml

  3. Para volver a cargar ConfigMap y habilitar el programador de Kubernetes para reiniciar CoreDNS sin tiempo de inactividad, realice un reinicio gradual mediante kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Uso de dominios personalizados

Es posible que quiera configurar dominios personalizados que solo se puedan resolver internamente. Por ejemplo, tal vez quiera resolver el dominio personalizado puglife.local, que no es un dominio de nivel superior válido. Sin un ConfigMap de dominio personalizado, el clúster de AKS no puede resolver la dirección.

  1. Cree un nuevo archivo denominado corednsms.yaml y pegue la siguiente configuración de ejemplo. Asegúrese de actualizar el dominio personalizado y la dirección IP con los valores de su propio entorno.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  puglife.server: | # you may select any name here, but it must end with the .server file extension
    puglife.local:53 {
        errors
        cache 30
        forward . 192.11.0.1  # this is my test/dev DNS server
    }

  2. Cree ConfigMap con el comando kubectl apply configmap y especifique el nombre del manifiesto DE YAML.

    kubectl apply -f corednsms.yaml

  3. Para volver a cargar ConfigMap y habilitar el programador de Kubernetes para reiniciar CoreDNS sin tiempo de inactividad, realice un reinicio gradual mediante kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Dominios de código auxiliar

CoreDNS también se puede usar para configurar dominios de código auxiliar.

  1. Cree un archivo denominado corednsms.yaml y pegue la siguiente configuración de ejemplo. Asegúrese de actualizar los dominios personalizados y las direcciones IP con los valores de su propio entorno.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    abc.com:53 {
     errors
     cache 30
     forward . 1.2.3.4
    }
    my.cluster.local:53 {
        errors
        cache 30
        forward . 2.3.4.5
    }

  2. Cree ConfigMap con el comando kubectl apply configmap y especifique el nombre del manifiesto DE YAML.

    kubectl apply -f corednsms.yaml

  3. Para volver a cargar ConfigMap y habilitar el programador de Kubernetes para reiniciar CoreDNS sin tiempo de inactividad, realice un reinicio gradual mediante kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Complemento de hosts

Se admiten todos los complementos integrados, por lo que los hosts de CoreDNS complemento también están disponibles para personalizar /etc/hosts.

  1. Cree un archivo denominado corednsms.yaml y pegue la siguiente configuración de ejemplo. Asegúrese de actualizar las direcciones IP y los nombres de host con los valores de su propio entorno.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    test.override: | # you may select any name here, but it must end with the .override file extension
          hosts { 
              10.0.0.1 example1.org
              10.0.0.2 example2.org
              10.0.0.3 example3.org
              fallthrough
          }

  2. Cree ConfigMap con el comando kubectl apply configmap y especifique el nombre del manifiesto DE YAML.

    kubectl apply -f corednsms.yaml

  3. Para volver a cargar ConfigMap y habilitar el programador de Kubernetes para reiniciar CoreDNS sin tiempo de inactividad, realice un reinicio gradual mediante kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Finalizaciones de dominio de búsqueda no válidas para internal.cloudapp.net y reddog.microsoft.com

Azure DNS configura un dominio de búsqueda predeterminado de <vnetId>.<region>.internal.cloudapp.net en redes virtuales mediante Azure DNS y un reddog.microsoft.com código auxiliar no funcional en redes virtuales mediante servidores DNS personalizados (consulte la resolución de nombres para recursos para obtener más detalles). Kubernetes configura las opciones de DNS del pod con ndots: 5 para admitir correctamente la resolución del nombre de host del servicio de clúster. Estas dos configuraciones se combinan para dar lugar a consultas de finalización de dominio de búsqueda no válidas que nunca se envían correctamente a los servidores de nombres ascendentes mientras el sistema procesa a través de la lista de búsqueda de dominios. Estas consultas no válidas provocan retrasos en la resolución de nombres y pueden colocar una carga adicional en los servidores DNS ascendentes.

A partir de la versión de AKS v20241025, AKS configura CoreDNS para responder con NXDOMAIN en los dos casos siguientes para evitar que estas consultas de finalización de dominio de búsqueda no válidas se reenvíen al DNS ascendente:

  • Cualquier consulta para el dominio raíz o un subdominio de reddog.microsoft.com.
  • Cualquier consulta de un subdominio de internal.cloudapp.net que tenga siete o más etiquetas en el nombre de dominio.
    • Esta configuración permite que la resolución de máquinas virtuales por nombre de host siga siendo correcta. Por ejemplo, CoreDNS envía aks12345.myvnetid.myregion.internal.cloudapp.net (6 etiquetas) a Azure DNS, pero rechaza mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 etiquetas)

Este bloque se implementa en el bloque de servidor predeterminado en Corefile para el clúster. Si es necesario, esta configuración de rechazo se puede deshabilitar mediante la creación de bloques de servidor personalizados para el dominio adecuado con un complemento de reenvío habilitado:

  1. Cree un archivo denominado corednsms.yaml y pegue la siguiente configuración de ejemplo. Asegúrese de actualizar las direcciones IP y los nombres de host con los valores de su propio entorno.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    override-block.server:
       internal.cloudapp.net:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }
       reddog.microsoft.com:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }

  2. Cree ConfigMap con el comando kubectl apply configmap y especifique el nombre del manifiesto DE YAML.

    kubectl apply -f corednsms.yaml

  3. Para volver a cargar ConfigMap y habilitar el programador de Kubernetes para reiniciar CoreDNS sin tiempo de inactividad, realice un reinicio gradual mediante kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Solución de problemas

Para conocer los pasos generales de solución de problemas de CoreDNS, como comprobar los puntos de conexión o la resolución, consulte Depuración de la resolución de DNS.

Configuración del escalado horizontal de pods de CoreDNS

Los picos repentinos en el tráfico DNS dentro de los clústeres de AKS son una aparición común debido a la elasticidad que AKS proporciona para las cargas de trabajo. Estos picos pueden provocar un aumento del consumo de memoria por parte de los pods de CoreDNS. En algunos casos, este aumento del consumo de memoria podría causar problemas de tipo Out of memory. Para evitar este problema, los clústeres de AKS escalan automáticamente los pods de CoreDNS para reducir el uso de memoria por pod. La configuración predeterminada de esta lógica de escalabilidad automática se almacena en el ConfigMap coredns-autoscaler. Sin embargo, puede observar que la escalabilidad automática predeterminada de pods CoreDNS no siempre es lo suficientemente agresiva como para evitar problemas de tipo Out of memory para los pods de CoreDNS. En este caso, puede modificar directamente el ConfigMap coredns-autoscaler. Tenga en cuenta que, si simplemente aumenta el número de pods de CoreDNS sin solucionar la causa principal del problema Out of memory, esto solo puede proporcionar una corrección temporal. Si no hay suficiente memoria disponible en los nodos en los que se ejecutan los pods de CoreDNS, entonces no ayudará aumentar el número de pods de CoreDNS. Es posible que deba investigar más e implementar soluciones adecuadas, como optimizar el uso de recursos, ajustar las solicitudes y límites de recursos o agregar más memoria a los nodos.

CoreDNS usa el escalador automático proporcional del clúster horizontal para la escalabilidad automática de pods. El ConfigMap coredns-autoscaler se puede editar para configurar la lógica de escalabilidad para el número de pods de CoreDNS. Actualmente, el ConfigMap coredns-autoscaler admite dos valores de clave ConfigMap diferentes: linear y ladder que corresponden a dos modos de control admitidos. El controlador linear produce una serie de réplicas en el intervalo [min,max] equivalente a max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ). El controlador ladder calcula el número de réplicas al consultar dos funciones de paso diferentes, una para el escalado principal y otra para el escalado de nodos, lo que produce el máximo de los dos valores de réplica. Para obtener más información sobre los modos de control y el formato ConfigMap, consulte la documentación ascendente.

Importante

Se recomienda un mínimo de 2 réplicas de pod de CoreDNS por clúster. La configuración de un mínimo de 1 réplica de pod de CoreDNS puede producir errores durante las operaciones que requieren purga de nodos, como las operaciones de actualización del clúster.

Para recuperar el coredns-autoscaler ConfigMap, puede ejecutar el comando kubectl get configmap coredns-autoscaler -n kube-system -o yaml que devolverá lo siguiente:

apiVersion: v1
data:
  ladder: '{"coresToReplicas":[[1,2],[512,3],[1024,4],[2048,5]],"nodesToReplicas":[[1,2],[8,3],[16,4],[32,5]]}'
kind: ConfigMap
metadata:
  name: coredns-autoscaler
  namespace: kube-system
  resourceVersion: "..."
  creationTimestamp: "..."

Comportamiento de escalado automático de pods verticales de CoreDNS

CoreDNS es un complemento esencial administrado por AKS y habilitado de forma predeterminada. Para mantener la disponibilidad del servicio CoreDNS, CoreDNS mantiene el uso de las solicitudes o límites de recursos proporcionados originalmente al habilitar la característica de escalado automático del complemento para evitar que el proceso de reinicio del pod de CoreDNS provoque la falta de disponibilidad del servicio.

Para el complemento CoreDNS administrado de AKS, las solicitudes o límites de CPU predeterminados se establecen en 100 m /3 núcleos y las solicitudes o límites de memoria en 70Mi/500Mi. En función de estos valores predeterminados, la relación de solicitud a límite para la CPU es aproximadamente 1:30 y, para la memoria, es aproximadamente 1/7. Si las solicitudes de CPU recomendadas son de 500 m, el VPA ajusta los límites de CPU a 15 para mantener esta relación. Del mismo modo, si las solicitudes de memoria recomendadas son 700Mi, VPA ajusta el límite de memoria a 5000Mi.

VPA establece los límites de CPU y memoria de CoreDNS en valores grandes basándose en la solicitud de CPU/Memoria recomendada por VPA y la relación entre la solicitud y el límite definida por AKS. Estos ajustes son beneficiosos para controlar varias solicitudes durante las horas punta del servicio. El inconveniente es que CoreDNS podría consumir todos los recursos de CPU y memoria disponibles en el nodo en los momentos de máxima demanda.

Es difícil establecer un único valor ideal de solicitudes y límites de CPU y memoria para cumplir los requisitos del clúster grande y el clúster pequeño al mismo tiempo. Al habilitar el escalado optimizado de complementos, tiene la flexibilidad de personalizar las solicitudes y límites de CPU y memoria de CoreDNS o usar VPA para escalar automáticamente CoreDNS para cumplir requisitos específicos del clúster. Estos son algunos escenarios que se deben tener en cuenta:

  • Está pensando en si VPA es adecuado para el servicio CoreDNS y desea ver solo las recomendaciones de VPA. Para deshabilitar VPA para CoreDNS, habilite el modo de actualización de VPA de invalidación en Desactivado si no desea que VPA actualice automáticamente los pods. Personalice la configuración de recursos en Implementación para establecer los límites o solicitudes de CPU/memoria en el valor que prefiera.
  • Está pensando en usar VPA, pero quiere restringir la proporción de solicitud a límite, por lo que VPA no aumentará el límite de CPU y memoria a valores grandes al mismo tiempo. Puede personalizar los recursos de la implementación y actualizar el valor de solicitudes y límites de CPU y memoria para mantener la relación de solicitud a límite a 1/2 o 1/3.
  • Si una política de contenedor VPA establece límites máximos permitidos para la CPU y la memoria, las solicitudes de recursos recomendadas no superarán esos límites. La personalización de la configuración de recursos permite aumentar o disminuir los valores maxAllowed y controlar las recomendaciones de VPA.

Para obtener más información, consulte Habilitación del escalado automático de complementos en el clúster de AKS (versión preliminar).

Habilitación del registro de consultas DNS

  1. Agregue la siguiente configuración a su ConfigMap coredns-custom:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  log.override: | # you may select any name here, but it must end with the .override file extension
        log

  2. Aplique los cambios de configuración y obligue a CoreDNS a recargar ConfigMap con los comandos siguientes:

    # Apply configuration changes
kubectl apply -f corednsms.yaml

# Force CoreDNS to reload the ConfigMap
kubectl -n kube-system rollout restart deployment coredns

  3. Vea el registro de depuración de CoreDNS con el comando kubectl logs.

    kubectl logs --namespace kube-system -l k8s-app=kube-dns

Solución de problemas de desequilibrio de tráfico de pods de CoreDNS

Puede observar que uno o dos pods de CoreDNS muestran un uso de CPU significativamente mayor y controlan más consultas DNS que otras, aunque varios pods de CoreDNS se ejecutan en el clúster de AKS. Se trata de un problema conocido en Kubernetes y puede provocar que uno de los pods de CoreDNS se sobrecargue y bloquee.

Esta distribución desigual de las consultas DNS se debe principalmente a las limitaciones de equilibrio de carga udp en Kubernetes. La plataforma usa un hash de cinco tuplas (IP de origen, puerto de origen, IP de destino, puerto de destino, protocolo) para distribuir el tráfico UDP, por lo que si una aplicación reutiliza el mismo puerto de origen para las consultas DNS, todas las consultas de ese cliente se enrutarán al mismo pod de CoreDNS, lo que da lugar a que un único pod controle una cantidad desproporcionada de tráfico.

Además, algunas aplicaciones usan la agrupación de conexiones y reutilizan las conexiones DNS. Este comportamiento puede concentrar aún más las consultas DNS en un único pod de CoreDNS, lo que agrava el desequilibrio y aumenta el riesgo de sobrecargar y posibles bloqueos.

Comprobación de la distribución del tráfico de pods de CoreDNS

Antes de comenzar, siga los pasos descritos en la sección Habilitación del registro de consultas DNS anterior para capturar los registros de consultas DNS necesarios desde pods de CoreDNS. Una vez habilitado, ejecute los siguientes comandos:

  1. Ejecute el comando siguiente para obtener los nombres de todos los pods de CoreDNS del clúster:

    kubectl get pods --namespace kube-system -l k8s-app=kube-dns

  2. Revise los registros de cada pod de CoreDNS para analizar patrones de consulta DNS:

    kubectl logs --namespace kube-system <coredns-pod1>
kubectl logs --namespace kube-system <coredns-pod2>
# Repeat on all CoreDNS pods

  3. Busque direcciones IP y puertos de cliente repetidos que solo aparecen en los registros de un único pod de CoreDNS. Esto indica que las consultas DNS de determinados clientes no se distribuyen uniformemente.

    Entrada de registro de ejemplo:

    [INFO] 10.244.0.247:5556 - 42621 "A IN myservice.default.svc.cluster.local. udp 28" NOERROR qr,aa,rd 106 0.000141s
    • 10.244.0.247: dirección IP de cliente que realiza la consulta DNS
    • 5556: puerto de origen de cliente
    • 42621: identificador de consulta

    Si ve la misma dirección IP de cliente y puerto repetidamente en solo los registros de un pod, esto confirma un desequilibrio de tráfico.

Si observa este desequilibrio, la aplicación podría reutilizar los puertos de origen UDP o agrupar sus conexiones. En función de la causa principal, puede realizar las siguientes acciones de mitigación:

  • Causado por la reutilización del puerto de origen UDP:

    La reutilización del puerto de origen UDP se produce cuando una aplicación cliente envía varias consultas DNS desde el mismo puerto de origen UDP. Si se trata del problema, actualice las aplicaciones o los clientes DNS para que aleatorifiquen los puertos de origen de cada consulta DNS, lo que ayuda a distribuir las solicitudes de forma más uniforme entre pods.

  • Causado por la agrupación de conexiones:
    Los grupos de conexiones son mecanismos utilizados por las aplicaciones para reutilizar las conexiones de red existentes en lugar de crear una nueva conexión para cada solicitud. Aunque esto mejora la eficacia, puede dar lugar a que todas las consultas DNS de una aplicación se envíen a través de la misma conexión y, por tanto, se enrutan al mismo pod de CoreDNS. Para mitigar esto, ajuste el control de conexiones DNS de la aplicación mediante la reducción de los TTL de conexión (período de vida) o la creación aleatoria de conexiones, lo que garantiza que las consultas no se concentran en un único pod de CoreDNS.

Estos cambios pueden ayudar a lograr una distribución de consultas DNS más equilibrada y reducir el riesgo de sobrecargar pods individuales.

Pasos siguientes

En este artículo se han mostrado algunos escenarios de ejemplo para la personalización de CoreDNS. Para obtener información sobre el proyecto CoreDNS, consulte la página de proyecto del canal de subida de CoreDNS.

Para obtener más información sobre conceptos básicos de red, consulte Conceptos de redes de aplicaciones en Azure Kubernetes Service (AKS).