La lliçó anterior va deixar un cap solt deliberat: ExternalName funciona perquè CoreDNS retorna un CNAME, els serveis headless funcionen perquè CoreDNS publica una entrada A per pod, i api-reserves troba postgres-reserves perquè algú resol aquell nom. Portem tres mòduls escrivint postgres-reserves:5432 a la configuració sense haver explicat mai qui tradueix això a una adreça IP. Aquesta lliçó obre la caixa: què és CoreDNS, com es configura, quins noms genera per a cada tipus d'objecte, què hi ha realment al /etc/resolv.conf d'un pod, per què el paràmetre ndots: 5 pot multiplicar per cinc les consultes DNS quan api-reserves truca a la passarel·la de pagaments, i com diagnosticar les tres fallades de DNS que et trobaràs una vegada i una altra.

1. Per què el descobriment es fa per DNS
2. CoreDNS: què és i on viu
3. El Corefile: la configuració del DNS del clúster
4. L'esquema de noms i les formes curtes
5. Registres de Services, Services headless i pods
6. Registres SRV i ports amb nom
7. El /etc/resolv.conf del pod i l'efecte d'ndots: 5
8. dnsPolicy i dnsConfig
9. Les variables d'entorn heretades de Docker
10. Diagnòstic: les tres fallades típiques
11. Escala: NodeLocal DNSCache i rèpliques de CoreDNS

L'alternativa seria configurar adreces IP, i no funciona: les IP dels pods són efímeres (02-05). Un rollout, un desallotjament o un reinici del node la canvien. Podríem fixar la IP del Service, que sí que és estable mentre el Service existeixi, però això tampoc no aguanta:

Amb DNS, api-reserves porta escrit postgres-reserves al seu ConfigMap des de 03-01, i aquell nom és vàlid als tres entorns, en un clúster nou i després de recrear el Service: és l'única referència estable que existeix a Kubernetes. A més, el DNS és universal: no requereix biblioteca, ni SDK, ni saber que ets a Kubernetes.

CoreDNS és un servidor DNS escrit en Go, modular a base de plugins, i és el DNS per defecte de Kubernetes des de la versió 1.13 (va substituir kube-dns). S'executa com un Deployment normal al namespace kube-system, exposat per un Service anomenat kube-dns (el nom es va conservar per compatibilitat).

Tres observacions que resolen molts dubtes:

• CoreDNS és una càrrega de treball com qualsevol altra. Pot caure, quedar-se sense recursos, ser desallotjada. Quan CoreDNS pateix, tota la plataforma sembla trencada simultàniament, i aquell símptoma global és el que t'ha de fer mirar aquí.
• La IP 10.96.0.10 és la desena adreça del serviceCIDR per convenció, i és la que el kubelet injecta a cada pod.
• El port 9153 exposa mètriques Prometheus (07-03): taxa de consultes, latència, errors. És de les primeres coses que convé monitorar.

Fixa't en la circularitat aparent: els pods arriben a CoreDNS a través d'un ClusterIP, que necessita kube-proxy però no necessita DNS. No hi ha problema de l'ou i la gallina perquè la IP 10.96.0.10 va injectada literalment al resolv.conf.

CoreDNS es configura amb un fitxer anomenat Corefile, que viu en un ConfigMap i es munta al pod. El pots llegir tal qual:

Llegeix això com una cadena de plugins que s'avaluen en ordre per a tota consulta que arribi al port 53.

Un cas pràctic de Rutas Norte: l'oficina té un DNS intern a 10.20.30.5 que resol *.interno.rutasnorte.example, on viu la base de dades de facturació heretada. S'afegeix un bloc específic amb kubectl edit configmap coredns -n kube-system:

El plugin reload ho recull sol. Compte: és configuració de tot el clúster; un error de sintaxi deixa CoreDNS en CrashLoopBackOff i amb ell tota la plataforma. Revisa el log després de cada canvi.

El nom canònic d'un Service té sempre aquesta estructura:

Les formes curtes funcionen gràcies a la llista search del resolv.conf (apartat 7). Des d'un pod de rutas-norte-pro:

Aquell últim cas mereix èmfasi. Un pod de rutas-norte-dev pot resoldre i connectar a postgres-reserves.rutas-norte-pro. La separació per namespace és organitzativa, no de seguretat. Només les NetworkPolicies de 04-06 ho impedeixen de debò.

Regla pràctica per a Rutas Norte:

• Dins del mateix entorn, fes servir el nom curt: postgres-reserves, redis-cache. El mateix ConfigMap serveix per a dev, pre i pro sense canvis.
• Per creuar namespaces, fes servir sempre la forma completa amb .svc.cluster.local. És explícita i, com veurem, més ràpida.

Una sola resposta: la IP virtual. El balanceig entre pods el fa kube-proxy després, com vas veure a 04-01. El DNS no intervé en el repartiment.

Tres registres A, un per pod llest (ready: true a l'EndpointSlice). Aquí el DNS sí que participa en el descobriment, i qui tria és el client. El plugin loadbalance barreja l'ordre a cada resposta perquè els clients que només miren el primer registre reparteixin alguna cosa.

Un pod que no està llest desapareix d'aquesta llista, tret que el Service tingui publishNotReadyAddresses: true (necessari perquè les rèpliques d'una base de dades es descobreixin entre si durant l'arrencada, cosa que veurem a 06-01).

Amb pods insecure al Corefile, tot pod té un nom derivat de la seva IP amb els punts substituïts per guions: 10-244-0-14.rutas-norte-pro.pod.cluster.local resol a 10.244.0.14. Fixa't en pod en lloc de svc. És d'ús molt limitat: ningú no escriu això a mà. La seva importància real arriba amb els StatefulSets, on cada pod obté un nom estable i llegible dins d'un Service headless:

Aquesta és la identitat de xarxa que fa possible una base de dades en clúster, i arriba a 06-01.

Els registres SRV publiquen, a més de l'adreça, el port. Es generen per a tot port amb nom d'un Service, amb el format _<port>._<protocol>.<servei>.<ns>.svc.cluster.local.

Recuperant l'api-reserves multiport de 04-02, amb ports http (3000) i metrics (9090):

El format és prioritat pes port desti. Un client que sàpiga llegir SRV descobreix el port sense tenir-lo configurat. En un Service headless, un SRV retorna una línia per pod, amb el port de cadascun:

Poques aplicacions consulten SRV; la majoria configura el port explícitament. Però és el mecanisme que fan servir diversos operadors i biblioteques de descobriment, i és la raó concreta per la qual insistim a anomenar sempre els ports.

El kubelet escriu aquest fitxer dins de cada contenidor:

Tres línies, tres decisions:

• nameserver 10.96.0.10: el ClusterIP de kube-dns. És el que fa que les formes curtes es resolguin.
• search: els sufixos que el resolutor provarà. El primer és el namespace mateix: per això postgres-reserves a seques funciona dins de rutas-norte-pro.
• options ndots:5: aquí hi ha el parany.

ndots:5 diu al resolutor: "si el nom que et demanen té menys de 5 punts, prova'l primer amb cada sufix de search, i només al final tal qual".

Compta els punts de pagos.proveedorexterno.example: dos. Menys de cinc. Així que el resolutor fa això:

Quatre consultes, tres d'inútils. I pitjor: cadascuna es fa per a A i per a AAAA, així que a la pràctica són 8 consultes quan n'hi havia prou amb 2. Les tres primeres, a més, viatgen a CoreDNS, que consulta l'API i retorna NXDOMAIN.

Ara trasllada això a Rutas Norte en un pont d'agost: api-reserves truca a la passarel·la de pagaments a cada compra. Amb 2.000 compres per minut i sense memòria cau de resolució a l'aplicació, són 16.000 consultes per minut on n'haurien de ser 4.000. CoreDNS se satura, la latència de resolució puja, i tot el clúster comença a anar a poc a poc per una causa que ningú no relaciona amb el DNS.

Un nom acabat en punt és un FQDN absolut: el resolutor no hi afegeix sufixos.

Una consulta. Fi.

Avís: si baixes ndots a 1, els noms curts com redis-cache (zero punts) continuen funcionant, però postgres-reserves.rutas-norte-pro (un punt) deixaria de resoldre's per cerca i necessitaria l'FQDN. Baixar a 2 és un compromís habitual i segur.

dnsPolicy és un camp del spec del pod que decideix quin resolv.conf rep.

El cas de ClusterFirstWithHostNet és un parany clàssic: un pod amb hostNetwork: true i dnsPolicy: ClusterFirst (el valor per defecte) rep el resolv.conf del node i per tant no pot resoldre cap Service. Si poses xarxa d'amfitrió, has de canviar també la política.

dnsConfig permet ajustar el fitxer resultant:

Amb dnsPolicy: None és obligatori donar almenys un nameserver a dnsConfig, o el pod no arrenca.

Kubernetes injecta a cada contenidor variables d'entorn amb l'adreça i el port de tots els Services que existien al seu namespace en el moment de crear-se el pod. És un vestigi de l'enllaçat de contenidors de Docker.

Semblen còmodes i no s'han de fer servir mai. Quatre raons:

1. Només existeixen els Services creats ABANS que el pod. Si desplegues api-reserves i després redis-cache, la variable no existeix. I l'ordre de creació no és una cosa que controlis de manera fiable.
2. Es congelen en arrencar el pod. Si el ClusterIP canvia (Service recreat), la variable continua amb el valor vell i el pod apunta a una IP morta fins que es reiniciï.
3. Contaminen l'entorn. Amb 50 Services al namespace són centenars de variables per contenidor. Hi ha casos documentats de fallades en arrencar per excedir la mida de l'entorn.
4. Trenquen la portabilitat. Aquell POSTGRES_RESERVES_SERVICE_HOST no significa res fora de Kubernetes.

Fes servir sempre el nom DNS, que no depèn de l'ordre, es resol fresc i funciona igual a qualsevol lloc. El soroll de variables s'elimina amb enableServiceLinks: false al spec del pod, recomanable a tots els Deployments de Rutas Norte.

El pod de treball, com a 04-01:

Comprovacions bàsiques a dins:

Causa: CoreDNS és caigut, saturat o no és accessible. És una fallada global, i la seva signatura és que tots els components fallen alhora.

Sospitosos habituals: pods de CoreDNS en CrashLoopBackOff per un Corefile mal editat; el Service kube-dns sense endpoints; CoreDNS OOMKilled per manca de memòria sota càrrega; o —i això serà molt rellevant a 04-06— una NetworkPolicy d'egress que bloqueja el port 53. Aquest últim cas és tan freqüent que li dedicarem un apartat sencer.

Causa: el resolv.conf del pod no és el del clúster. Gairebé sempre és dnsPolicy: Default posat sense voler, o hostNetwork: true sense ClusterFirstWithHostNet. Comprova-ho:

Segona causa possible: el nom està malament. Un error tipogràfic, un Service en un altre namespace, o el Service simplement no existeix.

El DNS no és el problema. Ja has demostrat que la resolució funciona; la fallada és al Service (endpoints buits, 02-05), al CNI o en una política de xarxa. Aquest és el cas més mal interpretat: es culpa el DNS perquè "no connecta pel nom", quan nslookup ja ha respost correctament.

La variant de lentitud sí que pot ser DNS: si la resolució triga segons, mira ndots i els dominis externs sense punt final (apartat 7), o busca saturació a les mètriques de CoreDNS.

En clústers amb càrrega alta el DNS es converteix en coll d'ampolla. Dues mesures estàndard:

Rèpliques de CoreDNS. Per defecte són 2 (1 a minikube). S'escala amb la mida del clúster, vigilant-ne les mètriques abans que faci mal: kubectl scale deployment coredns -n kube-system --replicas=3. Existeix cluster-proportional-autoscaler, que ajusta les rèpliques segons el nombre de nodes i nuclis, i és el que fan servir les distribucions gestionades.

NodeLocal DNSCache. Un DaemonSet que posa una memòria cau DNS a cada node. Els pods consulten aquella memòria cau local (per una IP d'enllaç, típicament 169.254.20.10) en lloc de creuar la xarxa fins a CoreDNS.

Per a Rutas Norte, amb els seus pics de ponts, és la mesura que es plantejaria juntament amb l'autoescalat de 09-01.

• Culpar el DNS quan nslookup respon bé. Si resol, el DNS ha fet la seva feina. Continua pel Service i els seus endpoints.
• Editar el Corefile sense revisar el log. Un error de sintaxi tomba CoreDNS i amb ell tot el clúster. Després de cada kubectl edit configmap coredns, mira kubectl logs -n kube-system -l k8s-app=kube-dns.
• Dominis externs sense punt final. Multipliquen per quatre (o vuit) les consultes. A Rutas Norte, l'URL de la passarel·la de pagaments ha de portar el punt.
• Fer servir hostNetwork: true sense dnsPolicy: ClusterFirstWithHostNet. El pod perd la capacitat de resoldre Services i l'error és desconcertant.
• Fer servir les variables *_SERVICE_HOST. Depenen de l'ordre de creació i es congelen. Fes servir noms DNS i desactiva-les amb enableServiceLinks: false.
• Guardar resolucions per sempre a la memòria cau de l'aplicació. Alguns entorns (la JVM amb la configuració per defecte històrica) les guarden sense caducitat i continuen fent servir una IP morta. Ajusta el TTL del resolutor del teu llenguatge.
• Suposar que el namespace aïlla. Un pod de dev resol i connecta a postgres-reserves.rutas-norte-pro. Això només ho talla 04-06.
• Consell: davant de qualsevol dubte, executa dig +search i no dig a seques. Sense +search no s'apliquen els sufixos i estaràs provant una cosa diferent del que fa la teva aplicació.
• Consell: vigila coredns_dns_request_duration_seconds i la taxa d'NXDOMAIN. Un pic d'NXDOMAIN sol significar que algú ha desplegat una aplicació amb noms externs sense punt final.

Des d'un pod efímer a rutas-norte-pro, resol postgres-reserves en les seves quatre formes (curta, amb namespace, amb .svc, completa) i comprova que totes donen la mateixa IP. Després resol postgres-reserves.rutas-norte-dev i explica què demostra el resultat.

Des d'un pod efímer, compta quantes consultes provoca resoldre pagos.proveedorexterno.example sense punt final i amb punt final. Calcula l'estalvi per a 2.000 compres per minut i proposa dues maneres d'arreglar-ho al manifest d'api-reserves.

Es despleguen tres pods de prova: A amb hostNetwork: true i dnsPolicy per defecte; B normal però consultant un Service inexistent; C normal, amb el Service correcte però el Deployment del qual està escalat a zero. Prediu el símptoma de cadascun i verifica'l.

Exercici 1

Les quatre primeres són la mateixa IP: les formes curtes es completen amb la llista search. La cinquena demostra que des de producció es resol el Service de desenvolupament, amb una IP diferent: els namespaces no aïllen la xarxa. I si a més proves nc -zv postgres-reserves.rutas-norte-dev 5432, connectarà.

Exercici 2

Sense punt: 4 intents (3 NXDOMAIN + 1 encert), per 2 en comptar AAAA = 8 consultes. Amb punt: 2. Estalvi del 75 %.

A 2.000 compres per minut: 16.000 consultes/min davant de 4.000. Dotze mil consultes inútils cada minut contra CoreDNS.

Dos arreglaments al manifest:

L'A és quirúrgica i no afecta res més; la B serveix quan no pots tocar les URL, però recorda que trenca les formes curtes amb un punt.

Exercici 3

El cas C és la lliçó més valuosa de les tres: resoldre no és connectar.

Ara saps qui tradueix postgres-reserves a una adreça IP. CoreDNS és un Deployment normal de kube-system, exposat pel Service kube-dns a 10.96.0.10, configurat per un Corefile el plugin kubernetes del qual observa Services i EndpointSlices per respondre el domini cluster.local, i el plugin forward del qual envia tota la resta al resolutor del node. Que sigui una càrrega de treball corrent té una conseqüència operativa: pot caure, saturar-se o quedar-se sense memòria, i quan això passa tota la plataforma sembla trencada alhora.

Domines l'esquema de noms <servei>.<namespace>.svc.cluster.local i saps que les formes curtes funcionen gràcies a la llista search del resolv.conf, no per màgia. Coneixes els registres que genera cada objecte: una A amb el ClusterIP per a un Service normal, una A per pod llest per a un de headless, noms de pod derivats de la IP, i registres SRV que publiquen el port dels ports amb nom. I entens el que la resolució no fa: no reparteix càrrega en un Service normal (això és kube-proxy) i no garanteix connectivitat.

L'apartat que més t'estalviarà és ndots: 5. Un domini extern amb menys de cinc punts provoca quatre intents de resolució, vuit consultes comptant AAAA, i als pics de ponts de Rutas Norte això són milers de consultes inútils per minut contra CoreDNS. El punt final a pagos.proveedorexterno.example. ho redueix a una. Saps ajustar dnsPolicy i dnsConfig, has vist per què hostNetwork: true sense ClusterFirstWithHostNet deixa el pod sense accés al DNS del clúster, i per què les variables *_SERVICE_HOST heretades de Docker no s'han de fer servir mai —depenen de l'ordre de creació i es congelen— fins al punt de desactivar-les amb enableServiceLinks: false. Tens també les tres fallades típiques amb la seva signatura inconfusible, i a l'horitzó NodeLocal DNSCache i l'escalat de CoreDNS per quan la càrrega estrenyi.

Amb la xarxa entesa (04-01), els tipus de Service dominats (04-02) i el descobriment resolt, ja no queda cap excusa: és hora d'obrir la plataforma al món. A 04-04 desplegarem un controlador d'Ingress i publicarem per fi www.rutasnorte.example contra botiga-web i api.rutasnorte.example contra api-reserves, amb un únic punt d'entrada, encaminat per domini i per ruta. Els clients de Rutas Norte podran, per primera vegada al curs, comprar un bitllet.