Service Discovery и DNS

Service Discovery и DNS

1) Perché è necessario

Nei sistemi distribuiti, i nodi compaiono e scompaiono e i clienti devono trovare istanze operative del servizio in modo rapido e affidabile. DNS - Livello di nomi universale servizio discovery è una strategia per confrontare il nome del servizio con gli endpoint reali in base alla salute, al peso e alla politica di routing.

• nomi stabili invece di indirizzi effimeri,
• accurata, ma non rumorosa (equilibrio tra freschezza e TTL),
• degrado senza caduta totale (failover/health-check),
• minimo «congetture» sul client: timeout, retrai, regole di cache.

2) Modelli di servizio discovery

2. 1 Client (client-side)

Il client autorizza il nome in un set di endpoint e bilancia (round-robin, EWMA, hash chiave). La fonte è DNS (A/AAAA/SRV), servizio-registro (Consul/Eureka), elenco statico.

Meno SPOF centrali, algoritmi flessibili.
Contro: eterogeneità dei clienti, è più difficile aggiornare la logica.

2. 2 Server (server-side)

Il cliente va sul fronte/LB (L4/L7, gateway/ingress). Bilanciamento e health-checking - lato proxy/bilanciatore.

I vantaggi sono il luogo unico della politica, l'osservazione.
Contro - Richiede un perimetro ad alta disponibilità (N + 1, multi-AZ).

2. 3 Ibrido

Il DNS fornisce un insieme di punti di ingresso (LB regionali), il successivo è il bilanciamento su L7/mesh.

3) DNS base, record e TTL

3. 1 Tipi di base

A/AAAA - indirizzo IPv4/IPv6.
CNAME - Alias a un altro nome (non ad apex).
SRV — `_service._proto. name 'host/porta/peso/priorità (per , ecc.).
TXT/HTTP/HTTPS - Metadati/puntatori (ad esempio per HTTP-discovery).
NS/SOA - Delega e attributi della zona.

3. 2 TTL e cascata cache

La cache è disponibile: resolver del sistema operativo, resolutore stub locale, nodi ( ), provider, ricorsori intermedi e il client della libreria. Freschezza reale = min (TTL, criterio del client). Anche la cache negativa (NXDOMAIN) viene memorizzata con «SOA». MINIMUM`/`TTL`.

• Prod - TTL 30-120s per i record dinamici, 300-600s per quelli stabili.
• Per i failover, preparare una TTL ridotta in anticipo anziché in caso di incendio.
• Tieni conto della cache sticky delle librerie (Java/Go/Node) - Configurare il risolutore TTL all'interno del runtime, se necessario.

4) Criteri di bilanciamento e tolleranza DNS

Weighted RR - pesi su A/AAAA/SRV.
Failover - Set primario/secondario (health-check esterno).
Geo/Latency è la risposta al RR/regione più vicina.
Anycast - Un IP in POP diverso (BGP); resistente ai guasti regionali.
Split-horizon - risposte diverse all'interno di VPC/on-pram e su Internet.
GSLB è un bilanciatore globale con health check e regole (latency, geo, capacity).

5) Health-checks e freschezza

• Oppure health-checker esterno controlla i record/pesi (GSLB, Route53/Traffic-policy, esternal-dns + campioni).
• Oppure client/mesh fa outlier-ejection attivo e retry di molti endpoint.

6) Kubernets: discovery dalla scatola

Nomi di servizio: 'svc. namespace. svc. cluster. local`.
ClusterIP: IP virtuale + kube-proxy/ebpf stabile.
Headless Service ('clusterIP: None') - Fornisce i record A a pod's (o il loro sottofondo), SRV per le porte.
EndpointSlice - Elenco scalabile degli endpoint (Sostituisci Endpoint).
CoreDNS - Risolutore DNS del cluster plugin rewrite/template/forward/cache; 'kube-dns' zona.
DNSCache: cache locale sul nodo più piccola di latency e intercettazione dei problemi dell'upstream resolver.

Esempio: 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

Il client può tagliare '_ grpc. _ tcp. payments. prod. svc. cluster. locale '(SRV) e ottenere host/porta/peso.

CoreDNS (porzione di 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
}

• con un locale al 169. 254. 20. 10`; kubelet indica questo punto.
• Riduce p99 name-resolution e protegge da «flap» upstream-DNS.

7) Service discovery вне K8s

Consul: agente, health-checks, servizio-directory, interfaccia DNS ('.consul'), KV per configure.
Eureka/ZooKeeper/etcd: registri per JVM/legacy; spesso in collegamento con sidecar/gateway.
Avvoy/Istio: EDS/xDS (Endpoint Discovery) e SDS (segreti); i servizi vengono annunciati tramite control-plane.

8) Protezione DNS

DNSSEC - Protezione dell'integrità dei record (firma zone). Critico per i domini pubblici.
DoT/DoH: crittografia del canale al ricorsore (criteri interni, compatibilità).
ACL e split-horizon: zona privata - solo VPC/VPN.
Protezione da avvelenamento da cache: randomizzazione delle porte/ID, TTL brevi per l'altoparlante.
Criteri su egress - Consente il DNS solo per i risvolti affidabili, registro.

9) Comportamento dei clienti e retrai

Rispetto della TTL: non memorizzare la cache all'infinito, non distribuirla con frequenti tagliandi (tempesta al ricorsore).
Happy Eyeballs (IPv4/IPv6), connettori paralleli a più A/AAAA riducono il tail.
Retrai solo in caso di richieste idipotenti; jitter, limitazione budget retraes.

• 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/DNS - Pratica

Abbassare la TTL da 24-48 ore prima del cambio programmato.
Tenete un set di endpoint canarini a basso peso per la validazione.
Utilizzare weighted + health-check invece dell'update manuale dei record A.
Per statica/edge - Anycast; per API - Geo/Latency + veloce L7-feelover.

11) Osservabilità e SLO per il nome

• Rate/latency query DNS, cache hit-ratio, errori per tipo (SERVFAIL/NXDOMAIN).
• Percentuale di richieste con risposte stale (se si utilizza lo stale-cache).
• Successo delle operazioni utente per i cambi di record (Business SLI).
• p95/p99 resolve-time nelle applicazioni.

• Rilascia il percorso: il client la cache locale con la cache a nodo, il resolver a cluster del provider.
• Monitorare i picchi NXDOMAIN (errori di nome/errore) e SERVFAIL (problemi ricorsori/risorse-limite).

12) Esempi di configurazione

CoreDNS: rewrite e 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 (forza resolver locale)

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

Avvoy: DNS-refresh dinamico

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

esternal-dns (supporto area pubblica)

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

13) Assegno foglio di implementazione (0-30 giorni)

0-7 giorni

Elenco dei nomi dei servizi, selezione del modello (client/server-side/ibrido).
TTL di base, attivare le NodeLocal DNSCache, i dashboard DNS-metriche.
Proibizione dì hard IP "nella configurazione/codice.

8-20 giorni

Servizi Headless + SRV per l' gRPC; Il EndpointSlice è acceso.
GSLB/weighted per esterni; health-checks e canarino.
Timeout/retrai dei clienti configurati e budget dei retrai.

21-30 giorni

Split-horizon e aree private; DoT/DoH di politica.
Test di commutazione (TTL) e feelover post-analisi.
I criteri mesh/EDS, outlier-ejection sono inclusi.

14) Anti-pattern

TTL = 0 nel →, tempesta ai ricorsori, ritardi imprevedibili.
Hardcode IP/porte, nessun CNAME/aliase per i livelli.
Modifica manuale dei record senza health-checks o canarini.
Una risolutrice globale senza cache sui nodi (ristretto).
Ignora la cache negativa (picchi NXDOMAIN).
Tentativi di «curare» un guasto DNS anziché un livello di dati/feelover.

15) Metriche di maturità

Il 100% dei servizi utilizza i nomi; Zero casi di hard-IP.
CoreDNS/NodeLocal in vendita, cache hit-ratio> 90% su nodi.
GSLB con health-checks documentati da TTL e runbook failover.
SRV/EndpointSlice per il stateful/gRPC, p99 resolve-time nelle applicazioni ≤ 20-30 ms.
Alert per SERVFAIL/NXDOMAIN e degrado cache hit-ratio.
Controlli CI: proibizione di latest e hard-IP nelle liste/configurazioni.

16) Conclusione

Servizio discovery è un contratto di nome stabile e disciplina della cache. Costruisci un modello ibrido: DNS fornisce un ingresso rapido e semplice, L7/mesh: salute e politiche intelligenti. Supportare TTL intelligenti, cache su nodi, servizi headless e SRV dove necessario, utilizzare GSLB/Anycast per i confini regionali, tenere d'occhio NXDOMAIN/SERVFAIL e p99 resolve-time. Allora il tuo nome sarà un bene affidabile come il servizio stesso.