Service Discovery и DNS

Service Discovery и DNS

1) Por qué es necesario

En los sistemas distribuidos, los nodos aparecen y desaparecen, y los clientes deben encontrar las instancias de trabajo del servicio de forma rápida y confiable. DNS: capa universal de nombres; discovery de servicio: una estrategia para asignar el nombre del servicio a los puntos de acceso reales, teniendo en cuenta la salud, el peso y las políticas de enrutamiento.

• nombres estables en lugar de direcciones efímeras,
• un apdate preciso pero no ruidoso (equilibrio entre frescura y TTL),
• degradación sin caída total (failover/health-check),
• un mínimo de «conjeturas» sobre el cliente: timeouts, retraídas, políticas de caché.

2) Modelos de discovery de servicio

2. 1 Cliente (lado cliente)

El propio cliente resuelve el nombre en un conjunto de puntos de conexión y equilibra (round-robin, EWMA, hash por clave). Fuente - DNS (A/AAAA/SRV), registro de servicios (Consul/Eureka), lista estática.

Pros: menos SPOF central, algoritmos flexibles.
Contras: la heterogeneidad de los clientes, es más difícil actualizar la lógica.

2. 2 Servidor (server-side)

El cliente va a front/LB (L4/L7, gateway/ingress). Equilibrio y health-checking - en el lado proxy/balanceador.

Pros: un único lugar de política, observabilidad.
Contras: necesita un perímetro de alta disponibilidad (N + 1, multi-AZ).

2. 3 Híbrido

El DNS da un conjunto de puntos de entrada (LB regionales), más lejos está el equilibrio en el L7/mesh.

3) DNS: fundamentos, registros y TTL

3. 1 Tipos básicos

A/AAAA - IPv4/IPv6 direcciones.
CNAME - alias a otro nombre (no en apex).
SRV — `_service._proto. name '→ host/puerto/peso/prioridad (para gRPC/LDAP/SIP, etc.).
TXT/HTTP/HTTPS - metadatos/punteros (incluyendo para el descubrimiento HTTP).
NS/SOA - Delegación y atributos de zona.

3. 2 TTL y caché en cascada

La caché tiene: resolver SO, resolver stub local, nodos (NodeLocal DNS/CoreDNS), proveedor, recursores intermedios y cliente de biblioteca. Frescura real = min (TTL, política del cliente). La caché negativa (NXDOMAIN) también se almacena en caché por 'SOA. MINIMUM`/`TTL`.

• Prod - TTL 30-120s para registros dinámicos, 300-600s para estables.
• Para los cambios (Feilover), prepare el TTL reducido con antelación, no «durante el incendio».
• Tenga en cuenta la caché sticky de las bibliotecas (Java/Go/Node): configure la TTL de resolver dentro del rantime si es necesario.

4) Políticas de equilibrio y tolerancia a fallas DNS

Weighted RR - pesos en A/AAAA/SRV.
Failover - kits primarios/secundarios (health-check afuera).
Geo/Latency es la respuesta a la región/RR «más cercana».
Anycast es una IP en diferentes POP (BGP); resistente a las interrupciones regionales.
Split-horizon son diferentes respuestas dentro de VPC/on-prem y en Internet.
GSLB es un equilibrador global con controles y políticas de salud (latency, geo, capacity).

5) Health-checks y frescura

• O bien el controlador de salud externo controla los registros/escalas (GSLB, Route53/Traffic-policy, external-dns + muestras).
• O bien el cliente/mesh hace un outlier-ejection activo y retry de muchos puntos de venta.

6) Kubernetes: discovery fuera de la caja

Nombres de servicio: 'svc. namespace. svc. cluster. local`.
ClusterIP: IP virtual estable + kube-proxy/ebpf.
Headless Service ('clusterIP: None'): da entradas A en pod's (o su subdominio), SRV para puertos.
EndpointSlice: lista escalable de endpoints (reemplazo de Endpoints).
CoreDNS: resolver DNS del clúster; plugins rewrite/template/forward/cache; 'kube-dns' zona.
NodeLocal DNSCache: caché local en el nodo → menos latency e intercepción de problemas de resolver Apstrim.

Ejemplo: Headless + SRV

yaml apiVersion: v1 kind: Service metadata: { name: payments, namespace: prod }
spec:
clusterIP: None selector: { app: payments }
ports:
- name: grpc port: 50051 targetPort: 50051

El cliente puede resolver '_ grpc. _ tcp. payments. prod. svc. cluster. local '(SRV) y obtener host/puerto/peso.

CoreDNS (fragmento ConfigMap)

yaml apiVersion: v1 kind: ConfigMap metadata: { name: coredns, namespace: kube-system }
data:
Corefile:
.:53 {
errors health ready cache 30 loop forward. /etc/resolv. conf prometheus:9153 reload
}

• DaemonSet con resolver local en el '169. 254. 20. 10`; kubelet especifica este punto.
• Reduce el p99 name-resolution y protege del «flap» el upstrim-DNS.

7) Service discovery вне K8s

Consul: agente, health-checks, directorio de servicios, interfaz DNS ('.consul'), KV para configuraciones.
Eureka/ZooKeeper/etcd: registros para JVM/legacy; a menudo en conjunto con sidecar/gateway.
Envoy/Istio: EDS/xDS (Endpoint Discovery) y SDS (Secretos); los servicios se anuncian a través de control-plane.

8) Seguridad DNS

DNSSEC: proteger la integridad de los registros (firma de zona). Crítico con los dominios públicos.
DoT/DoH: cifrado de canal a recursor (políticas internas, compatibilidad).
ACL y split-horizon: zona privada - sólo de VPC/VPN.
Protección contra envenenamiento por caché: aleatorización de puertos/ID, TTL cortos para altavoces.
Políticas de egresos: Permita DNS sólo para resolutores de confianza, registre.

9) Comportamiento de los clientes y retraídas

Respete el TTL: no almacene en caché indefinidamente, no «desdistribuya» con resolvas frecuentes (tormenta al recursor).
Happy Eyeballs (IPv4/IPv6), los conectores paralelos a varios A/AAAA reducen el tail.
Retrai sólo en solicitudes idempotentes; jitter, limitación de los retraídos budget.

• Java: `networkaddress. cache. ttl`, `networkaddress. cache. negative. ttl`.
• Go: `GODEBUG=netdns=go`/`cgo`, `Resolver. PreferGo`, `DialTimeout`.
• Node: `dns. setDefaultResultOrder('ipv4first')`, `lookup` с `all:true`.

10) GSLB/conmutación DNS: práctica

Baje el TTL de 300→60 24 a 48 horas antes de la conmutación programada.
Mantenga un conjunto de endpoints canarios con poco peso para validar.
Aplique weighted + health-check en lugar del apdate masivo manual de las entradas A.
Para estática/edge - Anycast; para API - Geo/Latency + rápido L7-failover.

11) Observabilidad y SLO para el nombre

• Rate/latency consultas DNS, cache hit-ratio, errores por tipo (SERVFAIL/NXDOMAIN).
• Porcentaje de consultas con respuestas stale (si utiliza stale-cache).
• Éxito de las operaciones de usuario en los cambios de registros (SLI de empresa).
• p95/p99 resolve-time en aplicaciones.

• Estratifique la ruta: cliente → caché local → caché de nodo → resolver de clúster → recursor de proveedor.
• Realice un seguimiento de las ráfagas de NXDOMAIN (errores de nombres/errores tipográficos) y SERVFAIL (problemas de recursos/límites de recursos).

12) Ejemplos de configuraciones

CoreDNS: rewrite y zona stub

yaml
.:53 {
log errors cache 60 rewrite name suffix. svc. cluster. local. svc. cluster. local forward. 10. 0. 0. 2 10. 0. 0. 3
}

example. internal:53 {
file /zones/example. internal. signed dnssec
}

systemd-resolved (fuerza de resolver local)

ini
[Resolve]
DNS=169. 254. 20. 10
FallbackDNS=1. 1. 1. 1 8. 8. 8. 8
Domains=~cluster. local ~internal
DNSSEC=yes

Envoy: DNS-refresh dinámico

yaml dns_refresh_rate: 5s dns_failure_refresh_rate:
base_interval: 2s max_interval: 30s respect_dns_ttl: true

external-dns (soporte de zona pública)

yaml args:
- --source=service
- --source=ingress
- --domain-filter=example. com
- --policy=upsert-only
- --txt-owner-id=cluster-prod

13) Lista de verificación de implementación (0-30 días)

0-7 días

Directorio de nombres de servicios, selección de modelos (cliente-/server-side/híbrido).
TTL básicos, habilitar NodeLocal DNSCache, dashboards métricas DNS.
Prohibición de «IP rígidas» en la configuración/código.

8-20 días

Servicios sin cabeza + SRV para gRPC; EndpointSlice está habilitado.
GSLB/weighted para externos; health-checks y canario.
Los tiempos de espera/retiros de los clientes y el presupuesto de los retiros están configurados.

21-30 días

Split-horizon y zonas privadas; DoT/DoH sobre políticas.
Prueba de conmutación (por TTL) y failover; post-análisis.
Las políticas mesh/EDS, outlier-ejection están habilitadas.

14) Anti-patrones

TTL = 0 en venta → tormenta a recursores, retrasos impredecibles.
Código duro IP/puertos, sin CNAME/alias para niveles.
Cambio de entradas «manualmente» sin health-checks y canarios.
Un resolver global sin caché en los nodos (cuello de botella).
Ignora la memoria caché negativa (picos NXDOMAIN).
Intentos de «curar» la falla de DNS a través de DNS en lugar del nivel de datos/feolover.

15) Métricas de madurez

El 100% de los servicios utilizan nombres; cero casos de hard-IP.
CoreDNS/NodeLocal en venta, cache hit-ratio> 90% en nodos.
GSLB con checks de salud documentados por TTL y runbook de conmutación.
SRV/EndpointSlice para stateful/gRPC, p99 resolve-time en aplicaciones ≤ 20-30 ms.
Alertas por SERVFAIL/NXDOMAIN y degradación cache hit-ratio.
Verificaciones en CI: prohibición ': latest' y hard-IP en las listas/configuraciones.

16) Conclusión

El discovery de servicio es un contrato de nombre estable y disciplina de caché. Construye un modelo híbrido: DNS da una entrada rápida y fácil, L7/mesh es salud y políticas inteligentes. Admita TTLs razonables, caché en nodos, servicios sin cabeza y SRV donde sea necesario, use GSLB/Anycast para los límites de las regiones, monitoree NXDOMAIN/SERVFAIL y p99 resolve-time. Entonces su nombre será un activo tan confiable como el propio servicio.