Container Service for Kubernetes:Best practices for DNS in Kubernetes clusters

Las mejores prácticas de DNS abarcan el lado del cliente y el lado del servidor:

• En el lado del cliente, reduzca la latencia de resolución mediante la optimización de las solicitudes de resolución de nombres de dominio. Minimice las anomalías de resolución con imágenes de contenedor adecuadas, sistemas operativos de nodo apropiados y NodeLocal DNSCache.

  • Optimize domain name resolution requests

  • Understand DNS configuration in containers

  • Avoid intermittent DNS resolution timeouts caused by IPVS defects

  • Use NodeLocal DNSCache

  • Use an appropriate CoreDNS version

• En el lado del servidor CoreDNS, supervise el estado de ejecución para detectar anomalías de DNS e identificar sus causas raíz. Mejore la alta disponibilidad de CoreDNS y el rendimiento de consultas por segundo (QPS) al ajustar la configuración de despliegue.

  • Monitor CoreDNS runtime status

    • Monitoring metrics

    • Operational logs

    • Kubernetes event delivery

  • Ensure CoreDNS high availability

    • Assess CoreDNS add-on pressure

    • Adjust the number of CoreDNS pods

    • Adjust CoreDNS pod specifications

    • Schedule CoreDNS pods

  • Optimize CoreDNS configuration

    • Disable affinity settings for the kube-dns service

    • Disable the Autopath plugin

    • Configure graceful shutdown for CoreDNS

    • Set the default protocol for the Forward plugin to communicate with upstream VPC DNS servers

    • Configure the Ready readiness probe plugin

La resolución de DNS es una de las actividades de red más frecuentes en Kubernetes. Muchas solicitudes se pueden optimizar o evitar:

• (Recomendado) Utilice grupos de conexiones. Si una aplicación en contenedores accede con frecuencia a otro servicio, almacene en caché las conexiones ascendentes en memoria para evitar la resolución de DNS y la configuración de TCP en cada acceso.

• Utilice sondeos asíncronos o prolongados para obtener la dirección IP de un nombre de dominio DNS.

• Utilice la caché de DNS:

  • (Recomendado) Si su aplicación no puede usar grupos de conexiones, almacene en caché los resultados de la resolución de DNS en el lado de la aplicación o use NodeLocal DNSCache.

  • Si NodeLocal DNSCache no está disponible, almacene en caché las consultas de DNS dentro del contenedor con Name Service Cache Daemon (NSCD). Consulte Uso de NSCD en clústeres de Kubernetes.

• Optimice el archivo resolv.conf: los parámetros ndots y search afectan la eficiencia de la resolución según la forma en que escriba los nombres de dominio en las configuraciones del contenedor. Consulte DNS policy configuration and domain name resolution para obtener detalles sobre ndots y search.

• Optimice la configuración del nombre de dominio para minimizar los intentos de resolución y reducir el tiempo de resolución:

  • Para acceder a un Service en el mismo namespace, utilice <service-name>, donde service-name es el nombre del Service.

  • Para acceder a un Service entre distintos namespaces, utilice <service-name>.<namespace-name>, donde namespace-name es el namespace del Service.

  • Para dominios externos, utilice nombres de dominio completos (FQDN). Agregue un punto final (.) para especificar direcciones absolutas y evitar la concatenación no válida de dominios de search. Por ejemplo, utilice www.aliyun.com. en lugar de www.aliyun.com.

    • En clústeres con versión 1.33 o posterior, establezca el dominio de búsqueda como un único "." (consulte 125883) para lograr un efecto similar:

      dnsPolicy: None
      dnsConfig:
        nameservers: ["192.168.0.10"]  ## Replace 192.168.0.10 with the actual CoreDNS service clusterIP
        searches:
        - .
        - default.svc.cluster.local  ## Replace "default" with your namespace name
        - svc.cluster.local
        - cluster.local

      Después de aplicar esta configuración, el archivo /etc/resolv.conf del pod se muestra de la siguiente manera:

      search . default.svc.cluster.local svc.cluster.local cluster.local
      nameserver 192.168.0.10

      Un "." como primer dominio de búsqueda trata todas las solicitudes de dominio como FQDN y las resuelve directamente sin intentos de búsqueda innecesarios.

      Importante

      Establezca dnsPolicy en None para que esta configuración surta efecto.

      Ejemplo completo de carga de trabajo

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: nginx
        name: nginx
        namespace: default
      spec:
        progressDeadlineSeconds: 600
        replicas: 3
        revisionHistoryLimit: 10
        selector:
          matchLabels:
            app: nginx
        strategy:
          rollingUpdate:
            maxSurge: 25%
            maxUnavailable: 25%
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
            - image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
              imagePullPolicy: Always
              name: nginx
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
            dnsPolicy: None
            dnsConfig:
              nameservers: ["192.168.0.10"]  ## Replace 192.168.0.10 with the actual CoreDNS service clusterIP
              searches:
              - .
              - default.svc.cluster.local
              - svc.cluster.local
              - cluster.local
            hostname: nginx
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            subdomain: subdomain
            terminationGracePeriodSeconds: 30

Reduzca el impacto de los defectos de IPVS con uno de estos métodos:

• Use NodeLocal DNSCache.

• Modifique el tiempo de espera de persistencia de sesión UDP de IPVS en kube-proxy. Consulte How do I modify the IPVS UDP session persistence timeout in kube-proxy?.

CoreDNS mantiene una buena compatibilidad con versiones anteriores en distintas versiones de Kubernetes. Mantenga CoreDNS en una versión reciente y estable. La página Component Management de la consola de ACK proporciona funciones de instalación, actualización y configuración. Supervise el estado del componente y actualice CoreDNS durante las horas de menor actividad cuando haya una actualización disponible.

• Consulte Automatic upgrade for non-managed CoreDNS para ver las instrucciones de actualización.

• Consulte las notas de la versión en CoreDNS.

Las versiones de CoreDNS anteriores a v1.7.0 presentan riesgos conocidos, entre los que se incluyen, sin limitarse a ellos:

• Si falla la conectividad entre CoreDNS y el servidor de API durante un reinicio del servidor de API, una migración o inestabilidad de la red, CoreDNS puede reiniciarse porque no logra escribir los registros de error. Consulte Set klog's logtostderr flag.

• CoreDNS consume memoria adicional durante el inicio. El límite de memoria predeterminado puede desencadenar problemas de falta de memoria (OOM) en clústeres grandes, lo que provoca que los pods de CoreDNS se reinicien repetidamente sin recuperarse. Consulte CoreDNS uses a lot of memory during initialization phase.

• CoreDNS tiene problemas conocidos que afectan a los dominios de Headless Service y a la resolución de dominios externos. Consulte plugin/kubernetes: handle tombstones in default processor y Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection.

• Si un nodo presenta anomalías, las versiones antiguas de CoreDNS pueden desplegar pods en ese nodo debido a las políticas de tolerancia predeterminadas. Estos pods podrían no evacuarse automáticamente, lo que causa errores de resolución de dominios.

La versión mínima recomendada de CoreDNS depende de la versión del clúster de Kubernetes:

Métricas de monitoreo

CoreDNS expone métricas de estado, como los resultados de resolución, a través de una interfaz estándar de Prometheus para ayudar a detectar anomalías en CoreDNS o en los servidores de DNS ascendentes.

Prometheus for ACK incluye métricas de monitoreo y reglas de alerta integradas para CoreDNS. Habilite Prometheus y Dashboard en la consola de Container Service for Kubernetes. Consulte CoreDNS component monitoring.

Si utiliza una instancia de Prometheus autogestionada, observe las métricas relevantes y configure alertas para las críticas. Consulte la documentación oficial de Prometheus para CoreDNS.

Registros de operación

Utilice los registros de CoreDNS para diagnosticar las causas raíz cuando ocurran anomalías de DNS. Habilite los registros de resolución de dominios y la recopilación de registros de SLS. Consulte Analyze and monitor CoreDNS logs.

Entrega de eventos de Kubernetes

En CoreDNS v1.9.3.6-32932850-aliyun y versiones posteriores, habilite el plugin k8s_event para entregar los registros críticos de CoreDNS como eventos de Kubernetes al Event Hub. Consulte la documentación del plugin k8s_event.

Las instancias de CoreDNS recién desplegadas tienen esta función habilitada de forma predeterminada. Al actualizar desde una versión anterior, modifique manualmente el archivo de configuración para habilitarla.

1. Abra el archivo de configuración de CoreDNS:

   kubectl -n kube-system edit configmap/coredns

2. Agregue los plugins kubeAPI y k8s_event.

   apiVersion: v1
   data:
     Corefile: |
       .:53 {
           errors
           health {
               lameduck 15s
           }
           // Begin addition (ignore other differences).
           kubeapi
           k8s_event {
             level info error warning // Deliver critical logs with info, error, or warning levels.
           }
           // End addition.
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // Omitted below.
       }

3. Compruebe el estado y los registros del pod de CoreDNS. Si los registros contienen la palabra reload, la modificación fue exitosa.

Evaluar la presión sobre el componente CoreDNS

Ejecute pruebas de estrés de DNS para evaluar la presión sobre el complemento CoreDNS. Las herramientas de código abierto como DNSPerf pueden ayudarle. Si no puede evaluar con precisión la presión de DNS, siga estas recomendaciones:

• Despliegue como mínimo dos pods de CoreDNS, cada uno con límites de recursos de como mínimo 1 núcleo de CPU y 1 GB de memoria.

• La capacidad de QPS de CoreDNS se relaciona con el uso de CPU. Con NodeLocal DNSCache, cada núcleo de CPU admite más de 10,000 QPS. Los QPS de DNS de la carga de trabajo del negocio varían significativamente. Supervise el uso máximo de CPU por cada pod de CoreDNS y aumente las réplicas cuando el uso supere un núcleo durante los periodos pico. Si desconoce el uso máximo, despliegue un pod de CoreDNS por cada ocho nodos del clúster como medida conservadora.

Ajustar la cantidad de pods de CoreDNS

La cantidad de pods de CoreDNS determina directamente los recursos de cómputo disponibles. Ajústela según su evaluación.

• Ajustar automáticamente la cantidad de pods según las políticas recomendadas

  Despliegue el siguiente recurso dns-autoscaler. Este ajusta la cantidad de pods de CoreDNS en tiempo real con una proporción de un pod por cada ocho nodos del clúster. Cantidad de réplicas: replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)), restringida por los límites max y min.

  dns-autoscaler

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: dns-autoscaler
    namespace: kube-system
    labels:
      k8s-app: dns-autoscaler
  spec:
    selector:
      matchLabels:
        k8s-app: dns-autoscaler
    template:
      metadata:
        labels:
          k8s-app: dns-autoscaler
      spec:
        serviceAccountName: admin
        containers:
        - name: autoscaler
          image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
          resources:
            requests:
              cpu: "200m"
              memory: "150Mi"
          command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=dns-autoscaler
          - --nodelabels=type!=virtual-kubelet
          - --target=Deployment/coredns
          - --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
          - --logtostderr=true
          - --v=9

• Ajustes manuales

  Ajuste manualmente la cantidad de pods de CoreDNS:

  kubectl scale --replicas={target} deployment/coredns -n kube-system # Replace {target} with the desired pod count

• No utilizar el escalado automático de cargas de trabajo

  Los mecanismos de escalado automático de cargas de trabajo, como el escalado horizontal de pods (HPA) o CronHPA, desencadenan operaciones de escalado frecuentes. Debido a las anomalías de resolución durante la reducción de escala de pods, no utilice el escalado automático de cargas de trabajo para los pods de CoreDNS.

Ajustar las especificaciones de los pods de CoreDNS

Modifique las especificaciones de los pods para ajustar los recursos de CoreDNS. En los clústeres administrados de ACK Pro, los pods de CoreDNS tienen un límite de memoria predeterminado de 2Gi y ningún límite de CPU. Establezca el límite de CPU en 4096m, con un mínimo de 1024m. Ajuste la configuración de los pods de CoreDNS en la consola.

Programar pods de CoreDNS

Despliegue los pods de CoreDNS en varias zonas y nodos para evitar fallos de un solo nodo o de una sola zona. Las versiones de CoreDNS anteriores a v1.8.4.3 utilizan antiafinidad de nodo débil de forma predeterminada, lo que puede colocar todos los pods en el mismo nodo cuando los recursos son insuficientes. Elimine los pods para desencadenar una nueva programación o actualice a la última versión del componente. Las versiones de CoreDNS anteriores a v1.8 ya no reciben mantenimiento. Actualice lo antes posible.

Evite desplegar CoreDNS en nodos con uso total de CPU o memoria, ya que esto afecta los QPS de DNS y la latencia de respuesta. Utilice parámetros personalizados para programar CoreDNS en nodos dedicados y lograr una resolución de nombres de dominio estable.

Las configuraciones predeterminadas de CoreDNS de versiones antiguas de Kubernetes pueden presentar riesgos. Compruébelas y optimícelas de la siguiente manera:

• Disable affinity settings for the kube-dns service

• Disable the Autopath plugin

• Configure graceful shutdown for CoreDNS

• Set the default protocol for the Forward plugin to communicate with upstream VPC DNS servers

• Configure the Ready readiness probe plugin

Deshabilitar la configuración de afinidad para el servicio kube-dns

Deshabilitar el plugin Autopath

Algunas versiones antiguas de CoreDNS tienen habilitado el plugin Autopath, lo que puede producir resultados de resolución incorrectos en escenarios extremos. Compruebe si el plugin está habilitado y deshabilítelo al editar el archivo de configuración. Consulte Autopath.

1. Abra el archivo de configuración de CoreDNS con kubectl -n kube-system edit configmap coredns.

2. Elimine la línea autopath @kubernetes y guarde el cambio.

3. Compruebe el estado y los registros del pod de CoreDNS. Si los registros contienen la palabra reload, la modificación fue exitosa.

Configurar el apagado controlado para CoreDNS

El mecanismo lameduck de CoreDNS habilita el apagado controlado. Cuando CoreDNS se detiene o se reinicia, las solicitudes en curso se completan con normalidad en lugar de interrumpirse de forma abrupta. El mecanismo lameduck funciona de la siguiente manera:

• Cuando CoreDNS finaliza, entra en modo Lameduck.

• En el modo lameduck, CoreDNS deja de aceptar nuevas solicitudes. Sin embargo, continúa procesando las solicitudes existentes hasta que se completen o hasta que expire el tiempo de espera de lameduck.

Establecer el protocolo predeterminado para que el plugin Forward se comunique con los servidores DNS de VPC

NodeLocal DNSCache se comunica con CoreDNS mediante TCP. CoreDNS utiliza el mismo protocolo de las solicitudes entrantes cuando se comunica con los servidores DNS ascendentes. De forma predeterminada, las solicitudes de resolución de dominios externos desde los contenedores de aplicaciones pasan por NodeLocal DNSCache y CoreDNS. Después llegan a los servidores DNS de VPC (100.100.2.136 y 100.100.2.138) a través de TCP.

# Before modification
forward . /etc/resolv.conf
# After modification
forward . /etc/resolv.conf {
  prefer_udp
}

Configurar el plugin de sondeo de disponibilidad Ready

Las versiones de CoreDNS posteriores a la 1.5.0 requieren el plugin ready para habilitar los sondeos de disponibilidad.

1. Abra el archivo de configuración de CoreDNS:

   kubectl -n kube-system edit configmap/coredns

2. Compruebe si existe la línea ready. Si no está presente, agregue ready. Presione Esc, escriba :wq! y luego presione Enter para guardar el cambio y salir.

   apiVersion: v1
   data:
    Corefile: |
     .:53 {
       errors
       health {
         lameduck 15s
       }
       ready # Add this line if missing, ensuring consistent indentation with Kubernetes.
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods verified
         fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf {
         max_concurrent 1000
               prefer_udp
       }
       cache 30
       loop
       log
       reload
       loadbalance
     }

3. Compruebe el estado y los registros del pod de CoreDNS. Si los registros contienen la palabra reload, la modificación fue exitosa.

Configurar el plugin multisocket para mejorar el rendimiento de resolución de CoreDNS

CoreDNS v1.12.1 introdujo el plugin multisocket. Cuando se habilita, CoreDNS utiliza varios sockets para escuchar en el mismo puerto, lo que mejora el rendimiento en escenarios con un alto consumo de CPU. Consulte la documentación de la comunidad.

Habilite multisocket en el ConfigMap coredns:

.:53 {
        ...
        prometheus :9153
        multisocket [NUM_SOCKETS]
        forward . /etc/resolv.conf
        ...
}

NUM_SOCKETS especifica la cantidad de sockets que escuchan en el mismo puerto.

Alinee NUM_SOCKETS con el uso estimado de CPU, los límites de recursos de CPU y los recursos disponibles del clúster. Por ejemplo:

• Si CoreDNS consume 4 núcleos en su punto máximo y hay 8 núcleos disponibles, establezca NUM_SOCKETS en 2.

• Si CoreDNS consume 8 núcleos en su punto máximo y hay 64 núcleos disponibles, establezca NUM_SOCKETS en 8.

Pruebe diferentes configuraciones y mida las QPS y la carga para determinar la configuración óptima.

Si no especifica NUM_SOCKETS, CoreDNS utiliza GOMAXPROCS de forma predeterminada. Este valor equivale al límite de CPU del pod de CoreDNS o a la cantidad de núcleos de CPU del nodo cuando no se establece ningún límite.