Service Discovery и DNS

Service Discovery и DNS

1) Por que é necessário

Nos sistemas distribuídos, os nós aparecem e desaparecem e os clientes devem encontrar as instâncias de trabalho do serviço de forma rápida e segura. DNS - camada universal de nomes; service discovery é uma estratégia para mapear o nome do serviço de endpoint reais com base na saúde, peso e política de roteamento.

• nomes estáveis em vez de endereços efêmeros,
• exato, mas não barulhento update (equilíbrio entre frescura e TTL),
• degradação sem queda total (failover/health-check),
• O mínimo de «palpites» no cliente, timeouts, retais, política em dinheiro.

2) Modelos de service discovery

2. 1 Cliente (cliente-side)

O cliente permite o próprio nome para o conjunto de endpoint e balança (round-robin, EWMA, hash na chave). A fonte é DNS (A/AAAA/SRV), serviço-registro (Consul/Eureka), lista estática.

Mais: menos SPOF central, algoritmos flexíveis.
Contras: heterogeneidade dos clientes, mais difícil de atualizar a lógica.

2. 2 Servidor (server-side)

O cliente vai para o front/LB (L4/L7, gateway/ingress). O balanço e o health-checking estão no lado proxy/balanceador.

Um lugar único na política, observabilidade.
Contras: é preciso um perímetro altamente acessível (N + 1, multi-AZ).

2. 3 Híbrido

O DNS dá um conjunto de pontos de entrada (LB regionais), mais adiante, um balanço em L7/mesh.

3) DNS: base, gravações e TTL

3. 1 Tipos básicos

A/AAAA - IPv4/IPv6 endereço.
CNAME - alias para outro nome (não para apex).
SRV — `_service._proto. name '→ servidor/porta/peso/prioridade (para gRPC/LDAP/SIP, etc.).
TXT/HTTP/HTTPS - Metadados/ponteiros (incluindo para discovery HTTP).
NS/SOA - delegação e atributos de área.

3. 2 TTL e cascata em dinheiro

O dinheiro tem resolvar OS, o stub-resolver local, os nós (NodeLocal DNS/CoreDNS), o provedor, os recursores intermediários e o cliente da biblioteca. Frescor real = min (TTL, política do cliente). O dinheiro negativo (NXDOMAIN) também é armazenado em "SOA. MINIMUM`/`TTL`.

• Prod - TTL 30-120s para registros dinâmicos, 300-600s para estáveis.
• Para alternar, prepare um TTL reduzido com antecedência, em vez de «durante um incêndio».
• Leve em conta o cachê sticky das bibliotecas (Java/Go/Node) - se necessário, configure o TTL de resolvar dentro do rating.

4) Políticas de equilíbrio DNS e resistência a falhas

Weighted RR - peso em A/AAAA/SRV.
Failover - kits primários/secundários (health-check-up exterior).
Geo/Latency - resposta ao RR/região mais próxima.
Anycast - um IP em POP diferente (BGP); resistentemente a falhas regionais.
Split-horizonte - diferentes respostas dentro do VPC/on-pram e na internet.
GSLB é um balanceador global com health checs e políticas (latency, geo, capacity).

5) Health-checks e frescor

• Ou o health-checker externo controla os registros/balanças (GSLB, Route53/Traffic-policy, external-dns + amostras).
• Ou o cliente/mesh faz outler-ejation ativo e retry de muitos endpoint.

6) Kubernetes: discovery da caixa

Nomes de serviço: 'svc. namespace. svc. cluster. local`.
ClusterIP: IP virtual estável + kube-proxy/ebpf.
Headless Service ('clusterIP: None'): dá gravações A para pod's (ou seu falso), SRV para as portas.
EndpointSlice: lista de endpoint escalável (substituir Endpoants).
CoreDNS: Resolver DNS do cluster; plugins rewrite/template/forward/cachê; 'kube-dns' área.
DNSCache: O dinheiro local no nó menos latency e interceptação de problemas de upstream.

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

O cliente pode cortar '_ grpc. _ tcp. payments. prod. svc. cluster. local '(SRV) e obter hosts/porta/peso.

CoreDNS (fatia de 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
}

• Com uma ressalva local no '169. 254. 20. 10`; kubelet indica este ponto.
• Reduz p99 name-resolution e protege contra «flap» upstream-DNS.

7) Service discovery вне K8s

Consul: agente, health-check, diretório de serviços, interface DNS ('.consul'), KV para configs.
Eureka/ZooKeeper/etcd: registros para JVM/legacy; muitas vezes em conexão com sidecar/passarela.
Envoy/Istio: EDS/xDS (Endpoint Divulgação) e SDS (segredos); os serviços são anunciados por controle-plano.

8) Segurança DNS

DNSSEC: proteja a integridade dos registros (assinaturas de zonas). Crítica para domínios públicos.
DoT/DoH: encriptação do canal para o recorsor (políticas internas, compatibilidade).
ACL e split-horizonte: área privada - apenas VPC/VPN.
Proteção contra intoxicação por kesh: randomização de portas/ID, TTL curto para dinâmica.
Políticos no egress: autorize o DNS apenas para resenhas confiáveis, revista.

9) Comportamento dos clientes e retrai

Respeite a TTL: Não cante indefinidamente, não «deslize» com ressalvas frequentes (tempestade ao recorsor).
Happy Eyeballs (IPv4/IPv6), conectórios paralelos a vários A/AAAA reduzem o tail.
Retrai somente quando solicitações idumpotentes; jitter, limitação de 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

Reduza o TTL de 300→60 24 a 48 horas antes da mudança programada.
Mantenha o conjunto de endpoint canarinho com pouco peso para validação.
Aplique weighted + health-check em vez de gravações manuais em massa A.
Para estática/edge - Anycast; para API - Geo/Latency + rápido L7-feelover.

11) Observabilidade e SLO para o nome

• Rate/latency DNS, cachê hit-ratio, erros por tipo (SERVFAIL/NXDOMAIN).
• Proporção de solicitações com respostas stale (se você usar stale-cache).
• Êxito de operações personalizadas em trocas de registros (SLI).
• p95/p99 resolve-time em aplicativos.

• Relaxe o caminho: o cliente → o cachê local → nódoa → o resolver de cluster → o recorsor do provedor.
• Acompanhe os destaques NXDOMAIN (erros de nome/erro) e SERVFAIL (problemas de recorsor/recursos-limite).

12) Exemplos de configuração

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 (força resolvar 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 dinâmico-refresh

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

external-dns (suporte para área pública)

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

13) Folha de cheque de implementação (0-30 dias)

0-7 dias

Catálogo de nomes de serviço, seleção de modelo (cliente/server-side/híbrido).
TTL básico, incluir NodeLocal DNSCache, dashboards DNS.
A proibição de «IP rígido» no configh/código.

8 a 20 dias

Serviços Headless + SRV para gRPC; Está ativado.
GSLB/weighted para externos; health-checks e canário.
Timeouts/retrações de clientes configurados e orçamento de retrações.

21-30 dias

Split-horizonte e áreas privadas; DoT/DoH de política.
Teste de mudança (TTL) e feelover; pós-análise.
Políticas mesh/EDS, outlier-ejation incluídas.

14) Anti-pattern

TTL = 0 em venda → tempestade em recordes, atrasos imprevisíveis.
Hardcod IP/portas, sem CNAME/alíase para níveis.
Altere os registros manualmente sem health-checks ou canarinhos.
Uma ressalva global sem dinheiro em nódulos (espaço estreito).
Ignorar o cachê negativo (picos NXDOMAIN).
Tentar «tratar» a falha de banco de dados via DNS em vez do nível de dados/feelover.

15) Métricas de maturidade

100% dos serviços usam nomes; Casos nulos de hard-IP.
CoreDNS/NodeLocal em venda, cachê hit-ratio> 90% em nódulos.
GSLB com health-checks documentados por TTL e runbook de mudança.
SRV/EndpointSlice para stateful/gRPC, p99 resolve-time em aplicativos ≤ 20-30 ms.
Alertas por SERVFAIL/NXDOMAIN e degradação de cachê hit-ratio.
Verificações CI: proibição de 'latest' e hard-IP em listas/configs.

16) Conclusão

O Service Discovery é um contrato de nome estável e disciplina de cachê. Construa um modelo híbrido: DNS oferece uma entrada rápida e simples, L7/mesh - saúde e políticas inteligentes. Suporte TTL razoável, dinheiro em nódulos, serviços headless e SRV onde você quiser, use GSLB/Anycast para as fronteiras regionais, siga NXDOMAIN/SERVFAIL e p99 resolve-time. Então o seu nome será um bem confiável como o próprio serviço.