Configurar NodeLocal DNSCache

Autopilot Estándar

En esta página, se explica cómo mejorar la latencia de búsqueda de DNS en un clúster de Google Kubernetes Engine (GKE) con NodeLocal DNSCache.

En el caso de los clústeres de Autopilot de GKE, NodeLocal DNSCache está habilitado de forma predeterminada y no se puede anular.

Arquitectura

NodeLocal DNSCache es un complemento de GKE que puedes ejecutar además de kube-dns.

GKE implementa NodeLocal DNSCache como un DaemonSet que ejecuta una caché de DNS en cada nodo de tu clúster.

Cuando un Pod realiza una solicitud de DNS, la solicitud va a la caché de DNS que se ejecuta en el mismo nodo que el Pod. Si la caché no puede resolver la solicitud de DNS, la caché reenvía la solicitud a uno de los siguientes lugares según el destino de la consulta:

kube-dns: todas las consultas para el dominio DNS del clúster (cluster.local) se reenvían a kube-dns. Los Pods node-local-dns usan el Service kube-dns-upstream para acceder a los Pods kube-dns. En el siguiente diagrama, la dirección IP del servicio de kube-dns es 10.0.0.10:53.
Dominios de stub personalizados o servidores de nombres ascendentes: las consultas se reenvían directamente desde los Pods de NodeLocal DNSCache.
Cloud DNS: todas las demás consultas se reenvían al servidor de metadatos local que se ejecuta en el mismo nodo que el pod desde el que se originó la consulta. El servidor de metadatos local accede a Cloud DNS.

La ruta de acceso de una solicitud de DNS, como se describe en el párrafo anterior

Cuando habilitas NodeLocal DNSCache en un clúster existente, GKE vuelve a crear todos los nodos del clúster que ejecutan la versión 1.15 y posteriores de GKE según el proceso de actualización de nodos.

Después de que GKE vuelve a crear los nodos, GKE agrega de forma automática la etiqueta addon.gke.io/node-local-dns-ds-ready=true a los nodos. No debes agregar esta etiqueta a los nodos del clúster de forma manual.

Beneficios de NodeLocal DNSCache

NodeLocal DNSCache proporciona los siguientes beneficios:

Tiempo de búsqueda de DNS promedio reducido
Las conexiones desde los pods a su caché local no crean entradas de tabla conntrack. Esto evita las conexiones caídas y rechazadas causadas por el agotamiento de la tabla de Conntrack y las condiciones de carrera.
Puedes usar NodeLocal DNSCache con Cloud DNS para GKE.
Las consultas de DNS para URL externas (URL que no hacen referencia a recursos de clúster) se reenvían directamente al servidor de metadatos local de Cloud DNS, sin pasar por kube-dns.
Las cachés de DNS locales recogen de forma automática los dominios de stub y los servidores de nombres ascendentes que se especifican en kube-dns ConfigMap.

Requisitos y limitaciones

NodeLocal DNSCache consume recursos de procesamiento en cada nodo de tu clúster.

NodeLocal DNSCache no es compatible con los grupos de nodos de Windows Server.

NodeLocal DNSCache requiere GKE versión 1.15 o superior.
NodeLocal DNSCache accede a los pods kube-dns a través de TCP.
NodeLocal DNSCache accede a upstreamServers y stubDomains mediante TCP y UDP en las versiones 1.18 o posteriores de GKE. Se debe poder acceder al servidor DNS con TCP y UDP.
Los registros DNS se almacenan en caché durante los siguientes períodos:
- El tiempo de actividad (TTL) del registro o 30 segundos si el TTL es más de 30 segundos.
- 5 segundos si la respuesta de DNS es NXDOMAIN.
Los Pods de NodeLocal DNSCache escuchan en los puertos 53, 9253, 9353 y 8080 en los nodos. Si ejecutas cualquier otro Pod hostNetwork o configuras un hostPorts con esos puertos, NodeLocal DNSCache falla y se producen errores de DNS. Los Pods de NodeLocal DNSCache no usan el modo hostNetwork cuando se usan GKE Dataplane V2 y Cloud DNS para GKE.
La caché de DNS local solo se ejecuta en grupos de nodos que ejecutan la versión 1.15 de GKE y versiones posteriores. Si habilitas NodeLocal DNSCache en un clúster con nodos que ejecutan versiones anteriores, los Pods en esos nodos usan kube-dns.

Habilitar NodeLocal DNSCache

En el caso de los clústeres de Autopilot, NodeLocal DNSCache está habilitado de forma predeterminada y no se puede anular.

Para los clústeres de Standard, puedes habilitar NodeLocal DNSCache en clústeres nuevos o existentes con Google Cloud CLI. Puedes habilitar NodeLocal DNSCache en clústeres nuevos mediante la consola de Google Cloud.

gcloud

Habilita NodeLocal DNSCache en un clúster nuevo

Para habilitar NodeLocal DNSCache en un clúster nuevo, usa la marca --addons con el argumento NodeLocalDNS:

gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --addons=NodeLocalDNS

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre del clúster nuevo.
COMPUTE_LOCATION: La ubicación del Compute Engine del clúster.

Habilita NodeLocal DNSCache en un clúster existente

Para habilitar NodeLocal DNSCache en un clúster existente, usa la marca --update-addons con el argumento NodeLocalDNS=ENABLED:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=NodeLocalDNS=ENABLED

Reemplaza lo siguiente:

CLUSTER_NAME: El nombre de tu clúster.

Console

Para habilitar NodeLocal DNSCache en un clúster nuevo, sigue estos pasos:

Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

Ir a Google Kubernetes Engine
Junto a Estándar, haz clic en Configurar.
Configura tu clúster como desees.
En el panel de navegación, haz clic en Herramientas de redes.
En la sección Opciones avanzadas de redes, selecciona la casilla de verificación Habilitar NodeLocal DNSCache.
Haz clic en Crear.

Verifica que NodeLocal DNSCache esté habilitado

Para verificar que NodeLocal DNSCache se esté ejecutando, enumera los pods node-local-dns.

kubectl get pods -n kube-system -o wide | grep node-local-dns

El resultado es similar al siguiente:

node-local-dns-869mt    1/1   Running   0   6m24s   10.128.0.35   gke-test-pool-69efb6b8-5d7m   <none>   <none>
node-local-dns-htx4w    1/1   Running   0   6m24s   10.128.0.36   gke-test-pool-69efb6b8-wssk   <none>   <none>
node-local-dns-v5njk    1/1   Running   0   6m24s   10.128.0.33   gke-test-pool-69efb6b8-bhz3   <none>   <none>

El resultado muestra un pod node-local-dns para cada nodo que ejecuta la versión 1.15 o posterior de GKE.

Inhabilita NodeLocal DNSCache

Para inhabilitar NodeLocal DNSCache, usa el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=NodeLocalDNS=DISABLED

Reemplaza lo siguiente:

CLUSTER_NAME: el nombre del clúster que se inhabilitará.

Soluciona problemas de NodeLocal DNSCache

Para obtener información general sobre el diagnóstico de problemas de DNS de Kubernetes, consulta Depuración de la resolución de DNS.

NodeLocal DNSCache no se habilita de inmediato

Cuando habilitas NodeLocal DNSCache en un clúster existente, es posible que GKE no actualice los nodos de inmediato si el clúster tiene una exclusión o un período de mantenimiento configurado. Si deseas obtener más información, consulta Advertencias para los períodos de mantenimiento y recreación de nodos.

Si no quieres esperar, puedes aplicar los cambios a los nodos de forma manual. Para ello, llama al comando gcloud container clusters upgrade y pasa la marca --cluster-version con la misma versión de GKE que el grupo de nodos ya ejecuta. Debes usar Google Cloud CLI para esta solución alternativa.

NodeLocal DNSCache con Cloud DNS

Si usas NodeLocal DNSCache con Cloud DNS, el clúster usa la dirección IP del servidor de nombres 169.254.20.10, como se muestra en el siguiente diagrama:

NodeLocal DNSCache con la arquitectura de Cloud DNS

Como resultado, la dirección IP del servicio kube-dns puede ser diferente de la dirección IP del servidor de nombres que usan tus Pods. Se espera esta diferencia en las direcciones IP, ya que la dirección IP del servidor de nombres 169.254.20.10 es necesaria para que Cloud DNS funcione correctamente.

Para verificar las direcciones IP, ejecuta los siguientes comandos:

Consulta la dirección IP del servicio kube-dns:
```
kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"
```
El resultado es la dirección IP de kube-dns, como 10.0.0.10:53.
Abre una sesión de shell en tu Pod:
```
kubectl exec -it POD_NAME -- /bin/bash
```
En la sesión de shell del Pod, lee el contenido del archivo /etc/resolv.conf:
```
cat /etc/resolv.conf
```
El resultado es 169.254.20.10

Política de red con NodeLocal DNSCache

Si usas la política de red con NodeLocal DNSCache y no usas Cloud DNS ni GKE Dataplane V2, debes configurar reglas para permitir que tus cargas de trabajo y los Pods node-local-dns envíen consultas de DNS.

Usa una regla ipBlock en tu manifiesto para permitir la comunicación entre los Pods y kube-dns.

En el siguiente manifiesto, se describe una política de red que usa una regla ipBlock:

spec:
  egress:
  - ports:
    - port: 53
      protocol: TCP
    - port: 53
      protocol: UDP
    to:
    - ipBlock:
        cidr: KUBE_DNS_SVC_CLUSTER_IP/32
  podSelector: {}
  policyTypes:
    - Egress

Reemplaza KUBE_DNS_SVC_CLUSTER_IP por la dirección IP del servicio kube-dns. Puedes obtener la dirección IP del servicio kube-dns mediante el siguiente comando:

kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"

Problemas conocidos

Tiempo de espera de DNS en ClusterFirstWithHostNet dnsPolicy cuando se usa NodeLocal DNSCache y GKE Dataplane V2

En los clústeres que usan GKE Dataplane V2 y NodeLocal DNSCache, los Pods con hostNetwork establecido en true y dnsPolicy configurados en ClusterFirstWithHostNet no pueden alcanzar los backends de DNS del clúster. Los registros DNS pueden contener entradas similares a las siguientes:

nslookup: write to 'a.b.c.d': Operation not permitted

;; connection timed out; no servers could be reached

El resultado indica que las solicitudes de DNS no pueden llegar a los servidores de backend.

Una solución alternativa es configurar los siguientes dnsPolicy y dnsConfig para los pods hostNetwork:

spec:
 dnsPolicy: "None"
 dnsConfig:
   nameservers:
     - KUBE_DNS_UPSTREAM
   searches:
     - cluster.local
     - svc.cluster.local
     - NAMESPACE.svc.cluster.local
     - c.PROJECT_ID.internal
     - google.internal
   options:
     - name: ndots
       value: "5"

Reemplaza lo siguiente:

NAMESPACE: Es el espacio de nombres del Pod hostNetwork.
PROJECT_ID: El ID del proyecto de Google Cloud.
KUBE_DNS_UPSTREAM: El ClusterIP del servicio ascendente de kube-dns. Puedes obtener este valor mediante el siguiente comando:
```
kubectl get svc -n kube-system kube-dns-upstream -o jsonpath="{.spec.clusterIP}"
```

Las solicitudes de DNS del Pod ahora pueden llegar a kube-dns y omitir NodeLocal DNSCache.

Errores de tiempo de espera de NodeLocal DNSCache

En los clústeres con NodeLocal DNSCache habilitado, los registros pueden contener entradas similares a las siguientes:

[ERROR] plugin/errors: 2 <hostname> A: read tcp <node IP: port>-><kubedns IP>:53: i/o timeout

El resultado incluye la dirección IP del servicio de IP del clúster kube-dns-upstream. En este ejemplo, no se recibió la respuesta a una solicitud de DNS desde kube-dns en 2 segundos. Esto podría deberse a alguno de los siguientes motivos:

Un problema de conectividad de red subyacente.
Aumentos significativos de las consultas de DNS desde la carga de trabajo o debido al escalamiento vertical del grupo de nodos.

Como resultado, los Pods kube-dns existentes no pueden controlar todas las solicitudes a tiempo. La solución alternativa es aumentar la cantidad de réplicas de kube-dns mediante el ajuste de los parámetros del ajuste de escala automático.

Escala kube-dns

Puedes usar un valor menor para nodesPerReplica a fin de asegurarte de que se creen más pods de kube-dns a medida que se escalan los nodos del clúster. Recomendamos configurar un valor max explícito para garantizar que la máquina virtual (VM) del plano de control de GKE no se sobrecargue debido a una gran cantidad de pods de kube-dns que observan la API de Kubernetes.

Puedes configurar max en la cantidad de nodos del clúster. Si el clúster tiene más de 500 nodos, establece max en 500.

En el caso de los clústeres de Standard, puedes modificar la cantidad de réplicas de kube-dns si editas el ConfigMap kube-dns-autoscaler. Esta configuración no es compatible con los clústeres de Autopilot.

kubectl edit configmap kube-dns-autoscaler --namespace=kube-system

El resultado es similar al siguiente:

linear: '{"coresPerReplica":256, "nodesPerReplica":16,"preventSinglePointFailure":true}'

La cantidad de réplicas de kube-dns se calcula mediante la siguiente fórmula:

réplicas = máx( ceil( núcleos × 1/núcleosPorRéplica ) , ceil( nodos × 1/nodosPorRéplica ), valorMáx )

Para escalar verticalmente, cambia nodesPerReplica a un valor más pequeño y, luego, incluye un valor max.

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"preventSinglePointFailure":true}'

Con esta configuración se crea 1 pod kube-dns por cada 8 nodos en el clúster. Un clúster de 24 nodos tendrá 3 réplicas y un clúster de 40 nodos tendrá 5 réplicas. Si el clúster supera los 120 nodos, la cantidad de réplicas de kube-dns no aumenta más allá de 15, el valor max.

A fin de garantizar un nivel de modelo de referencia de la disponibilidad de DNS en el clúster, establece un recuento mínimo de réplicas para kube-dns.

El resultado del ConfigMap kube-dns-autoscaler con el campo min sería similar al siguiente:

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"min": 5,"preventSinglePointFailure":true}'

¿Qué sigue?

Lee una descripción general de cómo GKE proporciona DNS administrado.
Lee la página sobre DNS para servicios y pods a fin de obtener una descripción general de cómo se usa DNS en los clústeres de Kubernetes.
Aprende a usar Cloud DNS para GKE.