Acerca de kube-dns para GKE

Estándar

Si ejecutas aplicaciones en clústeres estándar, kube-dns es el proveedor de DNS predeterminado que te ayuda a habilitar el descubrimiento y la comunicación de servicios. En este documento, se describe cómo administrar el DNS con kube-dns, incluida su arquitectura, configuración y prácticas recomendadas para optimizar la resolución de DNS en tu entorno de GKE.

Este documento está dirigido a desarrolladores, administradores y arquitectos responsables de administrar el DNS en GKE. Para obtener contexto sobre los roles y las tareas comunes en Google Cloud, consulta Roles y tareas comunes de los usuarios de GKE Enterprise.

Antes de comenzar, asegúrate de estar familiarizado con los servicios de Kubernetes y los conceptos generales de DNS.

Nota: Las configuraciones de kube-dns que se describen aquí son para los clústeres estándar. Si usas clústeres de Autopilot, estos métodos no se aplican porque Autopilot usa Cloud DNS como proveedor de DNS predeterminado.

Información sobre la arquitectura de kube-dns

kube-dns opera dentro de tu clúster de GKE para habilitar la resolución de DNS entre Pods y servicios.

En el siguiente diagrama, se muestra cómo interactúan tus Pods con el servicio kube-dns:

Componentes clave

kube-dns incluye los siguientes componentes clave:

• kube-dns Pods: Estos Pods ejecutan el software del servidor kube-dns. Se ejecutan varias réplicas de estos Pods en el espacio de nombres kube-system, lo que proporciona alta disponibilidad y redundancia.
• Servicio kube-dns: Este servicio de Kubernetes de tipo ClusterIP agrupa los Pods kube-dns y los expone como un solo extremo estable. ClusterIP actúa como el servidor DNS del clúster, que los Pods usan para enviar consultas de DNS. kube-dns admite hasta 1,000 extremos por servicio sin interfaz gráfica.
• kube-dns-autoscaler: Este Pod ajusta la cantidad de réplicas de kube-dns en función del tamaño del clúster, que incluye la cantidad de nodos y núcleos de CPU. Este enfoque ayuda a garantizar que kube-dns pueda controlar diferentes cargas de consultas de DNS.

Resolución de DNS interno

Cuando un Pod necesita resolver un nombre de DNS dentro del dominio del clúster, como myservice.my-namespace.svc.cluster.local, se produce el siguiente proceso:

1. Configuración de DNS del Pod: El kubelet de cada nodo configura el archivo /etc/resolv.conf del Pod. Este archivo usa el ClusterIP del servicio kube-dns como servidor de nombres.
2. Consulta de DNS: El Pod envía una consulta de DNS al servicio kube-dns.
3. Resolución de nombres: kube-dns recibe la consulta. Busca la dirección IP correspondiente en sus registros DNS internos y responde al Pod.
4. Comunicación: Luego, el Pod usa la dirección IP resuelta para comunicarse con el Service de destino.

Resolución de DNS externa

Cuando un Pod necesita resolver un nombre de DNS externo o un nombre que está fuera del dominio del clúster, kube-dns actúa como un solucionador recursivo. Reenvía la consulta a los servidores DNS ascendentes que están configurados en su archivo ConfigMap. También puedes configurar agentes de resolución personalizados para dominios específicos, también conocidos como dominios stub. Esta configuración dirige kube-dns para que reenvíe las solicitudes de esos dominios a servidores DNS ascendentes específicos.

Configura el DNS del Pod

En GKE, el agente kubelet de cada nodo configura los parámetros de DNS de los Pods que se ejecutan en ese nodo.

Configura el archivo /etc/resolv.conf

Cuando GKE crea un Pod, el agente kubelet modifica el archivo /etc/resolv.conf del Pod. Este archivo configura el servidor DNS para la resolución de nombres y especifica los dominios de búsqueda. De forma predeterminada, kubelet configura el Pod para que use el servicio de DNS interno del clúster, kube-dns, como su servidor de nombres. También completa los dominios de búsqueda en el archivo. Estos dominios de búsqueda te permiten usar nombres no calificados en las consultas de DNS. Por ejemplo, si un Pod consulta myservice, Kubernetes primero intenta resolver myservice.default.svc.cluster.local, luego myservice.svc.cluster.local y, luego, otros dominios de la lista search.

En el siguiente ejemplo, se muestra una configuración /etc/resolv.conf predeterminada:

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5

Este archivo tiene las siguientes entradas:

• nameserver: Define el ClusterIP del servicio kube-dns.
• search: Define los dominios de búsqueda que se agregan a los nombres no calificados durante las búsquedas de DNS.
• options ndots:5: Establece el umbral para cuando GKE considera que un nombre está completamente calificado. Un nombre se considera completamente calificado si tiene cinco o más puntos.

Nota: El ClusterIP real del servicio kube-dns difiere en cada clúster. Los clústeres de Autopilot no usan kube-dns. En cambio, usan Cloud DNS como proveedor predeterminado para una experiencia de DNS completamente administrada.

Los Pods configurados con el parámetro de configuración hostNetwork: true heredan su configuración de DNS del host y no consultan kube-dns directamente.

Personalizar kube-dns

kube-dns proporciona una resolución de DNS predeterminada sólida. Puedes personalizar su comportamiento para necesidades específicas, como mejorar la eficiencia de la resolución o usar los solucionadores de DNS preferidos. Los dominios de stub y los servidores de nombres ascendentes se configuran modificando el ConfigMap kube-dns en el espacio de nombres kube-system.

Modifica el ConfigMap de kube-dns

Para modificar el ConfigMap de kube-dns, haz lo siguiente:

1. Abre el ConfigMap para editarlo:

   kubectl edit configmap kube-dns -n kube-system
   

2. En la sección data, agrega los campos stubDomains y upstreamNameservers a lo siguiente:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     labels:
       addonmanager.kubernetes.io/mode: EnsureExists
     name: kube-dns
     namespace: kube-system
   data:
     stubDomains: |
       {
         "example.com": [
           "8.8.8.8",
           "8.8.4.4"
         ],
         "internal": [ # Required if your upstream nameservers can't resolve GKE internal domains
           "169.254.169.254" # IP of the metadata server
         ]
       }
     upstreamNameservers: |
       [
         "8.8.8.8", # Google Public DNS
         "1.1.1.1" # Cloudflare DNS
       ]
   

3. Guarda el ConfigMap. kube-dns vuelve a cargar la configuración automáticamente.

Dominios de stub

Los dominios stub te permiten definir agentes de resolución de DNS personalizados para dominios específicos. Cuando un Pod consulta un nombre dentro de ese dominio auxiliar, kube-dns reenvía la consulta al solucionador especificado en lugar de usar su mecanismo de resolución predeterminado.

Incluyes una sección stubDomains en el kube-dns ConfigMap.

En esta sección, se especifican el dominio y los servidores de nombres ascendentes correspondientes. Luego, kube-dns reenvía las consultas de nombres dentro de ese dominio a los servidores designados. Por ejemplo, puedes enrutar todas las consultas de DNS para internal.mycompany.com a 192.168.0.10 o agregar "internal.mycompany.com": ["192.168.0.10"] a stubDomains.

Cuando configuras un agente de resolución personalizado para un dominio stub, como example.com, kube-dns reenvía todas las solicitudes de resolución de nombres para ese dominio, incluidos los subdominios como *.example.com, a los servidores especificados.

Servidores de nombres ascendentes

Puedes configurar kube-dns para que use servidores de nombres ascendentes personalizados para resolver nombres de dominio externos. Esta configuración indica a kube-dns que reenvíe todas las solicitudes de DNS, excepto las solicitudes para el dominio interno del clúster (*.cluster.local), a los servidores ascendentes designados. Es posible que tus servidores ascendentes personalizados no puedan resolver dominios internos, como metadata.internal y *.google.internal. Si habilitas la federación de identidades para cargas de trabajo para GKE o tienes cargas de trabajo que dependen de estos dominios, agrega un dominio auxiliar para internal en ConfigMap. Usa 169.254.169.254, la dirección IP del servidor de metadatos, como el resolvedor de este dominio auxiliar.

Administra una Deployment de kube-dns personalizada

En un GKE estándar, kube-dns se ejecuta como una Deployment. Una implementación de kube-dns personalizada significa que tú, como administrador del clúster, puedes controlar la Deployment y personalizarla según tus necesidades, en lugar de usar la implementación predeterminada proporcionada por GKE.

Motivos para realizar una implementación personalizada

Considera una implementación de kube-dns personalizada por los siguientes motivos:

• Asignación de recursos: Ajusta los recursos de CPU y memoria para los Pods de kube-dns y optimiza el rendimiento en clústeres con tráfico de DNS alto.
• Versión de la imagen: Usa una versión específica de la imagen kube-dns o cambia a un proveedor de DNS alternativo, como CoreDNS.
• Configuración avanzada: Personaliza los niveles de registro, las políticas de seguridad y el comportamiento del almacenamiento en caché de DNS.

Ajuste de escala automático para objetos Deployment personalizados

La función kube-dns-autoscaler integrada funciona con la Deployment kube-dns predeterminada. Si creas una implementación kube-dns Deployment, el escalador automático integrado no la administrará. Por lo tanto, debes configurar un escalador automático independiente que esté específicamente configurado para supervisar y ajustar el recuento de réplicas de tu Deployment personalizado. Este enfoque implica crear y, luego, implementar tu propia configuración de escalador automático en el clúster.

Cuando administras una Deployment personalizada, eres responsable de todos sus componentes, como mantener actualizada la imagen del escalador automático. El uso de componentes desactualizados puede provocar una disminución del rendimiento o fallas de DNS.

Para obtener instrucciones detalladas sobre cómo configurar y administrar tu propia implementación de kube-dns, consulta Configura un Deployment personalizado de kube-dns.

Solucionar problemas

Para obtener información sobre la solución de problemas relacionados con kube-dns, consulta las siguientes páginas:

• Para obtener asesoramiento sobre kube-dns en GKE, consulta Soluciona problemas de kube-dns en GKE.
• Para obtener sugerencias generales sobre el diagnóstico de problemas de DNS de Kubernetes, consulta Depuración de la resolución de DNS.

Optimiza la resolución de DNS

En esta sección, se describen los problemas comunes y las prácticas recomendadas para administrar el DNS en GKE.

Límite de dominios de búsqueda de dnsConfig de un Pod

Kubernetes limita la cantidad de dominios de búsqueda de DNS a 32. Si intentas definir más de 32 dominios de búsqueda en el dnsConfig de un Pod, el kube-apiserver no creará el Pod y mostrará un error similar al siguiente:

The Pod "dns-example" is invalid: spec.dnsConfig.searches: Invalid value: []string{"ns1.svc.cluster-domain.example", "my.dns.search.suffix1", "ns2.svc.cluster-domain.example", "my.dns.search.suffix2", "ns3.svc.cluster-domain.example", "my.dns.search.suffix3", "ns4.svc.cluster-domain.example", "my.dns.search.suffix4", "ns5.svc.cluster-domain.example", "my.dns.search.suffix5", "ns6.svc.cluster-domain.example", "my.dns.search.suffix6", "ns7.svc.cluster-domain.example", "my.dns.search.suffix7", "ns8.svc.cluster-domain.example", "my.dns.search.suffix8", "ns9.svc.cluster-domain.example", "my.dns.search.suffix9", "ns10.svc.cluster-domain.example", "my.dns.search.suffix10", "ns11.svc.cluster-domain.example", "my.dns.search.suffix11", "ns12.svc.cluster-domain.example", "my.dns.search.suffix12", "ns13.svc.cluster-domain.example", "my.dns.search.suffix13", "ns14.svc.cluster-domain.example", "my.dns.search.suffix14", "ns15.svc.cluster-domain.example", "my.dns.search.suffix15", "ns16.svc.cluster-domain.example", "my.dns.search.suffix16", "my.dns.search.suffix17"}: must not have more than 32 search paths.

kube-apiserver devuelve este mensaje de error en respuesta a un intento de creación de Pod. Para resolver este problema, quita las rutas de búsqueda adicionales de la configuración.

Límite de nameservers ascendente para kube-dns

kube-dns limita la cantidad de valores de upstreamNameservers a tres. Si defines más de tres, Cloud Logging mostrará un error similar al siguiente:

Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update

En este caso, kube-dns ignora la configuración de upstreamNameservers y sigue usando la configuración válida anterior. Para resolver este problema, quita el upstreamNameservers adicional del kube-dns ConfigMap.

Aumentar la escala de kube-dns

En los clústeres estándar, puedes usar un valor más bajo para nodesPerReplica, de modo que se creen más Pods de kube-dns cuando se escale verticalmente la cantidad de nodos del clúster. Recomendamos configurar un valor explícito para el campo max para garantizar que la máquina virtual (VM) del plano de control de GKE no se sobrecargue debido a la gran cantidad de Pods kube-dns que observan la API de Kubernetes.

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

Nota: Establecer el valor del campo max en 500 no crea 500 réplicas. En su lugar, garantiza que las réplicas de kube-dns no aumenten la escala del valor del campo max. En la mayoría de los casos, debes establecer el valor del campo max en un valor mucho menor que 500.

Puedes modificar la cantidad de réplicas de kube-dns si editas el ConfigMap de kube-dns-autoscaler.

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

El resultado es similar a lo siguiente:

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

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

replicas = max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) )

Nota: El parámetro coresPerReplica es especialmente útil para los clústeres que tienen grupos de nodos con diferentes tipos y tamaños de máquinas. En estos clústeres heterogéneos, el ajuste de escala basado solo en la cantidad de nodos podría no reflejar con precisión la carga potencial de DNS. Si configuras el parámetro coresPerReplica, puedes ayudar a garantizar que la cantidad de réplicas de kube-dns se ajuste según la capacidad de procesamiento total del clúster, lo que proporciona un comportamiento de ajuste más preciso y con mayor capacidad de respuesta que se alinea mejor con las demandas de la carga de trabajo.

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

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

Esta configuración crea un Pod kube-dns por cada ocho nodos del clúster. Un clúster de 24 nodos tiene tres réplicas y un clúster de 40 nodos tiene cinco 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, que es el valor del campo max.

Para garantizar un nivel de referencia de disponibilidad de DNS en tu clúster, establece un recuento mínimo de réplicas para el campo kube-dns.

El resultado de kube-dns-autoscaler ConfigMap con el campo min configurado es similar al siguiente:

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

Mejora los tiempos de búsqueda de DNS

Varios factores pueden causar una latencia alta con las búsquedas de DNS o fallas de resolución de DNS con el proveedor kube-dns predeterminado. Las aplicaciones pueden experimentar estos problemas como errores getaddrinfo EAI_AGAIN, que indican una falla temporal en la resolución de nombres. Entre las causas, se incluyen las siguientes:

• Búsquedas de DNS frecuentes en tu carga de trabajo
• Alta densidad de Pods por nodo
• Ejecuta kube-dns en VMs Spot o interrumpibles, lo que puede provocar eliminaciones inesperadas de nodos.
• Alto volumen de consultas que supera la capacidad de la instancia dnsmasq dentro del Pod kube-dns Una sola instancia de kube-dns tiene un límite de 200 conexiones TCP simultáneas en la versión 1.31 de GKE y versiones posteriores, y un límite de 20 conexiones TCP simultáneas en la versión 1.30 de GKE y versiones anteriores.

Para mejorar los tiempos de búsqueda de DNS, haz lo siguiente:

• Evita ejecutar componentes críticos del sistema, como kube-dns, en VMs Spot o VMs interrumpibles. Crea al menos un grupo de nodos que tenga VMs estándar y no tenga VMs Spot ni VMs interrumpibles. Usa taints y tolerancias para garantizar que las cargas de trabajo críticas se programen en estos nodos confiables.
• Habilitar NodeLocal DNSCache. NodeLocal DNSCache almacena en caché las respuestas de DNS directamente en cada nodo, lo que reduce la latencia y la carga en el servicio kube-dns. Si habilitas NodeLocal DNSCache y usas políticas de red con reglas de rechazo predeterminadas, agrega una política para permitir que las cargas de trabajo envíen consultas de DNS a los Pods node-local-dns.
• Aumenta la escala de kube-dns.
• Asegúrate de que tu aplicación use funciones basadas en dns.resolve* en lugar de funciones basadas en dns.lookup, ya que dns.lookup es síncrono.
• Usa nombres de dominio completamente calificados (FQDN), por ejemplo, https://google.com./ en lugar de https://google.com/.

Es posible que se produzcan errores de resolución de DNS durante las actualizaciones del clúster de GKE debido a las actualizaciones simultáneas de los componentes del plano de control, incluido kube-dns. Por lo general, estas fallas afectan a un pequeño porcentaje de nodos. Prueba exhaustivamente las actualizaciones del clúster en un entorno que no sea de producción antes de aplicarlas a los clústeres de producción.

Garantiza la visibilidad del servicio

kube-dns solo crea registros DNS para los servicios que tienen extremos. Si un servicio no tiene ningún extremo, kube-dns no crea registros DNS para ese servicio.

Administra las discrepancias del TTL de DNS

Si kube-dns recibe una respuesta de DNS de un solucionador de DNS ascendente con un TTL grande o infinito, conserva este valor de TTL. Este comportamiento puede generar una discrepancia entre la entrada almacenada en caché y la dirección IP real.

GKE resuelve este problema en versiones específicas del plano de control, como 1.21.14-gke.9100 y posteriores, o 1.22.15-gke.2100 y posteriores. Estas versiones establecen un valor de TTL máximo en 30 segundos para cualquier respuesta de DNS que tenga un TTL más alto. Este comportamiento es similar al de NodeLocal DNSCache.

Consulta las métricas de kube-dns

Puedes recuperar métricas sobre las consultas de DNS en tu clúster directamente desde los kube-dns Pods.

1. Busca los Pods de kube-dns en el espacio de nombres kube-system:

   kubectl get pods -n kube-system --selector=k8s-app=kube-dns
   

   El resultado es similar a lo siguiente:

   NAME                        READY     STATUS    RESTARTS   AGE
   kube-dns-548976df6c-98fkd   4/4       Running   0          48m
   kube-dns-548976df6c-x4xsh   4/4       Running   0          47m
   

2. Elige uno de los Pods y configura el reenvío de puertos para acceder a las métricas de ese Pod:

   • El puerto 10055 expone las métricas de kube-dns.
   • El puerto 10054 expone las métricas de dnsmasq.

   Reemplaza POD_NAME por el nombre del Pod que elegiste.

   POD_NAME="kube-dns-548976df6c-98fkd" # Replace with your pod name
   kubectl port-forward pod/${POD_NAME} -n kube-system 10055:10055 10054:10054
   

   El resultado es similar a lo siguiente:

   Forwarding from 127.0.0.1:10054 -> 10054
   Forwarding from 127.0.0.1:10055 -> 10055
   

   Nota: Después de configurar el reenvío de puertos, no presiones Control+C; deja que se ejecute. Al mismo tiempo, abre otra sesión en el mismo shell de comandos y ejecuta curl en el extremo de la sesión recién abierta.

3. En una sesión de terminal nueva, usa el comando curl para acceder a los extremos de métricas.

   # Get kube-dns metrics
   curl http://127.0.0.1:10055/metrics
   
   # Get dnsmasq metrics
   curl http://127.0.0.1:10054/metrics
   

   El resultado será similar al siguiente ejemplo:

   kubedns_dnsmasq_errors 0
   kubedns_dnsmasq_evictions 0
   kubedns_dnsmasq_hits 3.67351e+06
   kubedns_dnsmasq_insertions 254114
   kubedns_dnsmasq_max_size 1000
   kubedns_dnsmasq_misses 3.278166e+06
   

¿Qué sigue?

• Lee una descripción general del DNS del clúster en GKE.
• Lee DNS para servicios y Pods para obtener una descripción general de cómo se usa DNS en los clústeres de Kubernetes.
• Obtén más información para configurar NodeLocal DNSCache.
• Obtén más información para configurar una implementación personalizada de kube-dns.