La lección anterior dejó un cabo suelto deliberado: ExternalName funciona porque CoreDNS devuelve un CNAME, los servicios headless funcionan porque CoreDNS publica una entrada A por pod, y api-reservas encuentra a postgres-reservas porque alguien resuelve ese nombre. Llevamos tres módulos escribiendo postgres-reservas:5432 en la configuración sin haber explicado nunca quién traduce eso a una dirección IP. Esta lección abre la caja: qué es CoreDNS, cómo se configura, qué nombres genera para cada tipo de objeto, qué hay realmente en el /etc/resolv.conf de un pod, por qué el parámetro ndots: 5 puede multiplicar por cinco las consultas DNS cuando api-reservas llama a la pasarela de pagos, y cómo diagnosticar los tres fallos de DNS que te vas a encontrar una y otra vez.

1. Por qué el descubrimiento se hace por DNS
2. CoreDNS: qué es y dónde vive
3. El Corefile: la configuración del DNS del clúster
4. El esquema de nombres y las formas cortas
5. Registros de Services, Services headless y pods
6. Registros SRV y puertos con nombre
7. El /etc/resolv.conf del pod y el efecto de ndots: 5
8. dnsPolicy y dnsConfig
9. Las variables de entorno heredadas de Docker
10. Diagnóstico: los tres fallos típicos
11. Escala: NodeLocal DNSCache y réplicas de CoreDNS

La alternativa sería configurar direcciones IP, y no funciona: las IPs de los pods son efímeras (02-05). Un rollout, un desalojo o un reinicio del nodo la cambian. Podríamos fijar la IP del Service, que sí es estable mientras el Service exista, pero eso tampoco resiste:

Con DNS, api-reservas lleva escrito postgres-reservas en su ConfigMap desde 03-01, y ese nombre es válido en los tres entornos, en un clúster nuevo y tras recrear el Service: es la única referencia estable que existe en Kubernetes. Además, el DNS es universal: no requiere biblioteca, ni SDK, ni saber que estás en Kubernetes.

CoreDNS es un servidor DNS escrito en Go, modular a base de plugins, y es el DNS por defecto de Kubernetes desde la versión 1.13 (sustituyó a kube-dns). Corre como un Deployment normal en el namespace kube-system, expuesto por un Service llamado kube-dns (el nombre se conservó por compatibilidad).

Tres observaciones que resuelven muchas dudas:

• CoreDNS es una carga de trabajo como cualquier otra. Puede caerse, quedarse sin recursos, ser desalojada. Cuando CoreDNS sufre, toda la plataforma parece rota simultáneamente, y ese síntoma global es el que debe hacerte mirar aquí.
• La IP 10.96.0.10 es la décima dirección del serviceCIDR por convención, y es la que el kubelet inyecta en cada pod.
• El puerto 9153 expone métricas Prometheus (07-03): tasa de consultas, latencia, errores. Es de lo primero que conviene monitorizar.

Fíjate en la circularidad aparente: los pods llegan a CoreDNS a través de un ClusterIP, que necesita kube-proxy pero no necesita DNS. No hay problema del huevo y la gallina porque la IP 10.96.0.10 va inyectada literalmente en el resolv.conf.

CoreDNS se configura con un fichero llamado Corefile, que vive en un ConfigMap y se monta en el pod. Puedes leerlo tal cual:

Lee esto como una cadena de plugins que se evalúan en orden para toda consulta que llegue al puerto 53.

Un caso práctico de Rutas Norte: la oficina tiene un DNS interno en 10.20.30.5 que resuelve *.interno.rutasnorte.example, donde vive la base de datos de facturación heredada. Se añade un bloque específico con kubectl edit configmap coredns -n kube-system:

El plugin reload lo recoge solo. Cuidado: es configuración de todo el clúster; un error de sintaxis deja a CoreDNS en CrashLoopBackOff y con él a toda la plataforma. Revisa el log tras cada cambio.

El nombre canónico de un Service tiene siempre esta estructura:

Las formas cortas funcionan gracias a la lista search del resolv.conf (apartado 7). Desde un pod de rutas-norte-pro:

Ese último caso merece énfasis. Un pod de rutas-norte-dev puede resolver y conectar a postgres-reservas.rutas-norte-pro. La separación por namespace es organizativa, no de seguridad. Solo las NetworkPolicies de 04-06 lo impiden de verdad.

Regla práctica para Rutas Norte:

• Dentro del mismo entorno, usa el nombre corto: postgres-reservas, redis-cache. El mismo ConfigMap sirve para dev, pre y pro sin cambios.
• Para cruzar namespaces, usa siempre la forma completa con .svc.cluster.local. Es explícita y, como veremos, más rápida.

Una sola respuesta: la IP virtual. El balanceo entre pods lo hace kube-proxy después, como viste en 04-01. El DNS no interviene en el reparto.

Tres registros A, uno por pod listo (ready: true en el EndpointSlice). Aquí el DNS sí participa en el descubrimiento, y quien elige es el cliente. El plugin loadbalance baraja el orden en cada respuesta para que los clientes que solo miran el primer registro repartan algo.

Un pod que no está listo desaparece de esta lista, salvo que el Service tenga publishNotReadyAddresses: true (necesario para que las réplicas de una base de datos se descubran entre sí durante el arranque, algo que veremos en 06-01).

Con pods insecure en el Corefile, todo pod tiene un nombre derivado de su IP con los puntos sustituidos por guiones: 10-244-0-14.rutas-norte-pro.pod.cluster.local resuelve a 10.244.0.14. Fíjate en pod en vez de svc. Es de uso muy limitado: nadie escribe eso a mano. Su importancia real llega con los StatefulSets, donde cada pod obtiene un nombre estable y legible dentro de un Service headless:

Esa es la identidad de red que hace posible una base de datos en clúster, y llega en 06-01.

Los registros SRV publican, además de la dirección, el puerto. Se generan para todo puerto con nombre de un Service, con el formato _<puerto>._<protocolo>.<servicio>.<ns>.svc.cluster.local.

Recuperando el api-reservas multipuerto de 04-02, con puertos http (3000) y metrics (9090):

El formato es prioridad peso puerto destino. Un cliente que sepa leer SRV descubre el puerto sin tenerlo configurado. En un Service headless, un SRV devuelve una línea por pod, con el puerto de cada uno:

Pocas aplicaciones consultan SRV; la mayoría configura el puerto explícitamente. Pero es el mecanismo que usan varios operadores y bibliotecas de descubrimiento, y es la razón concreta por la que insistimos en nombrar siempre los puertos.

El kubelet escribe este fichero dentro de cada contenedor:

Tres líneas, tres decisiones:

• nameserver 10.96.0.10: el ClusterIP de kube-dns. Es lo que hace que las formas cortas se resuelvan.
• search: los sufijos que el resolutor probará. El primero es el propio namespace: por eso postgres-reservas a secas funciona dentro de rutas-norte-pro.
• options ndots:5: aquí está la trampa.

ndots:5 le dice al resolutor: "si el nombre que te piden tiene menos de 5 puntos, pruébalo primero con cada sufijo de search, y solo al final tal cual".

Cuenta los puntos de pagos.proveedorexterno.example: dos. Menos de cinco. Así que el resolutor hace esto:

Cuatro consultas, tres inútiles. Y peor: cada una se hace para A y para AAAA, así que en la práctica son 8 consultas cuando bastaba con 2. Las tres primeras además viajan a CoreDNS, que consulta la API y devuelve NXDOMAIN.

Ahora traslada esto a Rutas Norte en un puente de agosto: api-reservas llama a la pasarela de pagos en cada compra. Con 2.000 compras por minuto y sin caché de resolución en la aplicación, son 16.000 consultas por minuto donde deberían ser 4.000. CoreDNS se satura, la latencia de resolución sube, y todo el clúster empieza a ir despacio por una causa que nadie relaciona con el DNS.

Un nombre terminado en punto es un FQDN absoluto: el resolutor no le añade sufijos.

Una consulta. Fin.

Aviso: si bajas ndots a 1, los nombres cortos como redis-cache (cero puntos) siguen funcionando, pero postgres-reservas.rutas-norte-pro (un punto) dejaría de resolverse por búsqueda y necesitaría el FQDN. Bajar a 2 es un compromiso habitual y seguro.

dnsPolicy es un campo del spec del pod que decide qué resolv.conf recibe.

El caso de ClusterFirstWithHostNet es una trampa clásica: un pod con hostNetwork: true y dnsPolicy: ClusterFirst (el valor por defecto) recibe el resolv.conf del nodo y por tanto no puede resolver ningún Service. Si pones red de host, tienes que cambiar también la política.

dnsConfig permite ajustar el fichero resultante:

Con dnsPolicy: None es obligatorio dar al menos un nameserver en dnsConfig, o el pod no arranca.

Kubernetes inyecta en cada contenedor variables de entorno con la dirección y el puerto de todos los Services que existían en su namespace en el momento de crearse el pod. Es un vestigio del enlazado de contenedores de Docker.

Parecen cómodas y no deben usarse nunca. Cuatro razones:

1. Solo existen los Services creados ANTES que el pod. Si despliegas api-reservas y luego redis-cache, la variable no existe. Y el orden de creación no es algo que controles de forma fiable.
2. Se congelan al arrancar el pod. Si el ClusterIP cambia (Service recreado), la variable sigue con el valor viejo y el pod apunta a una IP muerta hasta que se reinicie.
3. Contaminan el entorno. Con 50 Services en el namespace son cientos de variables por contenedor. Hay casos documentados de fallos al arrancar por exceder el tamaño del entorno.
4. Rompen la portabilidad. Ese POSTGRES_RESERVAS_SERVICE_HOST no significa nada fuera de Kubernetes.

Usa siempre el nombre DNS, que no depende del orden, se resuelve fresco y funciona igual en cualquier sitio. El ruido de variables se elimina con enableServiceLinks: false en el spec del pod, recomendable en todos los Deployments de Rutas Norte.

El pod de trabajo, como en 04-01:

Comprobaciones básicas dentro:

Causa: CoreDNS está caído, saturado o no es alcanzable. Es un fallo global, y su firma es que todos los componentes fallan a la vez.

Sospechosos habituales: pods de CoreDNS en CrashLoopBackOff por un Corefile mal editado; el Service kube-dns sin endpoints; CoreDNS OOMKilled por falta de memoria bajo carga; o —y esto será muy relevante en 04-06— una NetworkPolicy de egress que bloquea el puerto 53. Este último caso es tan frecuente que le dedicaremos un apartado entero.

Causa: el resolv.conf del pod no es el del clúster. Casi siempre es dnsPolicy: Default puesto sin querer, o hostNetwork: true sin ClusterFirstWithHostNet. Compruébalo:

Segunda causa posible: el nombre está mal. Un error tipográfico, un Service en otro namespace, o el Service simplemente no existe.

El DNS no es el problema. Ya has demostrado que la resolución funciona; el fallo está en el Service (endpoints vacíos, 02-05), en el CNI o en una política de red. Este es el caso más malinterpretado: se culpa al DNS porque "no conecta por el nombre", cuando nslookup ya ha respondido correctamente.

La variante de lentitud sí puede ser DNS: si la resolución tarda segundos, mira ndots y los dominios externos sin punto final (apartado 7), o busca saturación en las métricas de CoreDNS.

En clústeres con carga alta el DNS se convierte en cuello de botella. Dos medidas estándar:

Réplicas de CoreDNS. Por defecto son 2 (1 en minikube). Se escala con el tamaño del clúster, vigilando sus métricas antes de que duela: kubectl scale deployment coredns -n kube-system --replicas=3. Existe cluster-proportional-autoscaler, que ajusta las réplicas según el número de nodos y núcleos, y es lo que usan las distribuciones gestionadas.

NodeLocal DNSCache. Un DaemonSet que pone una caché DNS en cada nodo. Los pods consultan a esa caché local (por una IP de enlace, típicamente 169.254.20.10) en lugar de cruzar la red hasta CoreDNS.

Para Rutas Norte, con sus picos de puentes, es la medida que se plantearía junto con el autoescalado de 09-01.

• Culpar al DNS cuando nslookup responde bien. Si resuelve, el DNS ha hecho su trabajo. Sigue por el Service y sus endpoints.
• Editar el Corefile sin revisar el log. Un error de sintaxis tumba CoreDNS y con él todo el clúster. Tras cada kubectl edit configmap coredns, mira kubectl logs -n kube-system -l k8s-app=kube-dns.
• Dominios externos sin punto final. Multiplican por cuatro (u ocho) las consultas. En Rutas Norte, la URL de la pasarela de pagos debe llevar el punto.
• Usar hostNetwork: true sin dnsPolicy: ClusterFirstWithHostNet. El pod pierde la capacidad de resolver Services y el error es desconcertante.
• Usar las variables *_SERVICE_HOST. Dependen del orden de creación y se congelan. Usa nombres DNS y desactívalas con enableServiceLinks: false.
• Cachear resoluciones para siempre en la aplicación. Algunos entornos (la JVM con la configuración por defecto histórica) cachean sin caducidad y siguen usando una IP muerta. Ajusta el TTL del resolutor de tu lenguaje.
• Suponer que el namespace aísla. Un pod de dev resuelve y conecta a postgres-reservas.rutas-norte-pro. Eso solo lo corta 04-06.
• Consejo: ante cualquier duda, ejecuta dig +search y no dig a secas. Sin +search no se aplican los sufijos y estarás probando algo distinto de lo que hace tu aplicación.
• Consejo: vigila coredns_dns_request_duration_seconds y la tasa de NXDOMAIN. Un pico de NXDOMAIN suele significar que alguien ha desplegado una aplicación con nombres externos sin punto final.

Desde un pod efímero en rutas-norte-pro, resuelve postgres-reservas en sus cuatro formas (corta, con namespace, con .svc, completa) y comprueba que todas dan la misma IP. Después resuelve postgres-reservas.rutas-norte-dev y explica qué demuestra el resultado.

Desde un pod efímero, cuenta cuántas consultas provoca resolver pagos.proveedorexterno.example sin punto final y con punto final. Calcula el ahorro para 2.000 compras por minuto y propón dos formas de arreglarlo en el manifiesto de api-reservas.

Se despliegan tres pods de prueba: A con hostNetwork: true y dnsPolicy por defecto; B normal pero consultando un Service inexistente; C normal, con el Service correcto pero cuyo Deployment está escalado a cero. Predice el síntoma de cada uno y verifícalo.

Ejercicio 1

Las cuatro primeras son la misma IP: las formas cortas se completan con la lista search. La quinta demuestra que desde producción se resuelve el Service de desarrollo, con una IP distinta: los namespaces no aíslan la red. Y si además pruebas nc -zv postgres-reservas.rutas-norte-dev 5432, conectará.

Ejercicio 2

Sin punto: 4 intentos (3 NXDOMAIN + 1 acierto), por 2 al contar AAAA = 8 consultas. Con punto: 2. Ahorro del 75 %.

A 2.000 compras por minuto: 16.000 consultas/min frente a 4.000. Doce mil consultas inútiles cada minuto contra CoreDNS.

Dos arreglos en el manifiesto:

La A es quirúrgica y no afecta a nada más; la B sirve cuando no puedes tocar las URLs, pero recuerda que rompe las formas cortas con un punto.

Ejercicio 3

El caso C es la lección más valiosa de las tres: resolver no es conectar.

Ahora sabes quién traduce postgres-reservas a una dirección IP. CoreDNS es un Deployment normal de kube-system, expuesto por el Service kube-dns en 10.96.0.10, configurado por un Corefile cuyo plugin kubernetes observa Services y EndpointSlices para responder el dominio cluster.local, y cuyo plugin forward envía todo lo demás al resolutor del nodo. Que sea una carga de trabajo corriente tiene una consecuencia operativa: puede caerse, saturarse o quedarse sin memoria, y cuando eso ocurre toda la plataforma parece rota a la vez.

Dominas el esquema de nombres <servicio>.<namespace>.svc.cluster.local y sabes que las formas cortas funcionan gracias a la lista search del resolv.conf, no por magia. Conoces los registros que genera cada objeto: una A con el ClusterIP para un Service normal, una A por pod listo para uno headless, nombres de pod derivados de la IP, y registros SRV que publican el puerto de los puertos con nombre. Y entiendes lo que la resolución no hace: no reparte carga en un Service normal (eso es kube-proxy) y no garantiza conectividad.

El apartado que más te va a ahorrar es ndots: 5. Un dominio externo con menos de cinco puntos provoca cuatro intentos de resolución, ocho consultas contando AAAA, y en los picos de puentes de Rutas Norte eso son miles de consultas inútiles por minuto contra CoreDNS. El punto final en pagos.proveedorexterno.example. lo reduce a una. Sabes ajustar dnsPolicy y dnsConfig, has visto por qué hostNetwork: true sin ClusterFirstWithHostNet deja al pod sin acceso al DNS del clúster, y por qué las variables *_SERVICE_HOST heredadas de Docker no deben usarse jamás —dependen del orden de creación y se congelan— hasta el punto de desactivarlas con enableServiceLinks: false. Tienes también los tres fallos típicos con su firma inconfundible, y en el horizonte NodeLocal DNSCache y el escalado de CoreDNS para cuando la carga apriete.

Con la red entendida (04-01), los tipos de Service dominados (04-02) y el descubrimiento resuelto, ya no queda ninguna excusa: es hora de abrir la plataforma al mundo. En 04-04 desplegaremos un controlador de Ingress y publicaremos por fin www.rutasnorte.example contra tienda-web y api.rutasnorte.example contra api-reservas, con un único punto de entrada, enrutado por dominio y por ruta. Los clientes de Rutas Norte podrán, por primera vez en el curso, comprar un billete.