Usa kube-dns

Estándar

En esta página, se describe cómo Google Kubernetes Engine (GKE) implementa el descubrimiento de servicios con kube-dns, el proveedor predeterminado de DNS para clústeres de GKE.

Para los clústeres Autopilot, no puedes modificar la configuración predeterminada de kube-dns.

Arquitectura

Cuando creas un clúster, GKE implementa Pods de kube-dns en el espacio de nombres kube-system de forma automática. Los Pods acceden a la implementación de kube-dns a través del servicio correspondiente que agrupa los Pods de kube-dns y les proporciona una sola dirección IP (ClusterIP). De forma predeterminada, todos los Pods de un clúster usan este servicio para resolver consultas de DNS. En el siguiente diagrama, se muestra la relación entre los Pods y el servicio de kube-dns.

kube-dns escala para satisfacer las demandas del DNS del clúster. Este escalamiento es controlado por kube-dns-autoscaler, un Pod que se implementa de forma predeterminada en todos los clústeres de GKE. kube-dns-autoscaler ajusta la cantidad de réplicas en la implementación de kube-dns según la cantidad de nodos y núcleos del clúster.

kube-dns admite hasta 1,000 extremos por servicio sin interfaz gráfica.

Cómo se configura el DNS del pod

El kubelet que se ejecuta en cada nodo configura el etc/resolv.conf del Pod para usar el ClusterIP del servicio de kube-dns. En la siguiente configuración de ejemplo, se muestra que la dirección IP del servicio de kube-dns es 10.0.0.10. Esta dirección IP es diferente en otros clústeres.

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

kube-dns es el servidor de nombres autorizado para el dominio del clúster (cluster.local) y resuelve los nombres externos de forma recurrente. Los nombres cortos que no están completamente calificados, como myservice, primero se completan con rutas de acceso de búsqueda local.

Nota: En los clústeres de Autopilot de GKE, en la versión 1.27 y posteriores, el rango de IP del Service predeterminado es un rango administrado por Google: 34.118.224.0/20 y el Service kube-dns tendrá la dirección 34.118.x.10 de forma predeterminada (x está en el rango 224-239).

Agrega agentes de resolución personalizados para dominios stub

Puedes modificar ConfigMap para kube-dns a fin de establecer dominios stub como parte de la infraestructura de DNS dentro de los clústeres.

Los dominios stub te permiten configurar agentes de resolución por dominio personalizados para que kube-dns reenvíe las solicitudes de DNS a servidores DNS ascendentes específicos cuando se resuelvan estos dominios.

Nota: 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 a los servidores definidos, incluidos **example.com y *.example.com.

En el siguiente manifiesto de ConfigMap de ejemplo para kube-dns, se incluye una configuración stubDomains que establece agentes de resolución personalizados para el dominio example.com.

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",
        "1.1.1.1",
        "1.0.0.1"
      ]
    }

Ejecuta el siguiente comando para abrir un editor de texto:

kubectl edit configmap kube-dns -n kube-system

Reemplaza el contenido del archivo por el manifiesto y, luego, sal del editor de texto para aplicar el manifiesto al clúster.

Nameservers ascendentes

Si modificas el ConfigMap de kube-dns para incluir upstreamNameservers, kube-dns reenvía todas las solicitudes de DNS, excepto *.cluster.local a esos servidores. Esto incluye metadata.internal y *.google.internal, que el servidor ascendente no puede resolver.

Si habilitas la federación de identidades para cargas de trabajo para GKE o cualquier carga de trabajo que dependa de la resolución metadata.internal para retener la resolución de nombres *.internal, agrega stubDomain al ConfigMap.

data:
  stubDomains: |
    {
      "internal": [
        "169.254.169.254"
      ]
    }
  upstreamNameservers: |
    ["8.8.8.8"]

Soluciona problemas

Para obtener información sobre la solución de 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.

Limitaciones

Lee las siguientes secciones para obtener información sobre las limitaciones de kube-dns.

Límite del dominio de búsqueda

Existe un límite de 32 dominios de búsqueda de DNS para /etc/resolv.conf. Si defines más de 32 dominios de búsqueda, la creación del Pod falla con el siguiente error:

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 método 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.

Considera el límite de upstreamNameservers

Kubernetes impone un límite de hasta tres valores upstreamNameservers. Si defines más de tres upstreamNameservers, verás el siguiente error en Cloud Logging en los registros de implementación kube-dns:

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

Cuando esto sucede, kube-dns se comporta como si no tuviera upstreamNameservers configurado. Para resolver este problema, quita el upstreamNameservers adicional de la configuración.

Limitaciones de rendimiento con kube-dns

Si tienes una latencia alta con búsquedas de DNS o fallas de resolución de DNS con el proveedor de kube-dns predeterminado, esto podría deberse a lo siguiente:

• Realiza búsquedas de DNS frecuentes en tu carga de trabajo
• Implementa una mayor densidad de Pods por nodo.
• Superar el límite de 20 consultas por segundo (QPS) para cada pod de kube-dns
• Ejecuta kube-dns en VMs puntuales o interrumpibles, lo que puede provocar eliminaciones inesperadas de nodos y problemas de resolución de DNS posteriores

Para mejorar los tiempos de búsqueda de DNS, puedes elegir una de las siguientes opciones:

• Evita ejecutar componentes críticos del sistema, como kube-dns en VMs interrumpibles o interrumpibles. El uso de VMs Spot o interrumpibles para DNS puede causar fallas e interrumpir tu clúster.
• Como prácticas recomendadas, crea al menos un grupo de nodos compuesto por VMs estándar (interrumpibles o no Spot) para alojar componentes críticos del sistema, como kube-dns. Para garantizar que las cargas de trabajo críticas solo se programen en el grupo de nodos confiable que impida que se ejecuten en VMs Spot o interrumpibles, puedes usar taints y tolerancias para VMs Spot.
• Habilitar NodeLocal DNSCache
• Scale up 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 sincrónico. Las funciones dns.resolve* siempre realizan una consulta de DNS asíncrona en la red.

Nota: Durante las actualizaciones de clúster de GKE, pueden producirse fallas en la resolución de DNS debido a las actualizaciones simultáneas de los componentes del plano de control, incluido kube-dns. Esto puede suceder independientemente de si NodeLocal DNSCache está habilitado o no. Por lo general, solo un pequeño porcentaje de nodos (alrededor del 10%) se verá afectado en un momento determinado. Para minimizar las interrupciones, te recomendamos que pruebes de forma exhaustiva las actualizaciones del clúster en un entorno que no sea de producción antes de aplicarlas a los clústeres de producción.

Registros DNS de servicio

kube-dns solo crea registros DNS para los servicios que tienen extremos.

TTL grande de servidores ascendentes DNS

Si kube-dns recibe una respuesta de DNS de un agente de resolución de DNS ascendente con un TTL grande o "infinito", conserva este valor de TTL para la entrada de DNS en la caché. La entrada nunca vence y podría crear una discrepancia entre la entrada y la dirección IP real resuelta para el nombre del TTL.

GKE resuelve este problema en las siguientes versiones del plano de control estableciendo un valor de TTL máximo de 30 segundos para cualquier respuesta de DNS que tenga un TTL superior a 30 segundos:

• 1.21.14-gke.9100
• 1.22.15-gke.2100
• 1.23.13-gke.500
• 1.24.7-gke.500
• 1.25.2-gke.500 o superior

Este comportamiento es similar a NodeLocal DNSCache.

Registra las métricas de kube-dns o dnsmasq

Puedes obtener métricas sobre las consultas de DNS en el clúster de GKE. Esta es una forma rápida de obtener métricas de kube-dns o dnsmasq sin modificar la implementación.

1. Enumera los Pods en la implementación de kube-dns.

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

   El resultado será similar al siguiente ejemplo:

   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 un Pod y establece su nombre en una variable.

   POD="kube-dns-548976df6c-98fkd"
   

3. Configura la redirección de puertos para el Pod kube-dns elegido.

   $ kubectl port-forward pod/${POD} -n kube-system 10054:10054 10055:10055
   

   El resultado será similar al siguiente ejemplo:

   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.

4. Para obtener las métricas, ejecuta el siguiente comando curl en el extremo.

   $ curl http://127.0.0.1:10054/metrics; curl http://127.0.0.1:10055/metrics

   El puerto 10054 contiene métricas de dnsmasq y el puerto 10055 contiene métricas de kube-dns.

   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 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 una implementación personalizada de kube-dns.