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 que se encargan de administrar el DNS en GKE. Para obtener contexto sobre los roles y las tareas comunes en Google Cloud, consulta Roles y tareas comunes del usuario de GKE.

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 clústeres estándar. Si usas clústeres de Autopilot, estos métodos no se aplican, ya que Autopilot usa Cloud DNS como proveedor de DNS predeterminado.

Comprende 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. En el espacio de nombres kube-system, se ejecutan varias réplicas de estos Pods, que proporcionan alta disponibilidad y redundancia.
• Servicio kube-dns: En la siguiente tabla, se comparan los límites de configuración y escalabilidad de las versiones heredadas y basadas en CoreDNS de kube-dns:

  Función	Legacy (kube-dns 1.35 y versiones anteriores)	kube-dns en CoreDNS (1.36 y versiones posteriores)
  Conocimiento de los extremos	Conoce hasta 1,000 extremos por servicio. Si un Service tiene más de 1,000 Pods, kube-dns no conoce los extremos adicionales.	Conocimiento de todos los endpoints Esta versión usa EndpointSlices para garantizar la exactitud y mejorar la eficiencia de los servicios grandes.
  Servidores de nombres ascendentes	Limitado a 3	Admite hasta 15
  Conexiones TCP salientes simultáneas	Se limita a 200.	Admite hasta 1,500

• 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 cargas variables 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:

   • Versión 1.36 o posterior de GKE: La implementación basada en CoreDNS usa EndpointSlices para que kube-dns conozca todos los Pods de un Service. Esto mejora la exactitud y la eficiencia de los Services a gran escala.
   • Versión 1.35 o anterior de GKE: kube-dns resuelve nombres según la API anterior de Cloud Endpoints, que se limita a 1,000 extremos. Si un Service tiene más de 1,000 Pods de respaldo, kube-dns no conoce los extremos adicionales.

4. Comunicación: Luego, el Pod usa la dirección IP resuelta para comunicarse con el Service de destino.

Nota: Limitación entre VPCs para servicios sin interfaz gráfica: kube-dns no puede descubrir direcciones IP de extremos de servicios sin interfaz gráfica en toda la VPC ni desde diferentes redes de VPC. Si tu arquitectura requiere el descubrimiento entre VPCs para los servicios sin encabezado, usa Cloud DNS para GKE como proveedor de DNS en lugar de kube-dns.

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 se configuran en su archivo ConfigMap. También puedes configurar agentes de resolución personalizados para dominios específicos, que también se conocen como dominios stub. Esta configuración indica a kube-dns 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 establece la configuración de DNS para 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, el kubelet configura el Pod para que use el servicio de DNS interno del clúster, kube-dns, como su servidor de nombres. También propaga 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 predeterminada de /etc/resolv.conf:

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 su lugar, usan Cloud DNS como proveedor predeterminado para obtener una experiencia de DNS completamente administrada.

Los Pods configurados con hostNetwork: true heredan su configuración de DNS del host y no consultan kube-dns directamente, a menos que usen el ClusterFirstWithHostNet dnsPolicy.

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. Tanto los dominios de stub como 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 de la siguiente manera:

   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
         "8.8.4.4" # Google Public DNS Backup
       ]
   

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 de stub, 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 ConfigMap de kube-dns.

En esta sección, se especifican el dominio y los servidores de nombres upstream 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 y 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 le 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 upstream 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 resolutor de este dominio de stub.

Administrar una Deployment personalizada de kube-dns

En un clúster de Standard, kube-dns se ejecuta como una Deployment. Una implementación personalizada de kube-dns 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 que proporciona 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

El kube-dns-autoscaler integrado funciona con el Deployment de kube-dns predeterminado. 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é configurado específicamente para supervisar y ajustar el recuento de réplicas de tu Deployment personalizada. Este enfoque implica crear y, luego, implementar tu propia configuración del escalador automático en el clúster.

Cuando administras un Deployment personalizado, 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 cómo solucionar problemas de 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 asesoramiento general 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.

El 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

Las versiones heredadas de kube-dns (versión 1.35 y anteriores) limitan la cantidad 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 ConfigMap de kube-dns.

Aumentar la escala de kube-dns

En los clústeres de Standard, puedes usar un valor más bajo para nodesPerReplica, de modo que se creen más Pods de kube-dns cuando los nodos del clúster se escalen verticalmente. Te recomendamos que establezcas 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 supervisan 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 cambio, ayuda a garantizar que las réplicas de kube-dns no se escalen más allá 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 particularmente útil para los clústeres que tienen grupos de nodos con diferentes tipos y tamaños de máquinas. En esos clústeres heterogéneos, es posible que el escalamiento basado solo en la cantidad de nodos no refleje 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 carga de trabajo.

Para escalar verticalmente, cambia el valor del campo nodesPerReplica por uno 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 en la 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 VMs interrumpibles, lo que puede provocar eliminaciones inesperadas de nodos.
• Límites de conexión: Las versiones heredadas de kube-dns (versión 1.35 y anteriores de GKE) están limitadas a 200 conexiones TCP simultáneas. kube-dns en CoreDNS (versión 1.36 y posteriores de GKE) quita estos límites fijos para las conexiones entrantes y proporciona una capacidad significativamente mayor para las conexiones salientes.

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 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 fallas en la 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 a fondo 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.

Cómo administrar 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 crear 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 de 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 directamente desde los Pods de kube-dns. La forma en que recuperas estas métricas depende de tu versión de GKE.

GKE 1.36 y versiones posteriores

Si tu clúster ejecuta la versión 1.36 o posterior de GKE (kube-dns en CoreDNS), puedes supervisar el rendimiento de DNS con los paneles predefinidos en Cloud Monitoring o recuperar las métricas de forma manual desde los Pods.

Visualiza métricas en la consola de Google Cloud

1. En la consola de Google Cloud , ve a la página Paneles.
2. Selecciona el panel GKE DNS Observability - Cluster View.

Como alternativa, puedes consultar estas métricas directamente en la consola de Google Cloud yendo a Monitoring > Explorador de métricas y buscando los nombres de las métricas específicas.

Recupera métricas de forma manual

Para recuperar las métricas del Pod de forma manual, haz lo siguiente:

1. Busca los Pods de kube-dns.

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

2. Redirige el puerto 9153 a uno de los Pods.

   kubectl port-forward pod/POD_NAME -n kube-system 9153:9153
   

   Reemplaza POD_NAME por el nombre de uno de los Pods de kube-dns del resultado anterior.

3. Accede a las métricas.

   curl http://127.0.0.1:9153/metrics
   

Versión 1.35 de GKE y versiones anteriores

Esta versión de kube-dns usa Pods con varios contenedores. Para recuperar las métricas, haz lo siguiente:

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
   

2. Redirecciona los puertos 10055 (para el contenedor kube-dns) y 10054 (para el contenedor dnsmasq):

   #For the kube-dns container
   kubectl port-forward pod/POD_NAME -n kube-system 10055:10055
   #For the dnsmasq container
   kubectl port-forward pod/POD_NAME -n kube-system 10054:10054
   

   Reemplaza POD_NAME por el nombre de uno de los Pods kube-dns del resultado anterior. Ejecuta estos comandos de reenvío de puertos en sesiones de terminal independientes.

3. Accede a las métricas.

   #Metrics from the kube-dns container
   curl http://127.0.0.1:10055/metrics
   
   #Metrics from the dnsmasq container
   curl http://127.0.0.1:10054/metrics
   

¿Qué sigue?

• Lee una descripción general del DNS del clúster en GKE.
• 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.
• Obtén más información para configurar NodeLocal DNSCache.
• Obtén más información para configurar un Deployment personalizado de kube-dns.