Compartir vía

Personalización de CoreDNS con Azure Kubernetes Service

  • Artículo

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 del canal de subida.

AKS es un servicio administrado, así que no puede modificar la configuración principal para CoreDNS (un archivo CoreFile). En vez de eso, use un archivo ConfigMap de 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 ofrecía opciones de personalización diferentes a través de una asignación de configuración de Kubernetes. CoreDNS no es compatible con versiones anteriores de kube-dns. Todas las personalizaciones que usaba anteriormente deben actualizarse para CoreDNS.

Antes de empezar

  • En este artículo se supone que ya tiene un clúster de AKS. 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.

Compatibilidad con complementos

Se admiten todos los complementos de CoreDNS integrados. No se admiten los complementos de terceros o complementarios.

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 el ConfigMap mediante el comando kubectl apply configmap y especifique el nombre de su manifiesto de YAML.

    kubectl apply -f corednsms.yaml

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

    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 tiene que especificar un servidor de reenvío para el tráfico de red, puede crear un elemento ConfigMap para personalizar el 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 el ConfigMap mediante el comando kubectl apply configmap y especifique el nombre de su 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 le interese 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 archivo 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 el ConfigMap mediante el comando kubectl apply configmap y especifique el nombre de su 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

También se puede usar CoreDNS 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 el ConfigMap mediante el comando kubectl apply configmap y especifique el nombre de su 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 el complemento de hosts de CoreDNS también se puede 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 el ConfigMap mediante el comando kubectl apply configmap y especifique el nombre de su 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 el ConfigMap mediante el comando kubectl apply configmap y especifique el nombre de su 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

Solucionar problemas

Para ver 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 de escalabilidad de pods de CoreDNS

Los picos repentinos en el tráfico DNS dentro de los clústeres de AKS son una repetició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 más información sobre los modos de control y el formato de 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 ConfigMap coredns-autoscaler, 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: "..."

Habilitación del registro de consultas DNS

  1. Agregue la siguiente configuración al 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

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).